To Cache drive or not to Cache drive?


Recommended Posts

Ok, i give up. Reset the whole thing, even reformatted the usb disk, did a 'initconfig', re-assigned all drives and stuff, recreated the shares and everything. No result.

 

Copying to a cached user share is at 50MB/s a tad faster then copying to a non-cached user share (35MB/s) but it's still slow compared to copying to the cache drive directly at 80MB/s, and you would expect that copying to a cached user share would be close to 80MB/s as well, taking into account some file system overhead.

 

Anyone comments on this? Looks like a bug?

Link to comment
  • Replies 366
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I have the same mainbord as Jowi, the same hdd's (1 parity and 4 data), only my data drives are on a Areca ARC1300 controller (which is slower than the supermicro 8 port i think)

Copy speed to a 1 TB hitiachi cache hdd (connected to mainbord) is 32-40 Mbyte/sec

The protected volume is now checking parity at 50-80 Mbyte/sec also, so this will slow it down also i guess.

Link to comment

If a cached user share is almost as slow as a non cached one, and significantly (50%) slower then copying directly to the cache disks, it renders the whole idea of caching totally useless... basically adding a cache drive this way is a waste of money. I've tried a lot of things, even did a total reset of my config, didnt help, and the response in this topic from Lime or other techies is dissapointing to be hounest.

 

Maybe i'll better file this as a bug in the v5-rc5 thread cause i can't imagine this is normal behaviour. Maybe it gets some more attention that way as well.

Link to comment

and the response in this topic from Lime or other techies is dissapointing to be hounest.

 

Sorry for trying to be helpful  ::)

 

My cached shares work fine and no one else has chimed in with the same problem. That's a fairly significant datapoint.

 

Did you bother to check your cpu load whilst copying to see what shfs is doing?

Link to comment

2nd question; i've created a folder _apps on the cache drive, so MOVER will leave it alone, as i read somewhere in some topic. But now i've also read somewhere that using the _ prefix is not necessary, you could just go to user shares and set 'use cache' to ONLY. So i did that as well.

The "The add-on to modify "mover" to ignore directories with a leading "_" was written long ago for a different/earlier version of the "mover" script.  It does nothing to the current version of the script.  (it does no harm, but it does not change it in any way)

But now in my user shares overview, the _apps share shows up with an orange ball as in 'share has pending cache'. So it is not skipped by MOVER? How do i make sure MOVER is skipping a folder?

Use the feature built into unRAID.    Disable the  leading "_"  feature from unMENU's pagkage manager.  Delete the corresponding directories on the data disks. (after moving back any files that may have been moved of course)  No idea about "orange" indicators.  They may go away once you delete the directories on the data disks.

 

Joe L.

Link to comment

Delete the corresponding directories on the data disks. (after moving back any files that may have been moved of course)  No idea about "orange" indicators.  They may go away once you delete the directories on the data disks.

I found using v5.0's 'cache only' option does the job very nicely, so i'm, not using . or _ folders anymore. It wasnt clear to me that using . or _ was obsolete. Still, *any* folder on the cachedisk, be it a 'cache only' or a cached user share, shows an orange ball if there is any data in them. E.g. i 've installed apps like slimserver and sabnzb and dropbox to a 'cache only' folder named 'Apps' on the cache disk. The user share 'Apps' that shows up in the shares tab, has an orange ball stating 'share has pending cache'.

 

Offcourse i can not delete the folders on the data disk, nor the above 'Apps' folder, that would delete my data and installed apps, so i'm not sure what you mean by that. E.g. my 'movies' folder is on disk1, 2,3 and 4, using a split level. The user share which refers to this is 'cached : yes'. Surely you don't expect me to delete all occurances of the 'movies' folder on all data disks?

Link to comment

Delete the corresponding directories on the data disks. (after moving back any files that may have been moved of course)  No idea about "orange" indicators.  They may go away once you delete the directories on the data disks.

I found using v5.0's 'cache only' option does the job very nicely, so i'm, not using . or _ folders anymore. It wasnt clear to me that using . or _ was obsolete. Still, *any* folder on the cachedisk, be it a 'cache only' or a cached user share, shows an orange ball if there is any data in them. E.g. i 've installed apps like slimserver and sabnzb and dropbox to a 'cache only' folder named 'Apps' on the cache disk. The user share 'Apps' that shows up in the shares tab, has an orange ball stating 'share has pending cache'.

 

Offcourse i can not delete the folders on the data disk, nor the above 'Apps' folder, that would delete my data and installed apps, so i'm not sure what you mean by that. E.g. my 'movies' folder is on disk1, 2,3 and 4, using a split level. The user share which refers to this is 'cached : yes'. Surely you don't expect me to delete all occurances of the 'movies' folder on all data disks?

 

I run 5.0 and I setup a cache only share about a week ago for mysql+xbmc. All I did was ssh in and create the folder /mnt/cache/.mysql & it worked a treat. Mover ignores it.

Link to comment

