linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhe Zhang <zhe.zhang.research@gmail.com>
To: Sebastian Ochmann <ochmann@informatik.uni-bonn.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Is it safe to mount subvolumes of already-mounted volumes (even with different options)?
Date: Wed, 16 Jul 2014 23:27:02 -0400	[thread overview]
Message-ID: <CAMXuLLrLgxmG1uU+JS5vBe7m36s=4XobWhh438G4RD5b94bzRg@mail.gmail.com> (raw)
In-Reply-To: <53C6FA3D.9010803@informatik.uni-bonn.de>

Hi Sebastian,

I posted a similar question and got many helpful answers:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg35047.html

Basically, you cannot guarantee that the computing mounting /dev/sdx
doesn't write to arbitrary addresses of /dev/sdxN as unallocated
blocks and thus corrupting the file system on it (I assume sdxN in
your example is a sub volume of sdx).

On Wed, Jul 16, 2014 at 6:18 PM, Sebastian Ochmann
<ochmann@informatik.uni-bonn.de> wrote:
> Hello,
>
> I'm sharing a btrfs-formatted drive between multiple computers and each of
> the machines has a separate home directory on that drive. The root of the
> drive is mounted at /mnt/tray and the home directory for machine {hostname}
> is under /mnt/tray/Homes/{hostname}. Up until now, I have mounted /mnt/tray
> like a normal volume and then did an additional bind-mount of
> /mnt/tray/Homes/{hostname} to /home.
>
> Now I have a new drive and wanted to do things a bit more advanced by
> creating subvolumes for each of the machines' home directories so that I can
> also do independent snapshotting. I guess I could use the bind-mount method
> like before but my question is if it is considered safe to do an additional,
> "regular" mount of one of the subvolumes to /home instead, like
>
> mount /dev/sdxN /mnt/tray
> mount -o subvol=/Homes/{hostname} /dev/sdxN /home
>
> When I experimented with such additional mounts of subvolumes of
> already-mounted volumes, I noticed that the mount options of the additional
> subvolume mount might differ from the "original" mount. For instance, the
> root volume might be mounted with "noatime" while the subvolume mount may
> have "relatime".
>
> So my questions are: Is mounting a subvolume of an already mounted volume
> considered safe and are there any combinations of possibly conflicting mount
> options one should be aware of (compression, autodefrag, cache clearing)? Is
> it advisable to use the same mount options for all mounts pointing to the
> same physical device?
>
> Best regards,
> Sebastian
> --
> 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

  parent reply	other threads:[~2014-07-17  3:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 22:18 Is it safe to mount subvolumes of already-mounted volumes (even with different options)? Sebastian Ochmann
2014-07-16 23:18 ` Chris Murphy
2014-07-17  7:58   ` Sebastian Ochmann
2014-07-17  8:48     ` Qu Wenruo
2014-07-17  3:27 ` Zhe Zhang [this message]
2014-07-17  8:41 ` Hugo Mills
2014-07-17 15:45   ` Duncan

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='CAMXuLLrLgxmG1uU+JS5vBe7m36s=4XobWhh438G4RD5b94bzRg@mail.gmail.com' \
    --to=zhe.zhang.research@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=ochmann@informatik.uni-bonn.de \
    /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;
as well as URLs for NNTP newsgroup(s).