Le 23 oct. 08 à 05:40, Constantin Gonzalez a écrit : > Hi, > > Bob Friesenhahn wrote: >> On Wed, 22 Oct 2008, Neil Perrin wrote: >>> On 10/22/08 10:26, Constantin Gonzalez wrote: >>>> 3. Disable ZIL[1]. This is of course evil, but one customer >>>> pointed out to me >>>> that if a tar xvf were writing locally to a ZFS file system, >>>> the writes >>>> wouldn't be synchronous either, so there's no point in forcing >>>> NFS users >>>> to having a better availability experience at the expense of >>>> performance. >> >> The conclusion reached here is quite seriously wrong and no Sun >> employee should suggest it to a customer. If the system writing to a > > I'm not suggesting it to any customer. Actually, I argued quite a > long time > with the customer, trying to convince him that "slow but correct" is > better. > > The conclusion above is a conscious decision by the customer. He > says that he > does not want NFS to turn any write into a synchronous write, he's > happy if > all writes are asynchronous, because in this case the NFS server is > a backup to > disk device and if power fails he simply restarts the backup 'cause > he has the > data in multiple copies anyway. >
The case of a full backup (but not incremental) where an operator is monitoring that the server stays up for the full duration (or does the manual restart of the operation) seems like a singular case where this might make half sense. But as was stated, for performance which is the goal here, better use a bulk type transfer of data through some specific protocol (as opposed to NFS small file manipulations). What this creates is that failure of the server has immediate obvious repercusion on the client, and things can be restarted without further coordination. I understand also that with NFS directory delegation or Exclusive mount points one could solve this NFS peculiarity (which is totally unrelated to ZFS, and not to be confused with the ZFS / SAN storage cache flush condition). If CIFS is not subject to the same penalty, I can only assume that the integrity of the client's view cannot be guaranteed after a server crash. Anyone knows this for sure ? -r >> local filesystem reboots then the applications which were running are >> also lost and will see the new filesystem state when they are >> restarted. If an NFS server sponteneously reboots, the applications >> on the many clients are still running and the client systems are >> using >> cached data. This means that clients could do very bad things if the >> filesystem state (as seen by NFS) is suddenly not consistent. One of >> the joys of NFS is that the client continues unhindered once the >> server returns. > > Yes, we're both aware of this. In this particular situation, the > customer > would restart his backup job (and thus the client application) in > case the > server dies. > > Thanks for pointing out the difference, this is indeed an important > distinction. > > Cheers, > Constantin > > -- > Constantin Gonzalez Sun Microsystems > GmbH, Germany > Principal Field Technologist > http://blogs.sun.com/constantin > Tel.: +49 89/4 60 08-25 91 > http://google.com/search?q=constantin+gonzalez > > Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim- > Heimstetten > Amtsgericht Muenchen: HRB 161028 > Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland > Boemer > Vorsitzender des Aufsichtsrates: Martin Haering > _______________________________________________ > 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
