[arch-general] btrfs & Arch

[C Anthony Risinger]

On Mon, Aug 22, 2011 at 1:39 PM, Simon Schneider
<schneida.simon at gmail.com> wrote:
> Hi
>
> I was about to use btrfs for my new SSD but I couldn't find any reason why I
> shouldn't stay with my normal LVM and ext4 setup. Is there any particular
> reason why everyone is so crazy about that new fs?

for me at least i like how simple it is to try stuff ... one of my
favorite features is throwaway snapshots for testing various
*whatever*.  i can setup a chroot and instantly clone it and throw
away just as fast; IIRC `mkchrootpkg` does this by default it it
detects btrfs.

LZO compression on my eee s101 netbook (32GB "aftermarket" Runcore
SSD) has made a *definite* difference in system performance.

... and also a simple rsync (inplace) script can give you
fast/efficient "folding"/differential backups with very little work
(and this will work even better once offline [or online i guess]
de-dup is rocking)

i also use btrfs *heavily* in conjunction with namespace containers
(eg, lxc-tools and friends) -- btrfs is the perfect companion.  i can
create hundreds of development/staging/production containers in
seconds (if i actually needed them that fast ;-).  it's the
realization of namespaces at FS level.

i dont know much about LVM or soft-raid setups, and im sure much of
the above can be achieved with --bind mounts, layers of this-and-that
... but btrfs is simple and effective.  lastly -- and this is maybe a
growing trend -- LVM works at the block level whereas btrfs is object
level; btrfs can have object policies (eg RAID) with some objects
partially in one state or another (eg compression), intelligent
rebuilds (doesn't have to behave like a generic/dumb block device) ...
this means things like RAID1 only EVER have 2 copies of an object ...
even if there are 15 disks each object will only have 2 complete
copies so space can be utilized more effectively ... this also helps
to make full use of arrays with mismatched disk sizes/capabilities.
<---(these last bits were discussed on the list recently, and i may be
stating it incorrectly.  by all means, correct me if necessary)

-- 

C Anthony