Date: Mon, 6 Dec 1999 15:53:14 -0500 (EST) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Ronald G. Minnich" <rminnich@lanl.gov>, freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ELF & putting inode at the front of a file Message-ID: <Pine.GSO.3.96.991206152310.24121A-100000@sol.cs.binghamton.edu> In-Reply-To: <199912062133.NAA72851@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.991206152310.24121A-100000>