xfs
[Top] [All Lists]

Re: Setting project quotas on special files

To: xfs@xxxxxxxxxxx, Jeff Liu <jeff.liu@xxxxxxxxxx>
Subject: Re: Setting project quotas on special files
From: Tiziano Müller <tiziano.mueller@xxxxxxxxxxxxxxxxx>
Date: Sun, 10 Nov 2013 16:06:17 +0100
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <527F63FC.1050005@xxxxxxxxxx>
Organization: stepping stone GmbH
References: <1384069188.245087.68.camel@storm> <527F63FC.1050005@xxxxxxxxxx>
Reply-to: tiziano.mueller@xxxxxxxxxxxxxxxxx
Hi Jeff

Sorry for top-posting, but it may be better to illustrate this with an
isolated example:

I have a volume named "backup" mounted with option "pquota", then I do
the following inside that mountpoint:

localhost backup # mkdir test
localhost backup # ln -s /invalid/location test/symlinkA
localhost backup # echo 42:/var/backup/test >> /etc/projects
localhost backup # echo test:42 >> /etc/projid
localhost backup # xfs_quota -x -c 'project -s test' /var/backup
Setting up project test (path /var/backup/test)...
xfs_quota: skipping special file /var/backup/test/symlinkA
Processed 1 (/etc/projects and cmdline) paths for project test with recursion 
depth infinite (-1).
localhost backup # cp -al test/symlinkA test/symlinkB
cp: cannot create hard link "test/symlinkB" to "test/symlinkA": Invalid 
cross-device link
localhost backup # 

Creating a symlink after setting up project quotas in the same directory
yields a different behaviour:

localhost backup # ln -s /invalid/location test/symlinkC
localhost backup # cp -al test/symlinkC test/symlinkD
localhost backup # 

The following shows that a symlink alone (and not its target) can have a
project id assigned and that the project id must be assigned to be able
to create a hardlink of a symlink (no matter where it points to).

For each of the symlinks test/symlink{A,B} run `stat` to get the inode
then use xfs_db on that inode to get the attributes:

localhost backup #  xfs_db -r -c 'inode 4362' -c 'p' /dev/vdb1  | grep projid
core.projid_lo = 0
core.projid_hi = 0
localhost backup #  xfs_db -r -c 'inode 4363' -c 'p' /dev/vdb1  | grep projid
core.projid_lo = 42
core.projid_hi = 0

Unfortunately xfs_io tries to follow the symlinks so it can not be used
to set the project manually.

What works though is renaming the file:

localhost backup # mv test/symlinkA test/symlinkAtmp
localhost backup # mv test/symlinkAtmp test/symlinkA
localhost backup # stat test/symlinkA
  File: âtest/symlinkAâ -> â/invalid/locationâ
  Size: 17              Blocks: 0          IO Block: 4096   symbolic link
Device: fe11h/65041d    Inode: 4364        Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-11-10 15:49:44.870068178 +0100
Modify: 2013-11-10 15:49:44.870068178 +0100
Change: 2013-11-10 16:00:54.957571504 +0100
 Birth: -
localhost backup # xfs_db -r -c 'inode 4364' -c 'p' /dev/vdb1  | grep
projid
core.projid_lo = 42
core.projid_hi = 0
localhost backup # cp -al test/symlinkA test/symlinkB
localhost backup # 

Best regards,
Tiziano

Am Sonntag, den 10.11.2013, 02:46 -0800 schrieb Jeff Liu:
> On 11/10 2013 15:39 PM, Tiziano MÃller wrote:
> > Hi everyone
> >
> > It started with the following error:
> >
> >    dev # cp -al dvd dvd2
> >    cp: cannot create hard link âdvd2â to âdvdâ: Invalid cross-device link
> >
> > "dvd" is in this case a symlink (but I also did the test with special
> > devices).
> This definitely would fail if you trying to create hard links across
> volumes.
> >
> > What I did was: copy that symlink from somewhere else, trying to turn on
> > project quotas on a parent directoy of that "dev" directory which gives
> > me:
> >
> >   xfs_quota: skipping special file /var/foo/dev/dvd
> symlink files will be skipped and xfs_quota consider it as special file
> just like fifo, sock, etc...
> 
> If xfs_quota do check with follow symlinks, then the project id is potentially
> applied to files on another filesystem. 
> 
> >
> > When I examine the inode using xfs_db I get for my "dvd" symlink:
> >
> >   core.projid_lo = 0
> >   core.projid_hi = 0
> >
> > When I create a new symlink "foo" (with the same uid+gid as "dvd") and
> > examine it's inode using xfs_db:
> >
> >   core.projid_lo = 2398
> >   core.projid_hi = 61
> >
> > What I therefore seem to encounter is the problem mentioned in xfs_quota
> > for the project subcommand:
> >
> >   An attempt to create a hard link to a file in the tree will only succeed 
> > if the project identiâ
> >        fier matches the project identifier for the tree.
> >
> > I could now use xfs_io to fix all special files once (since newly
> > created ones will carry the project id directly), but why does
> > "xfs_quota -x -c 'project -s test1' /var" skip special files if it is
> > clearly possible and required to set the project id on them to have
> > hardlinks working again within the project dir?
> Sorry if I misunderstood your question, but the existing hard link files
> would
> notbe skipped IMO.  For the project subcommand, it means we could not create
> hardlinks cross different project trees.
> 
> Thanks,
> -Jeff
> 
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
stepping stone GmbH
Neufeldstrasse 9
CH-3012 Bern
Telefon: +41 31 332 53 63
www.stepping-stone.ch
tiziano.mueller@xxxxxxxxxxxxxxxxx

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