On 28/06/2009 19:31, Leslie Rhorer wrote:For RAID 4/5/6, I think it'll be refused. You have to shrink the filesystem, and LVM if you use it, then the array, so the used size is no bigger than the new drive - as you've noted, md doesn't mind if it doesn't use all the available space on its constituent devices. If it's a small reduction, as I imagine it would be, and your filesystem supports shrinking, it won't take long to do the the shrinks. Then adding the new drive will be painless. If your filesystem won't shrink - and some (many?) won't - I suspect you're scuppered. It has to be that way because md can't (currently?) tell whatever's layered over it to change itself (though I think (guess) that to some extent this may change at some point in the future with some of the topology stuff that's been discussed here recently). I don't know what RAID 0/1/10 would do but I imagine they'd be the same. Cheers, John. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Linus Torvalds | Re: LSM conversion to static interface |
| Ingo Molnar | Re: AIM7 40% regression with 2.6.26-rc1 |
git: | |
| Ingo Molnar | [bug, netconsole, SLUB] BUG skbuff_head_cache: Poison overwritten |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: Possible regression in HTB |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
