Disk consolidation/replacement + XFS conversion: Is this method sensible?

[mattkhan]

I have an array that is currently all reiser and made up of 6 disks inc parity. There is 1 user share that spans all disks and a few shares that are pinned to a single disk.

 

I would like to achieve 3 things in 1 go; convert to XFS, add some capacity, consolidate some drives.

 

I would like to keep the user shares available during this work and I do have a complete backup on a separate machine in the same network.

 

I was thinking of tackling this as follows, are there any flaws in this plan?

 

Will this keep the user shares available during this time? what happens to a usershare when there are files on 2 underlying drives?

 

Current State
-------------
Disk1   3T       
Disk2   3T          
Disk3   2T       
Disk4   2T       
Disk5   2T   

1) Add Drives

Disk6   4T
Disk7   4T   

2) Remove Parity & put shares into read only mode

3) Execute transfers using rsync from /mnt/disk to /mnt/disk

round   [source]   [dest]    notes
------- --------- -------- ------------
   1      Disk4    Disk6    2 * 2T -> 4T
          Disk5    
   2      Disk1    Disk7    3T to 4T
   3      Disk2    Disk1    3T to 3T
   4      Disk3    Disk2    2T to 3T

4) Create new config
- Remove Disks 3-5
- Move Disk 6 to Disk 3
- Move Disk 7 to Disk 4
- fix disk to user share mappings

5) Rebuild Parity   

 

[SSD]

Looks good to me. With backups in place.

 

You may experience performance issues with video playback with the copying in progress.

 

Rather than round 2 through 4, you might just copy disk3 to disk7 and be done with it.

 

Maybe no need to go read only. Once the lengthy initial copies occur, and just before the reconfiguration, you could do delta copies to pick up recent activity. Obviously depends on the nature of the data.

[mattkhan]

Rather than round 2 through 4, you might just copy disk3 to disk7 and be done with it.

this would leave those 2 disks as reiser though wouldn't it?

[JonathanM]

Will this keep the user shares available during this time? what happens to a usershare when there are files on 2 underlying drives?

The shares should be ok to read the entire time, however if you write to a file via share, duplicates are resolved in numerical order, so if the file exists in /mnt/disk1/stuff/ and /mnt/disk2/stuff/ and you write to that file in /mnt/user/stuff/ only the file in disk1 is used, so disk2 would have the old version. I would set the user shares read only for the duration of the operation by manipulating the security settings so no user has write privileges to any of the user shares.

[SSD]

Rather than round 2 through 4, you might just copy disk3 to disk7 and be done with it.

this would leave those 2 disks as reiser though wouldn't it?

 

You didn't include the reformat steps and in my pre-coffee stooper, forgot! Makes prefect sense as you defined. To avoid duplicate files in share issue, you can create a temp directory and copy to that. Only after lengthy copy complete, you can move the directory out of the temp folder into the root.

[Griz]

Do you risk duplicate files if you move /mnt/diskX/directory to /mnt/diskY/directory ?

 

 

I just moved about 2TB (using mc F6) and don't see any dupes, but don't know if this is OK or if I haven't found the dupes yet....

[itimpi]

Do you risk duplicate files if you move /mnt/diskX/directory to /mnt/diskY/directory ?

 

 

I just moved about 2TB (using mc F6) and don't see any dupes, but don't know if this is OK or if I haven't found the dupes yet....

if you move the files you should be OK.  If you copied them and forgot to remove the originals you could end up with duplicates.  You could use the script I wrote some time ago to easily and quickly find any duplicate files.  I often use it after moving a lot of files around just to check.