unRAID Server Release 6.2.0-rc5 Available

[sparklyballs]

on both of my unraid boxes running RC5 and going to the share settings page, the setting on both is auto for this feature.

on, off and auto are available. I haven't previously touched this setting on either box, auto is not off.....

 

According to the help text:

 

Auto = off

 

If there are settings for on, off and auto, to have it set to auto, that is not off.

At the very least it's damn confusing and badly designed, off means off, on means on and auto means on or off dependant on meeting the hardware requirements.

 

 

[RobJ]

ajgoyt, I moved all of your support to here.  I hope your Mellanox is fine!  You do seem to be making progress with it and 6.2 and the new networking config.

[garycase]

on both of my unraid boxes running RC5 and going to the share settings page, the setting on both is auto for this feature.

on, off and auto are available. I haven't previously touched this setting on either box, auto is not off.....

 

According to the help text:

 

Auto = off

 

If there are settings for on, off and auto, to have it set to auto, that is not off.

At the very least it's damn confusing and badly designed, off means off, on means on and auto means on or off dependant on meeting the hardware requirements.

 

While I think this setting is harmless, I DO agree that if the intent for it to be Off by default, it should indeed be OFF => not "Auto".    While the help indeed says "Auto = Off", that is very counterintuitive ... I'd think it would mean Off if you don't have a 10Gb adapter; On otherwise.    If that's not the case, there doesn't seem to be any reason to have an "Auto" setting.

 

[limetech]

"Auto" means "let the OS decide".  The idea is that when the setting has been sufficiently vetted then there will come a release where direct_io is ON by default.

 

Here is some explanation of this setting.  All it does is set the "direct_io" mount option when FUSE-based shfs (user share file system) is mounted.  What this means is that the linux vfs layer for shfs does not cache data blocks.  Since shfs is layered on top of individual device file systems such as xfs and btrfs, those file sytsems still are using the linux buffer cache.  Including this option effectively removes an extra memory copy in the I/O path.  This is why we see a speed up.  Speaking of speed up, in a 1Gb/s network the fastest effective throughput is only 100MBytes/sec; with 10Gb/s network it can reach 1000MBytes/sec which is now faster than the storage.  In unRAID you basically can only hit this sustained throughput if your target is a multi-device btrfs cache pool, and that is exactly the config we wanted to optimize for.

 

Enabling this option should not cause data corruption, but may slow down reads (though we have not seen that in our limited set of h/w we have tested on).

 

Why mark it "experimental"?  Mainly because I didn't want to take a bunch of grief for adding a "new feature" in an RC release.  But also, normally with changes like this we like to run on a wide variety of h/w configs, just to "make sure" there are no hidden gotchas.  In this case, this is an option which improves performance for a certain customer config we were testing.  In previous testing we used the 'boot/extra.cfg' file to add this option, but in the interest of making it easier on a user we decided to just make it an official config setting.

[garycase]

That's what I had assumed => I think the only "issue" is that it's set to "Auto" as the default.  [Even though jonp said "... The new option is disabled by default ."]  You might want to change the default to "Off" for the release version 

 

There was also some criticism about adding an "experimental feature" in an RC, but I understand your reasoning for doing so.  Not sure you avoided the  "... bunch of grief for adding a "new feature" in an RC release ..." => but what's done is done; and it does indeed seem like a harmless addition.

 

 

[limetech]

That's what I had assumed => I think the only "issue" is that it's set to "Auto" as the default.  [Even though jonp said "... The new option is disabled by default ."]  You might want to change the default to "Off" for the release version 

 

If we did that, then when we decide that "direct_io" should be included in the set of default mount options, everyone will have to go and manually change that setting.  Could also be we remove the setting entirely.  "Auto" is the correct setting in this context.

[garycase]

... If we did that, then when we decide that "direct_io" should be included in the set of default mount options, everyone will have to go and manually change that setting.

 

Not sure I understand this.  When you decide this is the case, won't that result in a new release?  ... or at least an update to Dynamix?    So it could be changed to Auto or On at that point.

 

 

... "Auto" is the correct setting in this context.

 

If that's the case, perhaps the Help text shouldn't say "Auto selects No"

[limetech]

... If we did that, then when we decide that "direct_io" should be included in the set of default mount options, everyone will have to go and manually change that setting.

 

Not sure I understand this.  When you decide this is the case, won't that result in a new release?  ... or at least an update to Dynamix?    So it could be changed to Auto or On at that point.

But the setting itself is stored in the file 'boot/share.cfg' with the line:

 

fuse_directio="auto"

 

Actually the file will be updated with that line if some other action causes it to be written... but, if we instead had the default in the code to be "no" and that got written to the file, a new release will not override that setting, instead user will have to go change it themselves.

 

... "Auto" is the correct setting in this context.

 

If that's the case, perhaps the Help text shouldn't say "Auto selects No"

When/if a new release is created where we think the proper "automatic" setting for that option should be Yes then we will change the Help text to say "Auto selects Yes". 

