Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 4 Aug 2021 14:13:55 -0300
From:   Thiago Rafael Becker <trbecker@gmail.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "steved@redhat.com" <steved@redhat.com>,
        "tbecker@redhat.com" <tbecker@redhat.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH] mount.nfs: Add readahead option
Message-ID: <YQrK09dj3cjJoTLk@nyarly.rlyeh.local>
References: <20210803130717.2890565-1-trbecker@gmail.com>
 <6b627dc6ebc9ee1cbd37a62b48d08b1a031f0f08.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6b627dc6ebc9ee1cbd37a62b48d08b1a031f0f08.camel@hammerspace.com>
Precedence: bulk

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