On 29/11/17 10:48, NeilBrown wrote: > On Wed, Nov 29 2017, Ian Kent wrote: > >> On 29/11/17 10:13, Mike Marion wrote: >>> On Wed, Nov 29, 2017 at 12:17:27PM +1100, NeilBrown wrote: >>> >>>> How big do people see /proc/self/mount* getting? What size reads >>>> does 'strace' show the various programs using to read it? >>> >>> We already have line counts into 5 figures. This wasn't an issue until >>> the change of /etc/mtab to a link. The large count is due to our large >>> direct automount maps. >>> > > So .... 90,000 lines with a length of may 120 chars or about 10Meg. > Presumably these machines would have so many gigabytes of RAM that > caching a 10M mountinfo file would go unnoticed? > > Reading that in 128K chunks without generating bits on the fly will help > a lot I suspect. > > We could probably ensure proper alignment by searching backwards for > '\n' when deciding how much to return for a read. > >> >> And, admittedly, the testing I was doing was with 15k+ size maps. >> >> Of course it's necessary to have this number of mounts to see serious >> problems which is easiest to do with large direct mount maps. >> >> The thing that's different now is that before applications started >> using /proc directly for mount table information using mount(2) >> instead of mount(8) was enough to prevent the mount entries from >> being added to the table seen by applications. > > I wonder who would notice if untriggered direct mounts quietly disappeared from > /proc/mounts... I suspect systemd would, but there is a good chance it > would fail-safe: assume that the mount worked. > Alternately we could introduce /proc/self/mountinfo2 which doesn't list > direct automounts and encourage problematic programs to use that where > available. Personally I think the proc filesystem tables should be a full representation of the mounted mounts. That needs to available somewhere. autofs still uses the proc mounts in one situation (there might be more I've missed in eliminating this) and other applications probably do too (I have patches to eliminate this one but they don't fit well with the current implementation). One approach I tried was to write a simple file system to mount over /etc/mtab (et. al.) and filter entries returned based on simple filter rules. That file system is not complete by any means and I couldn't get a feel for how effective it would be due to the direct access to the proc mount tables done by applications. OTOH, if applications could be persuaded to use /etc/(mtab|mounts|mountinfo) and only consult the proc tables when absolutely necessary this pseudo file system would be an ideal place for an entry cache .... Ian
