Greyhole problem, slow network transfer

Ok, so cancelling the tasks seems to have stopped it chasing it's tail. However I still cannot get the system to do a file balance..
I selected the 'Files balance' option from teh OMV plugin and it appears to have done nothing at all.. see log output below.

root@homeserver:~# greyhole --cancel-fsck
All scheduled fsck tasks have now been deleted.
Specific files checks might have been queued for problematic files, and those (fsck_file) tasks will still be executed, once other tasks have been processed.
root@homeserver:~# greyhole -L
Mar 08 21:01:40 INFO initialize: Cleaning executed tasks: keeping the last 60 days of logs.
^[OA^C
root@homeserver:~# greyhole -S
Greyhole daemon is currently stopped.
root@homeserver:~#

greyhole -L cmd was issued before selecting 'files balance' in the OMV plugin.. left it for a while with nothing appearing to happen and then stopped the tail and issued -S to get the daemon stopped log

Apologies again for my lack of knowledge here..
Ok, restarted the server and it's the 'lost' share that's causing the problem.. issued service start and then immediately -L and got what you see below..

root@homeserver:~# service greyhole start
Starting Greyhole ... OK
root@homeserver:~# greyhole -L
Mar 08 21:21:13 CRITICAL fsck_file: Tried to fsck a share that is missing from greyhole.conf. Quitting.

Issuing an omv-mkconfig greyhole gets a 'command not found' error..
Sorry again for my being dense but is there a path I need to use for this command or something.?

Ahhh, just found that in /usr/sbin but was dithering over whether to try it..

Ok done that.. hasn't made any difference, Greyhole quits with the same error instantly.

root@homeserver:/# omv-mkconf greyhole
# Stop Greyhole
# Start/Enable Greyhole
update-rc.d: using dependency based boot sequencing
Starting Greyhole ... OK
root@homeserver:/# greyhole -L
Mar 08 22:23:48 CRITICAL fsck_file: Tried to fsck a share that is missing from greyhole.conf. Quitting.
^C
root@homeserver:/# greyhole -S
Greyhole daemon is currently stopped.

Yeah I initially tried that once I realised what I had done.. When I removed the samba share initially I noticed a blank share in greyhole, realised what I'd done wrong and tried to delete the blank share in greyhole, it wouldn't let me do that so I readded the samba share and then tried to remove in from greyhole, it wouldn't let me do that either.. I then added the recreated share to greyhole and tried to delete both it and the blank share.. it was treating the new share as a seperate entity from the old one anf would delete the new share while ignoring the 'blank' one.
Finally I went through smb.conf and greyhole.conf and removed references to the blank share which seemed to fix it, share was removed from the gui and everything seemed fine..
But apparently not.. presumably there is somewhere else that the shares are referenced in relation to greyhole that I have missed or am not aware of.!?!?

Ok, progress finally.. I ran a couple of queries on the SQL database and found thousands of references to the missing share. I had it delete all the ones referencing the fsck_file action and restarted greyhole.. it seems to be working on balancing the pool now from what I can tell of the log output.
There were initially a whole bunch of instances in the log of it finding files in the share that no longer existed but it now skips those actions.. Unfortunately this problem predates all the file copying that I was doing earlier and so I presume there are close to 4TB of file checks and pool balancing that having been sitting queued and unable to run that are now running...

So sorry to have wasted everyone's time with my idiocy. Many many thanks for your help.

Would it possibly be easier to prevent a samba share from being removed if it is referenced in another plugin..?

In that case I can't think of anyway to get the plugin to act preventatively in this case. The plug has no control over the status of samba I presume and is only informed of changes. Given that in this case the error had been ignored by the idiot at the keyboard (me) for such a long time that there were several thousand queued actions in the database causing the problem, in most cases I'd assume that there were either none at all or only a few if the plugin issues the SQL query to remove the fsck actions from the database for the removed share at the point that it is removed.

:lol: squeak, squeak.. (can't think how to type that weird noise that guinea pigs make.!!)

Well then if what I am doing can be considered helping then I am happy to help.!!