Freddie

Good guess, It's working fine from my laptop. I've tried to revert to rc3 (which by the way is smooth and easy with the new procedure) and had the same result from my main computer, empty log windows. If anyone has a guess about what could be causing this, anyway I'll have a way to see logs using my laptop for the time being Thanks This happened to me on a previous upgrade. I ended up finding an old log window (which had worked) was still open. After closing the old log window, a new log window worked fine. I tried to reproduce the problem but couldn't.

I had a data disk and cache disk drop out. I'm comfortable with the steps needed to recover the array, but I wanted to document a couple of inconsistencies I'm seeing with the data disc status. I'm running version 6.0-rc3. The unRAID webGUI Main tab shows disk7 with a gray triangle. The tooltip legend/key suggests a triangle means "Content Being Reconstructed" and the gray means the disk is spun down. All other indications are that disk7 has been disabled so I would expect to see a red square, according to the legend/key. The disks.ini file shows: ["disk7"] idx="7" name="disk7" device="sdf" id="SPCC_Solid_State_Disk_D70207470B6B00621416" rotational="0" size="234431032" status="DISK_DSBL" temp="*" numReads="97767" numWrites="38725" numErrors="4" format="MBR: 4K-aligned" type="Data" color="red-blink" fsStatus="Mounted" fsError="" fsType="xfs" fsSize="234316564" fsFree="38380468" spindownDelay="15" spinupGroup="host5" deviceSb="md7" idSb="SPCC_Solid_State_Disk_D70207470B6B00621416" sizeSb="234431032" From the discussion of status icons "red-blink" means the disk is disabled and in standby (or spun down). The file at /usr/local/emhttp/plugins/dynamix/images/red-blink.png is actually a gray triangle. That is why I'm seeing a gray triangle and I expect that was a mistake and it should be a square. I'd argue that it should be a red square, because I don't care if my disabled disk is in standby or not. After all the discussions of status icons, I'm hoping this is already fixed in rc4. That leads me to wonder: Why does unRAID think my disabled disk is in standby? disk in standby: root@uwer:~# smartctl -i -n standby /dev/sdd smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.0.4-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Device is in STANDBY mode, exit(2) root@uwer:~# echo $? 2 root@uwer:~# hdparm -C /dev/sdd /dev/sdd: drive state is: standby disabled disk: root@uwer:~# smartctl -i /dev/sdf smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.0.4-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: /5:0:0:0 Product: User Capacity: 600,332,565,813,390,450 bytes [600 PB] Logical block size: 774843950 bytes scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46 scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46 >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. root@uwer:~# echo $? 2 root@uwer:~# hdparm -C /dev/sdf /dev/sdf: drive state is: unknown If unRAID is using the exit code of smartctl -n standby to determine the power state, that would explain why it thinks my disabled disk is in standby. Maybe there is a more robust way to check the power state. I think I'll try to upgrade to rc4 before rebuilding disk7 so I can see if the disabled disk status is presented differently.

Looks like a docker container from this: <root@4a098718778e> Does 4a098718778e match one of your container IDs? (use the advanced view in the webgui docker tab, or enter ' docker ps ' at the command line)

I came across something a bit concerning in the unRAID v6 manual: Anyone know how TRIM/discard on an SSD data device impacts parity?

Large cookies created by add-ons have caused this problem in the past: Check for any cookies associated with the server. You can also try using the IP address instead of the server name because that will bypass cookies associated with the server name (or vice versa).

For the historically curious, the relevant mover change happened at v6beta14. Here is a little bit of explanation: http://lime-technology.com/forum/index.php?topic=38353.msg356217#msg356217

My suggestion for the file expansion pattern was flawed, it left out disk10 and disk20. Better pattern: /mnt/disk{[12][0-9],[1-9]} Sorry I didn't catch that before you updated. If someone with a full complement of disks could post the output of this: ls -d /mnt/disk{[12][0-9],[1-9]} That would probably help.

