Quota Clarification

Quota Clarification

[Robert LeBlanc]

First off, thanks for the great work on btrfs. I've been trying to
follow the development for some time and now that Debian has
everything in Squeeze, I've been playing around with btrfs.

I would like to implement btrfs on a large file server that we are
currently using ACLs, user and group quotas and LVM snapshots. While
LVM is nice, it is just choking with as many snapshots as we have and
we need more. I took part of the EXT4 file system and copied it over
to a new partition to play with and was able to convert to btrfs
without problems. ACLs worked just fine which is great news.

I went to look at the quotas and repquota said that the mount point
doesn't have quotas enabled. I then searched for documentation about
quotas and it was pretty sparse. The only thing that I've found talked
about setting a quota for a subvolume by number of blocks. When I
toyed with ZFS, it had a similar quota system and from what I remember
reading, the devs were getting pressured to implement a quota system
like the previous file systems.

One thing I'm not sure how it will work is grace period and soft
quotas. It sure would be nice to have this feature with btrfs. The
same applies to checkquota were the owner can be e-mailed. Right now
we have one file system for home directories with user quotas and
another file system for group space with group quotas. We take
snapshots of these file systems and present them to the users as a
directory which Windows interprets as a Shadow Volume copy.

I thought it would be nice to have one btrfs file system and then
create two subvolumes with appropriate user or group quotas. I would
be able to snap the two subvolumes much like I do now. Since btrfs
does not snapshot subvolumes when a parent is snapped, if I have to
create a separate subvolume for each user or group I can see this
getting very hairy to manage when we have nearly a thousand users and
groups. Have the two subvolumes would give me great flexability to
reallocate space quickly.

Any insight would be helpful. I can't wait for btrfs to be stable, it
got lots of great potential.

Thanks,

Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University

Re: Quota Clarification

[Robert LeBlanc]

On Fri, Feb 26, 2010 at 8:51 PM, Robert LeBlanc <robert@leblancnet.us> wrote:
> First off, thanks for the great work on btrfs. I've been trying to
> follow the development for some time and now that Debian has
> everything in Squeeze, I've been playing around with btrfs.
>
> I would like to implement btrfs on a large file server that we are
> currently using ACLs, user and group quotas and LVM snapshots. While
> LVM is nice, it is just choking with as many snapshots as we have and
> we need more. I took part of the EXT4 file system and copied it over
> to a new partition to play with and was able to convert to btrfs
> without problems. ACLs worked just fine which is great news.
>
> I went to look at the quotas and repquota said that the mount point
> doesn't have quotas enabled. I then searched for documentation about
> quotas and it was pretty sparse. The only thing that I've found talked
> about setting a quota for a subvolume by number of blocks. When I
> toyed with ZFS, it had a similar quota system and from what I remember
> reading, the devs were getting pressured to implement a quota system
> like the previous file systems.
>
> One thing I'm not sure how it will work is grace period and soft
> quotas. It sure would be nice to have this feature with btrfs. The
> same applies to checkquota were the owner can be e-mailed. Right now
> we have one file system for home directories with user quotas and
> another file system for group space with group quotas. We take
> snapshots of these file systems and present them to the users as a
> directory which Windows interprets as a Shadow Volume copy.
>
> I thought it would be nice to have one btrfs file system and then
> create two subvolumes with appropriate user or group quotas. I would
> be able to snap the two subvolumes much like I do now. Since btrfs
> does not snapshot subvolumes when a parent is snapped, if I have to
> create a separate subvolume for each user or group I can see this
> getting very hairy to manage when we have nearly a thousand users and
> groups. Have the two subvolumes would give me great flexability to
> reallocate space quickly.
>
> Any insight would be helpful. I can't wait for btrfs to be stable, it
> got lots of great potential.
>

Another thing that I tried was to set a subvolume to a specified size,
but it changes the root and all other subvolumes to the same size. I
can understand how having subvolumes of differing sizes would be
beneficial, much like multiple logical volumes in an LVM volume group.
I fail to see the benefit of having a btrfs root fs that is less than
the disk or partition as the space can't be used for anything else. I
hope I'm just doing something wrong here.

Thanks,

Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University

Re: Quota Clarification

[Goffredo Baroncelli]

On Monday 01 March 2010, Robert LeBlanc wrote:
> On Fri, Feb 26, 2010 at 8:51 PM, Robert LeBlanc <robert@leblancnet.us> 
wrote:
> > First off, thanks for the great work on btrfs. I've been trying to
> > follow the development for some time and now that Debian has
> > everything in Squeeze, I've been playing around with btrfs.
> >
> > I would like to implement btrfs on a large file server that we are
> > currently using ACLs, user and group quotas and LVM snapshots. 

Pay attention that btrfs is under develop.

> > While
[...]
> > I went to look at the quotas and repquota said that the mount point
> > doesn't have quotas enabled. I then searched for documentation about
> > quotas and it was pretty sparse. 
AFICT quota is not available in btrfs.

[...]
> I fail to see the benefit of having a btrfs root fs that is less than
> the disk or partition as the space can't be used for anything else. I
> hope I'm just doing something wrong here.

A possible application is shrinking a filesystem, in case of change of hard 
disk.

> 
> Thanks,
> 
> Robert LeBlanc
> Life Sciences & Undergraduate Education Computer Support
> Brigham Young University
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512