cedric briner wrote:
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.
This is wrong. The on-disk format is always consistent.
The author of this blog is misinformed and is probably getting
confused with traditional journalling.
That's why the ZIL flushes the cache.
The ZIL flushes it's blocks to ensure that if a power failure/panic occurs
then the data the system guarantees to be on stable storage (due say to a fsync
or O_DSYNC) is actually on stable storage.
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.
True, but not blocks, rather system call transactions - as this is what the
ZIL handles.
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.
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 ?
Eric's, who works on ZFS!
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.
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. UFS requires the write cache to be disabled to maintain consistency.
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 ?
I suppose but we aim to strive for better than expected corruption.
We (ZFS) recommend not disabling the ZIL.
We also recommend not disabling the disk write cache flushing unless they are
backed by nvram or UPS.
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
This works.
- Good questions.
Neil.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
