I don’t like coffee. May I use Coke or Pepsi instead?
1 Like
Shun the unbeliever!
1 Like
Looks spot on to me. Regarding WD at least…
I believe this is very good idea.
The danger that newly bought HDD will have slightly different number of sectors is real.
In Seagate case its docs refer to “guaranteed sectors” but look like this can change between revisions. Drive Replacement Too Small Error
In WB case I cant even find number of guaranteed sectors. So how am I supposed to make sure my new drive will be the same size as the old one? Even single sector difference can be a problem and since this info is not online I cant even prove something is wrong.
Looks like even Unraid users are being bit by Seagate’s shenanigans.
You’ll notice he has three 12-TB Seagate drives of the same model: ST12000NM0127
One of the drive’s total capacity (in bytes):
12001339219968
The other two drives’ total capacity (in bytes):
12000138625024
The user on the Unraid forum incorrectly referred to them as “Western Digitals”, when in fact those model numbers are Seagate.
1 Like
I know it sounds hyperbolic, but this “fix” (which already existed in a simpler form with earlier versions of SCALE), needs to be triaged with a high priority.
Anyone who is creating new pools after May 2024 is risking bumping into this issue, which they won’t realize until the time comes to replace a failed drive.
Not only might they not remember this caveat about slight size discrepancies, but not everyone who runs TrueNAS at home reads these forums.
I’m telling you: Seagate drives are not uncommon for non-enterprise TrueNAS home users. I get that this isn’t a big deal for iX’s enterprise clients, but still…
This problem is more important than iX might realize, because it’s due to a recent change in SCALE, in which not enough time has passed to truly appreciate how many users will be struck by it years later.
2 Likes
Or SMB users who may have bought a mini. The drive compatibility list for the mini includes Seagate.
1 Like
This happened to me. I had 4 exact 12 TB refurbished drives I bought in December. One drive started throwing SMART errors. I bought 5 more in January. All from the SAME refurbish vendor and the exact same model number. ALL 5 from January are 1.2 GB smaller than the December drives. I ended up buying 4 new 14 TB drives from a different vendor. It seems you will always have to buy ever larger drives because you cannot guarantee X TB drive purchased even a month later is actually X TB according to TrueNAS. So instead of spending $150 or so with a refurbished drive you have to spend $1000 to replace all 4.
I get TrueNAS needs all the drives to be the same size, but 12 TB should be 12 TB no matter the vendor or model. There needs to be some sort of buffer. A few GB of buffer is not a big deal if it means not dealing with this problem.
1 Like
That’s the irony…
FreeNAS, TrueNAS Core, and early versions of SCALE did have a 2-GiB buffer.
Then they removed it.
Now they should absolutely add it back, and hopefully follow the suggestion of @yorick, which should cover all scenarios going forward.
You did nothing wrong. You were just unlucky that your pool was created without this buffer.
Most users don’t realize its future-proofing benefit, since it happens automatically in the background. Since the safety feature was removed, people will start to get bit by this issue when the time comes to replace drives or expand their vdev. (They won’t know until years later.)
Only after the automatic buffer was silently removed from SCALE do we start to appreciate how important it had been for years and years in the past.
Note that users who would be affected by this problem still would have been affected under the old system–the old disks were partitioned at size-2GB, and the new, smaller disks would also be partitioned at size-2GB, and thus the replacement would fail. The difference is that in that scenario, the user could go change that setting (and hopefully change it back once the disk replacement was done).
Indeed. Which is why this feature request suggests to make it automagick: Plan the partition 2 GiB smaller, and if that’s smaller than the smallest vdev member, try to increase the partition size to match that member. If it’s then still too small, oh well, nothing to be done. But for vdevs that were created with some kind of buffer, this would make replacements or additions “just work”, if they are the same “capacity class”.
2 Likes
Somewhat. The UI insists on it, to safeguard users from unexpected results. “I made a new vdev with 6 14TB and 2 12TB, why do I not get the extra capacity of the 14TB drives?!?”
That said, TrueNAS will happily import a pool with mis-matched drive sizes that was created from CLI. And once the smaller drives have been replaced with drives that match the larger ones, ZFS and thus TrueNAS automatically makes the additional capacity available.
That’s neither here nor there for this “12TB ain’t 12TB” case - here we just need that 2 GiB buffer to have great UX.
Ah, now we see another of iX’s evil plans! They have stock in HDD / SSD / NVMe companies and need people to constantly upgrade on failure. Instead of using the hot, warm or cold spare that a user might have hanging around. Now users have to BUY new devices that are in a higher storage “class”.
When will the evil conspiracies end?
First, fishing for how well a Non-ECC RAM TrueNAS Mini will sell. Now forcing people to buy noticeably larger replacement devices, even if they had, (hot, warm or cold), spare(s).
Of course, if you believe any of that, I own the Brooklyn Bridge and am willing to sell shares cheaply. Imagine all the tolls you can get part of! 
4 Likes
It’s not “according to TrueNAS;” it’s that it actually isn’t. The problem here is with the drive manufacturers; what’s being proposed here is a workaround (which IMO is a good one, and a refined form of what the product has had for a long time until they took it away a little under a year ago).
What’s strange is that I haven’t seen trouble like this in quite a long time. Drive capacities have been very standard, even across manufacturers. It’s strange to see this change.
3 Likes
Also add: Stressing our poor innocent boot drives, so that they can wear out and we have to buy "quality" SSD solutions.
For those who are wondering, here’s the reference.
1 Like
I am just afraid both sides will claim its the problem of the other.
- iX will claim HDD models should have exactly the same size/number of sectors and if not its defective product which should be returned.
- HDD manufacturers will claim they only promise certain amount of “guaranteed sectors” as minimum size and never promised every HDD will have exactly the same amount of sectors. So they will not acknowledge it as defect.
So what now?
Stand on the side of the user, (re)implement this feature. It’s not about who’s right, it’s about how to have an awesome user experience.
This is a small, small change with a big positive impact.
4 Likes
And all this just because ZFS cant shrink partition 
Doesn’t matter what iX claims HDD manufacturers should do now or assure in the future. It is within iX’s control to safeguard their users at very little cost. (Oh no, you won’t be able to use 2 GB on your 10-TB drive? 
)
Even if HDD manufacturers did assure that every “X-TB” drive would always have the exact number of bytes, even across models and brands, the safeguard doesn’t really hurt anyone. (See my sarcasm above about losing 2 GB from a 10-TB drive.)
The onus is on the software, not the storage drive companies.
1 Like
You are more than welcome to make that your mission in life, implement and test a vdev shrinking feature, and get the OpenZFS maintainers to include it.
I’ll see you in 2032.
In the meantime, let’s be pragmatic.
1 Like