On 12/4/19 3:56 am, Wol's lists wrote:
On 11/04/2019 10:51, Eyal Lebedinsky wrote:
On 11/4/19 7:21 pm, Andreas Klauer wrote:
On Wed, Apr 10, 2019 at 03:35:46PM +1000, Eyal Lebedinsky wrote:
I have a raid6 with 7 devices which is larger than needed now.
Download more things until it's just right. ;-)
One disk needs replacement
So replace it before doing anything else.
Already being done.
I will first resize (shrink) the fs, then reduce the array size (--array-size=).
mdadm --grow --raid-devices=6 should tell you the correct value for --array-size.
Then you know what exactly to shrink the filesystem to, so it's neither too large
nor too small.
but I do not know how to nominate which of the 7 devices to remove.
Not really possible.
Provided you know the device you want to remove, "mdadm --fail sdx --remove sdx" will remove that specific drive from the array.
You want to do this as the next step after shrinking the fs. This then gives you a degraded 7-drive raid-6 - the same as a raid-5. PROBABLY safe enough for a short time.
Then you can --grow (ie shrink) it to a 6-drive array.
So --grow can operate on a degraded array, creating a smaller non-degraded array?
While we discuss --grow, how much is written to the --backup-file?
1 Is this only some king of intent/progress log?
2 Does it hold a small portion, only written initially to make room for the reshape to start?
3 Will the full 20TB of data pass through it?
I hope the 3rd option is not the case as it will put a stain on this file and slow the reshape.
Being a temporary system, root fs is on a 200GB (very old) disk and writing 100 times its capacity
is a worry.
This will then rebuild the array so you are then hoping to avoid a drive failure during the rebuild but that's recoverable. A second failure would break your array.
Actually, you might be able to do --fail --remove --grow in one command, but I wouldn't like to say ... if you've got a system you can play with, you can try for yourself ...
Cheers,
Wol
--
Eyal at Home (eyal@xxxxxxxxxxxxxx)
