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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
