Re: Automount (was USS Features)
On 8/7/23 10:11 AM, Paul Gilmartin wrote: Instead of a home directory for each user with Documents, etc. subdirectories there's a global Documents directory with subdirectories for individual users. Which version of Windows are you talking about. Did something MASSIVELY change in Windows 11? For a *LONG* time it was C:\Documents and Settings\%UserName% for each user's home directory. At some point, I don't remember when, it became C:\Users\%UserName% for each user's home directory. I've not seen a version of Windows in 20 years that didn't have a dedicated home directory for each user where their files, documents, photos, etc. lived. Please share details about where you are seeing global document directory? That being said, I wouldn't be surprised if there was a -- as you say -- global directory that had sub-directories pointing into each user's directory as a convenience. But I would expect that users still had individual directories. C:\Global Documents\Bob -> C:\Users\Bob\Documents C:\Global Documents\Tom -> C:\Users\Tom\Documents C:\Global Pictures\Bob -> C:\Users\Bob\Pictures C:\Global Pictures\Tom -> C:\Users\Tom\Pictures C:\Users\Bob\Documents C:\Users\Bob\Pictures C:\Users\Tom\Documents C:\Users\Tom\Pictures -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
zfsadm shrink is faster and less disruptive. Nevertheless, shrinking is not automatic like growing is (can be). The fact that one can compress, decompress, encrypt, decrypt, grow, or shrink zfs files in-place and in-use implies to me that the zfs developers are pretty sharp. sas On Tue, Aug 8, 2023 at 9:34 AM Mike Schwab wrote: > If a user greatly reduces their file usage, you can create a new home > directory, copy the remaining files over, and release the old directory. > If it's a separate z/OS file system, you get the space back. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
If a user greatly reduces their file usage, you can create a new home directory, copy the remaining files over, and release the old directory. If it's a separate z/OS file system, you get the space back. On Tue, Aug 8, 2023, 07:11 Jack Zukt wrote: > As someone pointed out, it is only one more user file and I suppose that > you no not manage your space by restricting the number of user files. As it > has also been noticed, it can, and will be HSM migrated. > And when you delete a RACF userid the zfs file goes with all the others, > there is no USS directory to be located and deleted. > Never looked back after we implemented it a few years ago. > Best wishes > Jack > > > On Tue, Aug 8, 2023, 00:27 Andrew Rowley > wrote: > > > On 8/08/2023 12:37 am, Jon Perryman wrote: > > > Automount was created specifically to address some filesystem > > > blemishes. There's a problem they needed to solved and they allowed > > > people to continue without the use of automount. For those who choose > > > automount, they decided that with all its faults, it solved more > > > problems than it created. > > > > IBM didn't create automount. It was a standard unix thing before IBM did > > unix. IBM just came up with the idea of HSM migrating home directories > > as a use case. > > > > The primary problem with individual filesystems is that freespace > > doesn't get returned to the system. Deleted a file? The space still > > can't be used by someone else. If you accidentally fill up your > > filesystem, when you delete the file after all those "growing > > filesystem" messages: congratulations, you own the empty space. > > > > The secondary problem is that migrating filesystems makes file and > > directory level management impractical. > > > > # du --sh /home/* > > > > # find /home -size 2G > > > > Don't even think about it, unless you like HSM recalls. > > > > File level backup also gets complicated when filesystems are migrated. > > > > Pretty much all the problems that automounted individual filesystems are > > supposed to solve are actually a result of having individual > > filesystems. They don't have to be solved on other platforms because > > they didn't create them in the first place (or there is a better > > solution e.g. quotas). > > > > -- > > Andrew Rowley > > Black Hill Software > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
As someone pointed out, it is only one more user file and I suppose that you no not manage your space by restricting the number of user files. As it has also been noticed, it can, and will be HSM migrated. And when you delete a RACF userid the zfs file goes with all the others, there is no USS directory to be located and deleted. Never looked back after we implemented it a few years ago. Best wishes Jack On Tue, Aug 8, 2023, 00:27 Andrew Rowley wrote: > On 8/08/2023 12:37 am, Jon Perryman wrote: > > Automount was created specifically to address some filesystem > > blemishes. There's a problem they needed to solved and they allowed > > people to continue without the use of automount. For those who choose > > automount, they decided that with all its faults, it solved more > > problems than it created. > > IBM didn't create automount. It was a standard unix thing before IBM did > unix. IBM just came up with the idea of HSM migrating home directories > as a use case. > > The primary problem with individual filesystems is that freespace > doesn't get returned to the system. Deleted a file? The space still > can't be used by someone else. If you accidentally fill up your > filesystem, when you delete the file after all those "growing > filesystem" messages: congratulations, you own the empty space. > > The secondary problem is that migrating filesystems makes file and > directory level management impractical. > > # du --sh /home/* > > # find /home -size 2G > > Don't even think about it, unless you like HSM recalls. > > File level backup also gets complicated when filesystems are migrated. > > Pretty much all the problems that automounted individual filesystems are > supposed to solve are actually a result of having individual > filesystems. They don't have to be solved on other platforms because > they didn't create them in the first place (or there is a better > solution e.g. quotas). > > -- > Andrew Rowley > Black Hill Software > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On 8/08/2023 12:37 am, Jon Perryman wrote: Automount was created specifically to address some filesystem blemishes. There's a problem they needed to solved and they allowed people to continue without the use of automount. For those who choose automount, they decided that with all its faults, it solved more problems than it created. IBM didn't create automount. It was a standard unix thing before IBM did unix. IBM just came up with the idea of HSM migrating home directories as a use case. The primary problem with individual filesystems is that freespace doesn't get returned to the system. Deleted a file? The space still can't be used by someone else. If you accidentally fill up your filesystem, when you delete the file after all those "growing filesystem" messages: congratulations, you own the empty space. The secondary problem is that migrating filesystems makes file and directory level management impractical. # du --sh /home/* # find /home -size 2G Don't even think about it, unless you like HSM recalls. File level backup also gets complicated when filesystems are migrated. Pretty much all the problems that automounted individual filesystems are supposed to solve are actually a result of having individual filesystems. They don't have to be solved on other platforms because they didn't create them in the first place (or there is a better solution e.g. quotas). -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
We use automount with auto created ZFSs for each user. We set the size so it won’t grow beyond our settings. Works great. On Mon, Aug 7, 2023 at 7:57 AM Rick Troth wrote: > > 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 > >> <0471ebeac275-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 > > > > > > > > Regards > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Obviously it is not big deal. Yes, automount or not-automount is not the question (Hamlet). :-) It is just my opinion that automount require some setup and provide no value. And of course this is discussion forum, so I expect other opinions or arguments. This is kind of learning opportunity, which I appreciate. Regarding personal files - yes, it is not big deal, even for dozens of almost-empty filesystems multiplied by nn cylinders. Yes, DASD is quite cheap nowadays and we have a lot of. However when I take a time to consider minor deals, I see some disadvantages of automount and no advantages. With one exception: there are cases when a user wants his filesystem to be migrated. Migrated from system A to system B, etc. Important: it is not a migration of all the users. In that case it would be easier or quicker (for whom?) to use ADRDSSU dump/restore instead of pax. Note, I still consider automount and separate filesystems for every home dir vs common filesystem for home directories. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 07.08.2023 o 16:00, Steve Smith pisze: Every user on our system has dozens of "personal" files, ISPF-related, DDIR, etc. One more is no big deal. And if a user blows up their home filesystem, it's a minor issue (1 user), not a critical one (all users affected). I also do not want to manage space usage in the filesystems. I appreciate that you haven't continued the conflation of "automount" with what we're really talking about, which is individual home filesystems. Different systems have different requirements. If you think that a common user home filesystem is best for yours, fine. Nothing I've seen here has changed my view that automounted (with auto-create) individual filesystems is the best for us. sas On Mon, Aug 7, 2023 at 9:40 AM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Mon, 7 Aug 2023 10:00:45 -0400, Steve Smith wrote: > >I appreciate that you haven't continued the conflation of "automount" with >what we're really talking about, which is individual home filesystems. > I can hardly imagine not having a private home directory. It hardly matters to me whether it's a separate filesystem -- performance and reliability are concerns for admins. Likewise it doesn't matter whether it appears at the second level above "/" or higher. Nur even the name. I knew one user who had his Solaris HOME defined in RACF as his MVS HOME, even though his TSO user ID was not the lowest qualifier in that path. RACF, HOME, "~" and getpwuid sort it all out. Our admins chose, wisely IMO, to replicate as our OMVS UIDs the older Solaris UIDs. Windows appears to take an orthogonal approach. Instead of a home directory for each user with Documents, etc. subdirectories there's a global Documents directory with subdirectories for individual users. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
> On Monday, August 7, 2023 at 05:56:59 AM PDT, Rick Troth > wrote: > storage admin might truly dislike: auto-create a USS filespace for each user. Storage admins who don't like auto-create can create filespace by hand. Are you saying auto-create does not meet the needs for all? > automount has some advantages, though no, it's not always implemented > elegantly. Elegance is often not achievable when creating for something that already exists. IBM had few choices because of the faults of filesystem, Unix and z/OS. Automount was created specifically to address some filesystem blemishes. There's a problem they needed to solved and they allowed people to continue without the use of automount. For those who choose automount, they decided that with all its faults, it solved more problems than it created. This is true for all software whether it's Unix or z/OS. The solution to a problem usually changes the problem. On Monday, August 7, 2023 at 05:56:59 AM PDT, Rick Troth wrote: > 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; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Every user on our system has dozens of "personal" files, ISPF-related, DDIR, etc. One more is no big deal. And if a user blows up their home filesystem, it's a minor issue (1 user), not a critical one (all users affected). I also do not want to manage space usage in the filesystems. I appreciate that you haven't continued the conflation of "automount" with what we're really talking about, which is individual home filesystems. Different systems have different requirements. If you think that a common user home filesystem is best for yours, fine. Nothing I've seen here has changed my view that automounted (with auto-create) individual filesystems is the best for us. sas On Mon, Aug 7, 2023 at 9:40 AM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > 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 > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
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 <0471ebeac275-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
Re: Automount (was USS Features)
> 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 <0471ebeac275-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 Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Saturday, August 5, 2023 at 06:08:55 AM PDT, Radoslaw Skorupka wrote: > 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). Clearly the storage admins you asked have never felt the pain of z/OS Unix filesystems because they are insignificant. Have him pretend he has a 100TB filesystem and ask him how he will restore your files. What tool will he use when the filesystem is full causing hundreds of users to fail? How will he migrate inactive z/OS Unix files to free up space? Is he willing to add an additional 10TB to the filesystem which will never be freed? When a storage admin doesn't want to fully understand z/OS Unix filesystems, what options do you think they have? While automount has problems, it gives storage admins a solution they can deal with in their world. They can ignore storage quotas and use extents to limit size. I'm not saying automount is a great solution but there are people who find it useful. z/OS Unix filesystems are not a great solution but we've learned to live with it's problems. How is automount any different? b -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Sat, 5 Aug 2023 15:08:31 +0200, Radoslaw Skorupka wrote: >... >However it is not reality show or beauty contest, rather I'd like to see >some real advantages of automount. > At one time our site had an open-system NFS client so users could access traditional MVS data sets on their desktops. Generic maps on both client and mainframe server, with HSM autorecall on server map. At some point a user (undisclosed, perhaps never identified) did a large wildcard query. I think it ran for multiple days with recalls filling up all storage packs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
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 <0471ebeac275-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 Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
> 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). On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-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 -- Radoslaw Skorupka Lodz, Poland W dniu 31.07.2023 o 17:08, Paul Gilmartin pisze: > On Mon, 31 Jul 2023 09:43:38 -0500, Grant Taylor wrote: > >> On 7/31/23 8:06 AM, Rick Troth wrote: >>> per-user automount does not necessarily waste space >> IMHO automount is completely independent of shared / separate per user >> disk space. >> >>> The thing which is mounted might be a sub-directory of a shared space. >> Agreed. >> > Wasn't true in the Bad Old Days, when the only thing that could be mounted > was an entire HFS content (or an NFS [sub]directory.) > > And I was dismayed that the MVS mount maps needed to differ between > MVS NFS server and client. Solaris was smarter: mount on the server > would look at the map, say, "Oh! That's me!" and mount the directory as local. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
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 -- Radoslaw Skorupka Lodz, Poland W dniu 31.07.2023 o 17:08, Paul Gilmartin pisze: On Mon, 31 Jul 2023 09:43:38 -0500, Grant Taylor wrote: On 7/31/23 8:06 AM, Rick Troth wrote: per-user automount does not necessarily waste space IMHO automount is completely independent of shared / separate per user disk space. The thing which is mounted might be a sub-directory of a shared space. Agreed. Wasn't true in the Bad Old Days, when the only thing that could be mounted was an entire HFS content (or an NFS [sub]directory.) And I was dismayed that the MVS mount maps needed to differ between MVS NFS server and client. Solaris was smarter: mount on the server would look at the map, say, "Oh! That's me!" and mount the directory as local. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
