On 25/11/10 18:09, Brad Alexander wrote:
Um, isn't that kind of like a steering wheel that won't turn the car? :)
In reference to btrfs.fsck I think its got limited functionality now - but will improve over time
Actually, I understand. the filesystem is a work in progress. Besides, I've been using reiserfs for at least 8 years, and can probably count the number of times I have fscked it on two hands. But then again, when I needed to, I *really* needed to... In my particular case, the data on the external drive will be backed up elsewhere and available instantly from my workstation or fileserver, so "nuke-and-pave" is an option.
I've just tried it on my own similar drive as an experiment. I think, although I have not yet got far enough into it to fully understand it, is that a first step after mkfs.btrfs and then mount should be to create a subvolume that will be the default one. You should then umount the complete volume and mount the subvolume.
I missed that step out, and I think it was probably a mistake - but I'm finding the docs a little patchy. Its almost like you have to already know what it does to understand the docs. I am not sure if you mess up with this that you can then change it - docs covering this sort of advice seems to be missing.
What seems to be realy great - provided of course that you set it up duing the mkfs.btrfs time is that you can add multiple devices to the file system and replace raid and lvm. Because its built into the filesystem, synchronising a new device when its added to a raid array is a lot faster than the mdadm stuff that is currently available.
I currently run raid/lvm on my desktop for all bar my boot partition and I am condidering whether btrfs could replace it.
-- Alan Chandler http://www.chandlerfamily.org.uk