Announcement

Collapse
No announcement yet.

SUSE Reworking Btrfs File-System's Locking Code

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

  • #31
    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.

    Comment


    • #32
      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.
      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).

      Originally posted by starshipeleven View Post
      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)

      Comment


      • #33
        Originally posted by DrYak View Post
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            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.

            Comment


            • #36
              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.

              Comment


              • #37
                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!

                Comment


                • #38
                  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.....

                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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.

                      Comment

                      Working...
                      X