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

  • 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


      • Originally posted by pal666 View Post
        this is idiotic conclusion. databases should use nocow files.
        So the advantage of having to manually tune fs features vs. no need to care about is.. ?

        Comment


        • Originally posted by pal666 View Post
          lol, btrfs is better on all those metrics. it is faster than ext4 if you know what you are doing, it is more stable than xfs(facebook statistics), and it has more advanced features than zfs from day one
          Could you show how to configure it to be faster than EXT4?

          Comment


          • Originally posted by Neuro-Chef View Post
            So the advantage of having to manually tune fs features vs. no need to care about is.. ?
            that you get btrfs features and you don't tank performance?

            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.

              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.
              Well with BTRFS you are basically opting in for a system that either protects your data... Meaning it has to go read only instead of returning garbage data. Other filesystems may return faulty data. You have to decide what you prefer.

              I do agree with your that there are quite a few things read should have been improved from a user's perspective, but then again auto recovery from failure and spare devices is not straight forward with btrfs due to the complex configurations that are possible. Besides the user interface is clean and simple to use and gives you more control than any automated system. Going read only is very and in case of a corruption. Just think about it.

              As for data loss in kernel 5.2. that was the only royal screwup in years. And it was an early release kernel that was patched later. Nobody should run filesystems on non LTS kernels unless they are prepared to use their backups anyway.

              http://www.dirtcellar.net

              Comment


              • Originally posted by waxhead View Post
                Well with BTRFS you are basically opting in for a system that either protects your data... Meaning it has to go read only instead of returning garbage data. Other filesystems may return faulty data. You have to decide what you prefer.
                Looks like btrfs is *more* likely to lose your data in the case of a drive failure than ext4 is. The common case is on a single disk and most users suck at making backups, remember that. So ultimately btrfs being able to warn users of corruption (but not be able to do anything about it in the *common* case) is tempered by the fact that when disk failures happen btrfs will generally behave worse.

                Originally posted by waxhead View Post
                I do agree with your that there are quite a few things read should have been improved from a user's perspective
                Great, so you agree and you won't brush it off as an edge case right?

                Originally posted by waxhead View Post
                but then again auto recovery from failure and spare devices is not straight forward with btrfs due to the complex configurations that are possible. Besides the user interface is clean and simple to use and gives you more control than any automated system. Going read only is very and in case of a corruption. Just think about it.
                ​​​​​​​
                Oh right, dealing with errors is an edge case so it's ok.

                Originally posted by waxhead View Post
                As for data loss in kernel 5.2. that was the only royal screwup in years. And it was an early release kernel that was patched later. Nobody should run filesystems on non LTS kernels unless they are prepared to use their backups anyway.
                Blaming the users for data loss. It's like you have zero empathy for users, what a surprise.

                Just think about it.

                Comment


                • Originally posted by starshipeleven View Post
                  with btrfs you can nocow on a file/folder basis too, so no need for partitions.

                  But in general I always, always separate OS partition from payload partitions as this allows me to quickly clone around generic OS images in a snap, without pulling around terabytes of databases and other random crap from one server to the next.
                  It still has a performance disadvantages to nocow on a btrfs partition compared to e.g. XFS though

                  Comment


                  • I support this, almost all the buzz about performance is from people that does nothing relevant enough to be protected and as so, should be using something else where walk on ropes with a unicycle is tolerable. ZFS would be a good choice but lets stop this kiddish arguing, it is just more juridic juggling with knifes.

                    My only complain is quota performance, it do result in freezes while rebalancing, deleting subvolumes, etc, and as this really affect use experience this need to be worked before it turns a default, another point that bothers me is the lack of native encryption, but this is not like there is a easy desktop friendly and flexible solution native to the kernel or other juridic safe file systems.

                    Comment


                    • Originally posted by phoronix View Post
                      better handling when running out of disk space
                      Can I get the citation on that? I do wonder which filesystem has a greater performance for disks that are nearly full or completely full.

                      Comment

                      Working...
                      X