The real secret to this is re-laying out the filesystem data and altering and relaying out the metadata, which is why AFAIK, only VxFS can do this at the moment - it's perceived to be both hard and uncommon (despite all sysadmin's experiences to the contrary, and the manifest existence of fs-reorganisers) so most fs authors don't bother.
Shrinking volumes, by comparison, is just moving a fencepost. It's what they contain that needs the work.
On Mon, Aug 21, 2000 at 10:23:13PM +0100, Mark Simmons wrote:
The real secret to this is re-laying out the filesystem data and altering and relaying out the metadata, which is why AFAIK, only VxFS can do this at the moment - it's perceived to be both hard and uncommon (despite all sysadmin's experiences to the contrary, and the manifest existence of fs-reorganisers) so most fs authors don't bother.
Just in case a) this is what's being thought and b) there's anyone from NetApp listening: THIS WOULD NOT JUST BE A COOL FEATURE... IT WOULD SAVE ME DAYS OF EFFORT.
You see, our database is on that volume, so we have to schedule database downtime, copy the data to a second filer (lucky we have one, or this'd be to tape!) and then back. It's probably going to be 1-3 hour process which will suck up our downtime window for a whole week!
You see, our database is on that volume, so we have to schedule database downtime, copy the data to a second filer (lucky we have one, >
or this'd be to tape!) and then back. It's probably going to be 1-3
hour process which will suck up our downtime window for a whole week!
Is the time worth the cost of another disk? I doubt it.
Bruce
On Mon, 21 Aug 2000, Bruce Sterling Woodcock wrote:
Is the time worth the cost of another disk? I doubt it.
... plus a whole new disk shelf (and the space and power required) if he runs with full shelves with one spare, the way I suspect most people do.