Re: corrupt filesystem after snapshots on 3.2

[Russell Coker <russell@coker.com.au>]

On Sat, 29 Dec 2012, Chris Murphy <lists@colorremedies.com> wrote:
> Add another disk, or disk partition, to the Btrfs volume. That'll give it
> more space and hopefully you can back out at that point.

# df -h /mnt/tmp
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/rjca-crypt   12G   12G  637M  95% /mnt/tmp

I didn't expect that to work because the filesystem already reported free 
space.  I removed the snapshots and had problems during/after the removal so 
it seemed that there was space.

# btrfs filesystem show --all-devices
Label: none  uuid: 0f0b48e9-d2f7-4280-b417-4d1f5a933975
        Total devices 3 FS bytes used 5.63GB
        devid    1 size 6.00GB used 6.00GB path /dev/dm-16
        devid    2 size 6.00GB used 6.00GB path /dev/dm-17
        devid    3 size 6.00GB used 19.00MB path /dev/dm-18

However I've added another device and now "du -h" completes without any kernel 
panic (a major improvement).  Now I'm seeing the above, apparently 19MB used 
on the new dm-18 device seems to be making all the difference.

# btrfs subvol list /mnt/tmp
ERROR: Failed to lookup path for root 0 - No such file or directory

Strangely I was getting the above error while the btrfs scrub was in progress, 
but it went away when the scrub finished.  That seems like a bug to me.

Now the filesystem is now OK and I've copied all the data off it.  The data 
appears to be all intact (much of it could be verified against another system).

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/