NAS

And most the git based bug reports have been fixed

I don't know what specific limit I hit but by simply finding folders that could compress large numbers of files into a smaller sub set the problem went away. This is not ideal as for me at least there is a hard limit (which comes without warning) after which cache_dirs changes from a tool to help keep disks down to the tool that ensures disk always stay up. We need to find a way to locate these limits and warn in some quantifiable way.

So for lack of a more technical approach I am trying the tidy up route. This command added to bashrc alias duf='du -a | cut -d/ -f2 | sort | uniq -c | sort -nr' allows me to count files in dirs. Have to say I was surprised by some of the numbers

The webGUI dev is nothing to do with the V5 cycle. They are separate and discrete

Some limit is being hit on my secondary system with cache_dirs meaning the disks literally never spin down now. What limits should I be checking e.g. inodes etc etc

Agreed. I am going the udev route though but what I am personally capable of is not what unraid is about. I am talking about a core unraid webgui based native feature

I just added a new disk and reboot and it seems non array disk do actually show. So it is either the fact my first attempt was via USB or that emHTTP is not updating. Possibly both. I just added 3 drives by stopping the array, added the drives, & restarted the array. No reboot necessary... Then it must be a limitation of SATA vs USB. I am quite focused on this aspect of unraid this now as I am dropping SNAP as a unsuported plugin that doesnt fall into line with the new GUI and doesnt really do what I want now anyway. There should be an option to work with disks outside the array

I just added a new disk and reboot and it seems non array disk do actually show. So it is either the fact my first attempt was via USB or that emHTTP is not updating. Possibly both.

I would like to see this new webGUI present non array/cache disks in it own section. Ultimately I would like to replace SNAP however as a first step the GUI should show all disks connected on the homepage and not leave some hidden

+1 I could probably come up with something less important than the webgui, if I tried really hard. And I've been trying hard for four years already, ever since version 5-beta was announced. I am not sure we can assume the new webgui is part of V5 critical path at all since from day 1 it has been developed as a pacakge via git hub. I think you are voting on something that isnt going to be in 5 anyway. Either way Tom knows everyones views on this theres no point +1ing all over the place I cant see to reliably replciate it. This morning v5 gui load was as fast as v4.7. I will keep looking for a common factor

I would guess after a few hours of no access with browser closed and all drive spun down. What logic do you think would cause the drive state to slow down the webGUI load?

Anyone else notice that if you dont access the webgui for a while it takes a comparatively long time to initial load.

First off nice move using github, this will pay dividends in the end I am sure. Install went seemlessly here and its a quantum leap in usabilty as far as I am concerned One area that needs cleared up before it becomes a "thing" is that there is no license file that I can see. Technically this means that no one can fork the code legally in most country's since doing so breaches copyright. This is an ongoing thing on github with countless debates about it hence why they created this http://choosealicense.com/

You are of coarse correct. I am just spoiled this now as I have a EMC VNX to play with

No great advantage other than its the recommended way to do it and requires the user to know very little about ESX. Likely not many, if any, here fall into that camp. It used to be nice when you could just click via the appliance centre though. Horses for coarses. I prefer to work with the OS after it exists. Snapshot between OS upgrades if you do it the OS rather than the vmdk way Update: It occurred to me i never thanked you or congratulated you on your work. Nice work

As i understand it an online ova will do much the same i.e. if you accept all the defaults the end result will be the same... but you would be able to tweak a few things if needed IMHO once you have the base machine installed you should rely on the traditional copy files into unraid option along with snapshotting for reliability rather than blitzing the vmdk every time

There is a LOT to be said for everyone using the same trusted vmdk. For support reasons alone I would recommend it as it removes a load of questions that would need asked every time someone trys for vmware support. It would be nice though if this was an ova so you could install it in one go from ESX

Joe nice one. The details in that post do seem to make it possible and relatively trivial to have two USB keys for boot. I will try this ASAP because if it is reliable as it suggests it make ultimate sense to me.

I absolutely agree that what unRAID should do is check the licence/GUID fromm one key but boot from another medium. This way it doesn't matter how much you hammer your flash drive as the GUID would be almost untouched and RO on an alternative key But thats in the hands of the gods.... this USB adaptor thing is in the realm of the mortal users to be able to sort out. And both could compliment each other anyway

NO Lexar Mobile Card Reader and Adaptor Kit (LRWM01USBEUA)

PROBABLY According to this thread http://lime-technology.com/forum/index.php?topic=6185.msg161627#msg161627 this is the first device I have found that is valid: Kingston MobileLiteG2 - Card reader ( SD, MS PRO Duo, microSD, SDHC, MS Micro, microSDHC, Memory Stick PRO-HG Duo ) - Hi-Speed USB Update: Seems some fakes exist that look identical but dont have a unique GUID

I/we are looking to collect a list of USB to memory card adapters. unRAID will happily boot of just about any of these which means that the bit that usually breaks (the memory card itself) can be replaced without requesting a new license. The problem is that most of these adapters have one GUID per model/line meaning that you cant license them with unRAID. There is no way to know if the GUID is unique without physically having a device to test and it is not practical for me to buy 50 of them to test. This thread is a long term effort to find the perfect unRAID USB to memory card adapter. Ultimately it will make unRAID even more reliable. Update: Summary listed here http://lime-technology.com/wiki/index.php/USB_Card_Readers Feel free to edit and fix the formatting.

Experimenting with all the options now. Its crazy that this isnt a proper kernel tunable. I wonder how many disk hours are wasted for the sake of a few MB of ram globally per year. I suspect a huge amount

Joe, sorry I had to reboot to ensure that cache_dir started working properly again and disk spun down before bed. After 16 hours of little to no activity other than cache_dir the disks were still up. I rebooted and after cache_dirs had completed the disks spun down. This morning I moved 10GB of data via the network onto unRAID and as predicted the disks spun down. It seems that if you move a load of data using mc from disk share to disk share at some point the system gets into a state where cache_dirs can never complete. One scenario could be that cache_dirs (with my exclusions) has enough memory to complete. However by moving stuff around and cache pressure set to zero the inode count may be greater than the memory available. The result could be that the combination of cache pressure and the increased inode count caused by the moves puts us into an unwinable state. I dont expect this is a RAM limit as the math doesn't add up with 4GB of RAM but i could imagine some other kernel inode limit. I am not convinced by my theory here as it assumes that theres a kernel issue that someone far more extreme than me would have seen before.

This is intersting root@TOWER:~# /boot/scripts/cache_dirs -q killing cache_dirs process 2395 root@TOWER:~# /boot/scripts/cache_dirs -q cache_dirs not currently running root@TOWER:~# lsof | grep cache_dir cache_dir 32681 root cwd DIR 0,1 0 1 / cache_dir 32681 root rtd DIR 0,1 0 1 / cache_dir 32681 root txt REG 0,1 678832 59 /bin/bash cache_dir 32681 root mem REG 0,1 45518 605 /lib/libnss_files-2.7.so cache_dir 32681 root mem REG 0,1 1575187 598 /lib/libc-2.7.so cache_dir 32681 root mem REG 0,1 13474 406 /lib/libdl-2.7.so cache_dir 32681 root mem REG 0,1 10280 344 /lib/libtermcap.so.2.0.8 cache_dir 32681 root mem REG 0,1 131493 582 /lib/ld-2.7.so cache_dir 32681 root 0r FIFO 0,6 2711083 pipe cache_dir 32681 root 1u CHR 5,1 2969 /dev/console cache_dir 32681 root 2u CHR 5,1 2969 /dev/console