I am archiving a vast amount of media files that are rarely accessed. I’m writing large sequential files, at peaks of about 100MB/s.

I want to maximise storage space primarily; I have 20x 18TB HDDs.

I’ve been told that large (e.g. 20 disk) vdevs are bad because resilvers will take a very long time, which creates higher risk of pool failure. How bad of an idea is this?

  • Big_Expression7231@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I always understood as a balancing act in your vdev sizing. Too big = long rebuild times with so many disks spinning up every time. too small = wasted $ with TB loss to redundancy (raidz2 with 3 20tb disks only utilizes 33% of the TB purchased).

    I’ve always felt you should calculate how many disks do you need to saturate your connection and go from there. 10gig trunk on your network then you’ll want 1 vdev to be able to saturate a 10gig line. any larger than that you don’t get any benefit from.

    • dragonmc@alien.top
      cake
      B
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Hold on a sec…doesn’t more vdevs translate to more IOPS and speed?

      A few years back I was on this sub asking about the best way to carve my 16x2tb zfs pool, and was advised that multiple vdevs would be better for performance.

      I wound up going for 2 vdevs of 8x2tb raidz2, as it seemed to be the right redundancy to performance ratio for me.

      I do have to say though, while the pool itself has been rock solid, the performance is pretty bad…I had to turn off sync completely because it was unusable even just browsing files on the share. Even with sync turned off the performance is pretty bad still, and this is on a system with 16 cores and 64gb ram. I’d love to get some ideas on what a better performing config might be…I’m even open to ditching zfs altogether and going with reverting to mdadm if zfs is not there yet in terms of performance.