Re: Question regarding concurrent accesses through block device and fs

[Francis Moreau <francis.moro@gmail.com>]

Hello Nick,

Sorry for the long delay before my answer, but I don't have enough
time to dig the kernel source.

On Tue, Mar 3, 2009 at 4:52 AM, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> On Tuesday 03 March 2009 00:30:18 Francis Moreau wrote:
>> Nick Piggin <nickpiggin@yahoo.com.au> writes:
>> > On Monday 02 March 2009 08:07:30 Francis Moreau wrote:
>> >> This is the case where I can't find when the metadata are actually
>> >> written back to the disk by the flushers. I looked at
>> >> writback_inodes() but I fail to find this out.
>> >>
>> >> Could you point out the place in the code where this happen ?
>> >
>> > I guess it picks them up via their block device inodes.
>>
>> Probably but I don't find the actual place.
>
> It was an educated guess ;) I'm quite sure it does.
>

Ok I think I got the idea now. I though block device main purpose was
to handle block nodes such as /dev/sdx but it isn't.

>
>> I looked at the place where page are normally written back to disk (ie
>> in background_writeout()) but I can see only the writeback of data, not
>> metadata...
>
> What are you expecting writeback of metadata to look like? To the
> core kernel it looks the same as writeback of data.
>

I don't know. I was just thinking that since metadata are special since they
handle critical file system information, the kernel did treat them specially.

> But the cache layer on top of that ensures it *appears* not to be mixed
> up. A problem arises when the system crashes in the middle of this, and
> we lose that information and see a mixed up filesystem. Hence journalling
> filesystems.

Ok I guess I win a new tour in the kernel code ;) to understand how the cache
layer do that.

thanks a lot.
-- 
Francis