[E.g. my 'movies' folder is on disk1, 2,3 and 4, using a split level. The user share which refers to this is 'cached : yes'. Surely you don't expect me to delete all occurances of the 'movies' folder on all data disks?

No, I was apparently not clear.  I was referring to files moved from the "_" prefaced directories on the cache disk to the data disks.  I was not referring to any of the normal user-shares that either use, or do not use the cache drive.
Link to comment

Not sure if this was discussed already or not but is it possible to configure the "mover" to run more often then just 1x per day?  I would like to have an option to configure it to run every "X" amount of hours (4,6,8 or 12 hours).  Is this possible?

yes.  it is in the unRAID settings.
Link to comment

Not sure if this was discussed already or not but is it possible to configure the "mover" to run more often then just 1x per day?  I would like to have an option to configure it to run every "X" amount of hours (4,6,8 or 12 hours).  Is this possible?

yes.  it is in the unRAID settings.

 

OK, I dont see an "hourly" option.  I am running 5rc4, click on Settings > Share Settings and under the bottom section for "Mover Settings" I have Daily, Weekly & Monthly as options for the Mover Schedule.  Am I in the wrong place?

Link to comment

Did you bother to check your cpu load whilst copying to see what shfs is doing?

checked it with running top while copying to the ssd cache disk directly:

process smbd takes 100% cpu

 

when copying to a cached user share, smbd takes 45% cpu according to top, and is the accompanied by shsf process which takes 55%.

 

I'm not sure what that means...?

Link to comment

Ok, here's an interesting case regarding cache.

 

If i'm correct, the basic principle of using a cache disk is that it allows unraid to use 'cached' user shares, so that if you copy data to a user share, it is not copied directly to the array/disk, but instead is copied to the (unprotected) cache disk, which speeds things up. The data still seems to be in the user share, but in stead it's on the cache disk, and the mover process will distribute all 'cached' data over the array at night. So far so good.

 

But now... my cache disk is an 128GB SSD, and i have installed sabnzb on it. Sabnzb's completed results are also saved on the cache disk (ssd) in a folder 'download'. Once complete, i want to move my downloaded files, let's say it's an episode of a series, to the appropriate user share, in this case '/tvseries/blah/season1/'.

 

This user share is offcourse, 'cached'. So if i copy data to it, it is not copied to the array, but to my SSD... and this is where things get interesting, since the data i'm copying, allready IS on the SSD...

 

So, unRAID is now copying a file from a location on the SSD to another location on the same SSD at 50MB/s... which is pretty inefficient and basically rendering the whole principle of caching, useless... this way it still can take hours to copy a few HDTV seasons from SSD to SSD...

 

My workaround in this case is just to 'fake' unRAID's cached user share by creating the /tvseries/blah/season1 folder MYSELF on the SSD, and MOVE (ctrlX/ctrlV) gigabytes at once in a split second, bypassing the inefficient copy step... and the result is the same, and later that night, the mover process will still distribute it over the array...

 

(to be hounest, since my copy speed to a cached, ssd user share is just 50MB/s, i ALWAYS use the above workaround, these sort of slow speeds renders the use of a fast, transparent ssd cache, pretty much useless)

 

So, basically, unRAID's cached user share should be made aware if the data being copied to it, is allready on the same fysical location and act accordingly.

Link to comment

When you are moving the files from Sab, are you doing it via telnet/ssh or windows/samba.

 

From your previous screens it appears your cpu is your bottleneck. When writing to cache directly smbd can use the entire CPU, netting you higher speeds. When copied to user share, shfs kicks in, stealing some CPU cycles and slowing things down.

Link to comment

When you are moving the files from Sab, are you doing it via telnet/ssh or windows/samba.

Usually from windows/samba, but same speeds occur when doing internal copying on telnet.

 

From your previous screens it appears your cpu is your bottleneck. When writing to cache directly smbd can use the entire CPU, netting you higher speeds. When copied to user share, shfs kicks in, stealing some CPU cycles and slowing things down.

One would say an 1.8GHz Atom CPU would be sufficient to handle some basic file copying?

Link to comment

Mmm...  I've been lurking a lot on the forum and read great things about this board in combination wit unRAID, and now it turns out it's basically too slow for what i want, or my expectations were too high i suppose... either way, maybe i should go the Intel i3 route after all, with a nice X9SCM-F board...

Link to comment

It's no longer basic file copying when copying to a user share, that's why its becoming a bottleneck.

 

Writing directly to cache shfs isn't used, so it uses no cpu. Writing to the user share, it is writing to the same location but now shfs is looking at the data, where its destination is, the settings for that share(cache or not, split level, fill settings, amount free on disks in that share) to figure out where its going to end up. This spike in processing eats up valuable cycles, something that probably would never be noticeable but since your using a fast SSD, you've moved the writing bottleneck from the drive to the cpu.

 

I may be wrong, I'm no expert by any means, but its my interpretation.

Link to comment

I'm having the same 'speeds' when replacing the SSD with an old 500GB harddisk... so it's not the SSD that is pushing the limits of the cpu, i guess it's the whole user share principle that on it's own is pushing the Atom board to it's limits. I saw another topic where someone experiences 20% slower speed when copying to a user share compared to copying to a disk, i'm experiencing this as well. This guy also has an Atom board... looks like the Atom board is just not fast enough for utilizing unRAID to it's full potential.

 

Not to be blunt, but i think unRAID has to be more specific in terms of minimal hardware specifications. For newbies like myself, it's hard to find up to date info on things like this, a lot of info on the wiki and the Lime site is just plain old. The recommended motherboard has boards from 2007... so you start reading on the forum and find that this Supermicro Atom board is widely appreciated used, so it must be ok...

Link to comment

I'm having the same 'speeds' when replacing the SSD with an old 500GB harddisk... so it's not the SSD that is pushing the limits of the cpu, i guess it's the whole user share principle that on it's own is pushing the Atom board to it's limits.

I have ordered a SuperMicro X9SCM-F with an I3 2120T to deploy as Unraid.

I did not plan to use a cache drive, but I can temporary allocate one and do some tests if you think the Atom CPU is the bottleneck in the process. Will be some weeks though before I have time to proper install / test.

Link to comment

I have ordered a SuperMicro X9SCM-F with an I3 2120T to deploy as Unraid.

I did not plan to use a cache drive, but I can temporary allocate one and do some tests if you think the Atom CPU is the bottleneck in the process. Will be some weeks though before I have time to proper install / test.

That would be great! Much appreciated!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.