Messages in this thread | | | Subject | Re: Question regarding concurrent accesses through block device and fs | From | Francis Moreau <> | Date | Sun, 01 Mar 2009 22:07:30 +0100 |
| |
Nick Piggin <nickpiggin@yahoo.com.au> writes:
> On Monday 02 March 2009 01:42:55 Francis Moreau wrote:
[...]
> OK, the "buffercache", the cache of block device contents, is normally > thought of as metadata when it is being used by the filesystem (eg. > usually via bread() etc), or data when it is being read/written from > userspace via /dev/<blockdevice>. > > In the former case, the buffer.c/filesystem code together know when a > metadata buffer is unused (because the filesystem has deallocated it), > so unmap_underlying_metadata will work there. > > And it is insane to have a mounted filesystem and have userspace working > on the same block device, so unmap_underlying_metadata doesn't have to > care about that case. (IIRC some filesystem tools can do this, but there > are obviously a lot of tricks to it)
Thanks for clarifying this.
[...]
> Depends on the filesystem. Many do just use the buffercache as a > writeback cache for their metadata, and are happy to just let the > dirty page flushers write it out when it suits them
I guess you're talking about the pdflush threads here.
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 ?
> (or when there are explicit sync instructions given).
yes I see where this happens in these cases.
> Most of the time, these filesystems don't really know or care when > exactly their metadata is under writeback.
This sounds very weird to me but I need to learn how things work before doing any serious comments.
thanks -- Francis
| |