Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

phoronix.com

Post reply on HN
Print view View original

191–200 of 231 posts

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#191

Post by em-bee »

freeqaz wrote: post #80

We run BTRFS on our work laptops and have been for a few years now. Keep in mind that we're only 4 devs, so our sample size is small, but we haven't had any issues with it so far and it's been very pleasant to use so far! We published our internal doc for how we install our Arch setup with fully encrypted BTRFS if anybody is curious. Happy to answer any questions too! https://www.lunasec.io/docs/blog/arch-linux-insta…

i am running fedora on encrypted btrfs, on top of a mirror raid, and i have a lot of problem with the performance of the disk. I/O frequently hangs the GUI for a few seconds. throughput is fine once it gets going, but random access to many files appears to be an issue. searches pointing to btrfs on encryption being slow, but i think the raid is also a factor.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#192

Post by prmoustache »

dekhn wrote: post #27
dale_glass wrote: post #19

But is the RAID handling remotely sane yet? See https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... It has gems such as: * It won't boot on a degraded array by default, requiring manual action to mount it * It won't complain if one of the disks is stale * It won't resilver automatically if a disk is re-added to the array I think the first is the killer. RAID is a High Availability measure. Your system is…

Many folks I know who manage storage don't make the boot volume RAID (redundant)- instead, it's some rapidly duplicatable thing like an NMVE flash containing the root filesystem, and there's a replacement handy. Then you can bring up and bring the full power of userspace to bear on the RAID repair.

Back when solaris wasn't using zfs yet, we were using the live upgrade utility to duplicate the main boot environment on a local disk every night.

Machines booting from SAN had only one local disk, others would have 3 local disks (small and cheap ones because application data was on SAN anyway).

Main raid would do the job for availability in term of disk failure, 3rd bootdisk did the job in case of user erroror data corruption on the main boot env. It saved our asses a few times, bringing apps back online quickly and saving us from reinstalling or fixing stuff from a tenporary live environment.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#193

Post by matheusmoreira »

xorcist wrote: post #177
dale_glass wrote: post #19

But is the RAID handling remotely sane yet? See https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... It has gems such as: * It won't boot on a degraded array by default, requiring manual action to mount it * It won't complain if one of the disks is stale * It won't resilver automatically if a disk is re-added to the array I think the first is the killer. RAID is a High Availability measure. Your system is…

Remember that DM is still there for you even if you use btrfs. Every discussion about btrfs immediately escalates to how the btrfs RAID support develops. But btrfs is useful on its own without that mode. Should you wish to put a btrfs file system on software RAID (DM), you can still do that. The btrfs RAID modes are something else, where you cut the DM driver out of the picture. That's not going to be as well tested…

Yeah but DM doesn't have the btrfs flexible block allocation scheme that allows me to expand capacity one drive at a time and with drives of different capacities. This is very important for a home user like me.

To expand a typical RAID setup, you have to essentially fail every single drive in the array and replace them one by one with new identical drives. Expanding an array of N drives requires N resilvers which not only takes a long time but increases the chance of actually failing those drives due to massive I/O load. It's easier to build a second array and copy the data over. This combined with the fact you have to buy all the hardware up front makes it cost prohibitive for home users. You can't buy drives one at a time and expand capacity as needed.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#194

Post by ndsipa_pomu »

RealStickman_ wrote: post #147
alerighi wrote: post #92

Earlier quoted context omitted.

No, because I want to be elsewhere on a Sunday evening than in front of a computer modifying fstab to bring a production server back online.

Unless you want to reboot the server this shouldn't affect you in any way.

Unless you get a power outage or some other event that causes a reboot (e.g. STONITH)

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#195

Post by tecleandor »

happymellon wrote: post #166
jiggawatts wrote: post #75

Earlier quoted context omitted.

The list of bugs and counter-intuitive design decisions in BTRFS RAID should make anyone pause before ever considering it as a viable filesystem for anything . It's like people justifying MySQL saying that it's okay for it to lose or corrupt data, and that transactional integrity doesn't matter as much as people say it does. Yeah, maybe if you're website is a blog. But anyone storing real data should run away screami…

I've had more issues with my ZFS arrays than the BTRFS ones. The Linux implementation is pretty awful, with it demanding that it uses the absolute `/dev/sdx` reference even if you try to build it using serials or other unchaging reference. Replace a disk and then after the next restart it fails to bring up the RAID because `sdf` points to a different disk. At least BTRFS uses internal UUIDs so can bring up the arrays…

I don't know if you're talking about a veeeeery old implementation or haven't properly configured it, but you can use both the device reference or the partition UUID.

