On Sat, 29 Dec 2012, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
