From: "Tiziano Müller" <tiziano.mueller@stepping-stone.ch>
To: xfs@oss.sgi.com, Jeff Liu <jeff.liu@oracle.com>
Subject: Re: Setting project quotas on special files
Date: Sun, 10 Nov 2013 16:06:17 +0100 [thread overview]
Message-ID: <1384095977.245087.88.camel@storm> (raw)
In-Reply-To: <527F63FC.1050005@oracle.com>
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@oss.sgi.com
> 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@stepping-stone.ch
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-11-10 15:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-10 7:39 Setting project quotas on special files Tiziano Müller
2013-11-10 10:46 ` Jeff Liu
2013-11-10 15:06 ` Tiziano Müller [this message]
2013-11-11 6:43 ` Jeff Liu
2013-11-11 7:38 ` Tiziano Müller
2013-11-11 8:26 ` Jeff Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1384095977.245087.88.camel@storm \
--to=tiziano.mueller@stepping-stone.ch \
--cc=jeff.liu@oracle.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox