Amahi Forums

I just have quick question to see if something the little OCD demon inside my head wants to do will cause me any issues going forward.

Following the standard guidance for my build, I have the following:
/var/hda/files/ (2 TB drive, NOT on boot drive)
/var/hda/files/drive2 (2 TB drive for greyhole)
/var/hda/files/drive3 (2 TB drive for greyhole)
etc...

The OCD / windows server admin is bothered by this as it looks like drive2 etc are subsets or subfolders of the 1st drive. I completely understand the symbolic link concept, but to me this is confusing... particularly since there is a /var/hda/drives/ location which appears to be completely unused that would seem to be more logical as a mounting point.

If I change the /etc/fstab to mount the drives I want to use for greyhole to the /var/hda/drives (and unmount old etc) like so:
/var/hda/drives/gh_drive1
/var/hda/drives/gh_drive2
etc...

Would this cause any problems going forward? I would leave the first data drive mounted as /var/hda/files/, of course - which should make my LZ for greyhole 2TB so plenty of room for any fstab hanky panky as I migrate data to the system etc.

Not a big deal if this is something I should not do, it would just make it easier for me to map things out and keep them straight in my head.

OK, I wnet ahead and moved the mount points following all the directions in:https://wiki.amahi.org/index.php/Changi ... unt_points

The only change I made was mounting in /var/hda/drives/ instead of /var/hda/files/drives

It seems to be working well so far. I also inferred from that same article that I should not have included my /var/hda/files/ share in the actual storage pool - which I somehow missed in the setup instructions. (I had thought it would need to be a member to balance storage across all the disks.)

What seems to be happening now, is the 1.x TB of data I had pre-staged on /var/hda/files/shares is being moved off of /var/hda/files/ and into the pool. Got nervous as I watched files disappearing from the first disk but once I realized that /files/ is really just a landing zone, and not an actual storage location, it all made sense.

(Unless I'm wrong, in which case I fubar'd the server (again). I try to get the hard knocks up front so nbd if this is the case.)

Crap, I think I was wrong - GH appears to be eating all of my data. Or the disk stats page isn't updating correctly.

The only change I made was mounting in /var/hda/drives/ instead of /var/hda/files/drives

This change is really irrelevant to Greyhole. Having the mount point in either place works.

I also inferred from that same article that I should not have included my /var/hda/files/ share in the actual storage pool

That is correct as it's the LZ by default. You can move the LZ if you choose by following the Greyhole Landing Zone guidance.

Crap, I think I was wrong - GH appears to be eating all of my data. Or the disk stats page isn't updating correctly.

Trust, but verify. Check to see if the files are still there. The Bug #1493 may relate to your issue.

Trying to be patient and let greyhole finish, but it appears to be stalled. Tail for the greyhole log is coming up with a message repeated over and over - "Share is locked because another file operation is waiting for a file handle to be released. Skipping."

Restarting daemon, fsck etc do not seem to help

Idea's?

Give it time. If the file does not unlock find the file and investigate.

I presume you don't have any files open via your clients.

Time resolved it... although I ended up with a significant portion of the data gone by the time the fsck had run through everything. Not a big deal, as I just re-synced from the original source and then ran a balance to evenly spread across the storage pool.

Good to hear.

Closing this one as solved.