Arne Jansen
2011-Jul-10 08:21 UTC
[RFC] Subvolume Quota on-disk structures and configuration
Now that I''ve got a working prototype of subvolume quota, I''d
like to
get some feedback on the on-disk structure and the commands I intend
to use.
As a short name, I propose qgroups, as the most distinguishing feature
of this implementation is that you can not only put a quota on sub-
volumes, but also on groups of subvolumes, and even on groups of
groups. You can build a hierarchy that can, but not necessarily have to,
reflect the filesystem hierarchy.
There are two main numbers where you can put a quota on, the
''referenced'' and the ''exclusive'' count.
''Referenced'' means the full
amount of data a subvolume or group contains, no matter if it''s also
shared with other subvolumes (e.g. snapshots) or not.
''Exclusive'' on the
other hand means the amount of data for which _all_ references can be
reached from this subvolume or group. In case of a subvolume,
''exclusive'' is just the amount of space that will be freed if
you delete
the subvolume. I''ll explain this in more detail when I send the patch.
But now to the on-disk structure. All quota related configuration go
into a separate tree, the quota tree:
#define BTRFS_QUOTA_TREE_OBJECTID 8ULL
4 new keys get introduced for that:
/*
* Records the overall state of the qgroups.
* There''s only one instance of this key present,
* (0, BTRFS_QGROUP_STATUS_KEY, 0)
*/
#define BTRFS_QGROUP_STATUS_KEY 240
/*
* Records the currently used space of the qgroup.
* One key per qgroup, (0, BTRFS_QGROUP_INFO_KEY, qgroupid).
*/
#define BTRFS_QGROUP_INFO_KEY 242
/*
* Contains the user configured limits for the qgroup.
* One key per qgroup, (0, BTRFS_QGROUP_LIMIT_KEY, qgroupid).
*/
#define BTRFS_QGROUP_LIMIT_KEY 244
/*
* Records the child-parent relationship of qgroups. For
* each relation, 2 keys are present:
* (childid, BTRFS_QGROUP_RELATION_KEY, parentid)
* (parentid, BTRFS_QGROUP_RELATION_KEY, childid)
*/
#define BTRFS_QGROUP_RELATION_KEY 246
The keys are chosen in a way that first comes the STATUS_KEY,
followed by all INFO_KEYs, followed by all LIMIT_KEYs.
After that, for each qgroup present all relations follow.
Only the INFO_KEYs and the STATUS_KEY get updated regularly.
The idea is that those keys stay close to each other, to
minimize writes. The RELATION_KEY is chosen in a way that by
a simple enumeration all children and parents for a given
qgroup can be found.
The qgroupid is composed of a 16 bit ''level'' field, followed
by
a 48 bit ''id'' field. Currently, a qgroupid is represented as
level/id, e.g. 2/100, but that is subject to discussion. In the
case of a subvolume, the level is 0, and the ''id'' is just the
internal tree objectid (5 or >= 256). On the command line, the
user will be able to use the subvolume-path as the identifier.
/*
* is subvolume quota turned on?
*/
#define BTRFS_QGROUP_STATUS_FLAG_ON (1ULL << 0)
/*
* SCANNING is set during the initialization phase
*/
#define BTRFS_QGROUP_STATUS_FLAG_SCANNING (1ULL << 1)
/*
* Some qgroup entries are known to be out of date,
* either because the configuration has changed in a way that
* makes a rescan necessary, or because the fs has been mounted
* with a non-qgroup-aware version.
* Turning qouta off and on again makes it inconsistent, too.
*/
#define BTRFS_QGROUP_STATUS_FLAG_INCONSISTENT (1ULL << 2)
#define BTRFS_QGROUP_STATUS_VERSION 1
struct btrfs_qgroup_status_item {
__le64 version;
/*
* the generation is updated during every commit. As older
* versions of btrfs are not aware of qgroups, it will be
* possible to detect inconsistencies by checking the
* generation on mount time
*/
__le64 generation;
/* flag definitions see above */
__le64 flags;
/*
* only used during scanning to record the progress
* of the scan. It contains a logical address
*/
__le64 scan;
} __attribute__ ((__packed__));
Instead of hosting the scan cursor in the structure, one could
also make a separate key instead that is only present during
scanning.
struct btrfs_qgroup_info_item {
/*
* only updated when any of the other values change
*/
__le64 generation;
__le64 referenced;
__le64 referenced_compressed;
__le64 exclusive;
__le64 exclusive_compressed;
} __attribute__ ((__packed__));
For all uncompressed data the same value will be recorded for
compressed and uncompressed. The *_compressed values represent
the amount of disk space used, the other values the amount of
space from a user perspective. Another way to name these members
might be *_ram and *_disk.
The uncompressed values are hard to get, so a first version
might not support them yet and just record the on-disk values
instead.
/* flags definition for qgroup limits */
#define BTRFS_QGROUP_LIMIT_MAX_REFERENCED (1ULL << 0)
#define BTRFS_QGROUP_LIMIT_MAX_EXCLUSIVE (1ULL << 1)
#define BTRFS_QGROUP_LIMIT_RSV_REFERENCED (1ULL << 2)
#define BTRFS_QGROUP_LIMIT_RSV_EXCLUSIVE (1ULL << 3)
#define BTRFS_QGROUP_LIMIT_REFERENCED_COMPRESSED (1ULL << 4)
#define BTRFS_QGROUP_LIMIT_EXCLUSIVE_COMPRESSED (1ULL << 5)
struct btrfs_qgroup_limit_item {
__le64 flags;
__le64 max_referenced;
__le64 max_exclusive;
__le64 rsv_referenced;
__le64 rsv_exclusive;
} __attribute__ ((__packed__));
The flags record which of the limits are to be enforced. The last
two flags indicate whether the compressed or the uncompressed value
is to limit.
This structure also contains reservations, though they might be hard to
implement, as btrfs has no clear understanding of how much free space
is left. A straightforward implementation might be very inaccurate and
the first version will probably not implement it. I nevertheless
included those values here as a means for future expansion.
As you can see some of the identifiers are quite lengthy, and it gets
worse when the corresponding set/get functions are defined. I''m
thinking about abbreviating all identifiers with:
qgrp - qgroup
rfer - referenced
excl - exclusive
cmpr - compressed
Now to the command line extension.
btrfs quota enable <path>
This enables the qgroup support and creates the quota tree. The quota
will be in an inconsistent state until a rescan is started (and com-
pleted).
btrfs quota disable [--cleanup] <path>
Disables quota support, but leaves the tree in place. An additional
--cleanup also deletes the tree, and with it the configuration info.
btrfs quota rescan <path>
Start a full rescan of the filesystem. This is necessary after some
configuration changes, after the initial creation and after the fs
has been mounted with an older version of btrfs.
btrfs qgroup show <path>
Shows the current configuration and used space info. Not sure on this
one yet, it will probably get split in multiple commands and get some
options to limit the output.
btrfs qgroup limit [--exclusive] <size>|none <qgroupid> <path>
This sets actual limits on a qgroup. If --exclusive is given, the
exclusive usage is limited instead of the referenced. I don''t know
if there are use cases where both values need a (possibly different)
limit. <path> means the path to the root. Instead of
"<qgroupid>
<path>", a path to a subvolume can be given instead.
btrfs qgroup create <qgroupid> <path>
btrfs qgroup destroy <qgroupid> <path>
btrfs qgroup assign <childid> <parentid> <path>
btrfs qgroup remove <childid> <parentid> <path>
These 4 commands are used to build hierarchical qgroups and are only
for advanced users. I''ll explain more of the concepts in a later
paper.
The main point here is that in the simplest case, a user creates a
filesystem with initial quota support, creates his /var /usr /home
etc. subvolumes and limits them with commands like
btrfs qgroup limit 10g /usr
That should be simple enough for the common use case.
-Arne
--
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
Arne Jansen <sensille <at> gmx.net> writes:> > These 4 commands are used to build hierarchical qgroups and are only > for advanced users. I''ll explain more of the concepts in a later > paper. > > The main point here is that in the simplest case, a user creates a > filesystem with initial quota support, creates his /var /usr /home > etc. subvolumes and limits them with commands like > > btrfs qgroup limit 10g /usr > > That should be simple enough for the common use case. > > -Arne > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo <at> vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >Hello Arne, There are some discussion in mailling list topic "What to do about subvolumes". It is copy-on-write quota counting. One is charged the quota as physical blocks count. Another is charged as how much the user looks like. Both of them have different limitation. What solution would you use? The topic you mentioned is what I need. How is your btrfs quota implementation progress? You could release your patch for me if possible, I can join your idea, design and implementation. I have large disk array for testing. Best regards, Yeh. -- 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
Arne Jansen
2011-Aug-24 07:53 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 24.08.2011 09:26, Yeh wrote:> Arne Jansen <sensille <at> gmx.net> writes: > >> >> These 4 commands are used to build hierarchical qgroups and are only >> for advanced users. I''ll explain more of the concepts in a later >> paper. >> >> The main point here is that in the simplest case, a user creates a >> filesystem with initial quota support, creates his /var /usr /home >> etc. subvolumes and limits them with commands like >> >> btrfs qgroup limit 10g /usr >> >> That should be simple enough for the common use case. >> >> -Arne >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo <at> vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > Hello Arne, > > There are some discussion in mailling list topic "What to do about subvolumes". > It is copy-on-write quota counting. > One is charged the quota as physical blocks count. > Another is charged as how much the user looks like. > Both of them have different limitation. > What solution would you use?I have written an earlier mail to sketch out what I intend to implement. I don''t quite understand the 2 counting methods you refer to, but maybe that earlier mails helps (Subject: Quota Implementation). If not, I can try to describe in more detail what I implement. Most probably it will meet your need, unless you expect user quota :)> > The topic you mentioned is what I need. How is your btrfs quota implementation > progress? You could release your patch for me if possible, I can join your idea, > design and implementation. I have large disk array for testing. >Still fighting against delayed refs... it might take a few weeks until I have the first reasonably stable and cleaned-up version. -Arne> Best regards, > Yeh. > > > -- > 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
Phillip Susi
2011-Nov-21 16:06 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 7/10/2011 4:21 AM, Arne Jansen wrote:> btrfs qgroup limit [--exclusive] <size>|none <qgroupid> <path> > > This sets actual limits on a qgroup. If --exclusive is given, the > exclusive usage is limited instead of the referenced. I don''t know > if there are use cases where both values need a (possibly different) > limit. <path> means the path to the root. Instead of "<qgroupid> > <path>", a path to a subvolume can be given instead. > > btrfs qgroup create <qgroupid> <path> > btrfs qgroup destroy <qgroupid> <path> > btrfs qgroup assign <childid> <parentid> <path> > btrfs qgroup remove <childid> <parentid> <path> > > These 4 commands are used to build hierarchical qgroups and are only > for advanced users. I''ll explain more of the concepts in a later > paper. > > The main point here is that in the simplest case, a user creates a > filesystem with initial quota support, creates his /var /usr /home > etc. subvolumes and limits them with commands like > > btrfs qgroup limit 10g /usr > > That should be simple enough for the common use case.Wouldn''t that make the syntax above actually be: btrfs qgroup limit [--exclusive] <size|none> [qgroupid] <path> Since the qgroupid is optional? And the meaning of path depends on whether or not qgroupid is specified. With qgroupid, path is anywhere on the fs, but without it, it specifies the path of the implicit qgroupid, right? I also have a question about the interactions with groups of groups. Say I have 4 subvolumes: 1, 2, 3, and Z. I group the first 3 volumes and set a limit on them. Now if all 3 volumes share a chunk of space, that space should only count towards the group once, rather than 3 times. You might think the solution to that is to use the exclusive limits, but that would mean that any space volume 3 and volume Z share would not be counted in the group at all. I don''t care about volume Z since it is not part of the group, yet it can influence the used space of the group. Likewise, if I set an exclusive limit on the group, and then create snapshot Y from subvol 2, that would significantly reduce the exclusive charge for the group, and we don''t want that. -- 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
Arne Jansen
2011-Nov-21 17:20 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 11/21/2011 05:06 PM, Phillip Susi wrote:> On 7/10/2011 4:21 AM, Arne Jansen wrote: >> btrfs qgroup limit [--exclusive] <size>|none <qgroupid> <path> >> >> >> btrfs qgroup limit 10g /usr >> >> That should be simple enough for the common use case. > > Wouldn''t that make the syntax above actually be: > > btrfs qgroup limit [--exclusive] <size|none> [qgroupid] <path>You don''t mean to actually changing the syntax, but adding a better explanation or a more precise usage?> > Since the qgroupid is optional? And the meaning of path depends on > whether or not qgroupid is specified. With qgroupid, path is anywhere > on the fs, but without it, it specifies the path of the implicit > qgroupid, right? > > I also have a question about the interactions with groups of groups. Say > I have 4 subvolumes: 1, 2, 3, and Z. I group the first 3 volumes and > set a limit on them. Now if all 3 volumes share a chunk of space, that > space should only count towards the group once, rather than 3 times.It''s just what groups are made for. In your scenario the chunk of space would count only once. Some hopefully better explanation can be found at http://sensille.com/qgroups.pdf Have you already played with the patchset? -Arne> You might think the solution to that is to use the exclusive limits, but > that would mean that any space volume 3 and volume Z share would not be > counted in the group at all. I don''t care about volume Z since it is > not part of the group, yet it can influence the used space of the > group. Likewise, if I set an exclusive limit on the group, and then > create snapshot Y from subvol 2, that would significantly reduce the > exclusive charge for the group, and we don''t want that. > -- > 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
Phillip Susi
2011-Nov-21 18:29 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 11/21/2011 12:20 PM, Arne Jansen wrote:> On 11/21/2011 05:06 PM, Phillip Susi wrote: >> On 7/10/2011 4:21 AM, Arne Jansen wrote: >>> btrfs qgroup limit [--exclusive]<size>|none<qgroupid> <path> >>> >>> >>> btrfs qgroup limit 10g /usr >>> >>> That should be simple enough for the common use case. >> >> Wouldn''t that make the syntax above actually be: >> >> btrfs qgroup limit [--exclusive]<size|none> [qgroupid]<path> > > You don''t mean to actually changing the syntax, but adding a better > explanation or a more precise usage?What I mean is that your syntax listed <groupid> in angle brackets, indicating that it is a required argument, but your description seems to indicate that it is optional, so it should be in square brackets. Also the size bit I assume was meant to be a required parameter that should be either a number or the word none, so the angle brackets should enclose the |none part too.>> I also have a question about the interactions with groups of groups. Say >> I have 4 subvolumes: 1, 2, 3, and Z. I group the first 3 volumes and >> set a limit on them. Now if all 3 volumes share a chunk of space, that >> space should only count towards the group once, rather than 3 times. > > It''s just what groups are made for. In your scenario the chunk of space > would count only once. Some hopefully better explanation can be found atOhh, so the group is a union of the chunks in the members, not a sum? So if you set an exclusive limit on the group, that would count everything shared between 1, 2, 3 once, and not count any shared with Z? In other words, --exclusive excludes space shared with things outside the group, not within it?> http://sensille.com/qgroups.pdf > > Have you already played with the patchset?Not yet; I just found it today from the new thread on the subject, and look forward to playing with it tonight. I was wondering what revision the patches are based on, and are they in a public git repo? -- 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
Arne Jansen
2011-Nov-21 20:15 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
[I accidentally failed to include the list in the previous reply] On 11/21/2011 07:51 PM, Arne Jansen wrote:> On 11/21/2011 07:29 PM, Phillip Susi wrote: >> On 11/21/2011 12:20 PM, Arne Jansen wrote: >>> On 11/21/2011 05:06 PM, Phillip Susi wrote: >>>> On 7/10/2011 4:21 AM, Arne Jansen wrote: >>>> I also have a question about the interactions with groups of groups. Say >>>> I have 4 subvolumes: 1, 2, 3, and Z. I group the first 3 volumes and >>>> set a limit on them. Now if all 3 volumes share a chunk of space, that >>>> space should only count towards the group once, rather than 3 times. >>> >>> It''s just what groups are made for. In your scenario the chunk of space >>> would count only once. Some hopefully better explanation can be found at >> >> Ohh, so the group is a union of the chunks in the members, not a sum? So >> if you set an exclusive limit on the group, that would count everything >> shared between 1, 2, 3 once, and not count any shared with Z? In other >> words, --exclusive excludes space shared with things outside the group, >> not within it? > > Right. I think I haven''t implemented limiting exclusive yet, but that''s > no big deal, if you have a use case for it. Tracking of exclusive is > implemented.Just looked at the source, it is implemented :)>> >> Not yet; I just found it today from the new thread on the subject, and >> look forward to playing with it tonight. I was wondering what revision >> the patches are based on, and are they in a public git repo? > > I can rebase it to the current for-linus and push it out later today. >git://git.kernel.org/pub/scm/linux/kernel/git/arne/linux-btrfs.git qgroups just waiting for the replication to the mirrors... -- 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
Phillip Susi
2011-Nov-22 15:04 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 11/21/2011 3:15 PM, Arne Jansen wrote:>> I can rebase it to the current for-linus and push it out later today. >> > > git://git.kernel.org/pub/scm/linux/kernel/git/arne/linux-btrfs.git qgroups > > just waiting for the replication to the mirrors...What about the btrfs-progs changes to add the commands? -- 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
Hugo Mills
2011-Nov-22 15:07 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On Tue, Nov 22, 2011 at 10:04:05AM -0500, Phillip Susi wrote:> On 11/21/2011 3:15 PM, Arne Jansen wrote: > >>I can rebase it to the current for-linus and push it out later today. > >> > > > >git://git.kernel.org/pub/scm/linux/kernel/git/arne/linux-btrfs.git qgroups > > > >just waiting for the replication to the mirrors... > > What about the btrfs-progs changes to add the commands?Those should be waiting in the integration tree at [1]. Hugo. [1] http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Doughnut furs ache me, Omar Dorlin. ---
Phillip Susi
2011-Nov-26 04:14 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/2011 04:21 AM, Arne Jansen wrote:> Now that I''ve got a working prototype of subvolume quota, I''d like > to get some feedback on the on-disk structure and the commands I > intend to use.I think I''ve noticed a bug so far, and have one comment on the qgroup show command. The command seems to show the current usage of the qgroup, but I can''t see how to view the limits ( if any ). It seems like the show command should show both. The bug I seem to have noticed is that rm fails with EQUOTA. I set a 1g limit on a new subvol, and ran dd if=/dev/zero of=/mnt/foo, which created a file approx 1g in size before erroring out with EQUOTA. After that, I did an echo bar /mnt/bar, and to my surprise, this did not fail with EQUOTA. Now when I try to rm /mnt/bar or /mnt/foo, THAT fails with EQUOTA. I also got this in dmesg: [ 992.078275] WARNING: at fs/btrfs/inode.c:6670 btrfs_destroy_inode+0x31d/0x360 [btrfs]() [ 992.078276] Hardware name: System Product Name [ 992.078277] Modules linked in: nls_utf8 isofs bnep rfcomm kvm_intel kvm parport_pc ppdev dm_crypt binfmt_misc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event joydev snd_seq psmouse eeepc_wmi asus_wmi snd_timer snd_seq_device btusb bluetooth serio_raw snd sparse_keymap soundcore mei(C) snd_page_alloc w83627ehf hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor async_memcpy async_raid6_recov raid6_pq async_tx raid1 raid0 multipath linear dm_raid45 xor dm_mirror dm_region_hash dm_log btrfs zlib_deflate libcrc32c hid_microsoft usbhid hid mxm_wmi wmi radeon ahci libahci ttm drm_kms_helper e1000e xhci_hcd drm i2c_algo_bit zram(C) [ 992.078305] Pid: 2342, comm: rm Tainted: G C 3.2.0-rc2+ #7 [ 992.078306] Call Trace: [ 992.078311] [<ffffffff81062acf>] warn_slowpath_common+0x7f/0xc0 [ 992.078313] [<ffffffff81062b2a>] warn_slowpath_null+0x1a/0x20 [ 992.078320] [<ffffffffa020de9d>] btrfs_destroy_inode+0x31d/0x360 [btrfs] [ 992.078324] [<ffffffff811895cc>] destroy_inode+0x3c/0x70 [ 992.078326] [<ffffffff8118972a>] evict+0x12a/0x1c0 [ 992.078328] [<ffffffff811898c9>] iput+0x109/0x220 [ 992.078331] [<ffffffff8117e7b3>] do_unlinkat+0x153/0x1d0 [ 992.078333] [<ffffffff811740ea>] ? sys_newfstatat+0x2a/0x40 [ 992.078334] [<ffffffff8117f352>] sys_unlinkat+0x22/0x40 [ 992.078337] [<ffffffff8160d0c2>] system_call_fastpath+0x16/0x1b [ 992.078338] ---[ end trace 770bc93001697fbc ]--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7QZ6AACgkQJ4UciIs+XuL8PwCfQH+oKQ+AJNu5+mKXPdT4byX2 6BcAoKrAgii/ljRs/0lbk4AExbolurXA =1lN4 -----END PGP SIGNATURE----- -- 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
Arne Jansen
2011-Dec-01 09:15 UTC
Re: [RFC] Subvolume Quota on-disk structures and configuration
On 26.11.2011 05:14, Phillip Susi wrote:> On 07/10/2011 04:21 AM, Arne Jansen wrote: >> Now that I''ve got a working prototype of subvolume quota, I''d like >> to get some feedback on the on-disk structure and the commands I >> intend to use. > > I think I''ve noticed a bug so far, and have one comment on the qgroup show command. The command seems to show the current usage of the qgroup, but I can''t see how to view the limits ( if any ). It seems like the show command should show both.It seems there''s no command to show the limits, I''ll add it to qgroup show. Also it should be reflected in df.> > The bug I seem to have noticed is that rm fails with EQUOTA. I set a 1g limit on a new subvol, and ran dd if=/dev/zero of=/mnt/foo, which created a file approx 1g in size before erroring out with EQUOTA. After that, I did an echo bar /mnt/bar, and to my surprise, this did not fail with EQUOTA. Now when I try to rm /mnt/bar or /mnt/foo, THAT fails with EQUOTA. I also got this in dmesg:here we go :) Every quota implementation on a cow filesystem have to have this problem in the beginning :) I thought I had taken care of that, but maybe I''m missing a path there. I''ll have a look. -Arne> > [ 992.078275] WARNING: at fs/btrfs/inode.c:6670 btrfs_destroy_inode+0x31d/0x360 [btrfs]() > [ 992.078276] Hardware name: System Product Name > [ 992.078277] Modules linked in: nls_utf8 isofs bnep rfcomm kvm_intel kvm parport_pc ppdev dm_crypt binfmt_misc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event joydev snd_seq psmouse eeepc_wmi asus_wmi snd_timer snd_seq_device btusb bluetooth serio_raw snd sparse_keymap soundcore mei(C) snd_page_alloc w83627ehf hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor async_memcpy async_raid6_recov raid6_pq async_tx raid1 raid0 multipath linear dm_raid45 xor dm_mirror dm_region_hash dm_log btrfs zlib_deflate libcrc32c hid_microsoft usbhid hid mxm_wmi wmi radeon ahci libahci ttm drm_kms_helper e1000e xhci_hcd drm i2c_algo_bit zram(C) > [ 992.078305] Pid: 2342, comm: rm Tainted: G C 3.2.0-rc2+ #7 > [ 992.078306] Call Trace: > [ 992.078311] [<ffffffff81062acf>] warn_slowpath_common+0x7f/0xc0 > [ 992.078313] [<ffffffff81062b2a>] warn_slowpath_null+0x1a/0x20 > [ 992.078320] [<ffffffffa020de9d>] btrfs_destroy_inode+0x31d/0x360 [btrfs] > [ 992.078324] [<ffffffff811895cc>] destroy_inode+0x3c/0x70 > [ 992.078326] [<ffffffff8118972a>] evict+0x12a/0x1c0 > [ 992.078328] [<ffffffff811898c9>] iput+0x109/0x220 > [ 992.078331] [<ffffffff8117e7b3>] do_unlinkat+0x153/0x1d0 > [ 992.078333] [<ffffffff811740ea>] ? sys_newfstatat+0x2a/0x40 > [ 992.078334] [<ffffffff8117f352>] sys_unlinkat+0x22/0x40 > [ 992.078337] [<ffffffff8160d0c2>] system_call_fastpath+0x16/0x1b > [ 992.078338] ---[ end trace 770bc93001697fbc ]--- >-- 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