WhatNotToPutInGreyholeShares

Guillaume Boudreau edited this page May 30, 2016 · 5 revisions

What you shouldn't put in Greyhole shares

In no particular order, you shouldn't use Greyhole to store:

  • files that change often, particularly large files. Example: currently-downloading files (torrents, etc.) Instead, use another folder on one of your storage pool drive to store them, and move them to the correct folder in your Greyhole shares once the download is complete. (Seeding torrents are OK.)
    Another example would be the data files for CrashPlan (backups from other users that you store for them, using their free peer-to-peer backup feature). Store those in a storage pool drive if you want, as long as it's in a separate folder.
  • files that can be kept open/locked for a long time. Examples: currently-downloading files (torrents, etc.), Microsoft Office documents that you edit directly from your shares. Greyhole needs to work on the files that change in the same order they do, and once it finds a file that is still open or locked, it will wait until this change is complete before working on anything else on that Greyhole share. That could delay for a long time a lot of the file operations that happen on your shares.
  • files that absolutely need to stay available all the time. If the drive on which the 'primary' file copy is kept on disappears, that file will be gone from your Greyhole share until Greyhole scans your shares to find broken links, and fixes them. You should use RAID-1 (or something equivalent) to insure those files are always available.
  • millions of small files (less than a few kB each), unless you're a very patient person. The Greyhole daemon has a processing overhead that will not be negligible for small enough files, meaning that the time Greyhole will take to create or update its metadata about those files will be longer than the time it takes to create the necessary file copies on different drives (as needed). All of this will happen in background, so you might not notice, apart from the other file changes processing being delayed by quite a while. Also, the weekly fsck check of such a folder will take quite a while. Both of those might cause unwanted CPU and I/O usage, especially on low-end servers. It's not that it won't work, it's just that it will take a lot of resources, probably for little gain. Workaround: for files that don't change often, tar or zip them up all together, and store a single big file on Greyhole.