>>>>> "ck" == Christo Kutrovsky <kutrov...@pythian.com> writes: >>>>> "djm" == Darren J Moffat <darr...@opensolaris.org> writes: >>>>> "kth" == Kjetil Torgrim Homme <kjeti...@linpro.no> writes:
ck> The "never turn off the ZIL" sounds scary, but if the only
ck> consequences are 15 (even 45) seconds of data loss .. i am
ck> willing to take this for my home environment.
djm> You have done a risk analysis and if you are happy that your
djm> NTFS filesystems could be corrupt on those ZFS ZVOLs if you
djm> lose data then you could consider turning off the ZIL.
yeah I wonder if this might have more to do with write coalescing and
reordering within the virtualizing package's userland, though?
Disabling ZIL-writing should still cause ZVOL's to recover to a
crash-consistent state: so long as the NTFS was stored on a single
zvol it should not become corrupt. It just might be older than you
might like, right? I'm not sure it's working as well as that, just
saying it's probably not disabling the ZIL that's causing whatever
problems people have with guest NTFS's, right?
also, you can always rollback the zvol to the latest snapshot and
uncorrupt the NTFS. so this NEVER is probably too strong.
especially because ZFS recovers to txg's, the need for fsync() by
certain applications is actually less than it is on other filesystems
that lack that characteristic and need to use fsync() as a barrier.
seems silly not to exploit this.
>> I mean, there is no guarantee writes will be executed in order,
>> so in theory, one could corrupt it's NTFS file system.
kth> I think you have that guarantee, actually.
+1, at least from ZFS I think you have it. It'll recover to a txg
commit which is a crash-consistent point-in-time snapshot w.r.t. to
when the writes were submitted to it. so as long as they aren't
being reordered by something above ZFS...
kth> I think you need to reboot the client so that its RAM cache is
kth> cleared before any other writes are made.
yeah it needs to understand the filesystem was force-unmounted, and
the only way to tell it so is to yank the virtual cord.
djm> For what it's worth I personally run with the ZIL disabled on
djm> my home NAS system which is serving over NFS and CIFS to
djm> various clients, but I wouldn't recommend it to anyone. The
djm> reason I say never to turn off the ZIL is because in most
djm> environments outside of home usage it just isn't worth the
djm> risk to do so (not even for a small business).
yeah ok but IMHO you are getting way too much up in other people's
business, assuming things about them, by saying this. these dire
warnings of NEVER are probably what's led to this recurring myth that
disabling ZIL-writing can lead to pool corruption when it can't.
pgpI9mKkUHVuo.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
