Removing drives from pool process

[Rastalovich]

Afternoon,

I'm going through the process of removing 3 drives from my old pool during transfer to a newer pool. There would be over a tb of space remaining in the old pool once 3 drives are removed.

Doing the usual 'going' option, one at a time, I notice from the tail log that of course it includes the next 2 drives I'm going to remove when it's redistributing files.

Would it be possible to have an option '--going=/mnt/PD00/gh --exclude=/mnt/PD02/gh, /mnt/PD06/gh' ?

Many thanks. (this is where you tell me you already can :p)

[gboudreau]

A workaround you could use is defining target groups in greyhole.conf, and putting your 3 going drives into a group that is either used last, or not used at all.

[gboudreau]

Example config:

	drive_selection_groups = OK: /mnt/PD01/gh, /mnt/PD03/gh, /mnt/PD04/gh, /mnt/PD05/gh
	drive_selection_groups = GOING: /mnt/PD00/gh, /mnt/PD02/gh, /mnt/PD06/gh
	drive_selection_algorithm = forced (all OK) most_available_space

If you restart the daemon, it should complain that the /mnt/PD00/gh, /mnt/PD02/gh, and /mnt/PD06/gh drives will NOT be used as possible targets, because they are not listed in your drive_selection_algorithm, which is exactly what you want.

[Rastalovich]

Sounds a good idea. Whilst remaining files on the 2 other drives with remain available to the pool because of their links.

This change of the .conf would generally effect new file allocation and not effect reading of files already in the pool? So when the drives are to be removed, they will be copied-from and not copied-to.

Excellent.

[Rastalovich]

One thing, I seem to remember once the --going has finished, doesn't it schedule a fsck? Would this pickup that files in the db are not in the group and re-allocate them?

Or is this the process you're suggesting? Instead of just going down the --going route, do the .conf change first, then a fsck, then do --going - as the files will already be allocated off the 3 drives?

TIA

[gboudreau]

This change of the .conf would generally effect new file allocation and not effect reading of files already in the pool?

Yes. drive_selection_algorithm is used when Greyhole needs to choose where to place a new or modified file.
So when new files are added on your shares, or when you remove a drive and Greyhole needs to decide where the going files should be copied.

Would this pickup that files in the db are not in the group and re-allocate them?

fsck doesn't care for drive_selection_algorithm, unless it needs to create an additional copy.
If it does, it will use that config to choose on which drive it should place the new copy, and thus will never choose PD00, PD02 or PD06. But if there are already file copies on those drives, they will be counted as valid, until you use --going for that specific drive.

Or is this the process you're suggesting? Instead of just going down the --going route, do the .conf change first, then a fsck, then do --going - as the files will already be allocated off the 3 drives?

No. Use --going for each drive in succession, and wait until fsck completes each time, before you remove another drive.

[modem7]

Might be a useful thing to add to the GUI - multi-drive/share functionality for fsck, going, gone, add etc.