Kyle wrote:
> ... If I recall, the low priority  was based on the percieved low demand
> for the feature in enterprise organizations. As I understood it shrinking a
> pool is percieved as being a feature most desired by home/hobby/development
> users, and that  enterprises mainly only grow thier pools, not shrink.

Although it's historically clear that data tends to grow to fill available 
storable, it
should be equally clear that as storage resources are neither free nor 
the flexibility to redeploy existing storage resources from one system to 
considered more critical may simply necessitate the ability to reduce resources 
one pool for transfer to another, and therefore should be easily and efficiently
accomplishable without having to otherwise manually shuffle data around like a
shell game between multiple storage configurations to achieve the desired 

Seemingly equally valid, if its determined that some storage resources within a
pool are beginning to potentially fail and their storage is not literally 
at the moment, it would seem like a good idea to have any data which they
may contain moved to other resources in the pool, and simply remove them
as a storage candidate without having to replace them with alternates which
may simply not physically exist at the moment.

That being said, fixing bugs which would otherwise render the zfs file system
unreliable should always trump "nice to have features".
This message posted from
zfs-discuss mailing list

Reply via email to