svn commit: r189967 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[John Baldwin]

On Monday 13 April 2009 3:56:34 pm Tim Kientzle wrote:
> John Baldwin wrote:
> > On Wednesday 18 March 2009 12:19:44 pm John Baldwin wrote:
> >> Author: jhb
> >> Date: Wed Mar 18 16:19:44 2009
> >> New Revision: 189967
> >> URL: http://svn.freebsd.org/changeset/base/189967
> >>
> >> Log:
> >>   The zfs_get_xattrdir() function is used to find the extended attribute
> >>   directory for a znode.  When the directory already exists, it returns a
> >>   referenced but unlocked vnode.  When a directory does not yet exist, it
> >>   calls zfs_make_xattrdir() to create a new one.  zfs_make_xattrdir() 
returns
> >>   the vnode both referenced and and locked and zfs_get_xattrdir() was 
leaking
> >>   this vnode lock to its callers.  Fix this by dropping the vnode lock if
> >>   zfs_make_xattrdir() successfully creates a new extended attribute
> >>   directory.
> > 
> > This should fix the panics with ZFS and tar + EA.
> 
> Thanks.
> 
> One point I'm curious about.    This problem was
> originally triggered by calls to extattr_list_fd().
> This seems to imply that any call to extattr_list_fd()
> will allocate an extended attribute directory if it
> doesn't already exist.
> 
> This is surprising.  It also raises questions about
> both performance (tar now does extattr_list_fd()
> for every file being archived) and operation
> with read-only mounts.

I'm not sure if it actually allocates space on disk or if it just allocates a 
virtual node to handle EA requests that only allocates disk space once it has 
at least one attribute to store.

-- 
John Baldwin