Removal of drives from vdev without replacement drive

Feature Requests
1

I think it would be extremely beneficial to add an option that allows users to temporarily exclude drives from the pool size calculation. In my experience, obtaining a replacement drive isn’t always possible in a timely manner, whether due to availability, shipping delays, or budget constraints.

Having the ability to remove a failed or missing drive from the pool size calculation would provide greater flexibility and help users keep their systems operational while they work on sourcing a replacement. I suspect many others in the community have encountered similar situations.

I hope you’ll consider this feature request, as I believe it would address a real-world problem and improve the overall user experience for a significant number of users.

2

What pool layout? You can do this with Mirrors but, I don’t believe, Raid-Z(1,2,3) is possible under ZFS

3

It is a z1, which currently is not possible to remove a drive from the pool.

4

I believe having the ability to remove a drive then force a balanced re-silver and just reduce the overall vdev size would be a feature a lot of people could use at the moment as a used 12tb drive is $310 and a new one is $469

5

This is not something iX will likely take on. This is fundamental ZFS function that does not exist at the moment. And if ever, will be several years in the making.

So, this is the wrong forum. Try asking the OpenZFS people via the mailing list, conferences or GitHub.

3 Likes
6

Indeed it is not. This is an OpenZFS feature request, not a TrueNAS one.

1 Like
7

To hammer this home for other readers, ZFS does not support removing a data column or parity from a RAID-Zx vDev.

Further, while there is a quite clumsy zfs rewrite, that is not a practical re-balance method for RAID-Zx. This is because zfs rewrite happens at the block level, not the file / zVolume level. That means a 5 data column RAID-Z1 block will still require 5 data columns after the zfs rewrite.

Basically the re-blance, (aka the fabled block pointer rewrite grail), simply does not exist. And as far as I know, their are no plans to implement it.

2 Likes
8

Then you’re asking for shrinking the width of a raidz, which is not possible under (Open)ZFS, and, if it were, it would leave existing data with a missing column and degraded redundancy (no redundancy at all for your raidz1), which does not look like a good idea…

1 Like
9

Honestly, I don’t think a lot of people would want to do this, but I’m sure some people would.

The proper method to accomplish this is:

  1. Backup all your data.
  2. Destroy the pool.
  3. Recreate the pool using the drives you want.
  4. Restore your data.

And yes, most people will do this at least once when they first start using TrueNAS as they learn what pool design works best for them. I have redone my pool several times in the beginning, settling in on a RAID-Z2 for one main reason… I hate restoring data.

And everyone who posted comments are correct, this is not a TrueNAS restriction, but a non-supported OpenZFS function.

But thanks for posting to the forum and feel free to read and post as you see fit. We are all here to help.

2 Likes
10

I don’t think this is correct; RAIDZ device removal has been requested, a lot, for a very long time. The fact that it hasn’t yet been implemented indicates that it’s very difficult–if possible at all–to implement, not that there isn’t demand.

Someone who wants this implemented needs to bring a truckload of cash, a busload of developers, or both.

5 Likes
11

I highly doubt they will ever implement such a feature. I suspect it’s a tough process to do and very risky in terms of preserving data integrity. Expansion is relatively easy; shrinking is hard.

I suspect you’re hinting the price hikes due to the whole AI craze. :grinning_face:

This is primarily the reason why I decided to go with mirrors. It is much more flexible in terms of upgrade path.

4 Likes
12

Good point!
But hoping for a (risky and complicated) software “fix” to a hardware supply issue is not advisable. The most appropriate solution is to proactively search and get some cold spare(s) in advance when a reasonably priced opportunity arises. Second-hand HDDs come with the “benefit” of being already burned-in…

1 Like
13

Tough yes, preserving data integrity, easy.

In essence, removing a column(s) from a RAID-Zx vDev involves freezing the column(s) from future writes. This prevents the need to deal with normal updates. And stops the RAID-Zx vDev from using the frozen column(s) as stripe member(s). Meaning a 6 disk RAID-Z2 has 2 parity and up to 4 data columns. So, freezing a column would limit that vDev to 3 data columns.

The (excruciating & extremely messy) hard part is breaking up previously full stripe writes, (4 data columns & 2 parity in the example above), into 2 separate stripes. And accounting for any snapshots, clones, block clones, hard links, DeDup, etc…

Any RAID-Zx stripe that does not have to be fragmented, is relatively easy by comparison. (I did say in comparison!) Now this does require moving the block, (thus, block pointer re-write, which is hard but not as hard as fragmenting a block).

Maintaining data integrity is basically the easiest of them all. Regardless if it is a single block move or a 2 block fragmented move, all related data would be in the same ZFS write transaction group. (So both fragmented stripes and all associated metadata for a fragmented block, is written at the same time.) If it fails, (OS crash or power loss), the old data is still their. If the new write succeeds, then still good. Easy peasy.

Such a RAID-Zx vDev shrink task should be restartable. As long as the frozen column(s) state is preserved during export and import.

Yes, for those reading between the lines, I did give this a bunch of thought. Both adding parity to RAID-Z1/2 vDevs, and removing a column from RAID-Zx vDevs. (Note that adding parity to RAID-Z3 is not possible as ZFS does not support RAID-Z4.) However, I have no skills to implement such a feature.

1 Like