Amahi Forums

NOTE: i collected all of the information requested in the Wiki article. Even with much of the info going to apaste the result was quite lengthy so I apasted it as well, the information can be found at: https://paste.fedoraproject.org/paste/r ... UwkUJa96wQ

Some background:
I am upgrading and cleaning up my system which has been running since late 2012 (it's be through several upgrades). When I upgraded from Amahi 7 to Amahi 11 I did it by creating a new HDA and moving the disks over. This worked well enough, but there were some problems in resetting the shares (my fault) and it resulted in some duplicate information on disk. Since I had been wanting to rename the mount points for the pool disks, I thought I would take the drives off line one at a time, clean them up and put them back on line with the new names I wanted. Before I started I added some scratch disks to the pool to be sure there would be plenty of room. (These disks are mounted at /var/hda/drives/pool5 and /var/hda/drives/pool6.)

I started with the oldest disk (which is named WD-2). I did a "greyhole --going" on the drive. (I also unchecked it in the Drive Pooling->Partitions tab.) It took about 20 hours to move everything off of the drive and do the fsck. After the fsck for the "going" finished I did an additional one: "greyhole --fsck -o -m", just to insure nothing got lost.

I cleared off WD-2 and added it back as /var/hda/drives/pool2. I followed this with a "greyhole --fsck -o -m". Everything seems fine and as near as I can tell nothing got lost.

The problem:
Now whenever an fsck is run I get tens of thousands of messages like this (with different file names, of course):

Apr 18 15:00:03 WARN fsck: Found a metadata file pointing to a drive not defined in your storage pool: '/var/hda/drives/wd-2/gh/Backups/Photos/duplicati-ib1f3626fe7324bd7bb51f7663de6c46f.dindex.zip'. Will mark it as Gone.

I have run the fsck several times, the errors remain and don't appear to be fixed. Is there any way to clean this up? It makes it hard to dig through the log to see if fsck found anything real.

Gene

If you look through the information I provided you'll see that the greyhole queue has a lot in it. This is because I am doing some rearranging of the big shares (Backusp and backup_1) and an FSCK was running at the time I took the snap shot. I expected the situation and don't expect any problems.

Check Greyhole command options: You’ll see an option to clear delete orphaned metadata.

That should do the trick.

The option is -m or --delete-orphaned-metadata. I have run it several times with no change.

You need to do the Greyhole gone command for those drives to be removed from the database.

The going command moves the files only.

Once you do a "going" on a drive, it is removed from the storage pool. greyhole will not accept a "gone" on the drive.

Ah that’s right.

Recommend you submit a bug report to the Greyhole author. He should be able to help out.

This is a Greyhole specific issue and he is the expert.

Will do.

Please let us know the solution.

I posted this on the greyhole page and Guillaume Boudreau posted a fix. Here is a link to the page describing the issue and fix
https://github.com/gboudreau/Greyhole/issues/206

I applied the fix and tested it. It appears to work.

I did find that greyhole distributed with Amahi is different than the one of Github. (It appears that you consolidated many of the files.) So the line number was different. I made the change on line 4851.

Thanks for your help.

Gene