I agree with everything you wrote here. I would add a little clarification. When the 'fuser -mvk' is executed, all processes that were started by plugins should be shut down by the plugins. The problem is that powerdown is killing processes that are necessary to continue the shutdown process, not just the processes that are using the array. I can also cause the problem by creating an empty directory named /mnt/disk_maker/. root@uwer:~# fuser -mv /mnt/disk* USER PID ACCESS COMMAND /mnt/disk1: root kernel mount /mnt/disk1 /mnt/disk2: root kernel mount /mnt/disk2 /mnt/disk7: root kernel mount /mnt/disk7 /mnt/disk_maker: root kernel mount / root 1 .rce. init root 2 .rc.. kthreadd root 3 .rc.. ksoftirqd/0 root 5 .rc.. kworker/0:0H root 7 .rc.. rcu_preempt root 8 .rc.. rcu_sched root 9 .rc.. rcu_bh root 10 .rc.. migration/0 root 11 .rc.. migration/1 root 12 .rc.. ksoftirqd/1 root 14 .rc.. kworker/1:0H root 15 .rc.. khelper root 17 .rc.. netns root 20 .rc.. perf root 247 .rc.. writeback root 248 .rc.. ksmd root 249 .rc.. khugepaged root 250 .rc.. crypto root 251 .rc.. kintegrityd root 253 .rc.. bioset root 255 .rc.. kblockd root 372 .rc.. ata_sff root 388 .rc.. devfreq_wq root 486 .rc.. rpciod root 487 .rc.. kworker/1:1 root 488 .rc.. kworker/0:1 root 513 .rc.. kswapd0 root 544 .rc.. kworker/u8:1 root 582 .rc.. fsnotify_mark root 602 .rc.. nfsiod root 606 .rc.. cifsiod root 619 .rc.. xfsalloc root 620 .rc.. xfs_mru_cache root 658 .rc.. acpi_thermal_pm root 762 .rc.. vfio-irqfd-clea root 787 .rc.. kworker/1:3 root 854 .rc.. bioset root 861 .rc.. deferwq root 864 .rc.. scsi_eh_0 root 865 .rc.. scsi_tmf_0 root 866 .rc.. usb-storage root 869 .rc.. kworker/0:2 root 919 .rce. udevd root 968 .rc.. scsi_eh_1 root 969 .rc.. scsi_tmf_1 root 970 .rc.. scsi_eh_2 root 971 .rc.. scsi_tmf_2 root 972 .rc.. scsi_eh_3 root 973 .rc.. scsi_tmf_3 root 974 .rc.. scsi_eh_4 root 975 .rc.. scsi_tmf_4 root 977 .rc.. scsi_eh_5 root 978 .rc.. scsi_tmf_5 root 979 .rc.. scsi_eh_6 root 980 .rc.. scsi_tmf_6 root 997 .rc.. kworker/1:1H root 1004 .rc.. kworker/0:1H root 1093 .rce. rsyslogd root 1249 Frce. dhcpcd bin 1276 Frce. rpc.portmap rpc 1280 Frce. rpc.statd root 1290 .rce. inetd root 1300 .rce. sshd root 1311 .rce. ntpd root 1319 Frce. acpid messagebus 1332 Frce. dbus-daemon root 1334 .rce. crond daemon 1336 Frce. atd root 1341 Frce. nmbd root 1343 Frce. smbd root 1348 .rce. cpuload root 4393 .rc.. kworker/u8:0 root 4525 .rc.. kworker/u9:2 root 7061 .rce. emhttp root 7072 .rc.. md root 7073 .rc.. mdrecoveryd root 7075 .rc.. spinupd root 7076 .rc.. spinupd root 7077 .rc.. spinupd root 7078 .rc.. spinupd root 7251 .rce. apcupsd nobody 7295 Frce. dnsmasq root 7329 .rce. agetty root 7330 .rce. agetty root 7331 .rce. agetty root 7332 .rce. agetty root 7333 .rce. agetty root 7334 .rce. agetty root 7357 .rce. netatalk root 7362 .rce. afpd root 7363 .rce. cnid_metad avahi 7370 Frce. avahi-daemon avahi 7371 .rce. avahi-daemon root 7379 .rce. avahi-dnsconfd root 7399 .rc.. unraidd root 7425 .rc.. reiserfs/md1 root 7435 .rc.. reiserfs/md2 root 7447 .rc.. xfs-buf/md7 root 7448 .rc.. xfs-data/md7 root 7449 .rc.. xfs-conv/md7 root 7450 .rc.. xfs-cil/md7 root 7451 .rc.. xfsaild/md7 root 7462 .rc.. btrfs-worker root 7464 .rc.. btrfs-worker-hi root 7465 .rc.. btrfs-delalloc root 7466 .rc.. btrfs-flush_del root 7467 .rc.. btrfs-cache root 7468 .rc.. btrfs-submit root 7469 .rc.. btrfs-fixup root 7470 .rc.. btrfs-endio root 7471 .rc.. btrfs-endio-met root 7472 .rc.. btrfs-endio-met root 7473 .rc.. btrfs-endio-rai root 7474 .rc.. btrfs-endio-rep root 7475 .rc.. btrfs-rmw root 7476 .rc.. btrfs-endio-wri root 7477 .rc.. btrfs-freespace root 7478 .rc.. btrfs-delayed-m root 7479 .rc.. btrfs-readahead root 7480 .rc.. btrfs-qgroup-re root 7481 .rc.. btrfs-extent-re root 7482 .rc.. btrfs-cleaner root 7483 .rc.. btrfs-transacti root 7495 .rce. shfs root 7506 .rce. shfs root 7527 .rc.. loop0 root 7529 .rc.. btrfs-worker root 7530 .rc.. btrfs-worker-hi root 7531 .rc.. btrfs-delalloc root 7532 .rc.. btrfs-flush_del root 7533 .rc.. btrfs-cache root 7534 .rc.. btrfs-submit root 7535 .rc.. btrfs-fixup root 7536 .rc.. btrfs-endio root 7537 .rc.. btrfs-endio-met root 7538 .rc.. btrfs-endio-met root 7539 .rc.. btrfs-endio-rai root 7540 .rc.. btrfs-endio-rep root 7541 .rc.. btrfs-rmw root 7542 .rc.. btrfs-endio-wri root 7543 .rc.. btrfs-freespace root 7544 .rc.. btrfs-delayed-m root 7545 .rc.. btrfs-readahead root 7546 .rc.. btrfs-qgroup-re root 7547 .rc.. btrfs-extent-re root 7548 .rc.. btrfs-cleaner root 7549 .rc.. btrfs-transacti root 7551 Frce. docker root 7668 .rce. docker root 7729 .rce. docker root 7772 .rce. sleep root 7810 .rce. sleep root 7812 .rce. docker root 7838 .rce. docker root 7903 .rce. docker root 7964 .rce. docker root 8027 .rce. docker root 8096 .rce. docker root 8210 .rc.. kworker/u8:4 root 8971 .rce. cache_dirs root 10636 .rce. sshd root 10642 .rce. bash root 13428 .rc.. kworker/u8:3 root 19642 frce. emhttp root 19643 frce. bash root 19645 frce. tail root 23928 .rc.. kworker/u9:0 root 26527 .rc.. kworker/u9:1 root@uwer:~# fuser -mv /mnt/disk{[12][1-9],[1-9]} Specified filename /mnt/disk[12][1-9] does not exist. USER PID ACCESS COMMAND /mnt/disk1: root kernel mount /mnt/disk1 /mnt/disk2: root kernel mount /mnt/disk2 /mnt/disk7: root kernel mount /mnt/disk7 /mnt/disk_maker is just a directory on the root filesystem, therefor 'fuser -mvk /mnt/disk*' will kill all processes using the root filesystem. The author of the unassigned_devices plugin could fix the interaction by deleting the /mnt/disks/ directory in the unmounting_disks event (are you listening gfjardim?). But I think powerdown should limit the processes it kills to the ones that are using the array disks. Thats why I posted in this thread.

