cedric briner writes: > > You might set zil_disable to 1 (_then_ mount the fs to be > > shared). But you're still exposed to OS crashes; those would > > still corrupt your nfs clients. > > > > -r > > hello Roch, > > I've few questions > > 1) > from: > Shenanigans with ZFS flushing and intelligent arrays... > http://blogs.digitar.com/jjww/?itemid=44 > I read : > Disable the ZIL. The ZIL is the way ZFS maintains _consistency_ until > it can get the blocks written to their final place on the disk. That's > why the ZIL flushes the cache. If you don't have the ZIL and a power > outage occurs, your blocks may go poof in your server's RAM...'cause > they never made it to the disk Kemosabe. >
_consistency_ above may not be the right technical term. It's more about data loss. If you fsync, then data needs to be somewhere; that's in the zil. > from : > Eric Kustarz's Weblog > http://blogs.sun.com/erickustarz/entry/zil_disable > I read : > Note: disabling the ZIL does _NOT_ compromise filesystem integrity. > Disabling the ZIL does NOT cause corruption in ZFS. > That is correct. ZIL or not, the pool stays self-consistent from ZFS standpoint. This means it will be mounted and there shall be no error then. But the application may not agree with this statement. Without a zil, I fsunc a file but the data is not there (data loss) after reboot. > then : > I don't understand: In one they tell that: > - we can lose _consistency_ > and in the other one they say that : > - does not compromise filesystem integrity > so .. which one is right ? > ZFS/ZPOOL is consistent with itself (zil not required for that) or the ZFS/ZPOOL is consistent with the posix requirement regarding fsync (ZIL required). > > 2) > from : > Eric Kustarz's Weblog > http://blogs.sun.com/erickustarz/entry/zil_disable > I read: > Disabling the ZIL is definitely frowned upon and can cause your > applications much confusion. Disabling the ZIL can cause corruption for > NFS clients in the case where a reply to the client is done before the > server crashes, and the server crashes before the data is commited to > stable storage. If you can't live with this, then don't turn off the ZIL. > > then: > The service that we export with zfs & NFS is not such things as > databases or some really stress full system, but just exporting home. So > it feels to me that we can juste disable this ZIL. > the problem is dealing with failure (as I explain in the "fine combination" entry). With zil disable, you would need to unmount on all clients that mounted a FS that is backed by a ZFS with zil disabled. Might as well have to reboot them. So reboot of the server implies tracking down all client mounts... NFS was never intended for that... > 3) > from: > NFS and ZFS, a fine combination > http://blogs.sun.com/roch/#zfs_to_ufs_performance_comparison > I read: > NFS service with risk of corruption of client's side view : > > nfs/ufs : 7 sec (write cache enable) > nfs/zfs : 4.2 sec (write cache enable,zil_disable=1) > nfs/zfs : 4.7 sec (write cache disable,zil_disable=1) > > Semantically correct NFS service : > > nfs/ufs : 17 sec (write cache disable) > nfs/zfs : 12 sec (write cache disable,zil_disable=0) > nfs/zfs : 7 sec (write cache enable,zil_disable=0) > > then : > Does this mean that when you just create an UFS FS, and that you just > export it with NFS, you are doing an not semantically correct NFS > service. And that you have to disable the write cache to have an correct > NFS server ??? > Yes. That is why all shipping Sun products had the disk write cache disabled. But with ZFS we are safe no matter what the setting. > 4) > so can we say that people used to have an NFS with risk of corruption of > client's side view can just take ZFS and disable the ZIL ? > It's your call. You were running UFS with third party storage that had the write cache enabled means your air bag was disabled. Now you got a new car and want to disable the air bag on that one to gain some performance. It's your data, your life. But if people start doing this on a large scale we're in for trouble. -r > > > > > thanks in advance for your clarifications > > Ced. > P.-S. Does some of you know the best way to send an email containing > many questions inside it ? Should I create a thread for each of them, > the next time > > Since there are related , this format looked fine to me. > > > > -- > > Cedric BRINER > Geneva - Switzerland > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
