2009/3/25 Marius Gedminas <mar...@pov.lt>: > On Tue, Mar 24, 2009 at 07:51:38PM +0000, Matt Wheeler wrote: >> 2009/3/24 Timo Jyrinki <timo.jyri...@gmail.com>: >>> And the I/O problem comes from the hundreds/thousands of small files >>> that are inefficiently read. The amount of transferred data is not >>> that much that it would take more than 2-4s to read on modern even >>> laptop hard drives, if the data would be sequentially available in a >>> one big chunk. >> >> So if gconf used sqlite or something similar rather than >> ~/.gconf/blah/blah/blah/%gconf.xml, that would improve login times a >> lot? > > No. Sqlite likes to fsync(). Ext3 blocks the whole system when you > fsync(). Remember when Firefox 3 first appeared in Ubuntu? >
Bug in Ext3. Here's a proper fsync() flow for you: - write chunks of data [A] [B] [C] - Write data [D] - fsync() - Begin syncing [A] [B] [C] [D] to disk (with allocate-on-flush i.e. ext4, do that allocate) - Some program writes data [E], cache this as normal. - Write data [F] - fsync() while data [C] is still being written to disk - Extend current sync to include [D] [E] [F] (for AoF, re-allocate anything that you haven't started writing); start at the earliest piece of data if desired - etc etc etc In other words, when you flush (by fsync() or any other means), the kernel should internally snapshot what data is going to disk, do any allocation needed, and start writing it on the platters. Further writes to that or any other file should be accepted, and cached as normal. Flushes occuring during flushes (such as an fsync() on another file; an automatic write-out; a sync(); etc) should just update what's getting flushed to disk and continue on. The file system should not block the whole file system just because someone is flushing to disk. If you write file X and fsync(), I should be able to write more to file X, with the stipulation that the file as it existed when you called fsync() is going to disk now and my changes aren't yet. If you write file X and fsync(), I should be able to write file Y and even fsync() it if I want. If you call sync(), and a bunch of other files get written while that sync() happens, the file system should keep handling that stuff like normal and put it in cache until it's told to sync() again or decides the data's old and needs to go to disk-- even if that last sync() is still happening. Of course fsync() and sync() will still block as they normally do or don't, with the same stipulation. Just one call to fsync() might return before another call to fsync() (even an earlier one made on a much bigger file, depending on how the IO scheduler works). Maybe someone should look at how syncs work.... -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
