On Tue, Aug 03, 2021 at 03:15:54PM +0000, Trond Myklebust wrote: > There is already a method for doing this: you set up an appropriate > entry in /etc/udev/rules.d/. Adding a mount option, particularly one > that is NFS only and is handled in userspace rather than by the kernel > parser, just causes fragmentation and confusion. > > If you want to help users configure readahead, I'd suggest focussing on > a utility to help them set up the udev rule correctly. I prototyped a tool that runs on udev when a new bdi is added, you can see it at https://github.com/trbecker/readahead-utils. If this is good enough, it can have a user friendly tool that can be used to set the read ahead, check current values and manipulate the configuration file. I have a few limitations I see in this approach. This creates a different place to look into when debugging systems. Having the mount options would be more "in the face" of the engineer doing the debugging. This complicates configurations on clusters, and I find having the option better. I'm not sure how this would interact with containers, if this would create issues between the container and the host system. Advantages of this approach are the possibility to have defaults by fs type, device type, server (in case of a networked filesysem), wildcards. Some are good because they allow the user to improve memory usage (reducing the readahead for random access devices, increasing it for spinning devices and network devices, ...), some allow a set and forget configuration for directories that are used for hosting filesystems (automount, container directories, ...), which can't be achieved by a mount option. I agree with the fragmentation. Having this go into the kernel parser as a mount option seems to be a better way. Again, this is more granular and easier to find than having a separate application that runs on udev. I want opinions on these different approaches. Best, Thiago
