Re: per-directory quotas possible on 5.x ?
From: Robert Watson (rwatson_at_freebsd.org)
Date: 06/30/03
- Previous message: Bill Paul: "Looking for RealTek 8169-based NIC for testing"
- In reply to: Josh Brooks: "per-directory quotas possible on 5.x ?"
- Next in thread: Josh Brooks: "Re: per-directory quotas possible on 5.x ?"
- Reply: Josh Brooks: "Re: per-directory quotas possible on 5.x ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 30 Jun 2003 14:39:07 -0400 (EDT) To: Josh Brooks <user@mail.econolodgetulsa.com>
On Sun, 29 Jun 2003, Josh Brooks wrote:
> Normally, quotas work on a per-user, per-filesystem basis - so if a user
> has a home directory and other processes _not owned by that user_ are
> placing files and using up space into that directory, it will not count
> toward the quota (unless they get chowned/chgrpd to that user/group).
>
> Is there any way to enforce a quota on a directory, regardless of what
> ownership or group ownership the files and dirs inside the directory -
> that is to say, take directory X, located at an arbitrary spot on the
> system, I want it to grow no larger than size Y.
>
> I know this can be done by creating a lot of little partitions - maybe
> even vn-backed parttion-on-file, but that seems like a hack, as they
> would be hard to resize.
>
> I am looking for a way to force a changeable quota on a directory,
> regardless of what gets put in it, or who owns what gets put in it.
>
> Any hacks/asuggestions/comments of any kind are very appreciated.
Unfortunately, the UFS file system model makes it difficult to implement
this sort of feature. One major part of this is that files can exist in
more than one directory at a time, by virtue of hard links; this in turn
is relied on for file system checking, where a file may end up linked to
more than one directory when certain failure modes occur and are recovered
from. Another part of the problem is that the internals of UFS really
disassociate the namespace from the storage mechanism, and since such a
"directory based quota system" would determine the relationship between
files based on the namespace and not a per-inode attribute, this also
makes implementing such a system on a UFS file system difficult. FWIW,
you can sometimes get similar semantics using group quotas and the fact
that, on BSD, entries created in directories have the group of the parent
directory in which they are created...
Most of the systems I've seen that do quotas on a large scale do basically
follow the "many volumes" model -- for example, large AFS cells may have
tens or hundreds of thousands of volumes, and use volume size to impose
quotas, which sounds like what you're looking for. When I've seen things
like this done on UFS, it's usually been as a weak consistency accounting
mechanism -- measure the size of various trees at intervals and bill based
on the sampled size, rather than block allocation.
As you may have noticed in trying the vn-backed mechanism, there are some
inefficiencies that turn up in FreeBSD when have large numbers of
pseudo-devices, etc. The resizing problem is real, also, since we don't
have online file system resizing. FWIW, a file system like HFS+ (which
has a much more strict directory hierarchy) would lend itself to directory
quotas much more. A port of HFS+ to FreeBSD was recently posted to
freebsd-fs.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Bill Paul: "Looking for RealTek 8169-based NIC for testing"
- In reply to: Josh Brooks: "per-directory quotas possible on 5.x ?"
- Next in thread: Josh Brooks: "Re: per-directory quotas possible on 5.x ?"
- Reply: Josh Brooks: "Re: per-directory quotas possible on 5.x ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
