[arch-general] btrfs & Arch

[C Anthony Risinger]

On Mon, Aug 22, 2011 at 2:17 PM, C Anthony Risinger <anthony at xtfx.me> wrote:
> 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)

while i haven't personally (er... knowingly ;-) experienced any
problems, it's appropriate to mention that recently there have been
some reports of silent data-corruption in some setups.  i dont think
the exact cause is known yet ... but it also sounds like the new
btrfsck will tackle much of it.

... tbh, unless you want to get a feel for it, are ready to
troubleshoot, or have a specific use-case -- and have some other
backup systems in place -- you'll probably just want to roll with "the
usual" for now.

-- 

C Anthony