Partition device synchronisation

Partition device synchronisation

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hello, all. In GRUB we have tools to discover various parameters as to
how GRUB would see the disks on boot and for this we run the same code
as we have in boot time in userspace. So most natural for us would be
accessing whole disks like sda but unfortunately its cache isn't kept
synchronous with partitions (e.g. sda1), so if FS driver writes
something to sda1 it won't be visible through sda until pages are
dropped. Right now in Linux-specific code we try to find which partition
of sda starts at given sector (e.g. 2048) by trying all partition Linux
sees in order to read from sda1 rather than sda. The code is ugly and
sometimes create issues. So my questions are:
1) Do we have to issue some ioctl to reload those caches?
2) Is it considered a bug and should I plunge forward, fix it and send a
patch?

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Partition device synchronisation

[Jeff Moyer]

"Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com> writes:

> Hello, all. In GRUB we have tools to discover various parameters as to
> how GRUB would see the disks on boot and for this we run the same code
> as we have in boot time in userspace. So most natural for us would be
> accessing whole disks like sda but unfortunately its cache isn't kept
> synchronous with partitions (e.g. sda1), so if FS driver writes
> something to sda1 it won't be visible through sda until pages are
> dropped. Right now in Linux-specific code we try to find which partition
> of sda starts at given sector (e.g. 2048) by trying all partition Linux
> sees in order to read from sda1 rather than sda. The code is ugly and
> sometimes create issues. So my questions are:
> 1) Do we have to issue some ioctl to reload those caches?

You can issue the BLKFLSBUF ioctl.

> 2) Is it considered a bug and should I plunge forward, fix it and send a
> patch?

This is debatable.  See this thread:
  http://thread.gmane.org/gmane.linux.kernel/1241227/focus=1244202

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Partition device synchronisation

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On 11.05.2012 15:39, Jeff Moyer wrote:
> "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com> writes:
>
>> Hello, all. In GRUB we have tools to discover various parameters as to
>> how GRUB would see the disks on boot and for this we run the same code
>> as we have in boot time in userspace. So most natural for us would be
>> accessing whole disks like sda but unfortunately its cache isn't kept
>> synchronous with partitions (e.g. sda1), so if FS driver writes
>> something to sda1 it won't be visible through sda until pages are
>> dropped. Right now in Linux-specific code we try to find which partition
>> of sda starts at given sector (e.g. 2048) by trying all partition Linux
>> sees in order to read from sda1 rather than sda. The code is ugly and
>> sometimes create issues. So my questions are:
>> 1) Do we have to issue some ioctl to reload those caches?
> You can issue the BLKFLSBUF ioctl.
>
>> 2) Is it considered a bug and should I plunge forward, fix it and send a
>> patch?
> This is debatable.  See this thread:
>   http://thread.gmane.org/gmane.linux.kernel/1241227/focus=1244202
Thank you, it's all clear to me now. I'll make a patch based on this
information and ask the affected user to test it.
> Cheers,
> Jeff
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]