In message <
[email protected]> Bob Willard
That's fairly trivial.
First, take a look at the map as it exists now, and the preferred
result.
Start off by moving any existing blocks to the new drive as needed. This
frees up gaps on the existing drives, now look for what data should go
to each of those empty blocks. Rinse, repeat.
No unused space is needed, luckily by definition we have a new drive
available to start the process, the new drive offers enough free space.
It will always take longer to do a full backup/recreate/restore process,
and may end up being riskier to your data during the process.
In an ideal situation, your suggestion requires a read of the entire
array, write to another place, then the new array configuration can be
initialized (a full write cycle to the entire drive). At this point you
need to read all of the data again and write it to the RAID-5 array, but
as you're no doubt aware, writing to a RAID-5 array isn't just a single
write, but rather, it's a minimum of two reads and one writes and more
likely is two reads and two writes with some math in the middle there
(unless your data happens to match the results of your array
initialization)
Compare this to reorganizing an existing array, where the process
requires every sector to be read once and written once at best, or at
worst and read once and written twice (allowing for data to be
temporarily stored elsewhere during sector reorganizations, a process
which is entirely safe if properly journaled)
That being said, a live migration is a significantly more complex
process from the controller's point of view, so it's less likely that
inexpensive controllers can implement live migrations.
), but I'm open to more expensive suggestions, since until now, I