Announcement

Collapse
No announcement yet.

There's A Proposal To Switch Fedora 33 On The Desktop To Using Btrfs

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

  • Originally posted by waxhead View Post

    As for you Space Heater : You spread incorrect information. i do follow the BTRFS mailing list, and use BTRFS quite a bit myself for both desktop and server use so I do have some experience with it.
    ...
    What people use BTRFS for is precisely reliability and while I myself got bitten by the nasty corruption bug in kernel 5.2 (which is NOT LTS by the way) I was still able to extract most of my files, confidently knowing that they where ok thanks to data checksums without having to resort to backups.
    Checksumming is great when you have redundant copies of data so that you can repair the corruption, but btrfs' raid capabilities seem to still be incomplete/immature even with raid 1. In the end, detecting corruption is always nice, but it's not nice if it results in dropping a user to a rescue shell where the average user is going to be completely confused and will assume the filesystem is toast. From what I have seen and experienced, there appears to be zero empathy for the user experience in the btrfs community, unfriendly or confusing behavior is just brushed off as an edge case.

    I truly hope I'm completely wrong about btrfs and that it's done a 180 from where it was just a few years ago, but you casually mentioning that you lost data as recently as kernel 5.2 is the opposite of convincing (also Fedora does not stick to LTS kernels). In the end no amount of the advanced features matter if the file system itself goes sour.
    Last edited by Space Heater; 28 June 2020, 01:30 PM.

    Comment


    • Originally posted by profoundWHALE View Post
      I find it funny that I'm accused of being a ZFS shill. I've put ZFS on one system and it was a 2013 chromebook.
      I mainly run EXT4 or bcachefs, including running bcachefs on /

      Hopefully the btrfs shills don't get burned like I did and lose terabytes of data. Luckily I had a physical backup of the most important stuff due to paranoia.

      Every time I hear someone say "BTRFS is good now!", all I hear is the boy who cried wolf.
      Cool story bro.

      Comment


      • Originally posted by Vistaus View Post

        ... so you just choose a different file system during partitioning. Problem solved.
        I'm pretty sure that isn't an option with the Fedora installer any more.

        Comment


        • Originally posted by Space Heater View Post
          Checksumming is great when you have redundant copies of data so that you can repair the corruption, but btrfs' raid capabilities seem to still be incomplete/immature even with raid 1. In the end, detecting corruption is always nice, but it's not nice if it results in dropping a user to a rescue shell where the average user is going to be completely confused and will assume the filesystem is toast. From what I have seen and experienced, there appears to be zero empathy for the user experience in the btrfs community, unfriendly or confusing behavior is just brushed off as an edge case.
          when there are hardware issues in a btrfs raid, btrfs does the only sane thing he can do to avoid corrupting your data, that is puttin in in ro mode or non allowing you to mount it, unless you explicity say that you want to run it in a degraded mode.

          Manual intervention is required, and there's nothing that btrfs (or, any other fs) can do about it.

          Stop complaining about it and just learn how OS stratitification works.
          The "user experience" is not something regarding the kernel, is something that lays in userspace and is a reponsability of the distribution.

          Comment


          • Originally posted by profoundWHALE View Post
            Hopefully the btrfs shills don't get burned like I did and lose terabytes of data. Luckily I had a physical backup of the most important stuff due to paranoia.
            that's not called paranoia, it's called common sense and it applies to all filesystems of all OSes on all kind of storage.

            Comment


            • Originally posted by cynic View Post
              when there are hardware issues in a btrfs raid, btrfs does the only sane thing he can do to avoid corrupting your data, that is puttin in in ro mode or non allowing you to mount it, unless you explicity say that you want to run it in a degraded mode.

              Manual intervention is required, and there's nothing that btrfs (or, any other fs) can do about it.
              OpenZFS does not drop you to a rescue shell when you reboot after one drive in a raid1 array dies, unlike btrfs. In fact btrfs is the only filesystem I'm aware of that does this. Yet somehow OpenZFS isn't dropping data on the floor in this case, I wonder how it can do what you deem to be insane or impossible?

              Originally posted by cynic View Post
              Stop complaining about it and just learn how OS stratitification works.
              The "user experience" is not something regarding the kernel, is something that lays in userspace and is a reponsability of the distribution.
              This has nothing to do with "OS stratitification", but has a lot to do with btrfs-specific weaknesses. Thanks for projecting your condescension and ignorance towards me.

              Comment


              • Originally posted by cynic View Post
                when there are hardware issues in a btrfs raid, btrfs does the only sane thing he can do to avoid corrupting your data, that is puttin in in ro mode or non allowing you to mount it, unless you explicity say that you want to run it in a degraded mode.
                This is a load of bs. I can expect this basic non-reaction from brainless crap like mdadm, but a filesystem like btrfs should be perfectly capable of just automatically rebalancing the stuff that is now without parity on the remaining drives. (and there was a patch to do this saner "degraded mode", but of course it was stopped in a limbo because it didn't cover 100% of possible usecases)

                Hell, even mdadm does not just go read-only for lulz like that, the default reaction of most RAID systems is to just run in degraded mode and that's what is fair to expect. You need some form of notification system so they can tell you that something is fucked, but in the mean time there is no interruption of service and the RAID does its best to keep working as it was before.

                But wait, btrfs has no "degraded mode", if a disk fails it goes to "single", regardless of the original RAID level, and if I reboot the system it refuses to mount it unless I pass -o degraded which puts it into braindead state but at least it is rw.

                Comment


                • Originally posted by starshipeleven View Post
                  This is a load of bs. I can expect this basic non-reaction from brainless crap like mdadm, but a filesystem like btrfs should be perfectly capable of just automatically rebalancing the stuff that is now without parity on the remaining drives.
                  Only brainless sysadmins would prefer major things like this to be triggered automatically. It might make sense for a desktop distribution like Fedora, though, but only after six or seven releases beyond the initial deployment of the FS.

                  Comment


                  • On a desktop, I'd rather a mature filesystem with a low-latency focus such as NILFS2.

                    Which by the way also has snapshots and data checksums.

                    Comment


                    • Originally posted by curfew View Post
                      Only brainless sysadmins would prefer major things like this to be triggered automatically.
                      which is why each and every RAID in existence just dies whenever a drive has issues and you reboot the system.

                      Protip: RAID systems usually go in "degraded mode" and set off alarms, but are otherwise still functional even on reboot.

                      Comment

                      Working...
                      X