I've just assigned a disk to use as a cache, but i can't get the files I'm adding to the server to write to the cache disk, there still just going to the normal disks and creating parity at the same time..

 

 

I'm using user shares, and have selected yes to "use cache disk" on all the user shares... i even tried turning on disk shares and going into the cache disk and manually adding a movies folder in there.... what am i missing that's causing everything to still write to the normal disks

did you reboot?

 

 

I am experiencing the same issue.  Just to be sure I rebooted / retested prior to replying to this post.

 

I have 3 user shares configured to use the cache drive. 

 

All indications are that the cache drive is simply being ignored.  Even if I browse /mnt/cache in a telnet window it shows as being completely empty.  I've had the cache drive enabled on my shares for over a month now so I'd at least expect to see a quite large (and empty) directly structure on this drive.

 

BTW:  When I first attempted to use the cache disk (when initially introduced in 4.3-beta4) it did work just fine.  I'm running the Pro version of 4.3.3 right now and I'm not really sure at what point between beta4 and 4.3.3 the cache disk stopped working as advertised.

yea i've rebooted it, and as the guy above me said as well, it's just being ignored

Same thing happened to me. I eventually gave up and reassigned my cache disk. I figured I was too ignorant of Linux to use this feature until I had time to read up more about it.

OK.  Clearly this isn't an isolated issue.  I too am (for the most part) ignorant of Linux, but I don't want to give up.  I think the cache disk is a great idea and would like to use it.  If someone could give me any suggestions of what I might try as trouble-shooting steps I'm happy to try and post my results.

I had this problem also.  Here is what happened to me --

 

I have a download folder for hellanzb that writes to a user share.  Therefore it actually first writes to the cache drive as expected.  I telnet into the Tower and use MC to move the files to their proper user shares.  Because (I think) these are on the same disk they move instantly.  No waiting for large files to move from one disk to another.  Great!  Then I manually press the Move Now button to get everything where it needs to go but the files would not move.  They were ignored as others have found.

 

