Re: removing an ext2fs file forces disk activity

[Niels Möller]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> Well, if this is possible we could just avoid syncing the blocks back to the
> store in the filesystem in the first place.  Thomas' point is exactly that
> to make the expected guarantees you can not cache the writes in any
> simplistic fashion:  You have dependencies between some writes, where you
> have to assert a special order of doing the write back (imagine the task
> crashes in the middle of such a store synchronization run).

Is it not good enough to maintain the order of the writes, updating
diskblocks in the same order as the corresponding write by the client?
If you want to reorder blocks more, say, trying to write blocks in the
order they are layed out on the disk, I guess you need some
dependencies or transaction boundaries or similar hairy things, *and*
the interfaces for the extra communication between the filesystem and
the store, but for simply delaying some writes I'd be susrprised if
one can't get away with something simpler.

One problem is that if the filesystem modifies block A, then block B,
and then block A again, then you may need to keep this ordering, and
not merge it as one write to A and one to B. Is the touch-rm-loop of
this kind? Then I guess the simple ordering breaks down.

> For each file, a memory object is created.  This is then vm_map'ed into the
> server task.  See ext2fs/pager.c, diskfs_get_filemap, and libpager.
> This is the kernel's external pager interface.  Whenever you access the
> vm_map'ed region and fault, the kernel will send a message to the pager (in
> libpager, linked into the servers address space).  This will then lead to
> pager_read_page being called, which is a callback function for libpager.
> If you look into ext2fs/pager.c, this will eventually call store_read.

Ah, thanks for the explanation. Are directories on disk treated just
like files, in this respect?

> Well, this is the interface used by the pager to read/write the underlying
> store data.  Note that the actual caching is done in the kernel
> (gnumach/vm/*).

Hmm, and this level of caching deals with for both caching reads and
delaying writes?

> There is also a synchronization interface (and the amount of
> synchronization done by the filesystem here is what started the
> discussion.

Syncronization is performed on a per-memory-object-basis, or per page? 

I think I'm starting to realize what the hair is about. The filesystem
wants ordered transactions on the store. And to give it that, without
updating the real disk blocks at transation boundaries, one needs to
maintain information about the transactions in the actual caching
code, in the kernel.

Does the block caches of modern unices deal with this syncronization
problem at all, or do they just leave it to fsck or to special
transactional file systems?

Regards,
/Niels