Problems with set-default, home subvolume and snapshot

Problems with set-default, home subvolume and snapshot

[Björn Kalkbrenner]

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)..=
=2E

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=3D256 /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=3Dhome /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=F6rn
--
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

Re: Problems with set-default, home subvolume and snapshot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3587 bytes --]

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?                               

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Problems with set-default, home subvolume and snapshot

[Björn Kalkbrenner]

Hi!

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

"It's dead Jim."

When i tried to mount subvolid=3D0 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=F6rn

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

Re: Problems with set-default, home subvolume and snapshot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

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.                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Problems with set-default, home subvolume and snapshot

[Björn Kalkbrenner]

>    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. I=
f
i am done, i'll re-attach the broken btrfs system and dump some informa=
tion.
It shouldn't be a big problem to redirect the kernel messages to a file=
=2E

>    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 i=
t
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)=20

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

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

Re: Problems with set-default, home subvolume and snapshot

[Björn Kalkbrenner]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Hi,

Am 05.09.2011 14:45, schrieb Hugo Mills:

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

My recovery is done. Here are some infos...

-
Linux-3.0.0-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_965_@_3.20GHz-with-gentoo-2.0.3
- Btrfs v0.19-35-g1b444cd-dirty

First, i did a mount, then i got the btrfs-bug kernel msg (see
attachment). When i tried to mount a second time, mount hung, maybe due
to the first btrfs bug kernel message stuff.

The btrfsck.txt is the output of the btrfsck i tried, i know that
doesn't fix anything yet.

Bye
Björn