This is one of my systems using both identifications:

  root@multivac[~]# zpool status
    pool: boot-pool
   state: ONLINE
    scan: scrub repaired 0B in 00:01:33 with 0 errors on Fri Dec  9 03:46:34 2022
  config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          sdg3      ONLINE       0     0     0

  errors: No known data errors

    pool: multivac-slow
   state: ONLINE
    scan: scrub repaired 0B in 07:05:51 with 0 errors on Sun Nov 20 09:05:55 2022
  config:

        NAME                                      STATE     READ WRITE CKSUM
        multivac-slow                             ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ad3395b6-ac43-453c-9ba2-cf65542cb710  ONLINE       0     0     0
            2c423fe3-07a4-44cb-bc39-8b267c79d8c3  ONLINE       0     0     0
          mirror-1                                ONLINE       0     0     0
            8ca9d5a2-04cb-47a0-987a-8b3d27326975  ONLINE       0     0     0
            bec4c67f-fa41-4ab2-907f-0e5b1e052300  ONLINE       0     0     0
        cache
          bfef4d7f-c484-4c37-a0b7-81d59fa1e189    ONLINE       0     0     0
  root@multivac[~]# blkid|grep zfs_member
  /dev/sda2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="363024978934966364" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="2c423fe3-07a4-44cb-bc39-8b267c79d8c3"
  /dev/sdd2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="10877444988141002268" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="8ca9d5a2-04cb-47a0-987a-8b3d27326975"
  /dev/sdb2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="9244362969528724588" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="ad3395b6-ac43-453c-9ba2-cf65542cb710"
  /dev/sdc2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="11658072268678819533" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="bec4c67f-fa41-4ab2-907f-0e5b1e052300"
  /dev/sdg3: LABEL="boot-pool" UUID="13291833732043257716" UUID_SUB="15424416082895860251" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="b6c0b302-7599-4862-888b-be6f7a85b970"

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#196

Post by ndsipa_pomu »

ilyt wrote: post #123
josephcsible wrote: post #73

Earlier quoted context omitted.

IMO, the inconvenience this causes is outweighed by the prevention of data loss for people who otherwise would never have noticed the degraded array.

Right but if it's remote server you're fucked and you can't login on it to even assess what happened

This is why I want servers to always boot to an OS whenever possible. It's fine if production data is not available until someone fixes an array, but without the OS, it's a pain to even figure out what's happened, let alone fix it.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#197

Post by tecleandor »

viraptor wrote: post #99
waynesonfire wrote: post #38

Earlier quoted context omitted.

ZFS is widely used by many users and organizations. Just because it is not currently included in the Linux kernel does not mean that it is useless. There is ongoing work to integrate ZFS into the Linux kernel, and in the meantime, many users continue to find value in using ZFS on their systems. As an alternative, you could try using FreeBSD, which includes ZFS as part of the kernel. This can make it easier to take ad…

> There is ongoing work to integrate ZFS into the Linux kernel Could you paste a link to it, please? As far as I know, all efforts now are around ZoL which is not included for legal reasons.

BTW, ZoL is not anymore. ZoL and OpenZFS merged and it's all OpenZFS, sharing a codebase.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#198

Post by mananaysiempre »

cosmojg wrote: post #149
chasil wrote: post #55

Earlier quoted context omitted.

Btrfs is able to do one important thing that ZFS cannot: defragment. I see XFS as the performance leader (appears on TPC.org the most often that I can see), btrfs as the fullest featured, and ZFS with the strongest reliability.

XFS is the best filesystem for people who don't want to deal with filesystems. Btrfs is there for the rest of us.

Unfortunately, as best as I can tell you can’t shrink an XFS volume other than by completely rewriting it. (Also mkfs.xfs formats with Y2038-susceptible 32-bit timestamps by default, but that can be overriden.)

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#199

Post by mgerdts »

derkades wrote: post #175
mgerdts wrote: post #119

Earlier quoted context omitted.

> Is there a zfs native way to create raid0 disks now? zpool create swimming disk1 disk2 … That has worked for over 15 years.

This does not create a RAID 0 / stripe, but it is close.

RAID0 could be striping which would require all devices to be the same size or it could be concatenation which leaves it to some other layer to balance load across drives. What I suggested allows the use of the full capacity of the drives with weighted data placement based on available space on the drives.

What I suggested is not really RAID0. raidz is not really RAID5. ZFS intentionally improves on these for performance and reliability reasons.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#200

Post by helf »

vetinari wrote: post #186
helf wrote: post #111

Earlier quoted context omitted.

Yeah. On my end it just slowed to a completely unusable level. So while it technically didn’t lose data it effectively did since I was looking at weeks to replicate any data off it. I let it run for a week and it was still crawling when I gave up (4TB drive)

Was it a SMR drive, by a chance? You can make those crawl with any filesystem. I even had one that couldn't finish initial Time Machine backup.

I just double checked the drive and it is. I forgot about that aspect of it.

However I have run this same drive out of space using ext4, zfs, and xfs playing with it (it’s a drive I use for torrent etc) and none of them have crapped out like btrfs did on it.

Post reply on HN