Messages in this thread | | | Date | Thu, 12 Mar 2009 09:05:39 +0100 | Subject | Re: Question regarding concurrent accesses through block device and fs | From | Francis Moreau <> |
| |
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
| |