SUSE Reworking Btrfs File-System's Locking Code

[Charlie68]

Btrfs is used by SUSE and other companies including Facebook, if it were not reliable they would not use it. Personally with openSUSE I never had any problems and when I installed it to users who weren't very experienced, they were really happy to be able to go back and cancel updates or a change, in a simple way.

[DrYak]

Btrfs is used by SUSE and other companies including Facebook, if it were not reliable they would not use it. Personally with openSUSE I never had any problems and when I installed it to users who weren't very experienced, they were really happy to be able to go back and cancel updates or a change, in a simple way.

openSUSE is a company that have always done exemplary level of work to support whatever solution they decided to use (side example: they've put the effort to make systemd work perfectly for them).

regarding BTRFS, they've also created a bunch of tools to help automate various BTRFS process.

user-facing tools like snapper which make the "update roll-back" work in a snap.

back-end oriented tools like "btrfs-maintenance" which helped automate common maintenance task (scrubing and balancing).

Yep. Extremely convenient, so I know what the thing is doing instead of seeing a hung terminal command for 5 hours.

Me too, I like the display of pv (though if you're forced to use dd - because of limited recovery boot - kill -USR1 is your friend against black dead screens)

[duby229]

Been there, done that, it works.
hehe, seeing like-minded people. Also enjoying nice ascii-art progress bars ?
I suspect that duby has tried to mount two btrfs systems with the same UUID on the same computer (which is a no-go), instead of using the DD image on a different computer as normally everyone does.

It is the UUID problem described here of course, so if you did that you certainly would have the same problem everuyone else has. There is nothing special about you that would make you immune to the same flaw that everyone else has to deal with.

[duby229]

Not really. If btrfs can't fix the fs issues with a scrub (and in normal cases it can, since metadata is always redundant), then there is serious fs damage caused by btrfs bugs, fsck may or may not be able to deal with that until the developers add the functionality. For most bugs or issues that crop up they do add functionality to fsck.

No.
No.
Still marked as unstable https://btrfs.wiki.kernel.org/index.php/Status
What is this?

FSCK for btrfs must be missing quite a lot then. I really don't know, but I do know if ytou attempt to use it various bad things happen.

Yes, balancing btrfs breaks it.
Yes defragging btrfs breaks it.
Yes RAID5/6 is still broken and unstable.In fact RAID -AT ALL- on btrfs is slow and horribly laggy. The whole concept they implemented just "feels" broken.
Yes, lvm breaks btrfs and not just when snapshoting either. Check it out if you dare.

[duby229]

I said I do that all the time.

Try to guess what little detail allows me to do it.

That's an obvious lie, if you really had then both of them would be irrepairable.

[duby229]

Btrfs is used by SUSE and other companies including Facebook, if it were not reliable they would not use it. Personally with openSUSE I never had any problems and when I installed it to users who weren't very experienced, they were really happy to be able to go back and cancel updates or a change, in a simple way.

It's actually a really bad shame, one of the worst shames ever in computing history. There are more corrupted filesystems in production right now than you can imagine. And with no tools that can detect it or correct it, you just have to wait for some data corruption to trigger a bug before you even notice it. SuSe should be sued out of existence for it.

[Charlie68]

It's actually a really bad shame, one of the worst shames ever in computing history. There are more corrupted filesystems in production right now than you can imagine. And with no tools that can detect it or correct it, you just have to wait for some data corruption to trigger a bug before you even notice it. SuSe should be sued out of existence for it.

Bullshit, I myself had data corruption with ext4, but I don't consider it a crap file system, it can happen regardless of the file system and I didn't sue Debian for this!

[duby229]

Bullshit, I myself had data corruption with ext4, but I don't consider it a crap file system, it can happen regardless of the file system and I didn't sue Debian for this!

Except of course, with ext4 you could run fsck and actually get the results you'd expect. But of course, with btrfs you run fsck and it ruins the fs even worse....

Difference here is that ext4 has tools that work and btrfs doesn't. If ext4 becomes corrupted it can be detected and corrected, if btrfs becomes corrupted there are no tools that can detect it or correct it. Btrfs becomes corrupted by simple means like balancing it, and that's an absolute requirement due to the rampant out of free space bug. Btrfs becomes corrupted by defragging it, and that's an absolute requirement because unlike ext4 which attempts to make certain every file has contiguous free space after every file, btrfs tries to mash them all right next to each other....

Everyone that uses btrfs -must- keep it balanced and defragged, but doing so -will- cause data corruption. And there isn't -any- way to even detect it, you just simply have to wait for the day that corruption triggers a bug.....

[starshipeleven]

Except of course, with ext4 you could run fsck and actually get the results you'd expect. But of course, with btrfs you run fsck and it ruins the fs even worse....

With btrfs you should run a scrub, not a fsck.

If ext4 becomes corrupted it can be detected and corrected,

fsck corrects only the fs metadata. If a file is corrupted even fsck won't do shit.

if btrfs becomes corrupted ... Btrfs becomes corrupted ... Btrfs becomes corrupted

No it does not.

unlike ext4 which attempts to make certain every file has contiguous free space after every file, btrfs tries to mash them all right next to each other....

Explain how leaving space after every file has any use for a CoW filesystem that has to write any modified block to free space and then when it is written will delete the old block with the old data.

You would still fragment the file. That's how CoW works.

Everyone that uses btrfs -must- keep it balanced and defragged, but doing so -will- cause data corruption.

No it will not.

[starshipeleven]

FSCK for btrfs must be missing quite a lot then. I really don't know, but I do know if ytou attempt to use it various bad things happen.

Not really. Each time Gparted software works on a btrfs partition is calling fsck on it (and predictably it does not break anything). They must be mad as hatters I guess.

Yes, balancing btrfs breaks it.

No it does not

Yes defragging btrfs breaks it.

No it does not

RAID -AT ALL- on btrfs is slow and horribly laggy. The whole concept they implemented just "feels" broken.

No it does not

Yes, lvm breaks btrfs and not just when snapshoting either. Check it out if you dare.

LVM breaks btrfs if you use them on the same partition.
Why are you using LVM with btrfs when you can use btrfs subvolumes anyway.