Announcement

Collapse
No announcement yet.

Btrfs Sends In Fixes For Linux 6.10 & Restores "norecovery" Mount Option

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

  • #21
    The only time I had data recovery issues with btrfs was when running in raid5 mode with a faulty ddr4 stick for weeks, at which point so much data was corrupted only a restore was possible. I doubt other filesystems would have fared better. I'm running btrfs on my desktops and servers pretty much since the beginning because of the snapshot feature.

    Comment


    • #22
      Originally posted by kreijack View Post



      theriddick, if you are experiencing so many problem with BTRFS, may be you have some HW problem ? Or you have some uncommon configurations ?
      I've had this issue across a few machines. Normally the data lost is not a huge issue but the fact it keeps happening where the recovery tools FAIL to do anything about the partition and just say, broken, can't mount ever, its dead jim... is not a positive experience for me. It isn't a issue, until it is, then your fcked

      Comment


      • #23
        Originally posted by F.Ultra View Post

        you cannot call this false unless you also invented a time machine, went back in time before your system crash, changed the fs to EXT4 and then saw if you could recover from that very specific situation.

        Personal anecdote is that I had an ageing PSU that couldn't handle the sudden power spikes of my 7900xtx so I had several total system lockups per day for weeks until I understood that the issue was the PSU. None of my btrfs drives even needed recovery after any of those and yet I was often doing write intensive work at the time of crash. At work I've also had large servers with 40+ drives in a single btrfs partition survive hardware failure of drives with zero hiccups.

        On the other hand I have had several EXT4 and NTFS (from the Windows 2000 days and earlier when I still had to use Windows for work) that have died with zero recovery possibility.

        Btrfs is the most reliable fs I have every used in my 42 years of computing.
        Funny. Using btrfs from many years ago, before I had a UPS... a power outage would often cause my root partition to be completely trashed. Recovery was impossible, and indeed, trying to fsck only made things worse. Eventually switched back to ext4 after consistent problems, after giving btrfs enough goes. ext4 has never failed to recover from sudden outages for me. Ever.

        Now, for comparison, bcachefs has always managed to recover from outages for me ~ even when fsck was broken for some reason, as I was and still am using bcachefs Git master, I have never lost data. When the fsck issues were fixed, my data was still there, in its entirety. Even in the earlier days of bcachefs.

        More than I can ever say for my time with btrfs, which gave me more pain than was worth. When I finally divorced btrfs, it was with bitterness. Never trusted it again.

        Comment


        • #24
          Originally posted by theriddick View Post

          I think it was 6.8 at the time, but I've had it happen in the past on different kernel versions. It's just btrfs inability to reliably recover partitions that have data corruption which is common when a system hard locks. This is on a SSD+NVMe btw.

          F.Ultra just going to ignore your dribble here after. A system lockup is a system lockup, and this is not a isolated incident that only IV'E experienced when using BTRFS.
          It may be too late, but have you tried btrfs restore? Once, I had a damaged hard drive, and the only tool able to recover anything was btrfs restore.
          It is a bit unfriendly to use though.

          Comment


          • #25
            Poettering is in the right here, obviously. Furthermore, if you were going to change the name of this option, seeing what everyone is actually using it for... How about, ro_for_realsies_i_mean_fucking_only?
            ​​​​

            Comment


            • #26
              Originally posted by aviallon View Post

              It may be too late, but have you tried btrfs restore? Once, I had a damaged hard drive, and the only tool able to recover anything was btrfs restore.
              It is a bit unfriendly to use though.
              Oh yes, I tried everything. There was one command that let me temp mount it but no files appeared and the repair methods still failed on it.

              If you do a deep search on the internet you will see many people with btrfs partition failure issues. Some get lucky and can fix them, but not all.

              Comment


              • #27
                Originally posted by Valmar33 View Post

                Funny. Using btrfs from many years ago, before I had a UPS... a power outage would often cause my root partition to be completely trashed. Recovery was impossible, and indeed, trying to fsck only made things worse. Eventually switched back to ext4 after consistent problems, after giving btrfs enough goes. ext4 has never failed to recover from sudden outages for me. Ever.

                Now, for comparison, bcachefs has always managed to recover from outages for me ~ even when fsck was broken for some reason, as I was and still am using bcachefs Git master, I have never lost data. When the fsck issues were fixed, my data was still there, in its entirety. Even in the earlier days of bcachefs.

                More than I can ever say for my time with btrfs, which gave me more pain than was worth. When I finally divorced btrfs, it was with bitterness. Never trusted it again.
                well you say "many years ago" and there where plenty of time in the early days of btrfs where it wasn't production ready so it highly depends on which kernel version you ran back then.

                Originally posted by theriddick View Post

                I think it was 6.8 at the time, but I've had it happen in the past on different kernel versions. It's just btrfs inability to reliably recover partitions that have data corruption which is common when a system hard locks. This is on a SSD+NVMe btw.

                F.Ultra just going to ignore your dribble here after. A system lockup is a system lockup, and this is not a isolated incident that only IV'E experienced when using BTRFS.
                ​Why so hostile just because my experience doesn't match yours? I have never once stated that your experience wasn't true.

                Comment


                • #28
                  [QUOTE=F.Ultra;n1467052]
                  well you say "many years ago" and there where plenty of time in the early days of btrfs where it wasn't production ready so it highly depends on which kernel version you ran back then.
                  /QUOTE]

                  This was during a time btrfs was considered production ready. It was no long considered stable and ready for widespread usage. I jumped on-board enthusiastically.

                  Originally posted by F.Ultra View Post
                  ​Why so hostile just because my experience doesn't match yours? I have never once stated that your experience wasn't true.
                  I was just sharing my experience which runs counter to yours. I just find your statements about btrfs to be quite untrue for many who've suffered unrecoverable corruption. I know, because I went through too many cases of it. btrfs gave me corruption that couldn't be fixed, and was only made worse by trying to fsck it. btrfs's fsck is so unreliable that it can permanently corrupt your data. Which is why they recommended never using the repair option, and suggest a bunch of other options instead. Seems like they can't even fix their fsck because of how broken it is.

                  Meanwhile, bcachefs, even before being upstreamed, never ate my data. bcachefs's fsck actually does what fsck should do ~ and it doesn't run the risk of trashing your filesystem. At worst, it might get stuck. I have no choice but to uncleanly shut the filesystem down. But the filesystem never got trashed. Yes, fsck occasionally didn't work, but my data was still recoverable by downgrading to an earlier commit. This is true even now. I was pretty cautious about moving to bcachefs, because of my experiences with btrfs.

                  Another user had put a test server through stress testing, simulating sudden power outages to test the filesystem's resilience, and they never lost data. So that made me trusting enough to try it out on my end. And sure enough, power outages have never trashed the filesystem. Not even simulated ones, out of curiosity.

                  Comment


                  • #29
                    TBF since btrfs had provided norecovery for a long time, and other filesystems already supported norecovery, btrfs shouldn't have dropped it in the first place. Good to see it back.

                    Comment


                    • #30
                      Originally posted by F.Ultra View Post

                      well you say "many years ago" and there where plenty of time in the early days of btrfs where it wasn't production ready so it highly depends on which kernel version you ran back then.



                      ​Why so hostile just because my experience doesn't match yours? I have never once stated that your experience wasn't true.
                      Because your comments are contradictory and blatantly false.

                      Comment

                      Working...
                      X