3 ms·
this is a really neat addition to raid-z. i recall setting up my zfs pool in the early 2000s and grappling with disk counts because of how rigid expansion was.
by canvascritic 3y ago
this is a really neat addition to raid-z. i recall setting up my zfs pool in the early 2000s and grappling with disk counts because of how rigid expansion was. Good times. this would've made things so much simpler. small nitpick: in the "during expansion" bit, I thought he could have elaborated a touch on restoring the "health of the raidz vdev" part, didn't really follow his reasoning there. but overall, looking forward to this update. nice work.
- mgerdts 3y agoI remember in the decade+ before zfs was introduced and in several of the years since then trying to figure out the optimal stripe size for RAID 10 volumes and the optimal stripe size and count for RAID 5 volumes with Solaris Disk Suite, VxVM, Linux md, etc. Fixing bad decisions has typically meant backup twice, test a restore, fixe the volume, and pray one of your backups is good. :) ZFS has generally been easier to go from zero to working well once you accept that life doesn’t need to be so complicated as legacy md, lvm, and fs layers made it. It also has a pretty big footgun that causes me to carefully read the man page before using “zpool add” or “zpool attach”. Vdev removal is a big help for this.
- canvascritic 3y agooh, the memories of trying to optimize stripe sizes in the pre-zfs days! i can totally relate to the struggles with solaris disk suite and linux md. the pain of fixing poor decisions and the nail-biting backup processes are all too familiar. zfs really did simplify things in many ways. though i agree, it's always a good idea to tread carefully with commands like `zpool add` and `zpool attach`. glad vdev removal has made that process a bit smoother. it's pretty cool to see how storage management has evolved over the years. cheers for the trip down memory lane. :)