Marcus Brinkmann <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
