Feature #510

removing a share from the storage pool should unwind the files back to the share

Added by cpg about 12 years ago. Updated almost 10 years ago.

Target version:
Start date:
Due date:
% Done:



this is something that surprised me a bit while trying to demo greyhole ...

when i removed a share from the pool i was somehow expecting to have the file "unwound" ... i.e. the original share should have the files, not links to them.

from GH's point of view, it just knows that share is not in the pool any more when amahi restarts it.

if we were to implement this feature, we need some way to signal that a share has exited the pool so that the unwinding operation takes place.

of course, this brings along a huge number of issues, like what if the share is re-added or what if there is not enough space while unwinding the files?

is there a reason this is not a feature?

just wondering, because to me, these files in the share will be left littered in gh/ areas of the drives and the user should not be subjected to figuring where they are.

hopefully the fsck does NOT eliminate these files?? that would be BAD.


#1 Updated by gboudreau about 12 years ago

fsck: Greyhole loops on all shares found in it's config file, and fsck those dirs one after the other.
So if a share is removed from the config file, it won't be touched.

This isn't a feature in GH because this isn't a Greyhole issue, it's an Amahi issue.
Standalone Greyhole (i.e. not in Amahi), in it's current state, expects the user to do some things manually. This would be one of them.

Maybe you want to resolve this by stopping the user from being able to remove a share from the Greyhole pool.
If the user really want to remove a share from the pool, he'd have to create another share, that doesn't use the pool, and manually move his files over the new share.
This will ensure the user knows what he's doing, and will allow him to make sure there is enough free space.

Or maybe you want to make sure (by asking the user) that he really wants to remove the share from the pool. You'll then need to check if enough available space is available. If there isn't, tell the user to free some space first. If there is, tell him the files are getting copied from the storage pool to his shared directory, and don't allow him to touch the GH-related share options until it's done.

Unwinding the files would be very easy to implement using a simple shell script:
find /var/hda/files/some_share/ -type l -printf '%l\000' -printf '%p\000' | xargs -0 -l2 bash -s -c 'mv "$0" "$1"'

Then you might want to delete / move into the attic all the /gh/some_share/ folders.

#2 Updated by davidjmurray almost 12 years ago

I have just today replaced a disk (increase size) and had a similar problem of manually copying the files all around again.

If I may suggest, is it worth considering adding an option to the 'greyhole --balance' function similar to option of '--balance_away_from /disk/path' and let 'balance' unwind the files.

#3 Updated by gboudreau almost 12 years ago

What you want isn't related to this issue, and it already exists. It's the --going parameter.
That option moves out of the specified disk, and onto other disks of your pool, all the files for which you only have one file copy.
You can then remove that disk from the pool.

#4 Updated by cpg over 11 years ago

  • Status changed from New to Assigned
  • Assignee changed from gboudreau to cpg
  • Priority changed from Normal to High

#5 Updated by cpg over 11 years ago

Possible way to go about this initially:

"hey, your files are still in the pool, and only symlinks are in the shared directory." with a link to a wiki article explaining how to move the files from the pool to the share.

#6 Updated by gboudreau over 11 years ago

Document on Greyhole wiki about how to manually move the files out of the storage pool, and back into the share:

#7 Updated by bigfoot65 almost 10 years ago

  • Priority changed from High to Medium

Also available in: Atom