Thanks to both you and Freddie! Very fast work! Maybe a little bit too fast. There is an interaction between powerdown and the Unassigned Devices plugin. Unassigned Devices creates a directory at /mnt/disks/ powerdown now kills all processes using the filesystems of /mnt/disk* /mnt/disks/ fits the /mnt/disk* filename expansion /mnt/disks/ is on the root filesystem all processes using the root filesystem are killed bad things happen (or maybe more precisely, nothing else happens) I'd suggest that a change be made to the file pattern used to kill processes. Maybe this: /mnt/disk{[12][1-9],[1-9]} Or just revert my previous suggestion and live with the less effective process killing until a better solution is found.

The powerdown package appears to make a last ditch effort to kill PIDs that are using the array drives, but I don't think it is working quite as intended. From rc.unRAID version 2.13: logger "Killing active pids on the array drives" /usr/bin/fuser -k /mnt/user/* /mnt/disk* /mnt/cache /dev/md* 2>&1 | logger This will kill processes that are using the high level directories but it won't kill processes using subdirectories or files. As an example, when I have a shell open using the /mnt/disk7/ directory and another shell open using the /mnt/disk7/video/ directory, I get these results: root@tower:~# fuser -v /mnt/disk7 USER PID ACCESS COMMAND /mnt/disk7: root kernel mount /mnt/disk7 root 14286 ..c.. bash root@tower:~# fuser -vm /mnt/disk7 USER PID ACCESS COMMAND /mnt/disk7: root kernel mount /mnt/disk7 root 14286 ..c.. bash root 32333 ..c.. bash root@tower:~# fuser -k /mnt/disk7 /mnt/disk7: 14286c root@tower:~# fuser -mk /mnt/disk7 /mnt/disk7: 32333c The shell using /mnt/disk7/video/ is not killed until the -m option is added to the fuser -k command. Perhaps the -m option should be added in rc.unRAID to make the last ditch effort more effective. I would also add the -v option to get more information into the log about PIDs that had to be killed: logger "Killing active pids on the array drives" /usr/bin/fuser -mvk /mnt/user/* /mnt/disk* /mnt/cache /dev/md* 2>&1 | logger

