Btrfs devel - Sep 2011 - Problems with set-default, home subvolume and snapshot

Hi,

i''ve got an interesting btrfs subvolume problem which i can''t
understand... Maybe someone here can give me a tip because i think
that''s only a user error...

I had a root btrfs on / and made a subvolume some month ago for my home
on /home (i think cwd was / and i used "btrfs subvolume create
/home").

On friday i wanted to try an update of my distribution, so i
created a snapshot on /snapshots/20110902 (cwd was / and i entered
"btrfs subvolume snapshot / /snapshots/20110902).

Today i realized that my update failed, so i did
"btrfs set-default 257 /" (257 is the id of the snapshot from
friday)...

When i rebooted, the trouble began. The mounted "home" subvolume was
empty (even if mounted) and the new root from today which i used before
trying the set-default seems to be lost. Ok, not the main problem...

The snapshot from friday was mounted correctly on boot as root.

The directory /snapshots/20110902 is empty but it is still listed as
subvolume. My "home" was also empty but still listed as subvolume.
I tried to remove the subvolume, i tried to remove the directory, both
not working.

Then i tried to
"mount -o subvolumeid=256 /dev/mapper/root /home" (id of home subvol)
and the content of my home is back...


My questions are:

1. where is the "original" root from today morning before i did
set-default? Lost?

2. why can''t i do "mount -o subvolume=home /dev/mapper/root
/home"
anymore? To be more exact, i can, but why is it empty and why is it
working when i enter the subvolume id?

3. I am now using the snapshot /snapshots/20110902 but what is
/snapshots/20110902 now and why is it still listed? It''s empty?

4. can i now delete the snapshots/20110902 or will that drop my current
active working root?

5. can i rename snapshots, e.g. the snapshots/20110902 or "home" to
"home-20110905"?

6. is my btrfs filesystem broken now and should i recreate the whole
thing or is it safe to use it?

Bye
Björn
--
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

On Mon, Sep 05, 2011 at 12:13:25PM +0200, Björn Kalkbrenner
wrote:
> Hi,
> 
> i''ve got an interesting btrfs subvolume problem which i
can''t
> understand... Maybe someone here can give me a tip because i think
> that''s only a user error...
> 
> I had a root btrfs on / and made a subvolume some month ago for my home
> on /home (i think cwd was / and i used "btrfs subvolume create
/home").
> 
> On friday i wanted to try an update of my distribution, so i
> created a snapshot on /snapshots/20110902 (cwd was / and i entered
> "btrfs subvolume snapshot / /snapshots/20110902).
> 
> Today i realized that my update failed, so i did
> "btrfs set-default 257 /" (257 is the id of the snapshot from
friday)...
> 
> When i rebooted, the trouble began. The mounted "home" subvolume
was
> empty (even if mounted) and the new root from today which i used before
> trying the set-default seems to be lost. Ok, not the main problem...
   The original root is available by mounting with "subvolid=0" as a
mount option.

   Snapshots do not recurse into snapshots, so when you took a
snapshot of your original / (at the top level), you will have got a
snapshot of everything within / *except* /home (which is a
subvolume). /home should still be available as subvol=/home, or as
subvolid=256.
> The snapshot from friday was mounted correctly on boot as root.
> 
> The directory /snapshots/20110902 is empty but it is still listed as
> subvolume. My "home" was also empty but still listed as
subvolume.
> I tried to remove the subvolume, i tried to remove the directory, both
> not working.
   The directory you refer to is just a directory at this point, since
it''s the copy inside /snapshots/20110902. Anything else would be
somewhat insane, as you''d have a directory/snapshot loop.

   The subvolume path it''s referring to is not from your
currently-mounted /, but is instead from the (currently invisible)
top-level directory of your btrfs filesystem, which is only reachable
if you mount your filesystem somewhere with subvolid=0.
> Then i tried to
> "mount -o subvolumeid=256 /dev/mapper/root /home" (id of home
subvol)
> and the content of my home is back...
> 
> 
> My questions are:
> 
> 1. where is the "original" root from today morning before i did
> set-default? Lost?
   subvolid=0
> 2. why can''t i do "mount -o subvolume=home /dev/mapper/root
/home"
> anymore? To be more exact, i can, but why is it empty and why is it
> working when i enter the subvolume id?
   I don''t know about this one, sorry.
> 3. I am now using the snapshot /snapshots/20110902 but what is
> /snapshots/20110902 now and why is it still listed? It''s empty?
   It''s an empty directory.
> 4. can i now delete the snapshots/20110902 or will that drop my current
> active working root?
   The latter -- it will drop your working root.
> 5. can i rename snapshots, e.g. the snapshots/20110902 or "home"
to
> "home-20110905"?
   I believe that "mv" will accomplish this.
> 6. is my btrfs filesystem broken now and should i recreate the whole
> thing or is it safe to use it?
   It sounds like it''s all working correctly, and there''s
nothing
wrong. (Well, bar the inability to mount with "subvol=home")

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- If it''s December 1941 in Casablanca,  what time is it ---
                              in New York?

Hi!

Thank you Hugo for your answers, but i have an update.

"It''s dead Jim."

When i tried to mount subvolid=0 to a temporary folder i got a kernel
segfault and a BUG line in btrfs kernel code somewhere (reproducable),
after a reboot all volumes are broken, can''t be mounted anymore...
btrfsfsck gave me inode errors on subvol 256 (my home).
mount does nothing but sleep/hang...

Now i am trying to restore my system and home from a backup to a new
harddrive, without btrfs at the moment...

I think my question 6 is now answered: it''s completely broken.

Bye
Björn

--
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

On Mon, Sep 05, 2011 at 02:20:04PM +0200, Björn Kalkbrenner
wrote:
> Hi!
> 
> Thank you Hugo for your answers, but i have an update.
> 
> "It''s dead Jim."
> 
> When i tried to mount subvolid=0 to a temporary folder i got a kernel
> segfault and a BUG line in btrfs kernel code somewhere (reproducable),
> after a reboot all volumes are broken, can''t be mounted anymore...
   Did you manage to capture that output at all? (A photo would do).

   What kernel version are you running? (anything earlier than 2.6.39
is probably considered too old for comfort)
> btrfsfsck gave me inode errors on subvol 256 (my home).
> mount does nothing but sleep/hang...
   btrfsck doesn''t generally achieve much at the moment. However,
having mount hang is quite odd. It usually either succeeds, or causes
a kernel oops (if the latter has already happened, then *subsequent*
mount attempts may hang, but the original oops is still of interest)
> Now i am trying to restore my system and home from a backup to a new
> harddrive, without btrfs at the moment...
   It''d be good if you have the time to try to reproduce this,
particularly with the latest kernels (3.0 or 3.1-rcX)
> I think my question 6 is now answered: it''s completely broken.
   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- My doctor tells me that I have a malformed public-duty gland, ---  
                and a natural deficiency in moral fibre.

On Mon, Sep 05, 2011 at 11:30:33AM +0100, Hugo Mills
wrote:
> On Mon, Sep 05, 2011 at 12:13:25PM +0200, Björn Kalkbrenner wrote:
> > 2. why can''t i do "mount -o subvolume=home
/dev/mapper/root /home"
> > anymore? To be more exact, i can, but why is it empty and why is it
> > working when i enter the subvolume id?
> 
>    I don''t know about this one, sorry.
Well, it''s *sort of* expected if you think about it.  When you mounted
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).

However if you mount with subvolid=<objectid>, you point to a subvolume
directly, skipping the lookup (which leads to an empty dir if you are
inside your snapshot).  That''s why it works when you use the subvolid.
We should probably tune the lookup to make subvol= work in this case.
> > 6. is my btrfs filesystem broken now and should i recreate the whole
> > thing or is it safe to use it?
> 
>    It sounds like it''s all working correctly, and there''s
nothing
> wrong. (Well, bar the inability to mount with "subvol=home")
Like Hugo said, the behaviour you described above seems to be correct.


On Mon, Sep 05, 2011 at 02:20:04PM +0200, Björn Kalkbrenner
wrote:
> Hi!
> 
> Thank you Hugo for your answers, but i have an update.
> 
> "It''s dead Jim."
> 
> When i tried to mount subvolid=0 to a temporary folder i got a kernel
> segfault and a BUG line in btrfs kernel code somewhere (reproducable),
> after a reboot all volumes are broken, can''t be mounted anymore...
> btrfsfsck gave me inode errors on subvol 256 (my home).
> mount does nothing but sleep/hang...
> 
> Now i am trying to restore my system and home from a backup to a new
> harddrive, without btrfs at the moment...
> 
> I think my question 6 is now answered: it''s completely broken.
You say it''s reproducable, can you give us a backtrace to look at ?
> Bye
> Björn
> 
> --
> 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
--
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

Hi,

On Mon, Sep 05, 2011 at 12:13:25PM +0200, Björn Kalkbrenner
wrote:
> Then i tried to
> "mount -o subvolumeid=256 /dev/mapper/root /home" (id of home
subvol)
> and the content of my home is back...
this is a known limitation and a fix is pending in Josef''s development
tree

http://git.kernel.org/?p=linux/kernel/git/josef/btrfs-work.git;a=commit;h=4fbb149dfc7454d0f233fa8e5b9167f3645c8fcc


"Btrfs: fix how we mount subvol=<whatever>

 We''ve only been able to mount with subvol=<whatever> where
whatever was
 a subvol within whatever root we had as the default.  This allows us to
 mount -o subvol=path/to/subvol/you/want relative from the normal
 fs_tree root.  Thanks,"

currently, the /home subvolume is searched inside the volume set by
''set-default''. When you change it to an alternative root
snapshot, the
''/home'' subvolume lookup fails as you''ve seen.

The patch changes it so that the subvolumes are always looked up to the
original default root subvolume (I don''t know of a better name,
internal
id 5 or alse selectable by subvolid=0).


david
> 
> 
> My questions are:
> 
> 1. where is the "original" root from today morning before i did
> set-default? Lost?
> 
> 2. why can''t i do "mount -o subvolume=home /dev/mapper/root
/home"
> anymore? To be more exact, i can, but why is it empty and why is it
> working when i enter the subvolume id?
> 
> 3. I am now using the snapshot /snapshots/20110902 but what is
> /snapshots/20110902 now and why is it still listed? It''s empty?
> 
> 4. can i now delete the snapshots/20110902 or will that drop my current
> active working root?
> 
> 5. can i rename snapshots, e.g. the snapshots/20110902 or "home"
to
> "home-20110905"?
> 
> 6. is my btrfs filesystem broken now and should i recreate the whole
> thing or is it safe to use it?
> 
> Bye
> Björn
> --
> 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
--
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

On Mon, Sep 05, 2011 at 03:51:29PM +0200, David Sterba
wrote:
> Hi,
> 
> On Mon, Sep 05, 2011 at 12:13:25PM +0200, Björn Kalkbrenner wrote:
> > Then i tried to
> > "mount -o subvolumeid=256 /dev/mapper/root /home" (id of
home subvol)
> > and the content of my home is back...
> 
> this is a known limitation and a fix is pending in Josef''s
development
> tree
> 
>
http://git.kernel.org/?p=linux/kernel/git/josef/btrfs-work.git;a=commit;h=4fbb149dfc7454d0f233fa8e5b9167f3645c8fcc
> 
> 
> "Btrfs: fix how we mount subvol=<whatever>
> 
>  We''ve only been able to mount with subvol=<whatever> where
whatever was
>  a subvol within whatever root we had as the default.  This allows us to
>  mount -o subvol=path/to/subvol/you/want relative from the normal
>  fs_tree root.  Thanks,"
> 
> currently, the /home subvolume is searched inside the volume set by
> ''set-default''. When you change it to an alternative root
snapshot, the
> ''/home'' subvolume lookup fails as you''ve seen.
> 
> The patch changes it so that the subvolumes are always looked up to the
> original default root subvolume (I don''t know of a better name,
internal
> id 5 or alse selectable by subvolid=0).
   I''ve always tried to refer to it as the "top level" or
"subvolid=0".

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- Always be sincere,  whether you mean it or not. ---

>    Did you manage to capture that output at all? (A photo would do).
Not yet, i am still on recovery from backup, that may take some time. If
i am done, i''ll re-attach the broken btrfs system and dump some
information.
It shouldn''t be a big problem to redirect the kernel messages to a
file.
>    What kernel version are you running? (anything earlier than 2.6.39
> is probably considered too old for comfort)
3.0.0 is my current running kernel. Due to the fact that i created the
whole btrfs filesystem around two weeks before i think i also created it
with 3.0.0 but i am not sure.
> btrfsck doesn''t generally achieve much at the moment. However,
having
> mount hang is quite odd. It usually either succeeds, or causes a
> kernel oops (if the latter has already happened, then *subsequent*
> mount attempts may hang, but the original oops is still of interest) 
>    It''d be good if you have the time to try to reproduce this,
> particularly with the latest kernels (3.0 or 3.1-rcX)
I can, with 3.0.0.

Give me some hours of recovery :)


Björn

--
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

Hi Ilya,

Am 05.09.2011 15:07, schrieb Ilya Dryomov:
> Well, it''s *sort of* expected if you think about it. When you
mounted
> 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). However
> if you mount with subvolid=<objectid>, you point to a subvolume
> directly, skipping the lookup (which leads to an empty dir if you are
> inside your snapshot). That''s why it works when you use the
subvolid.
> We should probably tune the lookup to make subvol= work in this case. 
Ah, thank you very much, that sounds logical with the lookup table and
the - not valid access point - BUT:

Why could i still manually "mount -o subvol=home /dev/mapper/root
/home"
and home was just empty but mounted (i looked at the mount table output)?
Shouldn''t that give me an error that home can''t be found in
the lookup
table?

There was a difference between the content of subvol=home and
subvolid=256 and i was able to mount both but only one (id 256)
contained my data, the other seems to be empty.
> You say it''s reproducable, can you give us a backtrace to look at
?
Yes, when the backup recovery job is done... And that''s not really fast
currently due to external usb hd on my notebook... may take some time. ;)


Bye
Björn
--
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

On Mon, 2011-09-05 at 16:43 +0200, Björn Kalkbrenner
wrote:
> Hi Ilya,
> 
> Am 05.09.2011 15:07, schrieb Ilya Dryomov:
> > Well, it''s *sort of* expected if you think about it. When you
mounted
> > 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). However
> > if you mount with subvolid=<objectid>, you point to a subvolume
> > directly, skipping the lookup (which leads to an empty dir if you are
> > inside your snapshot). That''s why it works when you use the
subvolid.
> > We should probably tune the lookup to make subvol= work in this case. 
> 
> Ah, thank you very much, that sounds logical with the lookup table and
> the - not valid access point - BUT:
> 
> Why could i still manually "mount -o subvol=home /dev/mapper/root
/home"
> and home was just empty but mounted (i looked at the mount table output)?
> Shouldn''t that give me an error that home can''t be found
in the lookup
> table?
This is actually because of how the subvolume mounting works internally.
It turns out that currently, the command
	mount -o subvol=home /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 :)

-- 
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