On Mon, Aug 22, 2011 at 2:17 PM, C Anthony Risinger <anthony@xxxxxxx> wrote: > On Mon, Aug 22, 2011 at 1:39 PM, Simon Schneider > <schneida.simon@xxxxxxxxx> 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
