On 27/11/10 01:45, Brad Alexander wrote:
Thanks for your post, Alan.
Lets take this discussion back to the list rather than hold it in private - and I am subscribed, so no need to copy me either
On Fri, Nov 26, 2010 at 4:39 PM, Alan Chandler <alan@chandlerfamily.org.uk> wrote: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 created a btrfs partition on my laptop from my previous job, but really didn't experiment with it much. I definitely didn't get to play with the subvolumes and snapshotting...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 docs did you reference when using this? I haven't found anything that I could really sink my teeth into when searching. I have read the stuff on the btrfs wiki, but that almost seems like promotional material rather than howto or beginners stuff.
I found very little outside of the wiki
I've also considered just using ext4, since it seems fall in that gray area between reiserfs, which I have used for years and is getting really long in the tooth, and btrfs, which is the next great thing. However, that "having to fsck every 30 boots" mindset really tends to annoy me.
I used to use reiserfs and one of its great strengths was packing small files into the same block. I have since moved to bigger discs and ext4 - but it is wasteful of space.
The main reason I chose to try btrfs was because I was try to squeeze an extra level of backup into a 160G disk and it just wouldn't go - I was hoping this packing of files would help things. It did to some extent - enough to enable me to store most of what was important. Given it was a 3rd level backup I was willing risk loosing it.
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.This is something that I'm still trying to get my brain around. I create an lvm then stick my traditional filesystems inside of that container. When I build a box, I create an encrypted block on the hard drive, then stick an LVM within that. I wonder how this is going to work with btrfs...
As far as I can work out, using mkfs.btrfs with the -d raid1 -m raid1 switches becomes the equivalent of an mdadm assemble and a vgcreate all in one go. Creating a subvolume in that filesystem then becomes the equivalent of an lvcreate. Snapshoting that subvolume is the equivalent of the lvcreate with the -s switch.
Conceptually what I find difficult to understand is that you create these subvolumes and snapshots in directories within the overall filesystem - and you can designate one of them to be the default subvolume. The filesystem itself may be spread over multiple devices.
When you mount (one of) the device(s) you mount the subvolume. This leaves me with unanswered questions: - What happens to the rest of the filesystem when you mount the default subvolume - do you loose access to it - how do you mount the filesystem when its spread over multiple devices (ie what device do you refer to in the mount command).
I currently run raid/lvm on my desktop for all bar my boot partition and I am condidering whether btrfs could replace it.That is my ultimate goal. This external hard drive is just a small-scale experiment to see if the filesystem is viable yet and get familiar with its workings before eventually building systems with it.
Exactly what I was trying to do. -- Alan Chandler http://www.chandlerfamily.org.uk