>>>>> "bf" == Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes:
bf> If ZFS does try to order its disk updates in cronological
bf> order without prioritizing metadata updates over data, then
bf> the risk is minimized.
AIUI it doesn't exactly order them, just puts them into 5-second
chunks. so it rolls the on-disk representation forward in lurching
steps every 5 seconds, and the boundaries between each step are exact
representations of how the filesystem once looked to the userland.
I do not udnerstand yet if fsync() will lurch forward the _entire_
filesystem, or just the inode being fsync()d. Unless i'm mistaken
``the property,'' as I described it, can only be achieved by lurching
forward the entire filesystem whenever you fsync anything because
otherwise you will recover to an overall state through which you never
passed before the crash (with the fsync'd file being a little newer),
but it might be faster/better to violate the property and only sync
what was asked.
If it's the entire filesystem, then it might improve performance to
separate unrelated heavy writers into different filesystems---for
example it would be better to put a tape-emulation backup directory
and a mail queue directory into separate filesystems even fi they have
to go in the same pool. If it breaks the property and only sync's the
inode asked, then two directories on one filesystem vs two filesystems
should not change performacne of that scenario which is an advantage.
pgpUAlxtcFBkB.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
