Announcement

Collapse
No announcement yet.

Linux 5.5 SSD RAID 0/1/5/6/10 Benchmarks Of Btrfs / EXT4 / F2FS / XFS

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

  • #41
    Originally posted by profoundWHALE View Post
    then in 2016 I tried a RAID10 set-up with 24TB worth of drives and the only reason why I didn't lose everything was because I had everything important backed up on some old drives.
    Having backup is always a good idea no matter what

    Originally posted by profoundWHALE View Post
    I spent 2 weeks of what I can only describe as hell. I had so much data to scrub through and for tools to comb through that I would have to run them for a whole day, only to find that it failed at like 25%.
    If your scrubs are taking multiple days, then there's something wrong.
    e.g.: some background tasks that takes way too much I/O.
    or e.g.: smartctl kicking into full long selt-tests (which also kill I/O on rotationnal media due to seeking)
    or you're stacking above a lower layer that also has it's own pitfalls (stacking above a mdadm RAID5/6 which brings in a lot of read-modify-write cycles. Or used shingled drives in a way that managed to increase the r-m-w cycles despite btrfs being cow)

    Normally scrub should take a couple of hours max, and is something that needs to be performed on a regular basis to guarantee data safety.
    (I tend to run it weekly, monthly is about the min recommandations).

    If you have I/O problems, you might consider (a stable a mature) SSD caching layer between BTRFS and the drives.

    Originally posted by profoundWHALE View Post
    And the problem is that losing 75% of data means I lost more like 25% because the corruption was all over the place randomly. I had wedding videos that had chunks of missing audio and video.
    If you get corruption all over the place:
    - you've been mistaken and actually run one of the features not considered stable (like RAID5/6 instead of RAID0/1, like extref or skinny on a to old kernel).
    - you've got some massive hardware problem the difference being that the BTRFS checksumming actually notices it. It needs to be very massive if the RAID1 duplication is insufficient for recovering data.

    In my very long experience with BTRFS I've never seen a filesystem corrupt itself "just because BTRFS". It was always either me playing with experimental options, or the medium breaking.

    Originally posted by profoundWHALE View Post
    Exactly, fsck is known to break the filesystem. It's a complaint I listed because if you have a serious problem and fsck is more likely to destroy your data than to recover it, maybe it's poorly designed.

    And no, I didn't just fsck it and type in whatever commands. I read up on the manuals and only did "safe" commands, the problem I had is they kept failing at like 75%.
    {...}
    If the filesystem fails, which happens, I should be able to run a file system check that doesn't destroy the filesystem.
    *BTRFS SCRUB* is the standard check that you need to run periodically on BTRFS.

    FSCK is a big no-no on BTRFS - it's always stated as a last-resort only procedure when everything else fails, and usually there are better options before.
    And doesn't make sense on a CoW system - there should always be an older copy you could roll back to. And always checksums to be able to check *which* is the last known good. Do not try to reconstruct filesystem information if you could just fetch a still good copy.

    So either the filesystem should work as-is in recovery mode. Or you have too much corruption on your filesystem (Note: write random shit on random sectors of any filesystem could do this, it's not BTRFS specific).

    At which point you should immediately consider using the well documented 'btrfs restore' to extract any file (currently missing in your backup) before the drive actually dies (and watchout the logs of the command for checksum fails - btrfs restore can be set to ignore checksum errors instead of interrupting).

    At which point you have already recovered what you need and need only to run FSCK if you want to play around with the corrupted filesystem.


    Originally posted by profoundWHALE View Post
    and right now I'm testing bcachefs. No corruption issues, yet
    Originally posted by profoundWHALE View Post
    But guess what? Every time I've had an issue, either the filesystem can fix itself, or Kent pushes an update that day.
    Sorry, I can't follow you. Which is which ? No corruption issue, or Kent pushing update to fix corruption ?

    Originally posted by profoundWHALE View Post
    I'm the one who posts the Mega download links for the Deb packages on Reddit.
    Megadownload links? On Reddit? Okay, that kind of says it all. (Please, try to learn using 3rd party repos and digital signature).

    Comment


    • #42
      Originally posted by profoundWHALE View Post
      Well now I know that you don't know what you're talking about. Maybe you should go troll somewhere else

      https://git.kernel.org/pub/scm/linux...cb5c58097b918e
      Marking the disk format as "no longer unstable" is NOT the same thing as marking the entire filesystem stable. How f*cking retarded do you have to be to make that leap of logic? You're just an overly excitable Consoomer who wants extreme stability and up-to-the-minute cutting edge at the same time. You can't have both.

      I truly hope you get stung again and lose lots of important data. Perhaps eventually you'll realize how moronic you are and start making decisions like an adult.

      Comment


      • #43
        Originally posted by DrYak View Post
        In my very long experience with BTRFS I've never seen a filesystem corrupt itself "just because BTRFS". It was always either me playing with experimental options, or the medium breaking.
        This guy probably can't even tell the difference. He obviously has no patience whatsoever and just wants to blame the first thing that isn't himself. Probably caused by the same ADHD that prevents him from waiting for a technology to mature before going all-in, despite claiming to want "rock-solid stability".

        This cretin's reasoning is just all over the place -- no wonder he's trashed his data 3 times.

        Comment


        • #44
          Originally posted by profoundWHALE View Post
          Well now I know that you don't know what you're talking about. Maybe you should go troll somewhere else
          https://git.kernel.org/pub/scm/linux...cb5c58097b918e
          Finalizing the disk format just means that they pinky-swear to stop breaking the on-disk format at every release. i.e.: a btrfs partition formated on alpha 0.16.1, shouldn't necessarily break because your kernel use a module alpha 0.16.2.

          From that point onward, they only concentrate on fixing bugs, and working on features that do not break the on-disk format of the data.

          e.g.: once extref, or a new compression (zstd) or a new checksum (lz4) is introduced, the driver should still be able to mount old partitions, and old drivers should detect the unsupported feature and gracefully refuse to mount or to read/modify the files instead of utterly crashing and/or corrupting the partition due to feature mismatch.

          It absolutely does not signify that a filesystem is stable. In fact it's quite the contrary: it's only at this point that the bug hunting can *even start*.

          Comment


          • #45
            Originally posted by DrYak View Post
            Having backup is always a good idea no matter what


            If your scrubs are taking multiple days, then there's something wrong.
            e.g.: some background tasks that takes way too much I/O.
            or e.g.: smartctl kicking into full long selt-tests (which also kill I/O on rotationnal media due to seeking)
            or you're stacking above a lower layer that also has it's own pitfalls (stacking above a mdadm RAID5/6 which brings in a lot of read-modify-write cycles. Or used shingled drives in a way that managed to increase the r-m-w cycles despite btrfs being cow)

            Normally scrub should take a couple of hours max, and is something that needs to be performed on a regular basis to guarantee data safety.
            (I tend to run it weekly, monthly is about the min recommandations).

            If you have I/O problems, you might consider (a stable a mature) SSD caching layer between BTRFS and the drives.



            If you get corruption all over the place:
            - you've been mistaken and actually run one of the features not considered stable (like RAID5/6 instead of RAID0/1, like extref or skinny on a to old kernel).
            - you've got some massive hardware problem the difference being that the BTRFS checksumming actually notices it. It needs to be very massive if the RAID1 duplication is insufficient for recovering data.

            In my very long experience with BTRFS I've never seen a filesystem corrupt itself "just because BTRFS". It was always either me playing with experimental options, or the medium breaking.



            *BTRFS SCRUB* is the standard check that you need to run periodically on BTRFS.
            Here's the story all about how my life got flipped, turned upside down....

            I'm using this thing for network storage access k? I have it automatically scrubbing and defragging. Then one day, I try to open a file (such as a video) and notice that it's missing some frame and some audio. I didn't think too much of it.

            Continued use of the system and more and more files were showing the same problems, some even saying that the file doesn't actually exist.

            So I manually run a scrub. When I say it takes a whole day I mean I start it in the morning and by the time I got back from work it should be done but it always failed at about 70%.

            I saw that there were some more things I could try with scrub by instead of trying to do it in the drives and then come back and try another one, I tried the several different commands on each drive. I found out when I get back home hat they halted due to errors, you know the errors that it's supposed to fix.

            Eventually I managed to copy the files from one drive to an empty drive and whatever was totally corrupted was skipped automatically.

            But then I found out that even if it copied, many files were missing chunks from them.

            I had to use the list of corrupted files to know what it is that I needed to recover from backup, I checked around and I still had the original SD card for things like wedding videos.

            So, like I said. For me, the person, I will never be able to trust btrfs.

            And don't give me that "well it probably was set up raid5 crap". Anyone with half a brain would test something like that (making sure ngthst it's RAID10 and working) to replace the whole data storage solution.

            -------

            I've never had any issues with corruption -yet- on bcachefs. The problems I'm referring to is stuff like a piece of the software isn't working quite right like a certain feature might not be functional yet or a girl update fails to build. The point was when there's a problem with bcachefs Kent is like oh I need to fix that.

            When there's a problem with btrfs it's just sort of a "quirk" which you should know about or else you'll lose your data or something fun like that.

            Comment


            • #46
              Originally posted by DrYak View Post

              Finalizing the disk format just means that they pinky-swear to stop breaking the on-disk format at every release. i.e.: a btrfs partition formated on alpha 0.16.1, shouldn't necessarily break because your kernel use a module alpha 0.16.2.

              From that point onward, they only concentrate on fixing bugs, and working on features that do not break the on-disk format of the data.

              e.g.: once extref, or a new compression (zstd) or a new checksum (lz4) is introduced, the driver should still be able to mount old partitions, and old drivers should detect the unsupported feature and gracefully refuse to mount or to read/modify the files instead of utterly crashing and/or corrupting the partition due to feature mismatch.

              It absolutely does not signify that a filesystem is stable. In fact it's quite the contrary: it's only at this point that the bug hunting can *even start*.
              You've completely missed my point and can't tell if you're agreeing with me or not.

              If btrfs is as unstable as you guys say "lololol you shouldn't pick something unstable" then why should anyone trust their data with it in the first place?

              And if it is "stable" then it shouldn't just eat all my data like it did.

              Feature additions are very VERY different from something like the fsck, something which should be working before it is ever mainlined in the kernel.

              My criticism is that it is not stable and therefore shouldn't be trusted. For a system trying to replace ZFS, that's pretty bad.

              Comment


              • #47
                Originally posted by profoundWHALE View Post
                If btrfs is as unstable as you guys say "lololol you shouldn't pick something unstable" then why should anyone trust their data with it in the first place?

                And if it is "stable" then it shouldn't just eat all my data like it did.
                It wasn't stable in 2013. No one claimed it was back then. If you had half a brain you'd realize that a commit in December 2013 marking the disk format as "no longer unstable" ought to indicate that the filesystem as a whole is still pretty unstable.

                In 2020, Btrfs is now relatively stable. Shock horror, 7 years makes a difference.

                Originally posted by profoundWHALE View Post
                My criticism is that it is not stable
                Your criticism is bunk, due to being a clueless brainlet with severe ADHD. It's hard to take anything you say seriously after thoroughly demonstrating how idiotic you are...

                Comment


                • #48
                  You're an idiot, or a troll, or perhaps both.

                  2016 was the year I used it for real. You can't even keep the simplest of things straight and can't stop yourself from projecting. I don't care about your ADHD.

                  Comment


                  • #49
                    Originally posted by profoundWHALE View Post
                    You're an idiot, or a troll, or perhaps both.
                    2016 was the year I used it for real. You can't even keep the simplest of things straight and can't stop yourself from projecting. I don't care about your ADHD.
                    You probably think you're trolling me, but you're actually trolling yourself...

                    Comment


                    • #50
                      Haha that's a new one. I think I'll leave you and your mental gymnastics alone now

                      Comment

                      Working...
                      X