xfs_quota project + symlinks

xfs_quota project + symlinks

[Sten Spans]

This is with

root@backup:/root/backup# xfs_quota -V
xfs_quota version 2.8.11
root@backup:/backup# ln -s foo bar
root@backup:/backup# xfs_quota -x -c 'project -c 0'
Checking project 7 (path /backup)...
xfs_quota: cannot open /backup/bar: No such file or directory
Processed 1 /etc/projects paths for project 0

Would it be possible to handle symlinks better ?
Perhaps a check for symlinks in project.c ?

Re: xfs_quota project + symlinks

[Sten Spans]

On Thu, 26 Oct 2006, Sten Spans wrote:

>
> This is with
>
> root@backup:/root/backup# xfs_quota -V
> xfs_quota version 2.8.11
> root@backup:/backup# ln -s foo bar
> root@backup:/backup# xfs_quota -x -c 'project -c 0'
> Checking project 7 (path /backup)...
> xfs_quota: cannot open /backup/bar: No such file or directory
> Processed 1 /etc/projects paths for project 0
>
> Would it be possible to handle symlinks better ?
> Perhaps a check for symlinks in project.c ?

      86         if ((fd = open(path, O_RDONLY|O_NOCTTY)) == -1)
      87                 fprintf(stderr, _("%s: cannot open %s: %s\n"),
      88                         progname, path, strerror(errno));
      89         else if ((xfsctl(path, fd, XFS_IOC_FSGETXATTR, &fsx)) < 0)

If path is a symlink, then the project id is applied to a file
potentially on another filesystem. Wouldn't it be better to
add O_NOFOLLOW here ?

Re: xfs_quota project + symlinks

[Timothy Shimmin]

Hi,

--On 26 October 2006 3:45:59 PM +0200 Sten Spans <sten@blinkenlights.nl> wrote:

> On Thu, 26 Oct 2006, Sten Spans wrote:
>
>>
>> This is with
>>
>> root@backup:/root/backup# xfs_quota -V
>> xfs_quota version 2.8.11
>> root@backup:/backup# ln -s foo bar
>> root@backup:/backup# xfs_quota -x -c 'project -c 0'
>> Checking project 7 (path /backup)...
>> xfs_quota: cannot open /backup/bar: No such file or directory
>> Processed 1 /etc/projects paths for project 0
>>
>> Would it be possible to handle symlinks better ?
>> Perhaps a check for symlinks in project.c ?
>
>       86         if ((fd = open(path, O_RDONLY|O_NOCTTY)) == -1)
>       87                 fprintf(stderr, _("%s: cannot open %s: %s\n"),
>       88                         progname, path, strerror(errno));
>       89         else if ((xfsctl(path, fd, XFS_IOC_FSGETXATTR, &fsx)) < 0)
>
> If path is a symlink, then the project id is applied to a file
> potentially on another filesystem. Wouldn't it be better to
> add O_NOFOLLOW here ?
>
You want it to error out if it is a symlink.

I'm not familiar with O_NOFOLLOW. Looking at man page:
    If  pathname  is  a  symbolic  link, then the open fails.
    Symbolic links in earlier components of the pathname will still be followed.
So it would still allow you to follow onto another filesystem if part of the path
contained symlinks, by the look of it.
So I'm not sure that is what we want. Also this source is shared on IRIX and
I don't believe O_NOFOLLOW exists there.

I'm not that familiar with quotas (Nathan?, Donald?), but I would presume
that since symlinks take up space depending on the symlink path, that they should
have quota control on the space they take up.
In which case, one would actually not want to follow the symlink but rather
apply a limit to that actual symlink inode.
I don't know if this is the case though.

But I agree, I doubt one wants to follow the symlinks - it would get rather
confusing.

--Tim

Re: xfs_quota project + symlinks

[Sten Spans]

On Mon, 30 Oct 2006, Timothy Shimmin wrote:

> Hi,
>
> --On 26 October 2006 3:45:59 PM +0200 Sten Spans <sten@blinkenlights.nl> 
> wrote:
>
>> On Thu, 26 Oct 2006, Sten Spans wrote:
>> 
>> If path is a symlink, then the project id is applied to a file
>> potentially on another filesystem. Wouldn't it be better to
>> add O_NOFOLLOW here ?
>> 
> You want it to error out if it is a symlink.

