X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=Documentation%2Fbtrfs-quota.asciidoc;h=85ebf729c2faac60ff3685751d0ff0aa863ce8be;hb=678da5a7f71ed7fbc887e40cc8ef91008c6fe843;hp=ef2e5d33139c3f267063191eec5eedac37bf0cab;hpb=17144afb40d7637d8d8f29b7d75709583f459134;p=platform%2Fupstream%2Fbtrfs-progs.git diff --git a/Documentation/btrfs-quota.asciidoc b/Documentation/btrfs-quota.asciidoc index ef2e5d3..85ebf72 100644 --- a/Documentation/btrfs-quota.asciidoc +++ b/Documentation/btrfs-quota.asciidoc @@ -15,24 +15,24 @@ The commands under *btrfs quota* are used to affect the global status of quotas of a btrfs filesystem. The quota groups (qgroups) are managed by the subcommand `btrfs qgroup`(8). -NOTE: the qgroups are different than the traditional user quotas and designed +NOTE: Qgroups are different than the traditional user quotas and designed to track shared and exclusive data per-subvolume. Please refer to the section 'HIERARCHICAL QUOTA GROUP CONCEPTS' for a detailed description. PERFORMANCE IMPLICATIONS ~~~~~~~~~~~~~~~~~~~~~~~~ -When the quotas are turned on, they affect all extent processing, taking a -performance hit. It is not recommended to turn on qgroups unless the user +When quotas are activated, they affect all extent processing, which takes a +performance hit. Activation of qgroups is not recommended unless the user intends to actually use them. STABILITY STATUS ~~~~~~~~~~~~~~~~ The qgroup implementation has turned out to be quite difficult as it affects -the core of the filesystem operation. The users have hit various corner cases -over time, eg. wrong accounting or system instability. The situation is -gradually improving but currently (4.7) there are still issues found and fixed. +the core of the filesystem operation. Qgroup users have hit various corner cases +over time, such as incorrect accounting or system instability. The situation is +gradually improving and issues found and fixed. HIERARCHICAL QUOTA GROUP CONCEPTS --------------------------------- @@ -52,7 +52,7 @@ On the other hand, the traditional approach has only a poor solution to restrict directories. At installation time, the harddisk can be partitioned so that every directory (eg. /usr, /var/, ...) that needs a limit gets its own partition. The obvious -problem is, that those limits cannot be changed without a reinstallation. The +problem is that those limits cannot be changed without a reinstallation. The btrfs subvolume feature builds a bridge. Subvolumes correspond in many ways to partitions, as every subvolume looks like its own filesystem. With subvolume quota, it is now possible to restrict each subvolume like a partition, but keep @@ -96,7 +96,23 @@ instead of '0/ID'. For all higher levels, the ID can be chosen freely. Each qgroup can contain a set of lower level qgroups, thus creating a hierarchy of qgroups. Figure 1 shows an example qgroup tree. -// TODO: insert Figure 1 + +---+ + |2/1| + +---+ + / \ + +---+/ \+---+ + |1/1| |1/2| + +---+ +---+ + / \ / \ + +---+/ \+---+/ \+---+ +qgroups |0/1| |0/2| |0/3| + +-+-+ +---+ +---+ + | / \ / \ + | / \ / \ + | / \ / \ +extents 1 2 3 4 + +Figure1: Sample qgroup hierarchy At the bottom, some extents are depicted showing which qgroups reference which extents. It is important to understand the notion of 'referenced' vs @@ -165,7 +181,7 @@ own way how to integrate qgroups. `Replacement for partitions` The simplest use case is to use qgroups as simple replacement for partitions. -Btrfs takes the disk as a whole, and /, /usr, /var etc. are created as +Btrfs takes the disk as a whole, and /, /usr, /var, etc. are created as subvolumes. As each subvolume gets it own qgroup automatically, they can simply be restricted. No hierarchy is needed for that.