SUSE Continues Working On Transactional Updates With Btrfs

[Ignacio Taranto]

That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.

Have you ever used openSUSE/SUSE?

[RomuloP]

I've never faced a single problem like this, only the provisioning problem and a performance penalty by quotas, I would miss my / fs not being "snapshotable" This is the second machine to where I mirror my system. I really don't like reinstalling things and send receive is a great way of transplanting a system. I was considering playing with ZFS last year (it is good to know more solutions) but ZFS as root appears to be a messy hack... I will play with it anyway, I'm curious about ZVOLS and it's support to other FSs.

[dfyt]

I feel this has to be challenged.
1. How much data did you copy?

About 2.1T...although BTRFS will tell you 2.3T

2. Was it large or small files?

Mixed. VDI's, Movies, Jpgs, Games, Sourcecode. Basically a home folder.

3. How did you find out that BTRFS did use over 200GB more than ZFS/XFS?

df -hl. Note this is just a plain format as BTRFS then rsync so no snapshots etc. Source is XFS, then rsync to ZFS and BTRFS

When I last investigated this I was told it was due to some provisioning done by the filesystem - either way it seems way too excessive to me. Out the box. About a 2 years ago I did the same for my media centre and had big differences between BTRFS and ZFS both with compression off.

4. Locked directories look like they could be subvolumes as Zan Lynx said. Are they?

No there were not subvolumes, they we normal subfolders and sometimes even actual files - hence why I say corruption. Even booting from another distro / live would leave those specific files/folders as readonly even as root. Often you would not know which files but apps would misbehave then you see why as the settings files weren't been saved as they were "locked".

I have never lost data per se with BTRFS but have had regular corruption issues. I have only ever lost an entire drive with ZFS...faulty SATA cable - yet imo this still should not have cause me to be unable to mount the drive.

For me...

EXT4 for external drives
ZFS for raid or home
XFS root - if XFS get checksumming - it would be awesome.

[ZeroPointEnergy]

I don't get the people who still use something other than BTRFS or ZFS. Even if there are still some edge cases where it has problems, that is what a backup is for which you need anyway because of stuff which is a gazillion times more likely to happen like hardware failure or user errors.

On the other hand if you use EXT4 or whatever and get bitrot, which is really not uncommon when you have terabytes of data it will corrupt your backups as well and no one will ever notice until it is probably too late.

[patrakov]

Regarding snapper support for LVM + EXT4. As a person who used it, I would say it is a bad joke. It did save me from a long recovery procedure twice, by offering to roll back the system to a state it was in 1 hour before. But it also created two problems of its own. The issue is that in such stacked setup there is no good concept of available disk space, and if the LVM thin pool for snapshots fills up, you'll get I/O errors and filesystem corruption in the upper layers.

See https://lwn.net/Articles/747633/ for what XFS developers promise in this situation (and at least, they describe the status quo and its problems accurately).

[brrrrttttt]

That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.

It's no more complicated than competing filesystems (ZFS)...

[pal666]

I recently backed up a 4TB drive to another identical drive, BTRFS used 200GB more with compression over XFS or even ZFS.

btrfs duplicates metadata by default even on single drive(and can duplicate data if you choose). xfs does not support raid features at all, zfs requires multiple underlying drives to give you ability to recover from bitrot via raid1 and checksums. btrfs is superior to both of them, it uses more space to protect your data. but idiots will complain

Additionally whilst I haven't lost data I have often had times where the filesystem locks folders and you can't delete them etc.

move empty bugged folder to /lost+found/ , problem solved

[pal666]

I dont understand the thinking of Fedora and the choice to go with xfs on LVM. There is no way thats better than a volume and snapshot integration into the filesystem. They say "btrfs has problems"

instead of saying "we are not btrfs devs, so we do what we can"

[pal666]

The reason to stay away from snapshots (for beginners) is because defrag breaks reflinks and can increase space usage significantly.

this applies only to defrag + longlived snapshots. shortlived snapshots can provide atomicity for backups etc

[pal666]

ZFS has a similar model to btrfs,

no, zfs does not use btrees, because it was designed before invention of cow btrees. i.e. zfs is obsolete, i have no use for filesystems which can't change size (this rules out xfs as well)

ZFS is an excellent filesytem and more mature than btrfs

on solaris. but on solaris you can't choose btrfs anyway

so that can be another option, if one doesnt worrry too much about the BSD and GPL issue.

and if one doesn't worry too much about downloading some unsupported broken shit from internet