It might be somewhere in the forum but couldn't think of a proper search string.

 

Anyway my question is this:

 

If on the cache drive, I in fact "update" files already on the data array, what happens? Are those files moved properly?

 

To make it more specific: If I point a torrent client to some existing folder in my array and the client finds that the torrent needs some updates (some new files and some old files replaced by newer versions), can I safely use cache?

 

 

Any cache, whether it is the unRAID cache drive or an L1 or L2 CPU cache or a hard drive 8MB cache or etc, is supposed to be transparent to normal operation.  Everything should just work, as normal, with or without the cache, except hopefully faster with the cache.  I haven't personally used a Cache drive yet, but there don't seem to be reports of any unusual behavior yet, and I imagine Tom would want to hear of anything inconsistent with the expected behavior.  It should just work, and it shouldn't matter if the cache has not been 'flushed' yet.

 

In this case, I would think that modifying a file involves making changes directly to the parity protected file on a data share, Cache drive not involved.  On the other hand, replacing a file might involve deleting the old file from the data drive, then creating the new version of it on the Cache drive.  But again, you shouldn't have to even think about whether the Cache drive is involved or not.

 

yes but cache is still in beta, that is why I ask

 

mv by default I think does NOT replace existing files (then again I haven't even checked mover script to see what happens)

 

 

If an application opens an existing file already on the array, new writes to that file will go to the array.  The cache disk only comes into play when a new directory or file is created.

 

Note that it sometimes not obvious what's happening "under the hood" with different applications.  For example, suppose using Windows Explorer, you drag a file from your desktop to a share.  If that file does not already exist, then it will get created on the cache disk (if enabled for that share).  If the file already exists, Explorer will pop up a window asking if you want to overwrite the existing file.  If you click 'Yes' then the new file actually gets created on the array because what Explorer actually does is a file truncate followed by file append - it doesn't actually delete the file and then create a new one.

 

We have been looking at changing the user share code to recognize this: if a file truncate to 0 occurs, then we could instead delete the file and create a new one on the cache drive - current code does NOT do this however.

 

 

BTW, 'mv' command DOES overwrite by default.

Ok let's make it more complex (again fits in my current scenario described above)...

 

I rebuild a torrent to a new place, using old files...

 

I suppose everything goes to cache.

 

Then me ignorant newbie (or just user), go on and start sharing this torrent set all night.

 

Somewhere there, the mover kicks in.

 

Naturally, some files are locked because someone downloads them from me.

 

What happens? Do those (and only those - the locked ones) files just stay in cache (for the day), while the rest go to their final destination and all is well?

 

(btw just came to me... 4.3 final, should probably have a way to temporarily disable mover script - there are cases this might be needed)

 

 

It's going to depend how your torrent app opens the files for download.  Probably will open for read only, so in this case the mover will copy the open file to the array, but when it tries to delete, the 'mv' for that file will fail, and you will a see a syslog entry (in the next release where the bug that prevents such entries is fixed   But you will have 2 copies of the file - one on the cache disk and the copy it made to the array.  However, when you list the directory that file is in, or access the file in any way, the one on the cache disk will be referenced - so in effect the copy on the array is a "dead" file - more accurately it's a "duplicate" and will show up as such in the syslog.

 

As for temp. disable mover.  Maybe.  But in this particular case I would suggest making your torrent share non-cachable instead.

 

Might mention a similar thing happens when the array disk runs out of space during the 'mv' (the 'cp' portion of the 'mv' command opens a new file and then appends to it).  In this case you will again have 2 files - one on the cache disk and one on the array; and what's more, the copy on the array will be truncated.  But as long as the cache disk is present, the correct file will be referenced in future accesses.  But if the cache disk fails or you remove it in such a state, then you might get a surprise 

when you have a duplicate, I guess next day, mover retries to make the move right? (and if successful the cache file is finally deleted)

 

 

when you have a duplicate, I guess next day, mover retries to make the move right? (and if successful the cache file is finally deleted)

 

 

 

Correct.

final q: if I change the schedule through web interface - when does this change "registers"? immediately? (or do I need a reboot, array restart or whatever)