>>>>> "enh" == Edward Ned Harvey <solar...@nedharvey.com> writes:

   enh> Dude, don't be so arrogant.  Acting like you know what I'm
   enh> talking about better than I do.  Face it that you have
   enh> something to learn here.

funny!  AIUI you are wrong and Casper is right.

ZFS recovers to a crash-consistent state, even without the slog,
meaning it recovers to some state through which the filesystem passed
in the seconds leading up to the crash.  This isn't what UFS or XFS
do.

The on-disk log (slog or otherwise), if I understand right, can
actually make the filesystem recover to a crash-INconsistent state (a
state not equal to a snapshot you might have hypothetically taken in
the seconds leading up to the crash), because files that were recently
fsync()'d may be of newer versions than files that weren't---that is,
fsync() durably commits only the file it references, by copying that
*part* of the in-RAM ZIL to the durable slog.  fsync() is not
equivalent to 'lockfs -fa' committing every file on the system (is
it?).  I guess I could be wrong about that.

If I'm right, this isn't a bad thing because apps that call fsync()
are supposed to expect the inconsistency, but it's still important to
understanding what's going on.

Attachment: pgpUNxWo30EYO.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to