On 04/10/2013 06:44 PM, Anand Avati wrote:
On Apr 10, 2013, at 2:50 PM, Brian Foster <address@hidden> wrote:
On 04/10/2013 03:06 PM, Anand Avati wrote:
On Apr 10, 2013, at 6:10 AM, Jeff Darcy <address@hidden> wrote:
Since XFS doesn't allow hard links across directory tree quota
boundaries - we get EXDEV, it would prevent gluster from creation
".glusterfs" directory entries. So Gluster quota does both accounting
and enforcing of quota.
Well, that's certainly an unfortunate consequence of using links instead
of a log to track dirty files. :( One more reason to undo that damage,
I suppose, but that's a different thread.
The problem here is with the gfid hard links (for providing stable file
handles). Index uses hard links from an internal backing file which is also
created within .glusterfs - the actual dirty files are never linked into index.
While we do want to make index use a different format, it is completely
unrelated (in fact not a problem at all) to the XFS quota issue - which is
linking of true files into .glusterfs for providing stable file handles.
I went looking into this behavior because I don't recall running into it
before. I can reproduce EXDEV if I try link from project quota A to
project quota B but it looks like this only enforced when the target
directory has project quota inheritance enabled (to prevent writing a
file somewhere and linking it into a directory under quota, XFS enforces
that the project quota IDs must match).
I can create a file under a project quota and link it out of the project
quota subtree without an error. So you could create a file under a
project quota and link it under .glusterfs, but not vice versa and not
into another directory covered by a project quota.
I suppose this would be a problem if we set a quota limit on the volume top
level, as .glusterfs is a subdirectory of the export directory?
I don't think it's a severe problem. Project quotas in XFS are tracked
via a project ID inode field, just like a uid or gid, only inherited via
parent directory. One could conceivably set a project ID on / and
recursively through every file and directory in the tree with the
exception of /.glusterfs (where / refers to brick root directory).
It gets a bit hairier if you want to support subquotas because you now
have to emulate subquota accounting/enforcement on top of traditional
project quota accounting (along with dealing with the management of
project IDs between subquotas and whatnot).
I'm sure there are other caveats as well, such as management of project
quotas across separate volumes on the same filesystem, etc., so I'm not
necessarily saying this is the way to go or not... ;)