unRAID Server release 4.3-beta4 available

Tom, when copying a file to the cache disk, how about creating a symlink for on the appropriate array disk back to the file on the cache disk immediately, so the file is available natively before the mover gets to it?

like fatal, I have settled on the "read-only" user shares (so no one accidentally deletes/moves/modifies files on the server), and I write directly to hidden disk shares to update content.  Are you saying that I cannot use the cache disk feature with this setup?

Second, with regards to the idea of using the cache disk as a "hot spare", what happens if you have a drive failure, and 400GB of "stuff" still on the cache drive?  Because if you are using the cache drive feature, you are pretty much guaranteed that you are going to have files on there at any given moment, so I am not sure how you could use it to rebuild an array without losing all the data on the cache disk...

Lastly, I am not currently using a parity drive (need more space too badly right now).  Is the "slow write" performance tied to the use of an array with parity?  In other words, will the cache disk provide faster writes over a non-parity array?

Second, with regards to the idea of using the cache disk as a "hot spare", what happens if you have a drive failure, and 400GB of "stuff" still on the cache drive?  Because if you are using the cache drive feature, you are pretty much guaranteed that you are going to have files on there at any given moment, so I am not sure how you could use it to rebuild an array without losing all the data on the cache disk...

A way to get around this, as well as a feature I'd like to see (if it's not there already; waiting on a 1TB drive to come in so I can replace a 400GB drive and use it as the cache drive ), is a way to manually force a "cache dump" to the array itself, instead of waiting for the scheduled mover.

Second, with regards to the idea of using the cache disk as a "hot spare", what happens if you have a drive failure, and 400GB of "stuff" still on the cache drive?  Because if you are using the cache drive feature, you are pretty much guaranteed that you are going to have files on there at any given moment, so I am not sure how you could use it to rebuild an array without losing all the data on the cache disk...

I don't think there is any chance of it working that way.  No one would use a feature that could at any time cause data loss.  I imagine that when/if this 'hot spare' feature is implemented, on receiving indication of a failed drive within a parity-protected system, it would first check to see if the user has configured the cache drive as a 'hot spare', then check to see if it is empty.  If not, it would call the 'mover' thread, and recheck.  Only if the drive is completely empty of all files (empty folders would not count), would it proceed to substitute it for the failed drive.  In the future, an option for advanced users could be added, to allow conversion of the cache disk to hot spare if a convert_to_hot_spare script is found.  It would allow a user to shut processes down that might be using a swap file on the cache disk, delete any swap file, and move any special data off the drive.  In any case, there is no way a cache drive would be allowed to be used as a hot spare if there are ANY files left on it.  Just my thoughts of course...

Lastly, I am not currently using a parity drive (need more space too badly right now).  Is the "slow write" performance tied to the use of an array with parity?  In other words, will the cache disk provide faster writes over a non-parity array?

Testing will provide the best answer, but writing to the cache drive should be the same as writing to any unprotected drive, that is, any data drive in a system without a parity drive, such as yours.

A way to get around this, as well as a feature I'd like to see (if it's not there already; waiting on a 1TB drive to come in so I can replace a 400GB drive and use it as the cache drive ), is a way to manually force a "cache dump" to the array itself, instead of waiting for the scheduled mover.

Remember you are trying to use this as a "hot spare" to rebuild an array that just lost a drive, yet you want to do a "cache dump" to that same degraded array?  Probably not gonna work very well, and might take longer than ordering a new hard drive! 

And if you are using the cache drive feature, it seems that having files on it at any given time is almost a guarantee, unless you are moving files constantly (kinda defeats the idea of caching to me), and even then get's a little lucky...

RobJ, thanks.  I don't need tests or measurements.  I just wanted confirmation that parity is the main reason an array would be slower than a non-array disk.  Sounds like that is indeed the case.  So not a critical feature for me at this moment... 

Tom one more question:

What happens if you select to have cache for let say a folder named Movies on disk1 and the files you move in one single day (i.e. before mover runs) are LARGER (in total) than the available cache space? Do the rest of the files directly go to the appropriate disk? (loosing the speed bonus)

Remember you are trying to use this as a "hot spare" to rebuild an array that just lost a drive, yet you want to do a "cache dump" to that same degraded array?

I think you have just hit on a major defect of this idea, converting the cache disk to a hot spare, a problem big enough that I do not think that I would want to use it.  It is great that unRAID supports writing to a degraded array, but it certainly has increased risk.  Imagine having a 16 disk unRAID array, and one data drive goes down.  All you will be thinking about at that point is worrying about a second disk failing, and losing data.  If you copy file(s) to that array (as in a Cache dump), then ALL 15 of the other drives have to have their corresponding blocks read, making it very likely that you will be accessing long unused blocks on other drives, which increases the chance of a disk error occurring, which increases the chance of a second disk failure.  A small array would only have a small risk, but a dedicated 'hot spare' disk would still be safer.

