> I think the correct way to do this would be to use > the ignore flag in > /etc/mnttab > appropriately and systematically, to get the defaults > right. I can't see
I wish I could agree; however, the problem with that is the number of places the change would have to be made. Right now, AFAIK only two filesystems (autofs and fd) actually implement "ignore" as an option. automountd sensibly uses "ignore" with autofs entries, which after all only exist to intercept accesses so that the on-demand mount can be done; they're simply not interesting in the normal case. And fd is mounted from vfstab, so whether one puts "ignore" in there or not is up to the admin. But at present, every other filesystem does not recognize "ignore" as a mount option. mntfs allows "tags" (that look like additonal mount options in /etc/mnttab) to be set on entries, but _only_ when that does not conflict with the name of a mount option for that filesystem. Thus, adding "ignore" to lofs mounts would either require adding "ignore" as a mount option for lofs, or require hacking up automountd to treat "ignore" as a pseudo option (sort of like how it handles fstype=) and setting it as a tag for those mounts which used a filesystem that did not support "ignore" as an option. Perhaps adding "ignore" option support to all filesystems that don't have it would be the best solution, but it would also require people to add "ignore" options to their automount table entries. All of which sounds to me like a lot of extra work to get better control of df output, when the changes could be done to df instead and be much narrower in scope. I'd written a program to set or clear filesystem tags for entries that match a particular resource (special file, in the case of devices), mount point, or filesystem type, so I've already played around with the use of mntfs tags a bit. They can deal with non-automounted entries for filesystem types that don't support "ignore", but that's about all they're good for. > the value > of putting lots of special cases into df (which might > keep changing), > and putting it > into /etc/mnttab allows other consumers to leverage > the information as > well. That's why I was talking about adding a configurable way to ignore certain filesystem types (or perhaps other criteria too), rather than adding hard-coded specifics; and the supplied configuration (or behavior absent a configuration file) could be the same as it is now, at least until the risks of changing it are better understood. One additional capability that would help minimize further configuration changes would be if one could request that entries with a capacity of 0 be suppressed by default - that takes care of most of the uninteresting stuff other than lofs entries all at once, probably new ones as well as existing ones. The only change that I would anticipate is that as more pseudo filesystems (with no storage associated in the usual sense) are created, one might wish to add them to the list of filesystems not to display by default, which would be just a configuration file, and so no big deal. But allowing the configurable suppression of those with zero capacity would probably eliminate 99% of the need for that. > One way I would imagine approaching this would be to > allow multiple > fstypes to be > specified with -F. This way, I could easily specify > what I wanted to > monitor, > rather than trying to filter out the stuff I don't > want. That has problems too. What if one writes a script that only assumes ufs, pcfs, and udfs are "interesting" (since hsfs is read-only, space management on it isn't an issue), and then installs some previously unknown (to the system and/or script writer) filesystem like vxfs, or upgrades to a version of the OS that adds zfs (as examples)? One would have to go back and track down all the scripts that distinguished between "interesting" and "uninteresting" entries in that manner, and modify them. In very large sites, there may be central monitoring that's independent of the routine activity of individual admins, and no assurance that changes to system configuration and changes to monitoring will be handled by the same people. So now you have new filesystems on which space issues could arise, but the scripts that were part of the monitoring might not be aware of them. That would be mitigated if the list used with -F could include filesystem type names not known to the system (silently ignoring them as long as at least one was valid), but would still require either coordinated changes or anticipation of all filesystem types of interest that might be added later. Also, one couldn't use -o fstype-specific-opts with -F list where list had more than one fstype. I'd like it if one could ask for a list of filesystems with the -F option of df, but I don't think that's sufficient. So while I'd welcome all filesystem types supporting "ignore", and df -F list, I still think those would only be part of what it takes to provide good control and decluttering of df output. One other thing: when stdout of df is a tty, I think it ought to expand the size of the "Filesystem" field when the tty is wider than 80 characters (by the amount that the tty is wider than that) so that lines aren't broken as often (for those formats like -k or -h which presently may break lines where that field is too long). Limiting that change to those circumstances would avoid breaking scripts, but would make the output more readable in wide windows. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
