[TriLUG] Using Btrfs

[Aaron Joyner]

On Wed, Nov 19, 2014 at 2:49 PM, Paul Boyle <pboyle at uwo.ca> wrote:
>
> ... I guess another way to frame the question with regard to btrfs' RAID
> capabilities would be:  Does it makes sense to use btrfs on single disk
> systems?
>

Sure.  There are a lot of nice things about btrfs, independent of using
it's support to span your FS across multiple disks (RAID / volume
management).


This page:
> http://www.howtoforge.com/a-beginners-guide-to-btrfs
>
> mentions that mkfs.btrfs defaults to the "raid1" option for the
> filesystem's metadata but not for the data.  Does this imply a
> multi-disk system?  If not, how is the metadata mirrored (and where)?
>

Yes, in that example, they're feeding the mkfs.btrfs command 3 block
devices (mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd), and saying that it'll
store the FS metadata on two of the disks, using the raid1 profile.

By way of comparison, on your workstations, you'd run a command with only
one block device (similar to $(mkfs.btrfs /dev/sda)), and the metadata
would be stored on the one available disk, with the 'DUP' profile.  This
achieves a similar effect to help insulate the FS metadata against a bad
sector or two on the disk, but it doesn't protect against the disk failing
out-right.

Additional reading:
http://www.howtoforge.com/a-beginners-guide-to-btrfs
https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
https://btrfs.wiki.kernel.org/index.php/Glossary



> > - Snapshots in btrfs are "copy on write".  They start by taking
> > approximately zero room, and then begin to consume additional space
> > as you make more changes to disk.  They're typical use is to allow
> > for flexible local "backups", which insure against modest user error
> > (deleting an important file),
>
> This is exactly what I think would be most important about moving to
> btrfs.  Sometimes students hose an important file and it would be really
> nice to be able to "go back to before the accident".  I was thinking to
> make /home a btrfs files system with each user having their own
> subvolume.  I would leave the other paritions as ext4 partitions.
>

Snapshots are great for this use case.  You used to have to pay big money
to a vendor like NetApp or Veritas to get that functionality, but now it's
available in the open source products, and easy to use.

You can also achieve a similar effect, with any posix-compliant filesystem
that supports hardlinks, using tools like rdiff-backup, or some basic
scripting around rsync, or cp.  The advantage to btrfs is that it's
marginally more efficient, and baked right into the filesystem tools.


> How much space your snapshots take up is...
>
> I think it might take a while to get a feel as to what the space
> tradeoff versus granularity for typical usage on my systems.  I think
> different users would mostly likely have need/use different granularity
> (e.g. the student who is the lab everyday versus the student who only
> occasionally processes data).
>

This will be very workload dependent.  Imagine the following timeline:
10:10: a user starts a job which generates a huge amount data
10:54: the user goes to get coffee
10:55: the job completes
11:00: The hourly cronjob runs btrfs subvolume snapshot ...
11:01: the user returns, starts the post-processing job
11:02: the post processing job completes, deleting all the intermediate data

The size of the snapshot is roughly equivalent to the size of the
intermediate data set, but with out that cup of coffee...  I'm sure you get
the idea.  :)

Experimentation and observation are your friends.

Aaron S. Joyner