On Sunday 12 April 2009 12:14:01 am Tim Kientzle wrote: > John Nielsen wrote: > > On Wednesday 11 March 2009 12:35:37 am Tim Kientzle wrote: > >> John Nielsen wrote: > >>> I today noticed the same problem on -CURRENT i386 built March 9. > >>> ... using ZFS and initially > >>> thought that was the source of the regression but I haven't > >>> produced the lockup with anything but tar and the extattr removal > >>> hack seems to have fixed it for now ... > >> > >> The common element so far seems to be ZFS. Can you verify that > >> > >> $ lsextattr -h user <filename> > >> > >> hangs on your system as well? That invokes the same > >> extattr_list_link system call used by tar to enumerate > >> the extended attributes on a file. > > > > Confirmed. I ran the command on a file in /root (UFS) with no > > problem. Running again on a file in /home/john (ZFS) caused the hang. > > John Baldwin committed a fix for the ZFS problem > (r189967, 2009-03-18 16:19:44UTC), so this should be fixed. > > Could you verify that lsextattr no longer hangs > the kernel after this point? > > Could you verify that re-enabling extended attribute > archiving in tar no longer hangs? > > I'd like to enable the extended attribute support > in tar for real if this is really fixed. Yes, I saw the commit and manually reverted libarchive to test on 3/20. I sent the post below but I don't know if it went through. Everything was solid then and has been since, so I think jhb's patch did the trick. JN ---------- Forwarded Message ---------- Subject: Re: repeatable ZFS panic: share->excl Date: Friday 20 March 2009 From: John Nielsen <lists_at_jnielsen.net> To: freebsd-current_at_freebsd.org On Wednesday 18 March 2009 12:09:18 pm John Baldwin wrote: > On Tuesday 17 March 2009 3:04:40 am Pawel Jakub Dawidek wrote: > > On Fri, Mar 13, 2009 at 02:08:03PM -0400, John Baldwin wrote: > > > John Baldwin wrote: > > > >Yes, I think that is the real bug. Looking at this further I > > > > think zfs_get_xattrdir() will return the vnode locked if it has > > > > to create a new node via zfs_make_attrdir() but only returns it > > > > held and unlocked if it finds an existing one. So my new patch > > > > is to just fix zfs_get_xattrdir() to unlock the vnode if it > > > > creates a new one like so: > > > > > > > >(Sorry, TBird is probably going to butcher all the whitespace): > > > > > > > >--- > > > >//depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_d > >ir.c > > > > > >+++ > > > >/Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs > >_dir.c > > > > > >_at__at_ -940,6 +940,7 _at__at_ > > > > /* NB: we already did dmu_tx_wait() if necessary */ > > > > goto top; > > > > } > > > >+ VOP_UNLOCK(*xvpp, 0); > > > > > > > > return (error); > > > > } > > > > > > > >A non-butchered version is at > > > > www.FreeBSD.org/~jhb/patches/zfs_ea.patch. > > > > > > So lulf_at_ reports success with this patch. Pawel, can you review > > > it? > > > > Yes, it works for me too and looks good. The only thing we need to > > change is to check for error beeing 0 before unlocking the vnode. > > The zfs_make_xattrdir() function can still return with EIO, so I'd > > add something like this: > > > > if (error == 0) > > VOP_UNLOCK(*xvpp, 0); > > Yes, I realized this about 30 minutes after I sent this e-mail. :-P I > will commit a version with the error check today. > > > Thank you John for spending time on tracking this one down. > > Sure, was good to read a bit of the ZFS code. I had a chance to test this patch today and it looks good. Which is to say my system hasn't hung yet. :) I built world from 3/19 -HEAD and was able to "lsextattr -h user" on files on a ZFS without any ill effects. I un-patched libarchive (so it uses extended attributes again) and rebuilt and reinstalled it and bsdtar and was able to do portupgrades normally. Thanks to all involved. JN -------------------------------------------------------Received on Sun Apr 12 2009 - 14:48:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:46 UTC