Announcement

Collapse
No announcement yet.

SUSE Reworking Btrfs File-System's Locking Code

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic SUSE Reworking Btrfs File-System's Locking Code

    SUSE Reworking Btrfs File-System's Locking Code

    Phoronix: SUSE Reworking Btrfs File-System's Locking Code

    SUSE continues to back the Btrfs file-system and as part of that investing in new/improved functionality around this Linux file-system once billed as the competitor to ZFS. This week one of the SUSE developers sent out a set of patches implementing a new "DRW" lock and wiring that into the file-system driver...

    http://www.phoronix.com/scan.php?pag...Btrfs-DRW-Lock

  • starshipeleven
    replied
    Originally posted by duby229 View Post
    It's actually a really bad shame, one of the worst shames ever in computing history.
    It's almost as bad as Intel integrated graphics are for gaming, isn't it?

    There are more corrupted filesystems in production right now than you can imagine.
    No there aren't.

    And with no tools that can detect it or correct it,
    lol no.

    SuSe should be sued out of existence for it.
    SUSE is one of the best distros if you want to use btrfs as they do care and backport fixes and stuff.

    God help the poor souls that are using Ubuntu.

    Leave a comment:


  • Charlie68
    replied
    ...Beyond this, SUSE does not use Btrfs for data, but uses XFS. Sometimes certain statements are just words in the wind ....

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by Charlie68 View Post

    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.....

    Leave a comment:


  • Charlie68
    replied
    Originally posted by duby229 View Post

    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!

    Leave a comment:


  • duby229
    replied
    Originally posted by Charlie68 View Post
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:

Working...
X