Tom, when copying a file to the cache disk, how about creating a symlink for on the appropriate array disk back to the file on the cache disk immediately, so the file is available natively before the mover gets to it?

Let's say you have a user share named "Videos", which you allow to span disk1,disk2,disk3, and the cache disk is enabled for it.  On the Shares page you might have this:

Share name: Videos

Comments: Home movies

Allocation method: High-water

Split level: 1

Included disk(s): disk1-3

Excluded disks(s):

Use cache disk: Yes

Export mode: Export read/write

Scenario 1

Let's say I navigate to the Videos share under My Network Places and create a folder called "Spring 2008", and then copy the file "Aspen.avi" to that directory.  Since the cache disk is enabled for this share, system will:

a) create "Videos" directory on cache disk (if not already there)

b) create "Spring 2008" directory on cache disk (if not already there)

c) create "Aspen.avi" on cache disk

Later, whenever the mover is schedule to run, "Aspen.avi" will be copied to either disk1,disk2, or disk3, and then removed from cache disk.  The directory structure on the cache disk will remain however.  This is all transparent to accessing this folder structure via "Video" share under My Network Places - at all times the folder structure will be visible no matter which disk the folders/files actually reside on.

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.

Scenario 2

Same config, except that under "Export settings" on the Shares page, I also have "Disk shares" set to "Export read/write".  In this case, in addition to seeing all my user shares under My Network Places, I will also see all the disk shares (i.e., "disk1", "disk2", etc.), as well as the cache disk as "cache".

I then navigate to the cache disk share "Videos/Spring 2008" folder, and directly copy "Vale.avi" to this folder.  Now if I go back and click on the "Videos" share, I will immediately see that "Vale.avi" is in the "Spring 2008" folder there.  Note that I can directly write to any of the disk shares in this manner and the folders/files will immediate show up in the appropriate user share [but see *note below].

Scenario 3

Same config, except the Video user share export setting is set to "read-only".  In this case, I can not directly write to the user share, but I can still write to disk that is part of the user share (including the cache disk).  In other words, the user share export setting only applies when accessing files through that share.  If you wanted to totally disable writes, in addition to setting the user share write-only, you would also have to set the global "Disk export" setting to "write-only" or "don't export".

*note: here's how 'duplicates' are treated: A 'duplicate' is when the same file exists in identical folder structures on two or more disks.  For example, suppose you already have this:

/disk2/Videos/Spring 2008/Breckenridge.avi

and then you create the same named file on the cache disk:

/cache/Videos/Spring 2008/Breckenridge.avi

When you navigate to the Videos share via My Network Places, you will only see a single file named "Breckenridge.avi" under the "Spring 2008" directory.  The version you see (and would be accessed) is the one on the lowest numbered disk, where the cache disk is lower than any data disk (ie, as if it were "disk0").  So you would be accessing the version of Breckenridge.avi which is on the cache disk in this case.

Later when the mover decides to move Breckenridge.avi, there are three possibilities:

1. If, according to share allocation method, disk1 is the one picked to be the target, then Breckenridge.avi will get moved to disk1 and you will still have a duplicate.  But since disk1 is lower than disk2, you would see the version on disk1.

