From: Calvin Walton <calvin.walton@kepstin.ca>
To: "Björn Kalkbrenner" <terminar@cyberphoria.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Problems with set-default, home subvolume and snapshot
Date: Tue, 06 Sep 2011 08:16:18 -0400 [thread overview]
Message-ID: <1315311380.2530.6.camel@ayu> (raw)
In-Reply-To: <4E64E026.4020009@cyberphoria.org>
On Mon, 2011-09-05 at 16:43 +0200, Bj=C3=B6rn Kalkbrenner wrote:
> Hi Ilya,
>=20
> Am 05.09.2011 15:07, schrieb Ilya Dryomov:
> > Well, it's *sort of* expected if you think about it. When you mount=
ed
> > after set-default, your /home is no longer a valid subvolume access
> > point (it was in the default subvolume, until you rebooted). Inside
> > your snapshot /home is just an empty directory (there's more to it,
> > that's why you can't delete it, but that's irrelevant here). Howeve=
r
> > if you mount with subvolid=3D<objectid>, you point to a subvolume
> > directly, skipping the lookup (which leads to an empty dir if you a=
re
> > inside your snapshot). That's why it works when you use the subvoli=
d.
> > We should probably tune the lookup to make subvol=3D work in this c=
ase.=20
>=20
> Ah, thank you very much, that sounds logical with the lookup table an=
d
> the - not valid access point - BUT:
>=20
> Why could i still manually "mount -o subvol=3Dhome /dev/mapper/root /=
home"
> and home was just empty but mounted (i looked at the mount table outp=
ut)?
> Shouldn't that give me an error that home can't be found in the looku=
p
> table?
This is actually because of how the subvolume mounting works internally=
=2E
It turns out that currently, the command
mount -o subvol=3Dhome /dev/mapper/root /home
effectively does the same thing as
mount /dev/mapper/root /home # Mount the "default" subvolume
mount --bind /home/home /home # Switch to the "home" subvolume
which of course succeeds if /home in your default subvolume is an empty
directory.
Hopefully this can be improved at some point :)
--=20
Calvin Walton <calvin.walton@kepstin.ca>
--
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
next prev parent reply other threads:[~2011-09-06 12:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 10:13 Problems with set-default, home subvolume and snapshot Björn Kalkbrenner
2011-09-05 10:30 ` Hugo Mills
2011-09-05 12:20 ` Björn Kalkbrenner
2011-09-05 12:45 ` Hugo Mills
2011-09-05 14:31 ` Björn Kalkbrenner
2011-09-07 6:47 ` Björn Kalkbrenner
2011-09-05 13:07 ` Ilya Dryomov
2011-09-05 14:43 ` Björn Kalkbrenner
2011-09-06 12:16 ` Calvin Walton [this message]
2011-09-05 13:51 ` David Sterba
2011-09-05 13:57 ` Hugo Mills
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=1315311380.2530.6.camel@ayu \
--to=calvin.walton@kepstin.ca \
--cc=linux-btrfs@vger.kernel.org \
--cc=terminar@cyberphoria.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;
as well as URLs for NNTP newsgroup(s).