Well It currently errors out for symlinks pointing to
nowhere, but it does follow working symlinks.

I am using project quota's on a backup server, and was thinking
of using xfs_quota -c to check quota weekly. But if xfs_quota
follows symlinks then quota are also applied to other filesystems.

> I'm not familiar with O_NOFOLLOW. Looking at man page:
>   If  pathname  is  a  symbolic  link, then the open fails.
>   Symbolic links in earlier components of the pathname will still be 
> followed.
> So it would still allow you to follow onto another filesystem if part of the 
> path
> contained symlinks, by the look of it.
> So I'm not sure that is what we want. Also this source is shared on IRIX and
> I don't believe O_NOFOLLOW exists there.
>
> I'm not that familiar with quotas (Nathan?, Donald?), but I would presume
> that since symlinks take up space depending on the symlink path, that they 
> should
> have quota control on the space they take up.
> In which case, one would actually not want to follow the symlink but rather
> apply a limit to that actual symlink inode.
> I don't know if this is the case though.
>
> But I agree, I doubt one wants to follow the symlinks - it would get rather
> confusing.

Indeed quota are normally filesystem specific,
following symlinks breaks this which creates unexpected situations.

-- 
Sten Spans

"There is a crack in everything, that's how the light gets in."
Leonard Cohen - Anthem

Re: xfs_quota project + symlinks

[Nathan Scott]

On Mon, 2006-10-30 at 15:39 +1000, Timothy Shimmin wrote:
> Hi,
> 
> > If path is a symlink, then the project id is applied to a file
> > potentially on another filesystem. Wouldn't it be better to
> > add O_NOFOLLOW here ?
> 
> You want it to error out if it is a symlink.
> 

Thats not ideal.  But some way to stay on the symlink's filesystem
is probably needed here, from the sound of it.

> I'm not that familiar with quotas (Nathan?, Donald?), but I would presume
> that since symlinks take up space depending on the symlink path, that they should
> have quota control on the space they take up.

If they require space to be allocated (i.e the symlink target is not 
stored in the inode literal area), then that space allocation will be
subject to quota IIRC.

> In which case, one would actually not want to follow the symlink but rather
> apply a limit to that actual symlink inode.

*nod*

> 
> But I agree, I doubt one wants to follow the symlinks - it would get rather
> confusing.

*nod*

cheers.

-- 
Nathan

Re: xfs_quota project + symlinks

[Timothy Shimmin]

Okay, thanks, Nathan,

So does that mean we need a way for FSGETXATTR and FSSETXATTR ioctls to
work on the symlink inode? Is this (symlink ioctls) done elsewhere? :)

One for Donald :)

--Tim

--On 31 October 2006 9:24:03 AM +1100 Nathan Scott <nscott@aconex.com> wrote:

> On Mon, 2006-10-30 at 15:39 +1000, Timothy Shimmin wrote:
>> Hi,
>>
>> > If path is a symlink, then the project id is applied to a file
>> > potentially on another filesystem. Wouldn't it be better to
>> > add O_NOFOLLOW here ?
>>
>> You want it to error out if it is a symlink.
>>
>
> Thats not ideal.  But some way to stay on the symlink's filesystem
> is probably needed here, from the sound of it.
>
>> I'm not that familiar with quotas (Nathan?, Donald?), but I would presume
>> that since symlinks take up space depending on the symlink path, that they should
>> have quota control on the space they take up.
>
> If they require space to be allocated (i.e the symlink target is not
> stored in the inode literal area), then that space allocation will be
> subject to quota IIRC.
>
>> In which case, one would actually not want to follow the symlink but rather
>> apply a limit to that actual symlink inode.
>
> *nod*
>
>>
>> But I agree, I doubt one wants to follow the symlinks - it would get rather
>> confusing.
>
> *nod*
>
> cheers.
>
> --
> Nathan

Re: xfs_quota project + symlinks

[Nathan Scott]

On Tue, 2006-10-31 at 11:08 +1000, Timothy Shimmin wrote:
> 
> Okay, thanks, Nathan,
> 
> So does that mean we need a way for FSGETXATTR and FSSETXATTR
> ioctls to work on the symlink inode? Is this (symlink ioctls)
> done elsewhere? :)

The by-handle interfaces xfsdump is using must support symlinks,
right?  So, I assume theres a way (but I don't know for sure).

cheers.

-- 
Nathan