Date: Fri, 4 Oct 1996 00:34:40 +0900 (KST) From: Heo Sung-Gwan <heo@cslsun10.sogang.ac.kr> To: freebsd-hackers@FreeBSD.ORG Cc: freebsd-fs@FreeBSD.ORG Subject: Re: vnode and cluster read-ahead Message-ID: <Pine.SUN.3.93.961004003010.6582A-100000@cslsun10>
next in thread | raw e-mail | index | archive | help
John Dyson writes: >> >> You could maintain a number of 'pending readahead' structures indexed by >> vnode and block number. Each call to cluster_read would check for a >> pending readahead by hashing. For efficiency, keep a pointer to the last >> readahead structure used by cluster_read in the vnode in place of the >> existing in-vnode readahead data. Should be no slower than the current >> system for single process reads and it saves 4 bytes per vnode :-). > >Pretty cool idea. I am remembering now that this deficiency in our read >ahead code is well known. This might be something really good for 2.3 or >3.1 :-). (Unless someone else wants to implement it -- hint hint :-)). > I suggest a new idea. The fields for read-ahead(maxra, lenra, etc) are in file structure or other structure(e.g. Doug Rabson's readahead structure) that is pointed by a new field in file structure. And vnode has a new field to contain the point to the file structure. This vnode field is filled every read system call with the point to the file structure at vn_read() in kern/vfs_vnops.c Then it is possible that the file structure is accessed through vnode in cluster_read. Because the system calls are nonpreemptive the point to the file structure in the vnode is not changed until the current read system call is finished. This method removes the hashing using vnode and block number. Is it really possible? -- Heo Sung-Gwan Dept. of Computer Science, Sogang University, Seoul, Korea. E-mail: heo@cslsun10.sogang.ac.kr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.93.961004003010.6582A-100000>