Ext3 and many other popular filesystems allow per-user and per-group quota. In some cases, a "per directory tree quota" is needed: doesn't matter who writes the files, limit a directory tree from growing to a size of more than X bytes.
As I see it, it can be good for many cases, either limiting a directory from exploding (Lior wrote about a similar problem a few weeks ago), or simply allocating space per team-projects on a file server.
As far as I knew, the only UNIX FS that implemented this feature was Sun's unpopular SAMFS/QFS. However, I've just stumbled upon this man page and was surprised to find out that the good old (well, at least old 🙂 ) XFS does that already!
A quick "howto use project quota" cookbook:
1. Make the filesystem and mount it:
> mkfs.xfs /dev/loop0
> mount /dev/loop0 /mnt/tmp -o pquota
2. Create a project named "project1", which is the "/mnt/tmp/tree1" tree:
> echo "11:/mnt/tmp/tree1" >> /etc/projects
> echo "project1:11" >> /etc/projid
> xfs_quota -x -c 'project -s project1' /mnt/tmp
3. Set the tree quota to 2 MB:
> xfs_quota -x -c 'limit -p bhard=2m project1' /mnt/tmp
4. That's it.. Now let's make some tests:
> dd if=/dev/zero of=/mnt/tmp/tree1/aaa count=10 bs=1024k
dd: writing `aaa': No space left on device
2+0 records in
1+0 records out2093056 bytes (2.1 MB) copied, 1.51164 s, 1.4 MB/s
> touch fdsa
touch: cannot touch `fdsa': Disk quota exceeded
5. And there's also a nice report! (looks nicer with a fixed-width console font)
> xfs_quota -x -c 'report /mnt/tmp'
Project quota on /mnt/tmp (/dev/loop0)
Blocks
Project ID      Used      Soft      Hard   Warn/Grace
---------- --------------------------------------------------
project1Â Â Â Â Â Â Â Â 2044Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â 2048Â Â Â Â 00 [--------]
project2Â Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â 0Â Â Â Â 00 [--------]
Can you give instructions on how to do the same for Ext3 (for those of us that have left XFS back then and haven't looked back since 😉 )?
Unfortunately it is not possible with ext3 and most other filesystems..
I was interested in doing this too. Of course, you can probably also create a loopback filesystem of fixed size. Then it doesn't matter what the filesystem is, for those who prefer to stick with ext3 or something. Obviously then though, you lose the disc space whether you use it or not.
> Of course, you can probably also create a loopback filesystem of fixed size. Then it doesn’t matter what the filesystem is, for those who prefer to stick with ext3 or something. Obviously then though, you lose the disc space whether you use it or not.
I think this would be better achieved using LVM. Set the storage device as a physical volume (PV), with one logical group (LG); then carve off each logical volume (LV) with as much space as you want from that group.
You get the same “space is allocated to that volume whether you use it or not†property, but you are using a mature system (LVM) which is well-supported by standard tools for adding, removing, re-sizing, and other management.
I recently implemented a little project to accomplish this. It uses FUSE and provides a transparent filesystem layer which should accept any directory on a POSIX-compliant filesystem as a basedir and will expose a quota-enabled filesystem through its mountpoint. Quotas can be set on arbitrary files or directories and since they are only represented as xattrs (user.quota), there can be a very very large number of quotas for a single mountpoint, unlike other solutions which typically involve creating virtual block devices. I've put it up on google code if anybody is curious http://code.google.com/p/fusequota/
Any feedback would be greatly appreciated!
Pingback: Anonymous
Hi.
This is not per directory quota. This is *per* *filesystem* quota. You are giving quota limits to the whole filesystem (which you are mointing on a subdirectory). But you won't be able to limit subdirectories with different quotas per user on the same XFS filesystem