NAS

I agree but I want to make the point again that this is more than a "make folks feel better" option. We should never have a warning triangle for a legitimate user configuration. This is more than semantics as it breeds complacency i.e. orange is ok here so subconsciously users can ignore "safe" warnings . Users should be actively encouraged to rid their setup of warning and errors. I agree this is arguably an edge case so if we are sticking with the orange triangle we need to present them information why they have this triangle and how and why they can get rid of it. They shouldnt need to "hit the books" to understand. Early days I am sure we will settle on something in time.

For reference

Can you please share that link because if there is one officially supported one thats the one this thread should recommend.

Sums it up perfectly.

It seems LT now officially say not to use a card reader. http://lime-technology.com/hardware-recommendations/#usbflash "and not using a card reader." Given how surprisingly hard it has been to find a perfect candidate for it this does not surprise me. Perhaps we can discuss this new wording here, specifically to clear up that it is a recommendation only and what this means for this mini project and current reader users. (I suspect this will just be a recommendation etc etc but we should make sure since its on the official site and not the wiki or forum).

I dont want to.... and I dont think we should be teaching users to get used to ignoring soft errors/warnings. Thats what we are ultimately doing here since for certain configs the symbol will be persistent. Also It is a shared symbol since it is a single symbol representing two different configuration states, one which "should self heal" the other has been configured not to. I can see what you are saying but its just a different user usage case. Or put another way. Users shouldn't have to go to a manual and the forum to work out wtf this is about. This should be "one glance just get it stuff". None of the big boys would do it this way. For instance a yellow triangle on my EMC sans would never mean "its fine ignore it" Edit: travelling cant be to detailed this now.

As above, one state looks like an error condition when it is not. The triangle and color may not be intended to look like an error state but we have been taught by countless products to treat symbols like this as soft errors. This is not helped with the strong unprotected wording whiuch unless you think about it looks like an error. Also it is the only place in the entire web GUI that tells you if running the mover is required and/or will move files. For how I use this page the shared symbol doesnt work for me.

Version 6.0.0 The shares page currently has an orange triangle to signify "Some or all files are on unprotected storage." However there is a difference between files that are waiting to be processed onto protected storage by the mover script and those files on shares set to cache only. Ideally we should differentiate these two data types symbolically.

Good work. If we are capturing suggestions I still maintain every field should be allowed a corresponding description field that can be used to descriptive what the field is. I dont know what the best method of adding this would be though.

And grey as well. That means 5 symbols. What is grey supposed to convey? If you mean spin state then how do you combine that with disk disabled for example? TBH I am not sure what it will portray but I just mean people naturally "just get" a grey icon as meaning something like offline/passive. Its much the same as red, green and amber it is drummed in life long. Blue on the other hand is not intuitive we would need to teach people what that means. To me this is the most sane summary yet.

And grey as well.

Perhaps we should address this backwards and take the state list at the beginning and propose a smaller set of icons to match it. Then the icon author will have a clear remit to follow.

That is a very fair point. So i suppose the colour and shape could be linked and you could rely only on sub icon for variation i..e all green is always a circle, red is always a square etc

To my eye there are just too many. When users cant remember them and have to refer to a legend we have failed and icons are pointless I would stick to red, yellow and green because users will get that without trying. Add in grey because that is intuitive. If we must go beyond this use sub icons which is just one of the normal icons with another sub component added e.g. a normal icon with a small cross to signify. But my preference would be stick with just four icons and have extra information via a popup or readable txt. Edit: spooky bonienl. I like where your going although I personally dont thing we need sub icons and also differernt top level icons i.e. squares, circles and subicon ! etc My fundamental worry is that we will end up having to add more and more and its already far too many. It should be intuitive

This is not my "thing" but isnt there a documented standard somewhere?

A use case would add more weight to your 9 word request

You are talking about replacing a drive. We are talking about removing a drive (i.e. reducing the drive count in the server by one). You have a right to be confused though as we touched on a lot of things namely my opinion that to upgrade a drive you should not just pull one and have it rebuilt. For me this is a bad thing as it puts the system into a failed state for potentially a whole day+ in which time any real drive failure will result in data loss.

Whilst you can update yourself we should strive not to. other wise we are missing out on a principle point of docker. If the dev is MIA we can ask a live one to fork it

You can see why people get confised ... the manpage about -c is a bit misleading but if you read it all more debate here http://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives I am sure its possible in some world that rsync fails and deletes the original but ive never heard of anyone seeing it. has anyone? I am still going to recommend diskmv over cp/mv and manual rsync as I think the real list of data loss is because new users with no experience of this stuff start learing it by using/messing with rsync --delete-after.

would you consider adding an option to exclude a disk to consld8 . Obviously I am coming at this from the accelerator drive end which essentially precludes the use of consld8. Edit: actually thinking about it would it perhaps be a better idea to use consld8 with size and extension limits (as diskmv) i.e. as opposed to skipping the accel drive use consld8 to populate it Edit2: i dont think that would work since its fine for populating the accel drive but without being to exclude it all other consld8 actions would start pulling file from it again

Shows what seems like a scary task is actually rather trivial. Nice work

screen + mc I would say

ta much Been playing heavily with this docker and it is amazing how fast it is even for seriously large collections. Nice work

Request. Can you put your templates in a sub folder in github so that they are contained in one sub folder on disk. See any other repo as example. Ta

Can I ask what the use case you have for quotas is?