why was this changed? if i need a 256TB fs that would mean 256 different tasks to grow the FS. seems like a real pain in the you know what?
my only guess is that for HDP vols, HNAS admins should create thin filesystem and auto-expand??
There is a wealth of information in the man pages (man filesystem-expand, and man hdp).
There is also information in HNAS Storage Subsystem Guide (MK-92HNAS012-05) on that topic. However, long story short, your observation is correct and it is all HDP oriented.
For filesystems that reside on HDP based storage, the initial capacity is 1 TiB and the maximum manual expansion is 1 TiB.
You really don't need to create a 128 TiB filesystem on day 1 (that's really not thin provisioning). Create the 1 TiB fs and it will grow automatically as data is written with auto-expansion.
i use my HNAS FS as a commvault disk library, so i need to pre-provision a full 256TB FS each time so commvault knows what it has available. as 1TB FS that grows by auto-expansion does not fit that use case AT ALL!
terrible decision by HDS to do this.
Hello again Steve.
I would like to apologize for this inconvenience and make note that we are looking to improve upon the implementation in a latter release. The goal is to provide the look/feel of one large expansion, as you need.
Hopefully you have read some of the info in the man pages to understand why we chose to allocate space in that manner.
Unfortunately you will need to manually expand the filesystem multiple times in order to accommodate your need.
The alternative is to use non-HDP SD's, but I seriously doubt you would consider that as an option (nor should you, if you prefer to deploy HDP).
Retrieving data ...