On Wed, 2009-01-21 at 09:12 -0500, Theodore Tso wrote: > On Wed, Jan 21, 2009 at 12:37:11PM +0000, Jamie Lokier wrote: > > > > What about btrfs with data checksums? Doesn't that count among > > data-retrieval metadata? What about nilfs, which always writes data > > to a new place? Etc. > > > > I'm wondering what exactly sync_file_range() definitely writes, and > > what it doesn't write. > > > > If it's just in use by Oracle, and nobody's sure what it does, that > > smacks of those secret APIs in Windows that made Word run a bit faster > > than everyone else's word processer... sort of. :-) > > Actually, I take that back; Oracle (and most other enterprise > databases; the world is not just Oracle --- there's also DB2, for > example) generally uses Direct I/O, so I wonder if they are using > sync_file_range() at all. Usually if they don't use O_DIRECT, they use O_SYNC. > > I do wonder though how well or poorly Oracle will work on btrfs, or > indeed any filesystem that uses WAFL-like or log-structutred > filesystem-like algorithms. Most of the enterprise databases have > been optimized for use on block devices and filesystems where you do > write-in-place acesses; and some enterprise databases do their own > data checksumming. So if I had to guess, I suspect the answer to the > question I posed is "disastrously". :-) Yes, I think btrfs' nodatacow option is pretty important for database use. > After all, such db's > generally are happiest when the OS acts as a program loader than then > gets the heck out of the way of the filesystem, hence their use of > DIO. > > Which again brings me back to the question --- I wonder who is > actually using sync_file_range, and what for? I would assume it is > some database, most likely; so maybe we should check with MySQL or > Postgres? Eric, didn't you have a magic script for grepping the sources/binaries in fedora for syscalls? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
