On Thu, Jul 17, 2014 at 02:04:50AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 14, 2014 at 09:09:13AM +0200, Iustin Pop wrote:
> > The xfsctl man page says that an extent size should be settable any time
> > on a directory, so why would this fail? Looking at the kernel sources,
> > I see a number of possible cases where EINVAL is returned:
>
> And no special casing for directories at all..
I was not sure if di_nextents is valid (tracks the extents number, and
hence can be non-zero for a directory), I'll take this as a
confirmation.
> > So to me this reads as if the di_nextents check can also fail for a
> > directory which has extents, contradicting the man page. Which one needs
> > to be updated?
> >
> > The question arises to if the extent size also applies, then, to
> > allocating extents for a directory - instead of just being inherited for
> > files (the man page says no).
>
> We're not using the extent size hint on the directory itself.
Aha, this is good to know.
> So to
> me it seems we just not check for already allocated blocks if we're
> setting the extent size on a directory, but instead maybe make sure
> the directory.
Not sure I parse that - do you mean we should either check for a
directory, or for zero extent count?
> What's also a little odd is that we allow setting
> the extent size on a directory even if the extent size inherit bit is
> not set, which doesn't make much sense to me.
Since the hint it is never used for directories, agreed it doesn't make
sense. Should this be an error (since I don't think warnings can be
reported).
> Do you want to prepare a patch to remove the check for directories?
> At testcase for xfstests that ensures this works also would be highly
> useful..
I'll try to. Is the tree against which I should sent the kernel patch at
git://oss.sgi.com/xfs/xfs?
thanks,
iustin
|