Hi all,
I tried without success to get a working Btrfs+quota setup.
I created a new Btrfs filesystem on a new
partition, then activated quota management (''btrfs quota
enable''), and
created a few subvolumes.
I created a qgroup (with id 100) with ''btrfs qgroup create'',
and tried to
apply a quota on one of my subvolumes using ''btrfs qgroup
limit''
So far I''ve been unable to get this working, I can create a file (using
dd)
inside the subvolume that will happily eat all my FS space without triggering
anything that could look like a quota limitation.
btrfs-progs help is not really useful, it''s more like a quick reminder
than
a real ''help''.
So I have 2 questions for experimented Btrfs developers and users:
-Could someone post a working example of a quota configuration on 1 or
several subvolumes? Minimal/simplest working configuration.
-How can I see the used/remaining space for each subvolume that has a quota
set (I guess it should be done with ''btrfs qgroup show '' but
its output is
rather terse (returns ''0/100 0 0'' on my system).
Thanks in advance for your help, and all the work done to bring us so many
features.
--
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
On 08.10.2012 14:09, matthieu Barthélemy wrote:> Hi all, > > I tried without success to get a working Btrfs+quota setup. > I created a new Btrfs filesystem on a new > partition, then activated quota management (''btrfs quota enable''), and > created a few subvolumes. > I created a qgroup (with id 100) with ''btrfs qgroup create'', and tried to > apply a quota on one of my subvolumes using ''btrfs qgroup limit'' > > So far I''ve been unable to get this working, I can create a file (using dd) > inside the subvolume that will happily eat all my FS space without triggering > anything that could look like a quota limitation. > btrfs-progs help is not really useful, it''s more like a quick reminder than > a real ''help''. > So I have 2 questions for experimented Btrfs developers and users: > -Could someone post a working example of a quota configuration on 1 or > several subvolumes? Minimal/simplest working configuration.# mkfs.btrfs /dev/sdx WARNING! - Btrfs cloned-148-g8935d84 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label (null) on /dev/sdx nodesize 4096 leafsize 4096 sectorsize 4096 size 931.51GB Btrfs cloned-148-g8935d84 # mount /dev/sdx /mnt/test # btrfs quota enable /mnt/test # btrfs sub create /mnt/test/sub1 Create subvolume ''/mnt/test/sub1'' # dd if=/dev/zero of=/mnt/test/sub1/file1 bs=1048576 count=1 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 0.000873268 s, 1.2 GB/s # sync # btrfs qgroup show /mnt/test 0/257 1052672 1052672> -How can I see the used/remaining space for each subvolume that has a quota > set (I guess it should be done with ''btrfs qgroup show '' but its output is > rather terse (returns ''0/100 0 0'' on my system). >Right. 2 things to note: a) quota only shows up after some time. To enforce this, you can sync the fs. b) The output is too terse, some UI design is necessary here. The output means: qgroup references exclusive 0/257 1052672 1052672 Please refer here <http://sensille.com/qgroups.pdf> for a discussion of the meaning of those values. Your mistake was to create the group 0/100 yourself. The command qgroup create is only needed to create quota groups of subvolumes. To limit the subvol: # btrfs qgroup limit 2m /mnt/test/sub1 # dd if=/dev/zero of=/mnt/test/sub1/file1 bs=10485760 count=1 dd: writing `/mnt/test/sub1/file1'': Disk quota exceeded 1+0 records in 0+0 records out 1966080 bytes (2.0 MB) copied, 0.0056283 s, 349 MB/s Hope that helps :) -Arne> Thanks in advance for your help, and all the work done to bring us so many > features. > -- > 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-- 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
> On Mon, Oct 8, 2012 at 3:01 PM, Arne Jansen <sensille@gmx.net> wrote: >> >> >> Please refer here <http://sensille.com/qgroups.pdf> for a discussion of >> the >> meaning of those values.Thanks, I already read your paper a few days ago, but it was a quick reading in order to try to understand the concepts.>> Your mistake was to create the group 0/100 yourself. The command qgroup >> create is only needed to create quota groups of subvolumes.Yes, for me it wasn''t clear if one could create quotas without having first to play with qgroups explicitly. Thanks for pointing that out !>> >> To limit the subvol: >> >> # btrfs qgroup limit 2m /mnt/test/sub1 >> # dd if=/dev/zero of=/mnt/test/sub1/file1 bs=10485760 count=1 >> dd: writing `/mnt/test/sub1/file1'': Disk quota exceeded >> 1+0 records in >> 0+0 records out >> 1966080 bytes (2.0 MB) copied, 0.0056283 s, 349 MB/s >> >> Hope that helps :) >Totally :) Are there any plan to maybe get a better ''btrfs quota show'' output? Maybe with more details, maybe a simple '' 1 subvolume + all its snapshots'' accounting. Maybe I missed something, and I admit I didn''t read all the btrfs-progs patches related to qgroups, but there doesn''t seem to have an option to show a subvolume''s quota limit (not the referenced/exclusive usage counters). Am I right? Thanks again Arne for your help! -- 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
On 10/08/12 21:31, matthieu Barthélemy wrote:> > Are there any plan to maybe get a better ''btrfs quota show'' output?Definitely. The first priority was to get the kernel part running, when that is settled, we can improve the user mode part. There''s also still some work to do to make the tracking qgroups more presentable.> Maybe with more details, maybe a simple '' 1 subvolume + all its > snapshots'' accounting.Well, there''s no such thing as ''the snapshot of a subvolume''. As in btrfs each snapshot instantly is a subvolume in it''s own right. Btrfs doesn''t really keep track which snapshot is a descendant of which.> Maybe I missed something, and I admit I didn''t read all the btrfs-progs > patches related to qgroups, but there doesn''t seem to have an option to > show a subvolume''s quota limit (not the referenced/exclusive usage > counters). Am I right?Probably, I don''t remember :) That should be easy to fix anyway.> > Thanks again Arne for your help! > > >-- 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
On Mon, Oct 8, 2012 at 9:51 PM, Arne Jansen <sensille@gmx.net> wrote:> On 10/08/12 21:31, matthieu Barthélemy wrote: > >> >> Are there any plan to maybe get a better ''btrfs quota show'' output? > > Definitely. The first priority was to get the kernel part running, when > that is settled, we can improve the user mode part. There''s also still > some work to do to make the tracking qgroups more presentable. >Yes, and it seems to run well, I confirm that I was able to set a quota on a test subvolume and have it trigger as expected. But now I''m stuck again, though maybe the problem is as obvious as the one that made me post first... After having created a file that triggered a "quota exceeded" error, I created a snapshot of my subvolume. No problem here. Then I tried to remove the original ''big'' test file : rm: cannot remove `/btrfs/test/bigFile'': Disk quota exceeded I then tried to delete the snapshot subvol to see if it helped: # ./btrfs sub delete /btrfs/test/.snap1/ Delete subvolume ''/btrfs/test/.snap1'' # rm /btrfs/test/bigFile rm: cannot remove `/btrfs/roger/bigFile'': Disk quota exceeded # ./btrfs qgroup show /btrfs/ 0/257 1073725440 4096 0/261 1073725440 4096 261 was the snap that I just removed. Why is it still there? No problem, let''s remove it: # ./btrfs qgroup destroy 0/261 /btrfs/ # rm /btrfs/test/bigFile rm: cannot remove `/btrfs/test/bigFile'': Disk quota exceeded # ls -lsha /btrfs/test/ total 1.0G 0 drwxr-xr-x 1 root root 14 Oct 9 09:00 . 4.0K drwxr-xr-x 1 root root 10 Oct 8 19:56 .. 1.0G -rw-r--r-- 1 root root 1.0G Oct 8 19:58 bigFile I have to destroy my subvolume qgroup (0/257) to be able to ''rm'' my file. Is this the expected behavior? Of course I did something wrong again, but where? Thanks for your help, -- 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
On 09.10.2012 09:13, matthieu Barthélemy wrote:> On Mon, Oct 8, 2012 at 9:51 PM, Arne Jansen <sensille@gmx.net> wrote: >> On 10/08/12 21:31, matthieu Barthélemy wrote: >> >>> >>> Are there any plan to maybe get a better ''btrfs quota show'' output? >> >> Definitely. The first priority was to get the kernel part running, when >> that is settled, we can improve the user mode part. There''s also still >> some work to do to make the tracking qgroups more presentable. >> > Yes, and it seems to run well, I confirm that I was able to set a > quota on a test subvolume and have it trigger as expected. > > But now I''m stuck again, though maybe the problem is as obvious as the > one that made me post first... > After having created a file that triggered a "quota exceeded" error, I > created a snapshot of my subvolume. No problem here. > Then I tried to remove the original ''big'' test file : > > rm: cannot remove `/btrfs/test/bigFile'': Disk quota exceeded > > > I then tried to delete the snapshot subvol to see if it helped: > > # ./btrfs sub delete /btrfs/test/.snap1/ > Delete subvolume ''/btrfs/test/.snap1'' > # rm /btrfs/test/bigFile > rm: cannot remove `/btrfs/roger/bigFile'': Disk quota exceeded > > # ./btrfs qgroup show /btrfs/ > 0/257 1073725440 4096 > 0/261 1073725440 4096 > > 261 was the snap that I just removed. Why is it still there? >It may be that the corresponding qgroup does not get removed automatically with the subvol. So it''s not the subvol that''s still there, just the qgroup.> No problem, let''s remove it: > # ./btrfs qgroup destroy 0/261 /btrfs/ > > # rm /btrfs/test/bigFile > rm: cannot remove `/btrfs/test/bigFile'': Disk quota exceededDo you have a limit on 257?> > # ls -lsha /btrfs/test/ > total 1.0G > 0 drwxr-xr-x 1 root root 14 Oct 9 09:00 . > 4.0K drwxr-xr-x 1 root root 10 Oct 8 19:56 .. > 1.0G -rw-r--r-- 1 root root 1.0G Oct 8 19:58 bigFile > > > > I have to destroy my subvolume qgroup (0/257) to be able to ''rm'' my > file. Is this the expected behavior?In a way. You could just have raised the limit. The problem with cow filesystems is that a delete actually takes space, even if it gets freed afterwards when no snapshots are present. The quota code currently has no special handling for ''rm'', though it would obviously be useful. It is already on the TODO list. -Arne> Of course I did something wrong again, but where? > > Thanks for your help,-- 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