Objection: I do not compare thousands of automounted filesystems to same
thousands of permanently mounted same filesystems.
Absolutely the opposite, I mean INSTEAD of thousands (I'd say dozens)
automounted filesystems I'd like to have ONE or few permanently mounted
filesystems. Caution: common filesystem does not mean common/shared home
directory. In the filesystem I still can have thousands (dozens?) of
separate user directiories. Just another mountpoint above the home dir.
So, the mount time at the IPL will not be a problem. The same for mount
table and parmlib member.
Regarding mount table - I would bet it will be smaller. One (common)
filesystem vs (few) dozens filesystems belonging to active users.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 07.08.2023 o 14:56, Rick Troth pisze:
> However it is not reality show or beauty contest, rather I'd like to
see some real advantages of automount.
Last week I learned of a peculiar use of automount in z/OS which is
different from my experience and which a storage admin might truly
dislike: auto-create a (possibly large, in any case yet another to
manage) USS filespace for each user.
Yuck.
So I get it that some find automount counter productive.
My experience has always been quite different, whether with z/OS or
elsewhere.
The mounted objects are often sub-directories of a shared space
(advantage: NOT creating countless additional spaces to manage).
The mounted objects are called for on-demand (advantage: NOT requiring
a large table of filesystems to mount when the system starts).
I was blown away the first time I ran 'df' on USS. So many things
mounted!
And many of them were program products. As a long time Unix person and
sometime Unix admin, I do find program products to be excellent
candidates for their own mount point (whether also their own physical
space or shared).
Automounter could dramatically reduce the number of things needing
mount at boot time.
My first experience with automounter was for user home directories (in
that case, always residing in shared spaces on the back end).
But that was the time of shared workstations: a users home dir was not
mounted until she signed on.
Summary: YES, automount has some advantages, though no, it's not
always implemented elegantly.
-- R; <><
On 8/5/23 09:08, Radoslaw Skorupka wrote:
W dniu 04.08.2023 o 22:04, Jon Perryman pisze:
> On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka
wrote:
Regarding automount feature: IMHO it is less than useless.
While there is truth to what you say about automount, there are uses
where people find it useful because it provides features that some
customers need. Most notably, everything in a filesystem is randomly
placed within that filesystem without any controls. Ask a z/OS
storage admin if he could tolerate the same situation where all z/OS
datasets are placed randomly (no SMS nor disk esoterics).
I asked storage admin (myself) and heard NO. Automount changes
nothing to what you described (and what is IMHO disputable, but this
is different thread).
Oh, BTW: I met many other storage admins in my career. No one liked
automount feature, usually they didn't express any opinion, but
sometimes they complain on that.
However it is not reality show or beauty contest, rather I'd like to
see some real advantages of automount.
On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka
<00000471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
Regarding automount feature: IMHO it is less than useless.
- It require some effort to establish and manage (including storage
adm.)
- It wastes space, because even smallest empty home directory occupies
first extent of the ZFS/HFS.
- Space (extents) taken by some large files and then deleted is still
occupied by the user.
- Tools like find may omit currently unmounted directories, sometimes
making the search ineffective.
- I vaguely remember the z/OS Unix does not like excessive filesystems
being mounted.
- Automount/demount consume some resources.
- Last, but not least: I observed the are more active TSO users than
USS
users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS
just out of curiosity. In case of automount yet another filesystem is
created.
From the other hand one can create common filesystems for all home
directories.
When needed it can be divided among multiple filesystems.
Users with large needs may have dedicated filesystems.
Empty user directory does not consume resources. Even "touched".
My €0.02
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
