Re: Why subvolume and not just volume?
On 2015-08-06 03:23, Duncan wrote: Martin posted on Wed, 05 Aug 2015 09:06:40 +0200 as excerpted: [W]hat is the penalty of a subvolume compared to a directory? From a design perspective, couldn't all directories just be subvolumes? In addition to the performance issues mentioned by others, there's at least one further practical reason as well. Snapshots stop at subvolume boundaries. It's thus quite useful to use subvolumes to delineate the limits of the snapshot, saying, in effect, snapshot this dir (which happens to be a subvol not just a normal dir) recursively, but don't snapshot the subtree starting with this nested subdir (which again is a (different) subvol). And for some people, this is very useful functionality. I use it to specifically exclude subsets of trivially reproducible data from backups (for example, I always clone public git repositories into individual subvolumes, and keep my local copy of the Portage tree on a separate one (when it isn't on a separate filesystem that is)). smime.p7s Description: S/MIME Cryptographic Signature
Re: Why subvolume and not just volume?
Martin posted on Wed, 05 Aug 2015 09:06:40 +0200 as excerpted: [W]hat is the penalty of a subvolume compared to a directory? From a design perspective, couldn't all directories just be subvolumes? In addition to the performance issues mentioned by others, there's at least one further practical reason as well. Snapshots stop at subvolume boundaries. It's thus quite useful to use subvolumes to delineate the limits of the snapshot, saying, in effect, snapshot this dir (which happens to be a subvol not just a normal dir) recursively, but don't snapshot the subtree starting with this nested subdir (which again is a (different) subvol). Subvols act very much like directories, it is true. But they have a few additional properties and different behaviors, and it is the distinction between directories and subvols that makes them valuable /as/ subvols. Without a distinction, the whole reason to have subvols as a separate feature vanishes. (FWIW, the first systemd release, v219, to use btrfs subvolume in place of directories found out some of the behavior differences the hard way. Where it was previously doing mkdir, which returns success if the directory is already there, critical for a root filesystem keep read-only mounted by default, but with the required directories already created, on btrfs it tried to create a subvolume instead, which fails if there's a directory already there, particularly if it's a read-only mount. So the behavior creating a subvol differs from that of creating a subdir, and systemd's tmpfiles service was failing on read-only btrfs mounts as a result, while it previously succeeded, when it was only trying to create directories, which already existed. Oops! The bug was fixed in v221, but the experience does illustrate that while subvolumes behave in /many/ ways like subdirs, there are indeed small differences in behavior that can leap up and bite the unwary.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Why subvolume and not just volume?
Hi, Does anyone know the reason subvolumes are not called just volumes? I mean, the top subvolume is not called a volume, so there is nothing to be sub of. Also, what is the penalty of a subvolume compared to a directory? From a design perspective, couldn't all directories just be subvolumes? Martin -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why subvolume and not just volume?
Martin wrote on 2015/08/05 09:06 +0200: Hi, Does anyone know the reason subvolumes are not called just volumes? I mean, the top subvolume is not called a volume, so there is nothing to be sub of. Because normally a volume is referred as a complete filesystem. So from this respect, subvolume is not a full filesystem, it still need a lot of extra data from other trees to build its contents. So, that's why there is sub prefix. Although it acts much like a volume as it can be mounted like a filesystem, but it's still not a full filesystem. Also, what is the penalty of a subvolume compared to a directory? From a design perspective, couldn't all directories just be subvolumes? Yes, subvolume has its overhead, and when it comes as many as directories, the overhead won't be small. The overhead that I can remember is shown below. Use empty tree as an example for its size, and default mkfs options. The '+' after number means it will increase with snapshots 1) Empty tree block: 16K Of course takes more if its child file/dir grows 2) ROOT_ITEM in tree root: 439bytes 3) ROOT_BACKREF in tree root: 22+bytes 5) extent backref for tree block: 33+bytes for skinny metadata 53+bytes without skinny metadata Alone with other trees like log tree, one for each subvolume if fsync is called. Not to mention other run-time overhead. For example, to search a inode in one subvolume. Search_slot would be enough to find the INODE_ITEM. But to search a inode across subvolume boundary, need to first found the subvolume boundary and loop until we reach the subvolume containing the inode, then do the above search_slot to locate the INODE_ITEM. Although the overhead is already small, but not that small to make all directories to be subvolume. Thanks, Qu Martin -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why subvolume and not just volume?
On Wed, Aug 05, 2015 at 09:06:40AM +0200, Martin wrote: Also, what is the penalty of a subvolume compared to a directory? From a design perspective, couldn't all directories just be subvolumes? They could, but this would bring severe performance drop. * creating a subvolume implies a transaction commit * the subvolumes act like a mountpoint boundary so it needs to resolve the next subvolume root before directory traversal can descend to it You can try to create a deep hierarchy of directories and then do the same with subvolumes. The difference is too big for practical purposes. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