After just about giving up, I went to MC again and manually moved the files from the cache drive onto  a share with plenty of room -- but I moved them directly to one of the array disks.  Something like /mnt/disk5/Movies or /mnt/disk10/Music.  Then you have to install slocate (http://packages.slackware.it/package.php?q=current/slocate-3.1-i486-1) and build an index of your /mnt directory (very easy).  Then search the index for the file you moved manually from the cache to the disk#.  I will give the steps below but if you want an explanation here is my best GUESS at what is happening.

 

When a file is written to a user share it is actually written to the cache drive.  Then a symbolic link (I think this is a linux way of saying shortcut) is created on one of the /mnt/disk##/share folders.  When you see this file from the search it will have a zero file size.  Also, when you do an 'ls -l' in a telnet window this file will have an l in front of the permissions string (i.e. ldrwxr-xr-x).  I think the l stands for link.  Anyway for me, if this file was on a drive number lower than the drive I manually moved the file to, then the file would not work.  This is because of the way unRAID treats files with the same name in a user share.  unRAID only shows the file once, and uses the path of the file from the lowest disk.  In this case a 0 size file with a broken link since we manually moved the file from the cache drive.  Delete these links and even their directory on the disk drive in MC and now your manually moved file will work fine (and show up in its proper user share).  Then I deleted all of the empty folders on the cache drive. 

 

Now for some strange reason, everything works again.  The cache drive works perfectly again.  I don't really know why but it does.  So you may want to try this process to see if it works for you.

 

1. In MC move the files from the cache drive to a /mnt/disk##/share drive with plenty of space.

2. Install slocate

installpkg slocate

3. Create the file index database

slocate -U /mnt/ -v -o /mnt/cache/slocate.db

  I put my database file on the cache drive but put yours wherever is convenient.  It can be over 10M so be careful if you put it on /mnt/boot/.

4. When finished, search the file index database for the file or directory you previously moved

slocate -d /mnt/cache/slocate.db xxxx.xxx

where /mnt/cache/slocate.db is the path to your index file and xxxx.xxx is the name of your file or directory.

5. This will return a list of the paths to all instances of the file on your system.  Use MC to go to the directories and inspect the files.  There should be one on a disk## that has a file size -- this is the one you moved.  There should be one on a disk## that is a link and has a file size of 0.  Select the file in MC (CTRL+T) and then delete the file (F8). 

6. Do this for the other files.

7. Make sure your files work as expected from your user shares.

8. Delete all of the empty folders on the cache drive.

 

My cache drive works again.  I hope yours will too.

 

Bluto - I'm glad you resolved your issue.  Your info will surely help anyone else whose run into the same problem.

 

However, what I'm reading here is that you found a fix for a self-inflicted wound, but that before you used MC to move files from your cache drive everything was just fine.

 

What we're talking about in this thread is another issue where our cache drive is ignored to the point that files are never placed there to begin with.

I would like to refer you to a post by Tom concerning cache disk use, that may be relevant:  http://lime-technology.com/forum/index.php?topic=1731.msg12085#msg12085.

 

In particular, note the following :

Exception: if the cache disk is already full (meaning remaining free space is less than "Min free space" setting), then we don't use the cache disk & the folders/files will get created on the share normally - that is, according to it's allocation method.

 

I suspect the problem here may be the "Min free space" setting.  If this apparently internal setting is too high, then a Cache drive that is too small or does not have enough free space will not be used.  I don't like to speculate, but I can't help thinking that if MinFreeSpace is set by Tom based on percentages of disk size, or on the 'high water mark' (mentioned in the unRAID manual here:  http://lime-technology.com/wiki/index.php?title=UnRAID_Manual#User_shares, then go down to High-Water), then it may be set too high for User Shares with very large drives.

 

Complete speculation here, but as an example of what I'm thinking:  if MinFreeSpace were calculated based on disk size and set to 10% of largest disk, and you had added a terabyte drive to your User Share, then any Cache drive less than 100GB or had free space less than 100GB would be ignored.

 

This would explain the above Cache drive problems, when a user had large drives in the User Share and a relatively small Cache drive.  It would also explain bluto's results, as a case where he manually moved files from his Cache drive, thereby freeing space on it, and it worked again.

 

It would be useful to know, for each of the posters above, what the size of their Cache drive is, and the sizes of their drives in a particular User Share that refuses to use the Cache drive.

 

I suspect Tom will 'tweak' how this is calculated.

In my case it was a 750 Gb drive that I had previously been using for a Cache drive. Perhaps it was too 'full' then?

my cache drive "was" 120gig ide... with 2x750gig(1 parity) and 4x500gig sata drives for data, the cache drive was empty, as i had moved everything off it, and then remounted it as cache, i'd even tried a command i found on here somewhere to delete it's partition and recreate it, so unraid then reformated it.

 

the min free space thing in the web interface i tried lowering it, as it was 2000000 something, so i lowered it to like 10000 and even 0. but still didn't work

 

i've just gotten rid of it now anyway, but a future release will get all it's bugs sorted out and i'll give it another try

- I have 4 1TB drives (1 as parity). 

- Cache drive is 80GB. 

- Min. free space is 2000000 (2GB?)

 

RobJ - I read the post explaining the High Water allocation method.  Actually, reading this raised new questions as to why one of the included disks in the share is also being ignored as one 1TB drive has only 26GB remaining I'd think that under the High Water rules that I shouldn't have an empty 1TB drive in the share.  I'm expecting that maybe the Split Level setting of "1" might have something to do with this, but at the moment I'm just confused.  The punch-line to my joke is that I do think you may be on to something with your theory.  And if you're correct I'm guessing that the only options would be to get a much larger cache drive (larger than 80GB against 1TB drives) OR we need more discrete control over the High Water allocation method. 

 

At this point I'd welcome more conversation because I'm not 100% sure that I understand the situation, but my gut tells me you're on to something.

subwars, jarodtufts, fitbrit-

I would like to see your syslog after these steps:

1. reboot

2. copy some files to a share which has 'Use cache disk' set to Yes.

3. click the 'Move now' button on the Shares page

 

jimwhite-

No reboot should be necessary when changing Settings.

 

bluto-

Not sure what you're doing here... unRAID does not create any symlinks on the data disks.

 

RobJ-

The allocation method has no bearing on whether cache disk is used.  As long as cache disk is present & mounted, the share 'Use cache disk' setting is Yes, and the amount of free space is greater than the 'Cache Min. free space' setting, then it should create the object on the cache disk.

 

- I have 4 1TB drives (1 as parity). 

- Cache drive is 80GB. 

- Min. free space is 2000000 (2GB?)

 

RobJ - I read the post explaining the High Water allocation method.  Actually, reading this raised new questions as to why one of the included disks in the share is also being ignored as one 1TB drive has only 26GB remaining I'd think that under the High Water rules that I shouldn't have an empty 1TB drive in the share.  I'm expecting that maybe the Split Level setting of "1" might have something to do with this, but at the moment I'm just confused.  The punch-line to my joke is that I do think you may be on to something with your theory.  And if you're correct I'm guessing that the only options would be to get a much larger cache drive (larger than 80GB against 1TB drives) OR we need more discrete control over the High Water allocation method. 

 

At this point I'd welcome more conversation because I'm not 100% sure that I understand the situation, but my gut tells me you're on to something.

 

Right, you shouldn't have an empty 1TB drive.  I need to see your directory structure on the share.

Could someone please explain the min-free-space setting for a share that has the cache drive enabled.  I currently have this value on a share set to 0 and the mover is recording in my log that there isn't enough free space on the disk to move files from the cache drive when I know that there is plenty of free space.