[Top] [All Lists]

Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_a

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_alias
From: Timothy Shimmin <tes@xxxxxxx>
Date: Tue, 21 Oct 2008 10:16:02 +1100
Cc: Miklos Szeredi <miklos@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20081020092346.GA14455@xxxxxxxxxxxxx>
References: <20081015192839.GA867@xxxxxx> <E1KqWzC-00087u-TG@xxxxxxxxxxxxxxxxxxx> <20081016180947.GA26285@xxxxxx> <48F7D814.2080705@xxxxxxx> <20081017171000.GC18582@xxxxxx> <48FBD5AB.6090306@xxxxxxx> <20081020092346.GA14455@xxxxxxxxxxxxx>
User-agent: Thunderbird (Macintosh/20080914)
Christoph Hellwig wrote:
> On Mon, Oct 20, 2008 at 11:49:47AM +1100, Timothy Shimmin wrote:
>>> I have to revamp that whole
>>> function anyway as it's extremly buggy in many ways, especially when
>>> used to open directories (can lead to multiple dentries for a single
>>> directory - ouch) and then I'll kill the other uses.
>> Oh ok.
>> In userspace,
>> we use it for opening directories on xfsdump via jdm_open in order to
>> do bulkstat driven dirent dumping.
>> We also use it in xfsrestore - though I am not convinced we should -
>> it was initially done for "performance" reasons apparently.
> I think the use of the API is fine, the problem is that the current
> implemention is buggy.
Yeah, I have no problem for xfsdump as it is driven by bulkstat
but for xfsrestore it seems unnecessary.
In fact, it can restore to other filesystems so it must only be using
this in certain ways on restore.
Having a look, yeah it is predicated by:
  if ( tranp->t_dstdirisxfspr )
and then just uses the fd for XFS_IOC_FSSETDM, XFS_IOC_FSSETXATTR
for those xfs-specific things and in the same function it uses
the path for non-xfs-specific: utime, chown, chmod
So it seems unnecessary to me in restore.


<Prev in Thread] Current Thread [Next in Thread>