Amahi Forums

Hi guys.

I've just moved over to amahi and greyhole from WHS because of the new drive extender technology being introduced in Vail. So far I'm becoming more comfortable with greyhole, its principles and how it works. I even decided to use a third drive as the staging area thats very fast but not part of the storage pool that seems to work well.

I have a question though about the distribution of the files across the drives in the pool. I understand that the algorithim is set to always favour the drive with the most space which makes sense. However, I noticed that when copying files into the staging area that the files are then split across the physical drives even if they're part of the same folder. This means that for example when I added a movie to the share which was in two parts, the resultant location of the movie was split across both physical drives. Here's an example from my HDA.
You can see how the two parts of the same movie have been distributed across two drives. The same principle can be applied to any folder where there might be more than one file critical to the integrity of the app/movie/tune.
Another example. I noticed that music share has default sticky files set, however, I personally don't see the need to store all music on the same drive, but would like to ensure that all tracks from the same album (which are stored in their respective folders)are kept on the same drive together.

I understand that some might say, why not just use multiple copies to ensure both drives have all the data but I don't use multiple copies for my movies/music as I can always re-rip them but would always prefer for the folder its in and its contents to be stored on the same drive. I looked at sticky files as a possible solution but this only appears to keep all files in the share on the specified drive. So really my question is whether it's possible to extend the concept of sticky files so that it doesn't store the whole share on the same drive, but automatically keeps the sub-folders within the share on the same drive?

This would make life easier for me because if I did lose one of the drives or wanted to remove one of the drives from the storage pool, the folder and its relevant contents would still be in tack. Additionally power usage could also be reduced as only one drive needs to powered up to access the movie. If this functionality isn't in greyhole could it be considered a feature request?

I hope that made some sort of sense, if not just ask and I'll try to explain more clearly.
Huxy

Music files are sticky by default in Amahi because of AmahiTunes, which is a app that allows you to stream / download our music, and that app needs all the files to be on the same drive, because it uses the files inode numbers as a primary key in it's database.

Sticky files don't need to be at the share level, they can be at the directory level.
i.e. you could say sticky_files = Movies/Standard Definition/
This would stick together everything below "Standard Definition" in your Movies share.

What you'd like is for wildcards to be available in there, so you could do something like:
sticky_files = Movies/*/*
Which would make all subfolders of Standard Definition, High Definition (I guess!), etc. be stuck together, individually.
Greyhole doesn't support that yet.

And then, you have a problem with the /var/hda/platform/html/config/greyhole.yml file in Amahi.
In Amahi, this is the file that would allow you to customize the greyhole.conf file generated by Amahi when you change storage pool or shares options on the dashboard.
At this time, this file can only contain one sticky_files line.
I suggest you open a ticket in http://bugs.amahi.org if you need it to support more than one.

Hi,

Thanks for the excellent response and for the explanation about why music files are default sticky.

What you'd like is for wildcards to be available in there, so you could do something like:
sticky_files = Movies/*/*
Which would make all subfolders of Standard Definition, High Definition (I guess!), etc. be stuck together, individually.

Yea that makes sense. Some notion of sticky_dirs might make more sense over sticky_files but that's exactly the kind of functionality I'm looking for. I don't know anything about the code for greyhole but presumbly this kinda of check can be performed at the dir_selection_algorithm level?

I suggest you open a ticket in http://bugs.amahi.org if you need it to support more than one.

Will do as that would be essential for it to work!
Thanks

You can star this issue to be notified of any development being made on this:
http://code.google.com/p/greyhole/issues/detail?id=32

Thanks! I have also opened the following feature request.
http://bugs.amahi.org/issues/show/591

For everyone following at home, we have a new test release implementing the feature suggested in this post and the bug report:

http://alpha.amahi.org/tmp/hda-platform ... noarch.rpm

please test it and report back. You may need to

yum install wol

if you are running a stock 5.4 platform.

The part about allowing wildcards in sticky_files lines should be included in the next Greyhole version. I'll post a test RPM here once I have one.

cpg,

I just tested the latest rpm. The bug at line 106 is still there. Its currently unable to read the greyhole defaults and needs to be changed to read gh instead of gs:

profoundly embarrassing -- version .9 is out.

Use one of those, depending on your arch: Let me know if it works as expected.