3 ms·

This is a really good write up. It is curious the performance differences found between ZFS and Btrfs, as I've always had the reverse experience, with ZFS bein

by cmurf 7y ago

This is a really good write up. It is curious the performance differences found between ZFS and Btrfs, as I've always had the reverse experience, with ZFS being slower by maybe 15%. The scrubbing on md raid does take a while, every block must be checked as it has no idea what blocks are in use or not; although a write-intent bitmap would avoid a complete resync after an unclean shutdown.

StavrosK 7y ago
I have a joke NAS and I use ZFS for the disks. Unfortunately, at some point I started having problems where deleting a file will take half a minute (each file is only around a gigabyte). I have no idea why performance is killed like this, and nobody I asked on IRC seems to know why this is happening.
- craigyk 7y ago
  My guess is that ZFS is already pretty slow at deletes, your pool was pretty close to capacity and fragmented.
  - yjftsjthsd-h 7y ago
    Oh, yeah: ZFS at least used to degrade catastrophically in terms of performance once you got above... I think 80%? Granted, that was literally Solaris, so I don't know if it's been fixed since then.
    - cmurf 7y ago
      One of my long time Btrfs raid1 backups is 99% full. Writes still go at full speed (the much reduced speed you expect to get writing to the interior tracks of spinning disks). But these do avoid that nastiest form of fragmentation due to it only receiving snapshots from another filesystem, making it act like a tape backup until full. Deleting snapshots produces large contiguous holes of space for sequential writes. This form of snapshotting also scales up well. I've had hundreds of snapshots with no performance reduction, and deleting them is fast also. In cases with many changes in between snapshots, it results in much more complicated metadata. And now while making a snapshot is still cheap and fast, deleting older ones starts to become more expensive for the backref walk.
  - StavrosK 7y ago
    I doubt that, it's only ever been 40% full, unless I'm measuring wrong.

by cmurf 7y ago

StavrosK 7y ago

I have a joke NAS and I use ZFS for the disks. Unfortunately, at some point I started having problems where deleting a file will take half a minute (each file is only around a gigabyte). I have no idea why performance is killed like this, and nobody I asked on IRC seems to know why this is happening.

craigyk 7y ago
My guess is that ZFS is already pretty slow at deletes, your pool was pretty close to capacity and fragmented.
- yjftsjthsd-h 7y ago
  Oh, yeah: ZFS at least used to degrade catastrophically in terms of performance once you got above... I think 80%? Granted, that was literally Solaris, so I don't know if it's been fixed since then.
  - cmurf 7y ago
    One of my long time Btrfs raid1 backups is 99% full. Writes still go at full speed (the much reduced speed you expect to get writing to the interior tracks of spinning disks). But these do avoid that nastiest form of fragmentation due to it only receiving snapshots from another filesystem, making it act like a tape backup until full. Deleting snapshots produces large contiguous holes of space for sequential writes. This form of snapshotting also scales up well. I've had hundreds of snapshots with no performance reduction, and deleting them is fast also. In cases with many changes in between snapshots, it results in much more complicated metadata. And now while making a snapshot is still cheap and fast, deleting older ones starts to become more expensive for the backref walk.
- StavrosK 7y ago
  I doubt that, it's only ever been 40% full, unless I'm measuring wrong.