From owner-freebsd-hackers Mon Dec 6 14: 6:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 5EB9D14A05; Mon, 6 Dec 1999 14:06:24 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id RAA24839; Mon, 6 Dec 1999 17:06:16 -0500 (EST) Date: Mon, 6 Dec 1999 15:53:14 -0500 (EST) From: Zhihui Zhang Reply-To: Zhihui Zhang To: Matthew Dillon Cc: "Ronald G. Minnich" , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file In-Reply-To: <199912062133.NAA72851@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Matthew Dillon wrote: > :On Mon, 6 Dec 1999, Ronald G. Minnich wrote: > : > :> On Mon, 6 Dec 1999, Zhihui Zhang wrote: > :> > I have modified FFS filesystem code to put the disk inode at the beginning > :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of > :> > its disk inode and the rest of it are file data. > :> > :> first question I have is, why? > : > :I am doing some research on filesystem. I guess it may be faster to put > :the disk inode with its file data together so that both can be read into > :memory in one I/O. > : > :-Zhihui > > Not really. The inode tends to wind up being cached by the system > longer then file data, so placing it with the file data will not > help -- since it is already probably cached, the system generally doesn't > have to read it off the disk more then once anyway, and in a heavily > loaded system the system caching is sufficiently detached from the file > data processing that it is actually more beneficial to group inodes > together (one disk read is able to cache many inodes all in one go). I have read some papers. People have put disk inode with its file data. For small files, they can be read into memory with one I/O. In a distributed filesystem, if a inode block (contains 8192/128 inodes) is shared by multiple clients, it will hurt performance. One such paper may be "A 64-bit, shared disk file system for Linux" available at http://www.globalfilesystem.org/Pages/gfspapers.html. They call it "stuffed dinode". My understanding could be wrong though. > Another problem is that things like 'ls -la' or 'find' have to stat files > and if you put the inode at the beginning of the file you essentially > distribute the inodes all over the cylinder group rather then concentrate > all the inodes in one place. Yes. I have implemented most of the code. I noticed the "ls -al" is slow but "ls" is OK. > p.s. I was wrong about it breaking mmap() - in fact offseting the file > data on-disk will not break mmap(). But it will produce unaligned disk > transfers and potentially extra seeking. Yes. The cp command may use mmap(). I modify the mmap() so that this works. But this mmap() is done by the user, I can intercept it at the mmap() system call. As I said in my original email, the kernel uses memory map internally to load an ELF object file. I have to let the kernel know that there is a disk inode at the beginning of the ELF object file. It is hard for me to identify what part of the code is affected and to what extent. I think there should be a way. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message