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 inexhaustible; the flexibility to redeploy existing storage resources from one system to another considered more critical may simply necessitate the ability to reduce resources in 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 results. Seemingly equally valid, if its determined that some storage resources within a pool are beginning to potentially fail and their storage is not literally required 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 opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
