Please Linda, there's no need to cc me. I subscribe to this list. I don't need to get two copies of your mail responses. On 10/28/2014 06:50 PM, Linda Walsh wrote:
A systemd generation sysadmin will 'change state definition" and let the automounter do the unmount.
--- Change it how? from the command line? in 1 command specifying the device?
If this were the nfs automounter of old how would you tell it to adopt a new state? By changing the definition tables. Why should it be any different? This question has been answered, the controlling table in question is /etc/fstab. The people that altered it got the desired result.
If automounting was desired it would be in /etc/auto.xxx
Perhaps in an ideal world all storage would be treated the same, local and non local, and there would be just one definition table. Sadly we are dealing here with backward compatibility, that local storage is defined in /etc/fstab. Sidebar: most of the problems we face with systemd seem to arise from it having to deal with backward compatibility. If there really was a new systemdOS that didn't have to deal with backward compatibility then none of these problems would occur but you'd be screaming a different tune. In essence, there is no reason all storage should not be defined in /etc/auto.xx and managed by the old automounter model. As i've pointed out, the SUN networked 'thin client' workstations with 'rovong logins' worked that way. Having state clearly defined - documented - is important. The arguments I see presented are al "I ... I ... I". They don't seem to consider the situation where there are many sysadmins. Sysadmin#1 does the unmount to deal with what he sees as a problem. Perhaps he gets interrupted, "run over by a bus" we used to say[1][2]. Sysadmin#4 comes along and sees a disk unmounted "for no apparent reason", since the fstab says it should be mounted. Or perhaps sysadmin#2 sets up a new LVM/filesystem, adds it to fstab and runs "mount -a". if sysadmin#1 had modified the definition of state to communicate his change by altering fstab then the actions of #2 and #4 would not disrupt his work. Its been pointed out repeatedly that Linux has to "grow up" to deal with large installations. Cgroups and resource mapping are an example of that, and they too are irrelevant to home and single user systems and the kind of small "traditional" Linux installations. The arguments against a state model make sense for people who are procedurally oriented, who don't have to deal with heavily multi-tenanted, heavily multi-virtual installations where resource management and allocation is important. An ISP, for example, running SUSE on a IBM "mainframe (which is list a little larger than my tower and would still fit under my desk) might have to deal with 4000+ virtual instances. [1] The in-joke in BOFH style was that the VP/IT drove to work in a VW bus. And was a ... not very good ... driver. [2] Or for some other reason does come back to undo his change, there is no record of what he's done or why. -- Excellence is not an accomplishment. It is a spirit, a never-ending process. - Lawrence M. Miller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org