2. If, according to share allocation method, disk2 is the one picked to be the target, then Breckenridge.avi will replace the one on disk2 (note it's possible to configure the 'mv' command in the mover to not replace existing files - if set up like this then the file will remain on the cache disk).

3. If, according to share allocation method, disk3 is the one picked to be the target, then Breckenridge.avi will get moved to disk3 and you will still have a duplicate.  But since disk2 is lower than disk3, you would see the old version of Breckenridge.avi instead of the new one.

Because of the problems with duplicates, we strongly encourage you to not have duplicates!

Tom one more question:

 

What happens if you select to have cache for let say a folder named Movies on disk1 and the files you move in one single day (i.e. before mover runs) are LARGER (in total) than the available cache space? Do the rest of the files directly go to the appropriate disk? (loosing the speed bonus)

Correct.

Lastly, I am not currently using a parity drive (need more space too badly right now).  Is the "slow write" performance tied to the use of an array with parity?

Yes.

In other words, will the cache disk provide faster writes over a non-parity array?

No.

Remember you are trying to use this as a "hot spare" to rebuild an array that just lost a drive, yet you want to do a "cache dump" to that same degraded array?

 

I think you have just hit on a major defect of this idea, converting the cache disk to a hot spare, a problem big enough that I do not think that I would want to use it.  It is great that unRAID supports writing to a degraded array, but it certainly has increased risk.  Imagine having a 16 disk unRAID array, and one data drive goes down.  All you will be thinking about at that point is worrying about a second disk failing, and losing data.  If you copy file(s) to that array (as in a Cache dump), then ALL 15 of the other drives have to have their corresponding blocks read, making it very likely that you will be accessing long unused blocks on other drives, which increases the chance of a disk error occurring, which increases the chance of a second disk failure.  A small array would only have a small risk, but a dedicated 'hot spare' disk would still be safer.

 

I for one would be very much in favour a having a hot spare in addition to the cache disk. The way I see it, I could keep my hot spare in the array (it would have to be the same size as the largest drive in the array), until such time as I would need to add another drive for more storage or until a failure is detected. Then, if I decided to bring the hot spare in as additional storage, I could place an order for a new drive to meet my increased needs to be used as a hot spare until pressed into service.

If I had the choice, I would want the server to almost shut down when a fault is detected until it has brought the hot spare online and finished rebuilding. IMHO, a small price to pay for extra safety.

My two cents.

I don't like the hot spare concept. 

If a drive in an array appears to fail it may or may not as simple to fix as doing a rebuild.  For example, the failure may have been induced by a fan failure or HVAC failure in your house.  The worst thing to try to do if the computer is operating at a high termperature is to start a drive rebuild!  Or a controller may have failed and doing the rebuild may build a bunch of junk and ultimately corrupt your parity disk.  My advice is keep your spare on the shelf until you determine you need it.  Better yet, let the drive sit on Newegg's shelf until you need it.    I'd much prefer unRAID do as little as possible and wait for me to figure out what to do next.

If you have high availability requirements like a data center, the hot spare concept might be appealing.  But if you are a data center, you also have a data backup of everything and losing the entire array is only an inconvenience, not a disaster.  For me, reliability is more important than availability.  I wouldn't want unRAID to automatically rebuild on my cache disk or some other disk.

I'd much prefer to see some of these features which increase relability (but lower availability):

- Forced spindown if a drive hits configurable temperature A (e.g., 50C).

- Forced (clean) shutdown if a drive hits configurable temperature B (e.g., 53C)

- Forced (dirty) shutdown if a drive hits configurable temperature C (e.g., 56C).

- Forced (clean) shutdown when unRAID encounters certain severe errors (like detecting a drive failure).

- Forced (clean) shutdown after a power failure (signal from UPS)

If a forced shutdown is done, it should first try to save the syslog to the flash drive so a person can figure out why.

By manually editing some config file, you'd want to be able to turn off these auto-shutdown features to do diagnostics.  For example, if a drive's termperature mechanism goes screwy, you'd want to be able to boot to figure it out.

Just my $0.02

Very good points, Brian.  I believe you've convinced me, that at least for my way of using unRAID, I would prefer for the array to go offline, notify me, and let me decide what should happen.  The odds are good that a hot spare will restore the array without any problems, but I have absolutely no need for 'high availability', so why risk it.  Hot spares may be more important for others.

I'd much prefer to see some of these features which increase relability (but lower availability):

 

- Forced spindown if a drive hits configurable temperature A (e.g., 50C).

- Forced (clean) shutdown if a drive hits configurable temperature B (e.g., 53C)

- Forced (dirty) shutdown if a drive hits configurable temperature C (e.g., 56C).

- Forced (clean) shutdown when unRAID encounters certain severe errors (like detecting a drive failure).

- Forced (clean) shutdown after a power failure (signal from UPS)

 

If a forced shutdown is done, it should first try to save the syslog to the flash drive so a person can figure out why.

 

By manually editing some config file, you'd want to be able to turn off these auto-shutdown features to do diagnostics.  For example, if a drive's termperature mechanism goes screwy, you'd want to be able to boot to figure it out.

 

Just my $0.02

 

-Brian

This would be very good for security!

I hope features like this can be included in 4.3.

For security I am not sure how. For safety probably yes.

Perhaps you use "rsync" instead of "mv" to transfer the write cache to the "array proper"?

-> rsync allows you to limit the bandwidth you are using for the writes with the "bwlimit" switch.

-> Any large files that were interrupted by an unraid reboot would continue from the point they were interrupted.

-> You wouldn't need crontab and your performance wouldn't crash when you're having trouble sleeping at 3:40 AM.

-> Sometimes mv "loses" files if the right combinations of error conditions arise.

I've been using this method for a write cache disk for almost a year now and it works well.  The write cache disk is on each host (not the unraid array) and it writes to the unraid array using rsync across the network and a bwlimit=2048k.  rsync also works fine with localhost and has good performance.

My unraid array installs the rsync package and runs the daemon when it starts.  There are a seemingly infinite number of switches on rsync to control how the file is transferred so that it can be done most efficiently.

I'm not sure if it will work for everyone or not, but having lived with the "write problem" and worked around it - I wanted to share what has worked for me.

This forum has done so much to help me, that I hope this post will be helpful in some way.

Where is this version downloadable from? I don't see it in the downloads section.

thats because it has been superceded by 4.3.3 stable

Also, the mover does not delete the directory structure on the cache disk, thus it is possible for many empty directories to accumulate on the cache disk over time.  This will be addressed in a future unRAID OS release.

Is it safe to manually delete these  empty directories on the cache drive manually?

Yes.  You would first want to make sure that any sub-folders are also empty.