To Cache drive or not to Cache drive?

Is following hdd a good one for cache?

Samsung Spinpoint S250 HD250HJ 250GB 7200 RPM SATA DESKTOP

or this one:

Maxtor Diamondmax 10 300 gb S-ATA

I would use it for downloading with sabnzb onto the cache en then let it move to the array

which is good?

If the SMART reports for both are clean, then they are essentially equivalent.  If that Maxtor was made by Seagate, then the Spinpoint probably runs cooler.  So the choice is either a few more GB's or a cooler running drive.

ok thx

I bought a second hand hdd. When i will ad it as cache drive, will it automatically be formatted? Cause im not sure if its empty or how it is formatted...

I bought a second hand hdd. When i will ad it as cache drive, will it automatically be formatted? Cause im not sure if its empty or how it is formatted...

Anyone?

It will be formatted. The contents will be removed.

I have a disk I plan on using as a cache drive.  It was previoulsy a disk that was upgraded so it still contains a valid partition and the original data that was on it (can be seen if I boot it up with a fresh unraid install away from my main array).  What is the best method to reformat the drive so it is blank and can go be the cache disk??

What is the best method to reformat the drive so it is blank and can go be the cache disk??

Best method, in my opinion, would be to run preclear on it - not only will this ensure that the old contents are obliterated, but it will also perform a health check on the drive.

Question.  My server consists of a microATX motherboard, Fractal Design mATX case, and 6 2 TB WD Green drives (note:  the power-down cycle on the WD Greens has been set to 300 seconds - irrelevant to my question however).  My motherboard has 6 SATA ports.  So basically what I'm saying is that I have all my hard drive slots and SATA ports already in use.  I want to add a cache drive mainly just for the plugins that need them, I'm not that concerned about improving write performance.  I would prefer not to lose space on my array.  What are my best options?  Can I get a PCI-E SATA card and a 5.25" to 3.5" bay adapter and just add a 7th hard drive, is that a viable solution?  Is there a recommended SATA card to get to ensure compatibility?

Question.  My server consists of a microATX motherboard, Fractal Design mATX case, and 6 2 TB WD Green drives (note:  the power-down cycle on the WD Greens has been set to 300 seconds - irrelevant to my question however).  My motherboard has 6 SATA ports.  So basically what I'm saying is that I have all my hard drive slots and SATA ports already in use.  I want to add a cache drive mainly just for the plugins that need them, I'm not that concerned about improving write performance.  I would prefer not to lose space on my array.  What are my best options?  Can I get a PCI-E SATA card and a 5.25" to 3.5" bay adapter and just add a 7th hard drive, is that a viable solution?  Is there a recommended SATA card to get to ensure compatibility?

See the following thread:

http://lime-technology.com/forum/index.php?topic=12404.0

You can add another drive as long as you have a free port, doesn't have to be assigned as cache if you only want it for plugins.

What plugins are writing a lot of to the flash drive ?

I've just added a cache drive, an 128GB Corsair Performance Pro SSD, but i'm not happy about the increase in speed. Before the cache was installed, i could copy directly to a disk at about 70MB/s, and to a user share at 35-40MB/s.

Now with the SSD cache, if i copy directly to the cache, the speed tops at 70MB/s (which is a bit dissapointing since i expected a bit more, but i guess my network aint faster) but if i copy to a user share, which has the 'use cache = yes' setting, it maxes out at 50MB/s... i would assume that there should be no difference in speed between copying directly to the cache, or to a user share which is cached?

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.

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?

I've just added a cache drive, an 128GB Corsair Performance Pro SSD, but i'm not happy about the increase in speed. Before the cache was installed, i could copy directly to a disk at about 70MB/s, and to a user share at 35-40MB/s.

 

Now with the SSD cache, if i copy directly to the cache, the speed tops at 70MB/s (which is a bit dissapointing since i expected a bit more, but i guess my network aint faster) but if i copy to a user share, which has the 'use cache = yes' setting, it maxes out at 50MB/s... i would assume that there should be no difference in speed between copying directly to the cache, or to a user share which is cached?

Funny thing. The SSD was connected to the motherboards SATA2 controller, and the hdparm -t test gave approx. 130MB/s. So i moved the SSD to the SAS2LP's SATA3 port. Ran hdparm -t again, and it DOUBLED the speed to average of 275MB/s...

BUT... copying from my pc directly to the cache still is about 70-80MB/s, and to a CACHED!!! user share, about 50MB/s... what is wrong? Why do i have almost NO gain in speed with this lightning fast SSD?

Why is copying to a cached user share SLOWER than to the cache itself? What's the use for caching user shares if they don't take advantage of the speed?

Anyone else experienced this? That a 'cache only' user share is almost 50% slower when copying to than the cache itself?

I'm using v5.0-rc5, should i report to the rc5 thread and file as a bug maybe?

*edit* downgraded to v5-b14, recommended by other unraid users. Didn't make any difference.

Also, added syslog.txt for those interested...

Supermicro X7SPA 525 board

Supermicro SAS2LP-MV8

6x Hitachi 4TB (HDS724040ALE640) 7200rpm (1x parity, 5x data) all on SAS2LP card

Corsair Performance Pro 128GB (cache) also on SAS2LP card

4GB memory

syslog.zip

I feel like i'm all alone on this forum...

Anyway, could it be that a user share, with 'cache=yes', is still under parity protection when copied to? I can't see any other reason why copying to a cached user share should be 50% slower then copying to the cache disk itself.

I would assume a 'cached user share' is NOT under parity protection, until the moment the MOVER script moves the stuff to the array... only when it's placed on the array it is protected.

