What makes btrfs actually better?

>>56598893
actually nothing. it's a filesystem, most users can't see the differences between them

I've hard too many horror stories to trust my data with btrfs.

>>56598893
Less fattening than real butter.

>>56598893
Killer feature for me is near-instant, atomic, (sub)volume-level incremental backups.

File: mpv-shot0002.jpg (158KB, 1920x1080px) Image search: [Google]

158KB, 1920x1080px

>>56601361
>tfw the first time i copied a large/many small files to a new location.

Holy blazing jesus balls that was fast.

>>56601440
Its not really copying it though, its basically doing a hardlink under the hood. Any cow fs will do this (or its not a cow fs).

>>56601440
it's doing reflinks

basically, instead of making a new copy of the file, it simply creates a new file and links its content to where the other file is stored

it's not the same as a hardlink though, they still act like independent files, modifying or deleting one won't affect the other

native subvolumes, like partitions only they're naturally thin-provisioned (they're the size of their content, rather than fixed sizes)
compression, reflinks
native raid, which is very flexible, allowing for things like level conversion and fast disk adding/removing while online, and can make efficient use of disks which are different sizes
online volume resizing
to name a few

>>56601638
you forgot corrupting your data.

>>56601650
years ago, definately, but besides raid5/6 the stability is pretty good nowadays

speaking of that, btrfs of course also has checksumming, allowing for detection and repair (when using raid>0) of errors

i was using raid5 for one volume, which did eventually fall apart, but their recovery tools have gotten pretty good, and despite it being non-mountable, i still managed to get everything off the disks
in fact, recovery is much better than anything i've used before, it managed to not only restore all the files, it did so with the original names, in their original folders, and with their original permissions, literally lost nothing

>>56601740
>besides raid5/6

Yes, besides the feature that is most attractive to people who are the LEAST tolerant of data loss, it works fine :^).

>i was using raid5 for one volume, which did eventually fall apart, but their recovery tools have gotten pretty good, and despite it being non-mountable, i still managed to get everything off the disks

Because you had no actual data loss, so it just had to "find" it on disk and fix the records. If you had lost data, the parity would have failed any you would have been fucked.

I like the idea of btrfs, but it needs more work before its production ready. zfs is a better choice for now.

>>56601801
until they sort out raid5/6, you can still put btrfs on top of mdadm raid5/6
you lose the flexibility, but then, other filesystems depend on mdadm (or hardware) for raid anyway, so it's not like you're /worse/ off

zfs(onlinux) does have native raid also, and i did use it for some time, but its raid is very inflexible, it's very much only designed and suited for big setups, which is fine, that was their goal, but it makes it less useful for smaller home setups

>>56601947
What part of "production" implied "smaller home setups"?

>>56598893
It's basically all the features of Reiser without having all the slav-mail-order-bride-murdering primadonna issues like not playing nice with the VFS model, and it's not owned by Sun/Oracle.

>>56601638
>compression

why is this always touted as some great FS feature?
why isn't it looked at more as a layering violation?
I don't need by FS heuristically applying nigger-tier LZ variants when most of my data is already in media-specific compressed file formats.

>>56598893

CHEAP

ZFS

WANNABE

>>56601947
it's a shame btrfs RAID6 is fucked because the improvements it offers over regular mdadm RAID are what would make it perfect for the hobbyist data-hoarder. On-line rebalancing, checksumming and scrubbing, the ability to add (or remove, unlike ZFS) disks of pretty much any size individually without hassle.

I suspect the devs don't really want to bother with fixing it though. Project leader works for Facebook and they have their eyes on clustering for redundancy. Some guy submitted code a while back for 3/4/5/6-way pairity, in addition to 1 and 2 way (RAID 5 and 6) and he shot it down, saying basically "Don't care, we don't need it"

>>56601166
Old stories, you know time.

>>56598893
The fact that HAMMER2 isn't mature yet, because when it becomes mature it's going to be the best filesystem around.

>>56602122
>>why is this always touted as some great FS feature?
it's computationally cheap and gets you large space gains for some types of data, and does so completely transparently to the rest of the system
>why isn't it looked at more as a layering violation?
aren't we past this layering-violation fetish? The reason ZFS and btrfs are able to do the Good Things they do is because they're willing to abandon the strict separation between the RAID layer, the volume management layer, and the filesystem.
>I don't need by FS heuristically applying nigger-tier LZ variants when most of my data is already in media-specific compressed file formats.
I have it on for my array, even though the vast majority of my data is similarly incompressible. Because the speed cost is less than negligible (In ZFS the compressor is tuned to give up quickly when it encounters incompressible data) and occasionally some things compress well. It saves you space (maybe a tiny bit, maybe a very great deal, depending on your data) essentially for free.

>>56602122
>why is this always touted as some great FS feature?
you don't have to enable it, it's not even on by default
>why isn't it looked at more as a layering violation?
many of the Nice Things(tm) btrfs can do can only be done /because/ it handles every layer

>>56602222
quads

>>56601638
>cant even murder your wife

>>56598893
things it does better than ZFS: reflink copies, on-demand dedup, resizing
things ZFS does better: raid5/6, cache tiers
things non-CoW filesystems do better: being nice to spinning rust, database workloads