Date: Mon, 22 Jun 2009 15:20:04 GMT From: Danny Braniss <danny@cs.huji.ac.il> To: freebsd-fs@FreeBSD.org Subject: Re: kern/135412: ZFS issue Message-ID: <200906221520.n5MFK4Xr014924@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/135412; it has been noted by GNATS. From: Danny Braniss <danny@cs.huji.ac.il> To: Gavin Atkinson <gavin@FreeBSD.org> Cc: bug-followup@FreeBSD.org Subject: Re: kern/135412: ZFS issue Date: Mon, 22 Jun 2009 17:53:44 +0300 > Other useful information (from PR kern/135039): > > This appears to only affect 7-STABLE since the ZFS merge, but doesn't > affect -HEAD. > > After the recent import of ZFS v13 into 7-STABLE, an mkstemp() call from > an NFS client to a ZFS-backed NFS server will fail: the syscall returns > EIO and the server will have created a 0-byte file with 000 permissions. > This breaks not just mktemp but also mv, tar, rsync... > > Kip Macy said there's a flags check that is too strict, in email message > <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> > Otherwise, use cp and rm instead of mv, or use scp instead of NFS, or > use UFS2 on the server > > To submitter: did you upgrade your on-disk pools to v13, or is running > the new code and v6 pools enough to show the problem? What is the > output of "zpool upgrade"? it happens ONLY because zfs is v13, irrelevant if the pools have been upgraded, created, or not upgraded. so yes, just running a newer -stable is enough to show the problem. Since I am using ZFS + NFS, and providing service to several hundred users, telling them not to use tar, svn, rsync, etc is not an option :-) also, NFS V2 is broken/un-maintained. danny >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906221520.n5MFK4Xr014924>