Greyhole and the graveyard

[sidelight]

Just wondering if there is a way of triming the graveyard?

My kids decided to backup their PC's (Oh well I guess they sort of listened), by copying over the contents of their PC's hdds. I've cleared things down now and pointed them at the clonezilla disks (and dropbox for their college stuff). However, I'm left with several million files in my gh_graveyards which take an age to process.

[lrevxl]

I'm not entirely following you here, are the files still in your pool? Or are you saying you deleted the files and the tombstones are still present? If you did delete them did you delete them via Samba or directly on the drives?

[sidelight]

I deleted the files using smb shares. but graveyard entries are still there, so the fsck (with the -o as I had files missing) is full of warnings that the files are no longer in the storage pool.

[sidelight]

I think I understand now. I'm not talking about the attic, I'm talking about the .gh_graveyard directory, this is full of files representing deleted files.

[lrevxl]

I think I understand now. I'm not talking about the attic, I'm talking about the .gh_graveyard directory, this is full of files representing deleted files.

If files are deleted via the samba interface Greyhole should remove the tombstones for those files as well. I verified that this does indeed happen on my dev box. What version of Greyhole are you running? In your current situation Greyhole doesn't have a mechanism that will remove unused tombstones.

[sidelight]

lrevxl thanks for the reply,

Not sure why they are still on my machine, but it hasn't had a happy time lately (disk controller fault), replaced now but just trying to clear things up.

Is my best option to remove the files etc under .gh_graveyard and .gh_graveyard_backup and run an fsck to rebuild? Assuming this is what will happen?

[lrevxl]

The problem with that approach is that Greyhole will no longer know about the files on those drives so an fsck wouldn't do you much good, there is another option though. You could try removing the tombstones and running and fsck with the --find-orphaned-files option, so something like:

'greyhole --fsck --find-orphaned-files'

I ran a quick test on my dev box. I removed all the tombstones for all files. (Not a large set, just a couple hundred small files.) And then ran the above command and all the tombstones were recreated.

Note -- If you only have 1 file copy set for the share you must make sure to remove the tombstones from the backup graveyards too, otherwise the file will not be orphaned and the new write / tombstone creation will not happen.

If you're not comfortable with this you could try to manually clear the bad tombstones.

(FYI -- I did this test with Greyhole 0.9.6)

[sidelight]

Thanks lrevxl,

I'll upgrade from 0.9.2 and clear down the directories and run with -o. I think it'll be the best way to get my data back in sync.

[sidelight]

Upgraded to 0.9.6-1 using hda-greyhole-0.9.6-1.i386.rpm and got the following

Apr 17 21:29:28 localhost smbd[3430]: smbd_vfs_init: vfs_init_custom failed for greyhole
Apr 17 21:29:28 localhost smbd[3430]: [2011/04/17 21:29:28.393842, 0] smbd/vfs.c:309(smbd_vfs_init)
Apr 17 21:29:28 localhost smbd[3430]: error probing vfs module 'greyhole': NT_STATUS_UNSUCCESSFUL

downgrading to hda-greyhole-0.9.2-1.i386 and everything running again.

[lrevxl]

Which version of samba are you running? (smbd --version) I think this is due to you using an older version of samba than the vfs module is compiled for. See directions here http://code.google.com/p/greyhole/sourc ... /UPGRADING.''

The matured version of the orphaned file functionality has been in since version 0.9.1 so I believe you should be fine on 0.9.2.