Anton Aylward wrote:
--- 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?
I wouldn't have a need to temporarily unmount a network file system to do local maintenance.
This question has been answered, the controlling table in question is /etc/fstab. The people that altered it got the desired result.
That overrides the *predefined-ADMIN-CONTROLLED-mount table used by the mount command*. If systemd wants an automounter file, why doesn't it use /etc/auto like *nix systems have for ages?
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.
Local vs. remote isn't the issue. It's about manual & static control vs. automatic. /etc/auto.{xx} is ALREADY defined for automatic control. It is a serious design flaw to corrupt normal system function stemming from previous decisions to make /etc/fstab-static and /etc/auto-auto.
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.
--- The problem here is a gratuitous and unnecessary redefinition that removes local-static controlled mounts when a mechanism for "auto" already existed. There is also the statement of the "mount" developer regarding changing its format or usage: Karel Zak wrote:
On Wed, Aug 06, 2014 at 03:59:27PM -0700, Linda A. Walsh wrote:
As another matter of being user friendly, why can't we specify a defaults line for all mounts with the option of per-type defaults ...
Well, the problem is that fstab is de-facto standard. If you want to change semantic than you have to fix all programs that follow fstab setting. The file is no private mount(8) config file
----- The options and semantics for fstab are a "de-facto standard". (Karel Zak is the current maintainer of "mount"). systemd is not following the standard.
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.
I whole-heartedly agree... and have, at times, have experimented with mounts I didn't need local control of, but that were local, in /etc/auto.xxx. I worked at Sun for 3-4 years over the switch from bsd-based -> SysV based, so am familiar with their practices.
Having state clearly defined - documented - is important. The arguments I see presented are al "I ... I ... I".
??? Excuse me? show me 1 argument presented that way.
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.
No they are NOT. Home users are constantly concerned about their local buffer cache being thrashed by a large copy as well as a network copy hogging the bandwidth. Those are primarily HOME and single user systems that don't have the resources of LARGE installations. "Growing up" doesn't mean breaking all standards you learned as a kid. That's generally called *criminal* behavior.
[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. === So someone undid the change and the resulting catastrophe put the company out of business. Good reason to study a system as a whole before introducing incompatible change.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org