[garycase]

If "Auto selects No" now; and in the future it will be changed to "Auto selects Yes"; then what is the purpose of the Auto setting?    Why not just Yes or No ??

 

If it's really true that Auto "... means let the OS decide ...", then what is the basis for that decision?  If it simply means No now, and will mean Yes later, it doesn't seem like there's anything for the OS to "decide".

 

 

[RobJ]

I believe what he means is that currently the On and Off choices are what the user can choose to force either state, but the Auto choice selects what is currently considered the safe and optimal choice.  Until more testing is done, Auto is defined as Off, but when further testing indicates it's both safe and optimal for some machines, then Auto would be defined as On (unless a users system did not appear eligible?).  I suppose that in a case where the users system did not qualify for On, then Off should be forced, no On or Auto option available (or grayed).

[NAS]

I really dont want to post about this but I feel I have to.

 

Two points:

 

In my life long experience when faced with an "on/off/auto" choice then auto means on. It would not occur to me that it may mean anything else than this. I even subconsciously say "auto on" in my head. Is it wrong that it could mean something else, well no, but good design always start from a point of intuitive understanding. We need to stop using terms the industry have used for decades to mean one thing and then try to teach the world they mean something else to us.

 

This is a prime example of why you dont add new stuff in an RC. We now have last minute confusion needlessly that could easily have been handled in the 6.3 cycle.

 

 

[JorgeB]

Just my opinion, but I think Tom's explanation makes sense.

 

Also why all these issues with this setting but nobody had issue with this one, it's been present since the first v6.2-beta, default is also auto, in this case represents turbo write=off.

[limetech]

Just my opinion, but I think Tom's explanation makes sense.

 

Also why all these issues with this setting but nobody had issue with this one, it's been present since the first v6.2-beta, default is also auto, in this case represents turbo write=off.

 

It's the same kind of thing.  We have plans for this feature in the future where 'auto' might mean, "Sometimes it's on and sometimes it's off depending on what's happening." ie, dynamic.

[sparklyballs]

Just my opinion, but I think Tom's explanation makes sense.

 

Also why all these issues with this setting but nobody had issue with this one, it's been present since the first v6.2-beta, default is also auto, in this case represents turbo write=off.

 

had i noticed that particular anomaly before i would have also raised it because that's also counter-intuitive and against everything i've ever known in the computing arena, but the talk here was of the tunable for direct i/o and i checked out the page and noticed it.

 

[ajgoyt]

ajgoyt, I moved all of your support to here.  I hope your Mellanox is fine!  You do seem to be making progress with it and 6.2 and the new networking config.

I beleive I found a bug with RC5 both my cards and SFP cables are fine - Mike and John see this post - that RobJ moved me too.

 

http://lime-technology.com/forum/index.php?topic=51676.new#new

[JustinChase]

Updated from 6.1.9.

 

I've also reformatted my cache drive as BTRFS and have moved all the appdata and vms to it. These were on an "unassigned" SSD.

 

Just curious, why did you move off the SSD to the cache?

[PeterB]

In my life long experience when faced with an "on/off/auto" choice then auto means on.

 

Really?  So the logical deduction, from what you state, is that one of the options is superfluous.    If that were really the case, any true IT professional, based on logic and minimising complexity, would have eliminated one of the options in its infancy.

 

Admittedly, I'm retired from professional IT, but my experience has always been that 'on' means ON, 'off' means OFF and 'auto' means that it is either ON or OFF, dependent on some other factor.

 

My little home project, at the moment, is a domestic lighting control system - lights can be turned ON or OFF by a manual switch, or they can be set to 'auto' whereupon the system decides whether to turn a light ON or OFF, dependent on time of day, or ambient light level or other factors.  If 'auto' meant always on, the system wouldn't be very functional.

[garycase]

In my life long experience when faced with an "on/off/auto" choice then auto means on.

 

Really?  So the logical deduction, from what you state, is that one of the options is superfluous.    If that were really the case, any true IT professional, based on logic and minimising complexity, would have eliminated one of the options in its infancy.

 

Admittedly, I'm retired from professional IT, but my experience has always been that 'on' means ON, 'off' means OFF and 'auto' means that it is either ON or OFF, dependent on some other factor.

 

My little home project, at the moment, is a domestic lighting control system - lights can be turned ON or OFF by a manual switch, or they can be set to 'auto' whereupon the system decides whether to turn a light ON or OFF, dependent on time of day, or ambient light level or other factors.  If 'auto' meant always on, the system wouldn't be very functional.

 

Agree with Peter.    I have a lot of light switches in our home that have on/off/auto settings -- the auto means they'll turn on if they detect motion AND the ambient light is below a certain level.    In our cars, you can turn the lights on, off, or to auto, which means they'll come on automatically at night.  Same for the windshield wipers -- on/off/ or auto -- where auto means if it's raining they'll come on; otherwise they're off.  I can think of numerous other examples => but in every case "auto" means the system decides the state based on some defined parameter.

 