Anyone?

Please?

In the spirit of giving you some sort of response, just to let you know we're still out here

Anyway, could it be that a user share, with 'cache=yes', is still under parity protection when copied to? I can't see any other reason why copying to a cached user share should be 50% slower then copying to the cache disk itself.

It shouldn't be under parity protection. Unless you've found a bug or your config is somehow wrong.

Regarding performance depending on what you mean specifically by copying to the cache disk itself - when writing to the user share (cached or not) you will be going through the user share fuse subsytem in unraid. If you're literally writing to /mnt/cache then you're avoiding that.

So there is more work involved in unraid writing the data - which is nothing to do with parity. This should be negligible but it would depend on the horsepower of your machine and also possibly the type of data you're writing (lots of small files I'd imagine to be much more intensive).

I would assume a 'cached user share' is NOT under parity protection, until the moment the MOVER script moves the stuff to the array... only when it's placed on the array it is protected.

That's correct broadly, but there are edge cases where it's not true (updating an existing file that has already been written to parity though you could argue it's no longer on cache at that point but that transition could be quick and unnoticed if you happen to be doing it whilst the mover runs, cache disk filling up etc).

I can't comment specifically on your problems - it could be a bug. I'd be more inclined to suspect, due to the silence, that it's more likely to be a misconfig on your end and no one else has seen this problem.

I personally don't use this feature and stick to using the hidden file .directory technique to have the mover skip over things I don't want moved. More historical than anything else.

Sorry - I don't think this helps much.

It shouldn't be under parity protection. Unless you've found a bug or your config is somehow wrong.

 

I can't comment specifically on your problems - it could be a bug. I'd be more inclined to suspect, due to the silence, that it's more likely to be a misconfig on your end and no one else has seen this problem.

Thanks... offcourse my config could be faulty, but i wouldn't know what i could have done wrong. Its a pretty basic setup. As differences in speed concern, other users tell me that copying to a cached usershare is as fast as copying to the cache itself (/mnt/cache/) but in my case, copying to the cached user share is 50% slower. So if this a fault in my config, where do i look?

I could take the parity disk offline to see if the speed catches up? That would 'prove' that a cached usershare is parity protected and could explain the difference in speed?

OK, took the parity disk offline, but the big speed difference remains. So it's not the parity...

differences in speed concern, other users tell me that copying to a cached usershare is as fast as copying to the cache itself (/mnt/cache/) but in my case, copying to the cached user share is 50% slower. So if this a fault in my config, where do i look?

Sorry I'd have to disagree with them. The second you go near a user share you're hitting the shfs fuse filesystem in unraid. Always a penalty there. It shouldn't be huge, but it's there.

You can have a look at your cpu usage when copying to the cache via the user share. I imagine you'll see a spike in shfs usage. As opposed to copying direct to /mnt/cache where you shouldn't.

Other than that I have nothing. Other than reverting back to using '.hiddendirectory' as per the old school method and seeing if that helps any. You're taking out the unraid 5 config options at that point.

Try with another SSD too.

This has nothing to do with the . or _ folders anymore, it's pure copy speed to the cache disk itself (/mnt/cache) or a user share with the setting 'cache = yes'.

Copy speed to a protected, non-cached user share is about 30MB/s, and to a cached (non protected!) user share about 50MB/s, so there is a gain in speed, but it's nowhere near the 80-90MB/s i get when i copy to the cache disk directly. I can understand that going through the shfs fuse filesystem comes with a penalty, but then the question is, how much is that? Does it really take 50%?

My workaround is this: I dont copy to the cached user share anymore, instead i create a 'tvseries/blahblah/season' folder BY HAND on the cache, and copy to that at full speed... and at night the mover can do its thing.

Surely this isnt the way it should work...

This has nothing to do with the . or _ folders anymore, it's pure copy speed to the cache disk itself (/mnt/cache) or a user share with the setting 'cache = yes'.

Yes I know. What I'm saying is if you go back to that method you're removing any unraid config option being the problem. This is unlikely but I don't think either of us have any better suggestions? It's diagnostic if nothing else. This will at least keep samba in the loop too (don't know how you're doing your copies if you're already using samba then ignore me).

Copy speed to a protected, non-cached user share is about 30MB/s, and to a cached (non protected!) user share about 50MB/s, so there is a gain in speed, but it's nowhere near the 80-90MB/s i get when i copy to the cache disk directly. I can understand that going through the shfs fuse filesystem comes with a penalty, but then the question is, how much is that? Does it really take 50%?

Measure it and find out. I would say no / it's unlikely. But it depends on your system really. Or you're actually still updating parity - but you've already ruled that out.

My workaround is this: I dont copy to the cached user share anymore, instead i create a 'tvseries/blahblah/season' folder BY HAND on the cache, and copy to that at full speed... and at night the mover can do its thing.

 

Surely this isnt the way it should work...

No it's not but no one else seems to have your problem.

As previous I don't have anything better than I've already suggested and they're really only ways to try and further isolate the issue. I'd be thinking about binning the entire config and starting again from scratch.

I'd be thinking about binning the entire config and starting again from scratch.

That's a lot of work... i i'm willing to do that as a last resort. I've allready stripped it down to bare metal, removed all 3rd party apps (dropbox/sickbeard/slimserver/sabnzb) and removed all other packages and plugins, didn't help... also unassigned the cache (ssd) drive, rebooted, re-assigned etc. Only thing i didn't try is removing all shares and add those again as welll?

Or is there another way of 'resetting' the server without losing all disks and data? I wouldnt mind rebuilding parity since i'm allready doing that at the moment.

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.