3 ms·
> With ZFS you'd have to iterate through all files, list block locations and check if one of them is affected. I mean... you just described a scrub. I'd glad
by paulmd 7y ago
> With ZFS you'd have to iterate through all files, list block locations and check if one of them is affected.
I mean... you just described a scrub. I'd gladly sit through a scrub if it meant that I could grow a raidz vdev.
I'm suspecting there's some other hurdle.
- Dylan16807 7y agoThat's what makes it impractical to use for anything other than very big and rare events. But on top of that you need a way to plan the changes and make them completely safe to do, in a way that doesn't collide with any other changes made to this presumably-live filesystem. And you have to store tons of data from the scrub somewhere to use during this process.
- garmaine 7y ago> That's what makes it impractical to use for anything other than very big and rare events. Which is totally fine. Growing an array is a big and rare event. I'd be totally fine if I have to take the array offline or read-only for the duration. I just want the option to do so at all.
- rainbowzootsuit 7y agoRaidz expansion is currently a project under development in openzfs. https://m.youtube.com/watch?v=ZF8V7Tc9G28 https://m.youtube.com/watch?v=ZF8V7Tc9G28 https://youtu.be/Njt82e_3qVo https://youtu.be/Njt82e_3qVo
- justinclift 7y agoAlso, the work-in-progress (alpha quality) preview code: https://github.com/zfsonlinux/zfs/pull/8853 https://github.com/zfsonlinux/zfs/pull/8853
- paulmd 7y agoI'm aware, but I really really don't like the solution of all future reads/writes requiring O(N) reads to resolve the data locations.