Originally posted by moilami
View Post
Announcement
Collapse
No announcement yet.
SUSE Reworking Btrfs File-System's Locking Code
Collapse
X
-
Well, it's about damn time.... Maybe when the evaluate this locking code they'll finally figure out how to fix disk layout corruption.... It's come a decade too late, waaaayyy too many people have already had horrible experience with it and now it's reputation is so badly tarnished it'll never recover.
It's desperately way past due to kill BTRFS and its guaranteed disk corruption with fire and brimstone. We desperately need a new CoW FS with an -actually- stable disk layout. Time for FS devs to get coding.....
Comment
-
Originally posted by duby229 View PostWell, it's about damn time.... Maybe when the evaluate this locking code they'll finally figure out how to fix disk layout corruption.... It's come a decade too late, waaaayyy too many people have already had horrible experience with it and now it's reputation is so badly tarnished it'll never recover.
It's desperately way past due to kill BTRFS and its guaranteed disk corruption with fire and brimstone. We desperately need a new CoW FS with an -actually- stable disk layout. Time for FS devs to get coding.....
http://www.dirtcellar.net
- Likes 2
Comment
-
Originally posted by boxie View PostI had my first bad btrfs experience recently. 4 disk raid 5
Eventually, it will get there, specially given companies likes OpenSUSE (and Facebook, etc.) investing resources into it.
But that peculiar feature is not there yet.
It would be like using XFS (because it's stable) and then complaining because a mess ensued because you turned on a "they barely started this experiment yet" feature such as copy-on-write snapshotting.
Originally posted by boxie View Postand 4 disk raid10 - 1tb SMR drives - access latency was > 200ms (which is obviously not cool) - had to drop back to a 4 disk md raid 10 with ext4.
It's similar to running your EXT4 with an LVM layer in the middle with snapshotting enabled (except that BTRFS has a bit better performance in that regard).
Also, currently load-balancing isn't optimal between RAID1 copies in BTRFS (it's still a very primitive PID-base system)
If having the fastest best performance is the most important to you, you should indeed stick to more-to-the-bare-metal FS such as EXT4.
(Though keep in mind that in-place overwriting isn't necessarily the best for shingled drive - nor flash for what matter. You'd might be having a bit more success with some logstructured or another CoW filesystem. Compare with, e.g.: F2FS)
(Or switch to flash. SMR aren't really supposed to be used for performance, mostly for large volume archival - they are better used as "seldom written" drivers. At which point using a filesystem with CRC actually *makes* sense.)
Originally posted by duby229 View PostWell, it's about damn time.... Maybe when the evaluate this locking code they'll finally figure out how to fix disk layout corruption.... {...}
It's desperately way past due to kill BTRFS and its guaranteed disk corruption with fire and brimstone.
"fsck" doesn't make sens on a CoW FS (like BTRFS) or log-structured one. There is always by definition an older copy that is still consistent, and can usually be mounted and accessed with the corresponding recovery mount option.
If that fails, you can still use the btrfs restore to get back as much as possible from your data from an unmounted block device.
The only thing that kills BTRFS is hardware failure, which would kill any other file system too (and in this case, again, use btrfs restore to get as much as possible out of it. Whereas with an in-place overwrite FS, the proper procedure would be to make a perfect DD copy, and run fsck on that, and falling backing to photorec to carve out any lost file).
If you're afraid of hardware failure, use proper redundancy (and again, BTRFS' own RAID56 isn't stable, use MDADM instead for now).
And always backup (which is something for which CoW filesystem help simplify a lot, by using snapshot (opensuse's "snapper" tools simplifies a lot) to make history instead of complex "rsync with reference copies and symlinks/hardlinks". CRC on backups are also a reassuring thing)
Originally posted by R41N3R View PostBtrfs saved me several times from disk failures and I trust it more than other file systems, especially when it gets constant improvements like this.
Comment
-
Originally posted by DrYak View Post
Please, keep in mind that according to the official status RAID5/6 (the parity-based ones) is not officially considered stable. (Further reading about RAID5/6 available in the wiki).
Eventually, it will get there, specially given companies likes OpenSUSE (and Facebook, etc.) investing resources into it.
But that peculiar feature is not there yet.
It would be like using XFS (because it's stable) and then complaining because a mess ensued because you turned on a "they barely started this experiment yet" feature such as copy-on-write snapshotting.
I have a 5 disk raid5 in another machine, and it works flawlessly on the same type of drives - but - it has a much different access pattern.
The Raid10 setup also exhibited the same bad access latency.
The common denominator is the SMR drives. I am guessing btrfs has not had tuning done on it yet for these drives
Comment
-
Originally posted by DrYak View Post
Please, keep in mind that according to the official status RAID5/6 (the parity-based ones) is not officially considered stable. (Further reading about RAID5/6 available in the wiki).
Eventually, it will get there, specially given companies likes OpenSUSE (and Facebook, etc.) investing resources into it.
But that peculiar feature is not there yet.
It would be like using XFS (because it's stable) and then complaining because a mess ensued because you turned on a "they barely started this experiment yet" feature such as copy-on-write snapshotting.
Also keep the whole point of BTRFS is to have a whole layer handling several key features like CoW/snapshotting and systematic CRC checking of every bit of data (not only metadata) (and also optionnally compression).
It's similar to running your EXT4 with an LVM layer in the middle with snapshotting enabled (except that BTRFS has a bit better performance in that regard).
Also, currently load-balancing isn't optimal between RAID1 copies in BTRFS (it's still a very primitive PID-base system)
If having the fastest best performance is the most important to you, you should indeed stick to more-to-the-bare-metal FS such as EXT4.
(Though keep in mind that in-place overwriting isn't necessarily the best for shingled drive - nor flash for what matter. You'd might be having a bit more success with some logstructured or another CoW filesystem. Compare with, e.g.: F2FS)
(Or switch to flash. SMR aren't really supposed to be used for performance, mostly for large volume archival - they are better used as "seldom written" drivers. At which point using a filesystem with CRC actually *makes* sense.)
Disk corruption will mostly happen when you treat it as a regular in-place overwrite filesystem (which can leave the system in an inconsistent state) and try to run fsck (whose main job normally is to make sense out of inconsistent data, optionally with the help of a log journal) to "repair it". It will only corrupt it further.
"fsck" doesn't make sens on a CoW FS (like BTRFS) or log-structured one. There is always by definition an older copy that is still consistent, and can usually be mounted and accessed with the corresponding recovery mount option.
If that fails, you can still use the btrfs restore to get back as much as possible from your data from an unmounted block device.
The only thing that kills BTRFS is hardware failure, which would kill any other file system too (and in this case, again, use btrfs restore to get as much as possible out of it. Whereas with an in-place overwrite FS, the proper procedure would be to make a perfect DD copy, and run fsck on that, and falling backing to photorec to carve out any lost file).
If you're afraid of hardware failure, use proper redundancy (and again, BTRFS' own RAID56 isn't stable, use MDADM instead for now).
And always backup (which is something for which CoW filesystem help simplify a lot, by using snapshot (opensuse's "snapper" tools simplifies a lot) to make history instead of complex "rsync with reference copies and symlinks/hardlinks". CRC on backups are also a reassuring thing)
Just saved me again from a SD card corruption a couple of weeks ago.
EDIT: "You said eventually it will get there, but I have to wonder how many more decades will that take?Last edited by duby229; 10 June 2019, 06:54 AM.
Comment
-
Originally posted by starshipeleven View Postwtf is even "disk layout corruption" anyway.
I know, lets start with dd.... go ahead dd a btrfs disk and see if it works anywhere else..... Try it.....After you -actually- try it we can start a real conversation about lvm.Last edited by duby229; 10 June 2019, 07:03 AM.
Comment
-
Originally posted by duby229 View PostWhere do I even start.....
I know, lets start with dd.... go ahead dd a btrfs disk and see if it works anywhere else..... Try it.....After you -actually- try it we can start a real conversation about lvm.
There is a limitation when you do raw copies but it is not "it will not work anywhere else". Please be more specific so I know you know.Last edited by starshipeleven; 10 June 2019, 08:54 AM.
Comment
Comment