/greyhole/tasks' is marked as crashed and should be repaired

[dinomic]

The files with an arrow are not actual files, they are symbolic links. Those will always be there, as they are what allows Samba to show files in your shares.
Those links are very small, and having them on your / partition costs almost nothing.
So files that are moved into the pool are not using space on your / partition, unless you added the / partition into the pool.

Ah, thanks gboudreau! I just assumed that it was still a physical file as it was showing the full file size, but I've just checked the Properties, and it does indeed point to the 1st drive in the pool.

So I'm guessing that, as soon as the file is copied to the pool, it removes the file from the system drive and replaces it with the symbolic link? Does this happen as soon as it has successfully copied the file to Disk1 in the pool, or when it has been also balanced to Disk2 (assuming that it's being copied to 2 disks)?

You are right, the System Drive is not part of the Pool, which is why I was shocked that it was being used whilst files were being copied over to the Pool via the network Share. I guess it makes sense that it would copy to a "physical" disk first, though before being copied to the pool, but I guess that also seems that a System Drive of only 60GB will not suit. Can the landing zone actually be one of the pooled drives? I've yet to find how to actually change this landing zone (still searching this forum...)?

[gboudreau]

http://forums.amahi.org/viewtopic.php?f ... zone#p9944
http://forums.amahi.org/viewtopic.php?f ... one#p11385

The symlink is created as soon as the first copy is created. The other copies are created by reading the symlink target, and using that as the source for additional copies.

[dinomic]

Thanks again, gboudreau. I'd already found the first link, but the 2nd link you posted help confirm what I'd read.

Would I be right in guessing that, if the end result you want is to copy a set of files for a share on both disk1 and and disk2, by selecting disk1 as the LZ will actually speed up the Greyhole operation (after all, it then won't have to copy the file from 1 disk to another, twice!)?

In order to fix the problem caused by running out of space, I had to move over a few of the files manually. So I cut/pasted them from the System Drive over to disk1, and then created a symbolic link back to them on the System Drive. Could I be breaking anything by doing so? For example, will the "tombstones" be created? What *are* the tombstones?

I think part of the problem I've been experiencing is exacerbated by the SSD System Drive being super-fast to read-write, whereas the 3TB Hitachi drives are VERY slow. I don't know whether it's because they're stuck on 1.5Gb/s (even though they *should* be able to do 6Gb/s), because they're not handled properly via the 3Ware controller, or whether that's how slow the drives actually are. But I've been seeing REAL slow speeds like 2.5MB/s!

Anyway, thanks again for your help, and let me congratulate you on a GREAT bit of software - it's your Greyhole that tempted me to drop WHS and come over to Amahi (ooooer, that sounds a bit rude! ).

[gboudreau]

Having the LZ on a drive that is chosen by GH to hold the first copy, you'll indeed save time and resource, since it will just be renamed to the proper location, instead of being copied.

Tombstones are small files that are in the storage pool (in the .gh_graveyard folder) that contains information about where the different copies of a files are, and which one is used by the symbolic link.

To re-create tombstones, you'll need to launch a --fsck from the command line. As long as the files are in the LZ, or if you have symbolic links in the LZ, GH will create the tombstones that are missing.

[ralfb]

I'll leave mysql -u root -phda -e "repair table tasks_completed" greyhole running overnight now.

Still running after more than a night and most of the day.

I'm thinking of killing the process and reinstalling Amahi....

Ralf

[dinomic]

Wow! Mine took about an hour to fix, but then I don't have many files on there yet (about 175Gb, duplicated). How much data have *you* got copied over? If you have considerably more data, maybe it might be better to let the fix run a bit longer?

Have you run out of disk space on the LV, like me? If so, how about freeing up some space by moving a few large files manually, and creating the symbolic links? This might help the DB get fixed.

Mine finally finished the GH updating onto both drives. I then changed the LV path in the Web panel and ran -fsck, but the log suggested there was nothing queued (although I did notice most symbolic links had moved from the System Drive to the new LV). However, I then tried to copy over more files from a Windows machine and noticed the System Drive's usage going up again, so I stopped it! Will have to investigate tonight if it's recovered properly and try again...

[ralfb]

I've got about 5 TB of stuff, movies, music, pics.

Still waiting.

How may I flush / empty the landing zone? Where is it?

Can't even mount my shares.

thanks,

Ralf

[gboudreau]

I'll leave mysql -u root -phda -e "repair table tasks_completed" greyhole running overnight now.

Still running after more than a night and most of the day.

I'm thinking of killing the process and reinstalling Amahi....

Ralf

You can just drop that table, and re-create it:

Code: Select all

mysql -u root -phda -e "drop table tasks_completed" greyhole mysql -u root -phda -e "CREATE TABLE tasks_completed (id BIGINT UNSIGNED NOT NULL, action VARCHAR( 10 ) NOT NULL, share TINYTEXT NOT NULL, full_path TINYTEXT NULL, additional_info TINYTEXT NULL, complete ENUM( 'yes', 'no' ) NOT NULL, event_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP) ENGINE = MYISAM" greyhole

Then restart the greyhole service, and wait for it to move files into the pool, thus free space in your / drive.

[ralfb]

Many thanks.

how long does the drop table command take as it's taking a while now.

mysql -u root -phda -e "drop table tasks_completed" greyhole

Is that expected?

Thanks

Ralf

[gboudreau]

No. It's probably locked because there is another MySQL thread still trying to repair that table.

Code: Select all

service mysqld restart

Then try again to drop the table.
Alternatively, you can stop the mysqld service, then manually remove the /var/lib/mysql/greyhole/tasks_completed* files, then restart the mysqld service.