[Hammerfest]

I signed up to post some issues I am having with my setup, but couldn't resist when I saw this debate happening, SOOO, I decided to ask around my office, also asked a few friends, keeping in mind about 10-40 years of Tech work per person...

 

office "poll" results where if there is an Auto feature/option, chances are: ITS ON

 

I literally gave no supporting information, I asked them what is the first thought when looking at something and it says "auto", 100% of the people I asked (admittedly only 17 total, 13 techs who work for me and 4 friends) said ON...

 

To each their own, but to me and at least the group of people I deal with on a daily basis, if it says auto, 99% of the time it means ON

 

Feature deserves an Auto/Off/On value, I will be doing 10Gbe testing with my rig before the end of the month, company is prepping 10Gbe stuff's and my box is an allowed test box, even providing me an Intel 10Gbe for testing (must be returned of course...)

[garycase]

Just my opinion, but I think Tom's explanation makes sense.

 

Also why all these issues with this setting but nobody had issue with this one, it's been present since the first v6.2-beta, default is also auto, in this case represents turbo write=off.

 

I'm surprised at this.  I had seen the setting; and haven't experimented with it to confirm; but I had assumed that "Auto" meant if all the disks are already spinning, use turbo write; and if not, use the standard write method.    Disappointing to find out that's not the case.

 

[NAS]

In my life long experience when faced with an "on/off/auto" choice then auto means on.

 

Really?  So the logical deduction, from what you state, is that one of the options is superfluous.    If that were really the case, any true IT professional, based on logic and minimising complexity, would have eliminated one of the options in its infancy.

 

Admittedly, I'm retired from professional IT, but my experience has always been that 'on' means ON, 'off' means OFF and 'auto' means that it is either ON or OFF, dependent on some other factor.

 

My little home project, at the moment, is a domestic lighting control system - lights can be turned ON or OFF by a manual switch, or they can be set to 'auto' whereupon the system decides whether to turn a light ON or OFF, dependent on time of day, or ambient light level or other factors.  If 'auto' meant always on, the system wouldn't be very functional.

 

Reading what you wrote and I think I agree with you that when I say "Auto on" in my head what I am really saying is "Auto on when needed" which does imply if you think it through that it starts from an off state. However if someone was to ask me the other way around to choose a word that describes this behavior I would never choose "Auto" I would almost certainly choose "Dynamic".

 

So, I signed up to post some issues I am having with my setup, but couldn't resist when I saw this debate happening, SOOO, I asked around my office, asked a few friends, 10-40 years of Tech work per person...

 

"poll" results where if there is an Auto feature/option, CHANCES ARE ITS ON

 

I literally gave no supporting information, asked whats is the first thought when looking at something and it says "auto", 100% of the people I asked (admittedly only 17 total, 13 techs who work for me and 4 friends) said ON...

 

To each their own, but to me and at least the group of people I deal with on a daily basis, if it says auto, 99% of the time it means ON

 

Like above this made me realise that my default mindset for this is on "manually enabled", off manually disabled" and  auto "Automatically start". The difference being a one time even and not a dymanic thing (think windows services for a better example).

 

Thanks for the  informal poll though I would have predicted those results but given the strong cases either way I started second guessing.

 

This just proves why you need a beta cycle, even the most obvious thing can generate bugs

[Lev]

Just did an upgrade from 6.1.9 using the plug-in method. No issues to report. VMs and Docker containers all work fine. File transfers are all at expected speeds. Nice work!

[PeterB]

... and  auto "Automatically start".

 

Okay, I can see where you're coming from, but 'automatic start' is a very restricted application of the concept of 'automatic'.  Perhaps one of the more common uses of the word 'automatic' is in relation to a car gearbox (automobile transmission for those on the wrong side of the pond!).  Here, the word automatic has little bearing on a startup condition, but means that the system will always select the gear which is considered to be most appropriate for the conditions pertaining at any point in time.

 

(think windows services for a better example).

I'd rather not ...!

 

The interpretation of an 'auto' setting may well depend on background experience.  Over my career I worked on business applications, systems software, industrial control systems among others, and it may be the control side which conditions my interpretation.

[garycase]

I think we've beat this to death 

 

Tom said:  "Auto" means "let the OS decide". 

 

... so in the context of UnRAID that's what it means.  I tend to agree with Peter that this implies there is some basis for that decision [and thus it's not intuitive that it would always mean "On" or "Off" ] ... but apparently that's not the case.    I think, for example, that in the case mentioned r.e. the turbo-write setting, the OS should base its choice on whether or not all disks are currently spinning, which to me is the intuitive meaning of "auto" in that case -- but that's also not the case [in that instance, auto = Off].

 

[NAS]

My final word on this, given the amount of confusion the current wording is not suitable and clearly has to be changed. Necessitating users refer to a manual to understand a state selection is a design fail.