[-- Attachment #2: btrfs-bug.txt --]
[-- Type: text/plain, Size: 4191 bytes --]

device fsid b8ff0678-6466-4b4c-ab32-31108423ecfb devid 1 transid 32199 /dev/mapper/sdh2
------------[ cut here ]------------
kernel BUG at fs/btrfs/inode.c:4586!
invalid opcode: 0000 [#1] SMP 
CPU 6 
Modules linked in: hidp usbip_host(C) usbip_core(C) nfsd ipv6 bnep rfcomm hid_magicmouse cpufreq_ondemand acpi_cpufreq freq_table mperf tun vboxnetflt vboxdrv nvidia(P) snd_hda_codec_realtek snd_hda_intel btusb snd_hda_codec joydev bluetooth rfkill snd_hwdep snd_pcm snd_timer snd snd_page_alloc processor i2c_i801 e1000e i2c_core thermal_sys button pcspkr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tg3 libphy e1000 fuse nfs lockd sunrpc raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log dm_mod scsi_wait_scan hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_monterey hid_microsoft hid_logitech hid_gyration hid_ezkey hid_cypress hid_chicony hid_cherry hid_belkin hid_apple hid_a4tech sl811_hcd usbhid ohci_hcd ssb uhci_hcd usb_storage ehci_hcd usbcore lpfc qla2xxx megaraid_sas megaraid_mbox megaraid_mm megaraid sx8 DAC960 cciss mptsas mptfc scsi_transport_fc scsi_tgt mptspi mptscsih mptbase atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth advansys initio BusLogic arcmsr sg pdc_adma sata_inic162x sata_mv ata_piix ahci libahci sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_sl82c105 pata_cs5530 pata_cs5520 pata_via pata_jmicron pata_marvell pata_sis pata_netcell pata_sc1200 pata_pdc202xx_old pata_triflex pata_atiixp pata_opti pata_amd pata_ali pata_it8213 pata_pcmcia pcmcia pcmcia_core pata_ns87415 pata_ns87410 pata_serverworks pata_platform pata_artop pata_it821x pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x pata_mpiix libata

Pid: 23202, comm: mount Tainted: P         C  3.0.0-gentoo #1                  /DX58SO
RIP: 0010:[<ffffffff812f313e>]  [<ffffffff812f313e>] 0xffffffff812f313e
RSP: 0018:ffff8802ea5397c8  EFLAGS: 00010282
RAX: 00000000ffffffef RBX: ffff8802a9830a88 RCX: ffff880322236dd8
RDX: 000000000000000c RSI: ffff88013874b760 RDI: ffff880320c1c500
RBP: ffff8802ea539838 R08: ffff8802a9830a88 R09: ffff8800cecc7000
R10: ffff8802ea539600 R11: ffff8802ea5396a8 R12: ffff8802a9830678
R13: ffff8800cecc7000 R14: 000000000000000f R15: ffff88022666c700
FS:  00007f3dbf849740(0000) GS:ffff88032fcc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f3dbf1b0600 CR3: 00000002ea73a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount (pid: 23202, threadinfo ffff8802ea538000, task ffff88032e0b2c70)
Stack:
 ffff880200000001 00000000000058c9 ffff8802ea5397f8 ffff8802a982a540
 00000000000751d8 0000000000000001 0000000000001000 0000000000000000
 ffff880281e52000 ffff8802a9830678 ffff88013874b7f0 ffff8802ea539988
Call Trace:
 [<ffffffff81316e02>] 0xffffffff81316e02
 [<ffffffff813178dc>] 0xffffffff813178dc
 [<ffffffff81315242>] 0xffffffff81315242
 [<ffffffff813154e4>] 0xffffffff813154e4
 [<ffffffff81316660>] 0xffffffff81316660
 [<ffffffff8131769e>] ? 0xffffffff8131769e
 [<ffffffff812e951a>] 0xffffffff812e951a
 [<ffffffff812cbfc2>] 0xffffffff812cbfc2
 [<ffffffff810a1a1b>] ? 0xffffffff810a1a1b
 [<ffffffff8139e57c>] ? 0xffffffff8139e57c
 [<ffffffff810b9c02>] 0xffffffff810b9c02
 [<ffffffff810d0cf4>] 0xffffffff810d0cf4
 [<ffffffff810d0d8a>] 0xffffffff810d0d8a
 [<ffffffff810d14e2>] 0xffffffff810d14e2
 [<ffffffff8109e193>] ? 0xffffffff8109e193
 [<ffffffff8109e1eb>] ? 0xffffffff8109e1eb
 [<ffffffff810d15c9>] 0xffffffff810d15c9
 [<ffffffff8158697b>] 0xffffffff8158697b
Code: 41 8b 04 24 44 89 f1 66 c1 e8 0c 4c 89 fa 0f b7 c0 4c 89 ee 0f b6 80 f0 fa 5b 81 48 8b 7d a8 89 04 24 e8 a1 e8 fe ff 85 c0 74 04 <0f> 0b eb fe 45 01 f6 4d 63 f6 4c 03 b3 d8 00 00 00 4c 89 b3 d8 
RIP  [<ffffffff812f313e>] 0xffffffff812f313e
 RSP <ffff8802ea5397c8>
---[ end trace 8fa5393ebe82965d ]---

[-- Attachment #3: btrfsck.txt --]
[-- Type: text/plain, Size: 1607 bytes --]

btrfsck /dev/mapper/sdh2 
root 256 inode 433544 errors 400
root 256 inode 433651 errors 400
root 256 inode 433652 errors 400
root 256 inode 433653 errors 400
root 256 inode 433657 errors 400
root 256 inode 433658 errors 400
root 256 inode 433659 errors 400
root 256 inode 433660 errors 400
root 256 inode 433661 errors 400
root 256 inode 433662 errors 400
root 256 inode 433663 errors 400
root 256 inode 433664 errors 400
root 256 inode 433665 errors 400
root 256 inode 433666 errors 400
root 256 inode 433667 errors 400
root 256 inode 433668 errors 400
root 256 inode 433669 errors 400
root 256 inode 433670 errors 400
root 256 inode 433671 errors 400
root 256 inode 433672 errors 400
root 256 inode 433673 errors 400
root 256 inode 433674 errors 400
root 256 inode 433675 errors 400
root 256 inode 433676 errors 400
root 256 inode 433677 errors 400
root 256 inode 433678 errors 400
root 256 inode 433679 errors 400
root 256 inode 433680 errors 400
root 256 inode 433681 errors 400
root 256 inode 433682 errors 400
root 256 inode 433683 errors 400
root 256 inode 433684 errors 400
root 256 inode 433685 errors 400
root 256 inode 433686 errors 400
root 256 inode 433687 errors 400
root 256 inode 433688 errors 400
root 256 inode 433689 errors 400
root 256 inode 433690 errors 400
root 256 inode 433789 errors 400
root 256 inode 479558 errors 400
found 434559426560 bytes used err is 1
total csum bytes: 421578512
total tree bytes: 2862436352
total fs tree bytes: 2200010752
btree space waste bytes: 725511512
file data blocks allocated: 5089338077184
 referenced 428338118656
Btrfs v0.19-35-g1b444cd-dirty

Re: Problems with set-default, home subvolume and snapshot

[Ilya Dryomov]

On Mon, Sep 05, 2011 at 11:30:33AM +0100, Hugo Mills wrote:
> On Mon, Sep 05, 2011 at 12:13:25PM +0200, Bj=C3=B6rn Kalkbrenner wrot=
e:
> > 2. why can't i do "mount -o subvolume=3Dhome /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?
>=20
>    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=3D<objectid>, you point to a subvolu=
me
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=3D work in this case.

> > 6. is my btrfs filesystem broken now and should i recreate the whol=
e
> > thing or is it safe to use it?
>=20
>    It sounds like it's all working correctly, and there's nothing
> wrong. (Well, bar the inability to mount with "subvol=3Dhome")

Like Hugo said, the behaviour you described above seems to be correct.


On Mon, Sep 05, 2011 at 02:20:04PM +0200, Bj=C3=B6rn Kalkbrenner wrote:
> Hi!
>=20
> Thank you Hugo for your answers, but i have an update.
>=20
> "It's dead Jim."
>=20
> When i tried to mount subvolid=3D0 to a temporary folder i got a kern=
el
> 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...
>=20
> Now i am trying to restore my system and home from a backup to a new
> harddrive, without btrfs at the moment...
>=20
> 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=C3=B6rn
>=20
> --
> 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

Re: Problems with set-default, home subvolume and snapshot

[Björn Kalkbrenner]

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=3D<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=3D work in this cas=
e.=20

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=3Dhome /dev/mapper/root /ho=
me"
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=3Dhome and
subvolid=3D256 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 ?=20

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=C3=B6rn
--
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

Re: Problems with set-default, home subvolume and snapshot

[Calvin Walton]

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

Re: Problems with set-default, home subvolume and snapshot

[David Sterba]

Hi,

On Mon, Sep 05, 2011 at 12:13:25PM +0200, Bj=F6rn Kalkbrenner wrote:
> Then i tried to
> "mount -o subvolumeid=3D256 /dev/mapper/root /home" (id of home subvo=
l)
> 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=3Dlinux/kernel/git/josef/btrfs-work.git;a=3Dco=
mmit;h=3D4fbb149dfc7454d0f233fa8e5b9167f3645c8fcc


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

 We've only been able to mount with subvol=3D<whatever> where whatever =
was
 a subvol within whatever root we had as the default.  This allows us t=
o
 mount -o subvol=3Dpath/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, interna=
l
id 5 or alse selectable by subvolid=3D0).


david

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

Re: Problems with set-default, home subvolume and snapshot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]