>>>>> "sh" == Seth Heeren <s...@zfs-fuse.net> writes:
sh> If you don't want/need log or cache, disable these? You might
sh> want to run your ZIL (slog) on ramdisk.
seems quite silly. why would you do that instead of just disabling
the ZIL? I guess it would give you a way to disable it pool-wide
instead of system-wide.
A per-filesystem ZIL knob would be awesome.
sh> I beg your pardon? The crux with transaction logs is that they
sh> get _physically committed_ (and synced, that is) before
sh> writing the actual transaction so that the log will survive
sh> reboot and the transaction can be rolled back at reboot. This
sh> is crucial for atomicity/integrity.
No, it's crucial for durability. You'll have the other two even
without fsync(), so long as writes are never reordered. Unlike other
filesystems, AIUI ZFS never reorders writes (it always restores to a
TXG commit point, which are 5 - 30sec apart, but are point-in-time
snapshots so there's no reordering). Thus, even without the
persistent ZIL, the recovered system should be crash-consistent and
preserve ACI but not D of databases stored on it.
For an MTA accepting mail and promising the sender, ``I've durably
stored what you sent,'' it's a problem. For a distributed database
where nodes need to be in sync with each other, it's a problem. For
an NFS server where you don't want to have to reboot all the clients
when the server reboots, it's a problem. but for *corrupting* a
database, it's *not* a problem, and for two separate databases stored
in the same ZFS filesystem being in sync wrt each other (ex., an
sqlite3 database being in sync with the mbox it points to) it's also
*not* a problem.
makes sense?
pgpVtKF5dkjEL.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
