From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] smbfs async readpage Date: Wed, 07 Aug 2002 10:34:57 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3D515A41.938808C0@zip.com.au> References: <3D50A8D4.AA31B1DD@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: To: Urban Widmark List-Id: linux-fsdevel.vger.kernel.org Urban Widmark wrote: > > On Tue, 6 Aug 2002, Andrew Morton wrote: > > > What you can do (please, I'd be interested in checking that it's > > workable) is to create an smbfs_backing_dev_info, and arrange > > (in smb_iget) for each new inode's mapping->backing_dev_info > > to point at it. > > Yes, the highest number of pages in action appears to be (mostly) limited > by what I set ra_pages to. If I set ra_pages to 1 or 2 my printks still > report up to 4 requests issued, but with 10 I never get more than 10. > 40 gives something that looks like 40, without actually counting the lines > ... That sounds promising. > > > Then implement some way of diddling smbfs_backing_dev_info.ra_pages > > and voila, tunable readahead. > > Other fs' seems to be using the default too. New 2.5 feature or does block > device based filesystems get this value from somewhere else? > (like the block device they live on?) Yes, there's a backing_dev_info structure in each block request queue and a pointer to that is placed in each address_space which is hosted by that queue. > If being able to tune readahead is important, I could imagine a desire to > tune differently on a per-mount basis. So I'd stick it in the smbfs > superblock and have a readahead=N mount option. Tunability may be important for preventing bad behaviour rather than for giving users something good ;) Does readahead across a n/w filesystem help much?