- Joined
- May 17, 2014
- Messages
- 3,611
While playing with some of the new OpenZFS features, (checkpoints & special allocation classes), I found the manual page for
So, special allocation classes are now more clearly documented as being a removable vDev type, (with restrictions);
Issue - Man page - zpool Special Allocation Class, not removable? #7880
Pull - Clarify 'zpool remove' restrictions #7893
Commit - Clarify 'zpool remove' restrictions #5140a58
Of course
For those that don't know, the
Okay, my manual page update is not game changing fix. But, in the early days of BTRFS, (a similar file system, but Linux only), the features tended to be poorly documented. Sometimes taking many months before the documentation caught up with the code. (Only to have new features missing docs.) So anything that makes our lives easier, I am all for it.
I've submitted a few other issues, but they are still weeding their way through the process. (For example,
Edit: Added the commit link.
zpool
lacked information on whether the new special allocation class
vDevs are removable. So, I submitted an issue, (aka bug report), and requested an update to the manual page. After some minor discussions, it was both approved and a pull request created.So, special allocation classes are now more clearly documented as being a removable vDev type, (with restrictions);
Issue - Man page - zpool Special Allocation Class, not removable? #7880
Pull - Clarify 'zpool remove' restrictions #7893
Commit - Clarify 'zpool remove' restrictions #5140a58
Of course
special allocation classes
won't hit FreeNAS for many months, if not a year or more. It first needs to weed it's way through to ZFS on Linux, with the target version of 0.8.0.For those that don't know, the
special allocation classes
allow you to have your DeDup table, (if any), small files, SLOG, and or Metadata on a separate vDev. Assuming you used a SSD, (or faster SSD than your main pool vDevs), this would speed up various operations. And may reduce main pool fragmentation.Okay, my manual page update is not game changing fix. But, in the early days of BTRFS, (a similar file system, but Linux only), the features tended to be poorly documented. Sometimes taking many months before the documentation caught up with the code. (Only to have new features missing docs.) So anything that makes our lives easier, I am all for it.
I've submitted a few other issues, but they are still weeding their way through the process. (For example,
snap
as an alias for snaphot
is in-consistantly used. It should be a global abbreviation.)Edit: Added the commit link.
Last edited: