On 7/30/23 18:50, Andrew Rowley wrote:
On 30/07/2023 2:28 am, Jon Perryman wrote:
ASK YOURSELF: Name the z/OS Unix feature that sort of fixes the
fundamental design flaw with Unix filesystems just described?
I suspect most people won't think about each user having a unique
filesystem using automount to make their filesystem available.
Typical Unix uses one file system with all users having directories
in the /user directory.
An automounted filesystem per user has always been a terrible idea. I
think it was given as an example of how you could use automount and
somehow morphed into a recommendation. (Other OSes can e.g. use
automount to mount a remote user filesystem via NFS).
I responded to this in a thread fork.
The points Andrew makes are sound, but there's context where per-user
automount is a GOOD idea.
Reasons it's a bad idea:
1) Freespace in the filesystem is not shared between users. This means
that you need much more space than if there was one pool of freespace
shared between all.
(repeating)
if the thing mounted is a sub-dir of a shared space, this argument is void.
2) It makes simple questions like e.g. "Which users have a
.ssh/authorized_keys file?" much harder to answer.
Certainly.
But it also means that ~.ssh/authorized_keys follows the user, which is
beneficial.
A filesystem per user is basically equivalent to a SMS storage group
and catalog per user. You get isolation between users, but at the
expense of much more difficult management.
But, again, an automount per user does not necessarily mean a filesystem
per user.
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
