Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Why subvolume and not just volume?
Date: Thu, 6 Aug 2015 07:23:30 +0000 (UTC)	[thread overview]
Message-ID: <pan$26b5e$81e797b6$ee8aa3f0$e575c51a@cox.net> (raw)
In-Reply-To: CAK4jXzy8OpRMnF=hYEamZVxiumH9Xn_8uDo_xOQhYfLf3cA9dA@mail.gmail.com

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


  parent reply	other threads:[~2015-08-06  7:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  7:06 Why subvolume and not just volume? Martin
2015-08-05  7:23 ` Qu Wenruo
2015-08-05 17:13 ` David Sterba
2015-08-06  7:23 ` Duncan [this message]
2015-08-06 11:17   ` Austin S Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$26b5e$81e797b6$ee8aa3f0$e575c51a@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox