Joe L.

I personally use cache_dirs -w -e "data"

root@Tower:~# lsof /mnt/user 2>/dev/null | grep -v "PID USER" | more COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME smbd 5139 nobody cwd DIR 0,13 536 17592186071455 /mnt/user/Backups smbd 5139 nobody 26r DIR 0,13 536 17592186071455 /mnt/user/Backups smbd 5139 nobody 32r DIR 0,13 536 17592186071455 /mnt/user/Backups smbd 5139 nobody 34r REG 0,13 74695784 17592186046319 /mnt/user/Backups/irefield100.ts Thank you. I think I see the issue. Around line 307 is this: # Get the list of logical disks affiliated with the user-share being accessed lsof /mnt/user 2>/dev/null | grep -v "PID USER" | while read a b c d e f g h i I changed it to this: # Get the list of logical disks affiliated with the user-share being accessed lsof /mnt/user 2>/dev/null | grep "/mnt" | while read a b c d e f g h i The idea was to get rid of the column headings. Originally, with "root" as the only user, the pattern matched as PID and USER were separated by one space. With the user "nobody" the two column headings have several spaces between them, so the "grep -v" did not exclude the heading. Instead, now I just look for the lines with /mnt. (same end effect, but does not depend on spacing in header between PID and USER) An updated version of the script is attached. See if it works for you. Joe L. spinup_when_accessed.zip

However, this is not the cause of the slow transfers... It is an issue you'll need to correct at some point before you have to deal with a disk failure.

drwxrwxrwx 11 nobody users 536 2013-05-06 03:42 /mnt/disk12/Backups/ That is exactly as expected... I'm trying to identify what the difference might be. (you are correct though, it is not working properly on your server) Now, one more command to try for me, while the file is being accessed: lsof /mnt/user 2>/dev/null | grep -v "PID USER"

What do you see when you type: ls -ld /mnt/disk*/Backups

What makes you think you need it at all? (Most of us with Microsoft clients on the LAN do not.. Only people I can think of who might are those with Linux or MAC clients on their LAN.)

You've given symptoms, but provided no clues. Have you changed unRAID versions since you last "dumped data" to the array? Do you think letting us know the version of unRAID you are using, or attaching a syslog and the output of ifconfig eth0 would help us with some clues? (hint... they would)

Unfortunately, no, those shown in the screen capture are NOT the recommended settings. The min and max seconds per scan should be 1 and 10 The actual values dynamically adjust themselves, so constraining them to a smaller range will not help much. Most people do not need to populate anything in the "Include" or "Exclude" directory fields. In fact, the example shown would ONLY scan "tmp" and ".apps" and that is probably not where all the media lives on that user's server. (They are illustrating a bad set of settings) Apparently, the person who copied the cache_dirs code into a plugin does not know much about using it. Joe L.

Sorry to say, if installed from a plugin (as you seem to have done to have a GUI screen) then it probably will not have the files expected from an unMENU install. Joe L.

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=27604.0[/iurl]

No, unMENU does not install hdparm. Other than loading its own files in /boot/unmenu, nothing is installed automatically. unMENU does not install anything on its own. unMENU only installs packages you choose to install in its package manager. hdparm version 9.37 is NOW part of the standard unRAID distribution. The only reason "hdparm" is available as a package in unMENU is because at one time you could elect to install the newer version 9.37 to replace an older version. ( version 9.37 was newer than the older version 9.27 included on older versions of unRAID). See here: http://lime-technology.com/forum/index.php?topic=22458.msg199131#msg199131 Joe L.

You apparently have 32Gig of RAM. Am I correct? If so, read here: http://lime-technology.com/forum/index.php?topic=22675.msg225348#msg225348 reboot and use the 4Gig memory option in the boot menu. It will likely help a lot. It will NOT help unless you are writing to a 7200 RPM data drive, or simultaneously writing to multiple 5400 RPM data drives. Correct, parity disk is not involved with writes to the cache drive. Write performance to the protected disks in the array are ultimately limited by the slowest rotational speed drive involved ,since the disk platters MUST rotate in between the READ and then WRITE of the same sector on both the parity disk and the data disks involved. See the above link for current issue when > 4Gig of memory present on some hardware. Probably will not make a difference in speed. You can experiment. There are some disks with a firmware bug that lost data if NCQ was enabled and you invoked either a smartctl or hdparm command. You might want to make sure you don't have one of that model disk. If a driver was missing, you would not be able to get to the disk at all. There will be updates to drivers constantly in future releases of unRAID. Since the next release of unRAID is predicted in June, you could wait a few days to see what evolves.

basically, stop the array and reboot. The user-shared file-system crashed, so everything under /mnt/user is not accessible. The data is still there however, on the actual disk file-systems. Joe L.

You also cannot remove a directory if you've changed directory to it. So log off. OR you can remove it easily by typing cd / rm /mnt/user/Movies If it still says it is not empty, type ls -al /mnt/user/Movies to see what remains.

If the 640 GB drive is the current cache drive in movieraid, it will NOT be re-constructed when replaced with a 1TBThe cache drive has no protection from parity and the other data disks. It will NEVER be reconstructed. If the 640GB drive is currently a data disk assigned to the protected array, it will be re-constructed onto the 1TB drive when replaced with the 1TB drive. Since you only mentioned one 640GB drive, and it was mentioned as the cache drive, I'll assume it will NOT be re-constructed, but instead you would see the old contents of the 1TB drive. Joe L.

The preclear plugin was removed from SimpleFeatures. The error is expected. Use the command line version available here: http://lime-technology.com/forum/index.php?topic=2817.0

You are incorrect... it is a problem on any disk. If the one disk with the HPA dies, then the BIOS will write one to another. (and either clobber parity, or a file-system on a data disk) Basically, it is a ticking time-bomb... waiting for one of the disks in the array to fail, and eventually one will. Find another MB, or see if the BIOS on your MB can be upgraded.

sync = calculate parity based on READING ALL DATA DISKS and WRITING calculated values to parity disk. check = calculate parity based on reading all data disks and then compare calculations to values READ from parity disk. (it should match, if not, then parity is incorrect) sync = writing parity check = reading parity Joe L.

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=21323.0[/iurl]

I don't know of anything in unMENU that is used by the mover. After you removed SimpleFeatures and /boot/unmenu, did you reboot? (That IS necessary to actually un-unstall whatever you had previously installed) The rsync error might be an indication that you are running out of memory. (or memory corruption) Another less likely possibility is memory that is causing errors. I would perform a memory test to rule that out. The error you are seeing is not one that indicates any kind of data loss. Nor does it indicate a system crash.. (although "rsync" is obviously crashing.) To remove everything SimpleFeatures installs you need to rename /boot/extra (or delete its contents) and remove the contents of /boot/plugins and /boot/config/plugins and then reboot. Joe L.

Make sure you disable any spin-down while performing the long test. A spin-down will abort the test. Joe L. Good to know - but I'm surprised that it would be spun down while it's still actively in use. I gather this means the spindown timer is maintained by UnRAID without "knowledge" of other disk use by Linux. Does this mean add-ons that only use the cache drive (i.e. no writes to the array) could encounter the same issue? I'm pretty sure unRAID uses the built-in spin-down timer on the cache drive, but not sure if the SMART test triggers it. Best to disable the spin-down during a long test. Joe L.

Make sure you disable any spin-down while performing the long test. A spin-down will abort the test. Joe L.

You forgot the step where you START the array with disk1 unassigned or disconnected. Unless disk1 (the one you will assign the current parity disk) is showing a RED indicator BEFORE you swap any other disks into the array, the swap-DISABLE procedure will not work. Once it is showing a RED indicator, you can stop the array and swap the disks as you described.

Unfortunately, the CX series are nowhere near as good as the higher-end Corsairs. I've seen several cases where systems wouldn't boot reliably with CX series supplies ... but work fine with their better units. Personally, I only buy HX series units, but the TX series is also quite good. [The AX are outstanding supplies, but I can't think of any reason to spend that much.] Yes, this is a good idea. But don't try to rebuild it on the failing drive ... you can deal with that later. You will, of course, need a new 2TB drive. I'd suggest a new WD Red unit. You'll probably have to use the "trust parity" feature to force UnRAID to use the old parity drive; but if you're CERTAIN ... I mean REALLY CERTAIN ... I mean ABSOLUTELY REALLY CERTAIN ... that nothing's been written to the array, then that's fine A new 2T is not required. Use the parity-swap-disabled procedure: 1. Install the original 2T parity drive. 2. Replace disk1 with a 3T drive. 3. Power-on the server 4. Assign the 3T drive as parity and the (formerly) parity drive as disk 1. 5. Start the array. UnRAID will copy parity from the old parity drive to the new 3T parity drive and then rebuild disk1 on the 2T drive that was formerly parity. Be careful here. The swap-DISABLED procedure will only work if the disk being replaced is already disabled. You cannot just swap around working disks.

It is a good practice since it weeds out the drives that might fail in their first hours of use AND it identifies any un-readable sectors BEFORE you put your data on them. It does not shorten then time the array will be off-line, since the array is online when a disk is being re-constructed even if a disk is not pre-cleared when being used as a replacement for an existing drive and a drive re-construction is occurring. If you feel lucky, you can skip it, but roughly 1 in 5 drives seems to be defective from the factory... Care to play the odds? Joe L.