I'm not sure diskmv is the best tool to use for switching file systems, especially if you want to follow the recommendation to verify files on the destination disk before deleting files from the source disk. I've updated the first post to try and address this issue. I think it would be good to have more testing before making a plugin. I only know of the few users that have posted in this thread. Has anyone else out there used these scripts? Any problems? New users may want to wait until there's been more testing, but if you want to jump in thestewman, these are just bash scripts that you run from the commandline (telnet, ssh or a keyboard/monitor attached to the server). It works much like the preclear script if you used that. There are many ways to set it up, the easiest may be: [*]Download the latest release zip from github, currently https://github.com/trinapicot/unraid-diskmv/archive/v0.2.0.zip [*]Extract the zip and copy diskmv and consld8 to the root of your unRAID flash drive [*]At the command prompt, change to the directory that contains the scripts: cd /boot/ [*]Run the script: diskmv -h

Yes I will consider it. I have encountered that type of error in the past with the mover script. I traced it back to cache_dirs but never really understood what was going on. Are you running cache_dirs? For me, running 'ps 7924' (where the number matches the number in the error message) showed it was a cache_dirs process. That's about as far as my understanding of the proc filesystem goes. Maybe it's time for me to do some reading.

Suggestion #1: sure Suggestion #2: probably not any time soon That's how I expected the global settings to work, based on my recollection of some explanations limetech posted in the user share copy bug discussions. I think there is a good chance the array restart caused the change in behavior, not the version upgrade. Can you make it work by excluding the Accelerator drive in the individual user share settings?

Master branch of diskmv on github now has an argument for the small file option. The user is required to specify the max size in kilobytes, there is no default max size limit. There is also a new option to specify file name extensions. https://github.com/trinapicot/unraid-diskmv example: root@tower:~# diskmv -e 'txt,n?o,ha sh' -s 4 /mnt/user/dup/test/ cache disk2 Running in test mode, no files will be moved. Moving /mnt/cache/dup/test into /mnt/disk2/dup/test ./dup/test/xyz zyx/exttest.ha sh ./dup/test/xyz zyx/exttest.nfo ./dup/test/xyz zyx/exttest.txt ./dup/test/exttest.nfo ./dup/test/exttest.txt diskmv finished ... but it ran in test mode

That is my plan, except I was going to increase the default size limit. I was also going work on adding an option to specify file name extensions (first cut will probably be hard coded like the size limit is currently). I would still like to hear about any benefits you see from the accelerator drive, doesn't need to be quantitative. Are you spinning up drives less frequently? Are you seeing less lag in media players?

