I've been running v3.0 pro happily for many moons and decided to try the 4.3-beta6 and the cache drive feature.  I moved some files off an unRAID disk and made it the cache drive.

 

I setup a user share (movies) using the default allocation method (high-water) split level (0), included disks (all), and excluded disks (none).

 

I have three available data disks with size and free space as per below. disk3 became the cache drive.

 

disk1  size - 390,711,352   free -  20,007,192

disk2  size - 390,711,352   free -  28,111,080

disk3  size - 199,148,512   free - 199,109,588  (Not installed, used as cache drive )

disk4  size - 390,711,352   free - 294,900,264

 

With the cache drive enabled for the movies share setup as above I copied a directory with a single .iso file sized 22,198,720 from a client to the movies share.  The copied directory and file was written sueccessfully to the cache drive as expected at a nice speed.  The next morning I noticed disk1 was out of space and that the copied file still existed on the cache drive.  The directory and copied file also existed on disk1 in the movies directory but was incomplete since as per above disk1 didn't quite have enough free space to hold that sized file.

 

Thinking it might be a bug with the cache drive or chron file mover implementation I deleted the (iincomplete) file from disk1 and the (complete) file from the cache drive and disabled the cache drive.  When I tested copying the file again from the client to the movies share it again went to disk1 which of course still didn't have quite enough free space to hold the copied file.

 

Perhaps there's something I don't understand about the use of user shares and/or the high-water allocation method but this seems like very bad behavior to me.  It seems to me the allocation algorithim should NEVER attempt to write a file larger than the remaining space on any given disk it attempts to write to.  I'm hoping this is a bug which can be fixed.  It seems like this condition would be relatively easy to re-create and test and/or somebody else must have run into it?

 

I read the below referenced thread including Tom's comments and wonder if things are working as designed or if I need to re-think how user shares and allocation work

 

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

 

I'd be happy to re-create the behavior and post a log if that would help.

 

--Don

 

ps I'm studying the below posts to try and figure out strategies to take to avoid the behavior I'm seeing but would appreciate any further comments

 

Question about High water allocation method

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

 

User share... out of disk space... but I am not

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

I think a split level of "0" indicates that folders should never be duplicated on other disks, so it would fail to try a different disk, because you asked it not to.  Try a split level of "1" and see if it helps.

 

Joe L.

 

PS.

Just guessing how it would work with the cache drive, as I do not have one defined in my array.  Others with split level of "0" have had the same issue though.

 

 

Joe is exactly right.  With split-level 0, the s/w will look for the first disk (counting from 1) which contains the directory you're trying to copy to, and then write the file to that disk.  You want to set split level to 1.

 

As for running out of space - it depends on how the file is created.  Some protocols will tell the target system that it is going to create a file of exactly N bytes, and then proceed to write the file.  Others will first create the target file with size 0, and then "append" to it as the copy proceeds, and hence the target system doesn't know the final size of the file until after it's been written.

 

This behavior of not telling the target system the size of a file being written is also why there is a "Min free space" setting on the cache disk.

Thanks, that does appear to solve my problem.  I'd suggest not using 0 for the default split level setting since it can cause this nasty behavior but I suppose there are reasons I don't understand for that choice.

 

Unfortunately, I now have a different, strange problem.  After setting the split level for the aforementioned movies share to 1, the mover successfully moved a couple of .iso images sitting on it overnight.

 

One .iso image went to one of my installed disks (disk4) as expected, but the other went to my *not installed* disk3 which had been assisgned as the cache disk.  unRAID appears to believe this physical drive is two different disks (the 'not installed' disk3 and the cache drive).  It sees the size of each as the same but the free space as different.  The .iso file in question appears in the disk3 movies directory but not in the cache disk movies directory.

 

Did I confuse unRAID by un-assigning a previously assigned disk and re-assigning it as a cache drive? I wonder what would happen if I excluded disk3 from my shares?

 

Attached are scans of my unRAID main and devices screens to illustrate.

 

When you "un-assigned" disk3 it was exactly the same as if disk3 had failed.  Your server still thinks it is part of the array of disks it is protecting with parity.

 

The un-assignment of a disk is one way to test how your array will perform when a drive fails.  At this point, the parity drive and all the other data drives are supplying an image of what used to be on disk3.

 

To make your array forget about drive three you must un-assign it, and then use the "Restore" button on the main page to store a new configuration without the un-assigned drive.  (Restore does not actually restore anything, it instead Stores a new configuration based on the currently assigned drives and then proceeds to re-calculate parity baded on the currently assigned drives.)

 

So... if the file on disk3 is important, move it to one of the other disks using the "disk" shares or...

 

Telnet in and type

mv /mnt/disk3/your_filename.iso /mnt/disk4/

 

Then, use the "restore" button, and you should be back to where you think you should be.  You discovered a feature of unRAID, not a bug. A missing disk can still be read AND written to.

 

Joe L.

Great, thanks very much for taking the time to explain that Joe much appreciated.  You are a hero member indeed!

When you "un-assigned" disk3 it was exactly the same as if disk3 had failed.  Your server still thinks it is part of the array of disks it is protecting with parity.

 

Hmmm, I actually did not know (or realize) that . I thought un assigning a disk removes it.

So in theory, could I "move" the data to another physical disk by un assigning it and re assigning another disk to the slot?

When you "un-assigned" disk3 it was exactly the same as if disk3 had failed.  Your server still thinks it is part of the array of disks it is protecting with parity.

 

Hmmm, I actually did not know (or realize) that . I thought un assigning a disk removes it.

So in theory, could I "move" the data to another physical disk by un assigning it and re assigning another disk to the slot?

Not just theory, but that is exactly how you would replace a drive that fails.  The new drive has to be at least as big as the original, and also equal or smaller than the parity drive.  (although there is a procedure to swap them if the replacement drive is bigger than the parity drive)

 

Right now, in effect you have an array with one "failed" disk.  You would lose data if any other disk would fail at the same time..

When you assign another disk to disk3 the data will be restored to it and the red-indicator will turn green once more. At that time you will again be protected from a drive failure.

 

If you do not want the data on disk3 any longer, or have moved what was put there last night off, you can use the "Restore" button to save a new configuration without it and it will re-compute parity on the remaining drives.

 

You will want to do one or the other as soon as practical otherwise, there is no additional protection from a subsequent disk failure, and that would negate the reason you are setting up an unRaid array.

 

Joe L.