Thanks for testing and providing feeback switchman. Yep, that should happen, but it doesn't. I'll work on that. That is a "feature" of bash (the shell you are using to enter the commands). Spaces and parens are special characters in bash and they must be quoted or escaped when they are in file names. You get the same cryptic error for the same problem in very basic bash commands: root@tower:~/testdata# ls Archer (2009) -bash: syntax error near unexpected token `(' root@tower:~/testdata# ls "Archer (2009)" Archer\ (2009) root@tower:~/testdata# ls Archer\ \(2009\) Archer\ (2009) It's just something you have to deal with when working at the command line. The "\" tells bash to ignore the special meaning of the next character. The tab key can be very helpful in these situations, it will autocomplete file names when possible. Type in the first part of the file name then hit tab and it will autocomplete if there is a single file that matches. Hit tab twice and it will list all the possible matches. When it autocompletes it includes the necessary backslashes to escape the special characters.

Yes, consld8 calls diskmv and diskmv only moves files from one disk to another. No moves are done to or from the user share. I was trying to follow your flowchart, but I am not a flowcharter. I think a lot of the logic involving disk usage and free space is already included in consld8. A relatively simple script could be made to loop through all first level subdirectories and perform consld8 on each of them, letting consld8 determine the destination disk. You could even use 'find' and do it with one line (probably). An alternative solution might be to add a recursive option to consld8. If a disk is not found with enough free space for the specified directory, consld8 is performed on all of the first level subdirectories. I came at these tools from a perspective that day-to-day dispersal of files is controlled by split level settings. If a new season of a tv show starts then a new season folder is created on the same disk as the other seasons of that show. This can be accomplished with split level settings. But sometimes mistakes are made or disks fill up and things need to be rearranged. That is when I intended for diskmv and consld8 to be used. That being said, if you want to run them on a cron schedule, I won't try to stop you.

I say keep it simple for now. But I don't see how the whole concept of Accelerator drives is going to benefit me all that much. For video management I use Kodi and all the metadata is stored in a shared database and thumbnails are cached on local clients. NAS, have you actually moved files onto an accelerator drive? Have you realized any of the benefits you are looking for? I really haven't paid much attention to the timestamps. My expectation is if a folder doesn't exist on the destination disk, rsync will preserve the times. But if the directory exists on the destination disk and the contents of the directory are changed, the filesystem will update the modified time of the directory.

Thanks, I will likely do that. You seem like values around 4096c and now you bring up the concept of blocks. Are you wanting to move small files onto a filesystem with a smaller block size?

Sorry. Didn't know I had a PM. I added an option in diskmv to only move small files from one disk to another. https://github.com/trinapicot/unraid-diskmv The limit is hard coded to 4k at the moment and after looking at my data, I realized that is really small. I'm thinking 1024k is a better default value. Thoughts? You can change this line if you want to play with it: maxsize=4k # Default to 4096 byte max file size for small files I'm planning to make the limit adjustable but I don't yet know how I'm going to process/validate the input value. I got annoyed with the `-size` test in `find` because `-size -1024k` returns lots of expected files but `-size -1M` doesn't return any files. I think it is due to integer math. Perhaps as an easy next step I will require the limit be specified in kilobytes and must be greater than 1. fuser is involved to check if a file is in use. If it is in use, it will not be moved. So I assume bad things could happen if you try to move a file when in use.

Based on the comments and suggestions made earlier, I have released updated scripts here: https://github.com/trinapicot/unraid-diskmv/tree/v0.2.0 This is very much a "use at your own risk" kind of thing, but I am tagging releases that I trust and have used on my own data. But I definitely make sure my data is fully backed up before using it. Anyone interested enough to test it out? @NAS & @WeeboTech: The master branch has an option in diskmv to move only small files from one disk to another. If you are interested.

I don't think that is the case. The diskmv utility I made is able to create the full destination path with the find/rsync structure. I think the -R flag in rsync is what enables it. I'll try to verify that later today.

'diskmv' is a utility to that moves files. 'consld8' is one of many possible utilities that determine how files should be moved depending on the goal. These many possible utilities then call 'diskmv' to get the job done. mbfrosty's 'rebalance' / 'pressure relief' and lboregard's 'unBalance' / 'disk packer' are other examples that could use 'diskmv' to get their job done. Another I've seen suggested is 'empty disk' which is very similar to 'unBalance', just with more available space.

I agree. The error message is not good and that may be a reason to have a separate check for a null value. I will make it better and add some usage output on error. I will also add the DEBUG snippet. Thank you.

Thanks. All your ideas are under consideration. I especially like the dry run default for diskmv. I was planning to remove the test option as default in consld8, but I now think having them both be "opt in" for write would be better.