Date: Mon, 6 Dec 1999 16:46:36 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu> 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: <199912070046.QAA73815@apollo.backplane.com> References: <Pine.GSO.3.96.991206152310.24121A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
Yes, ls (without any options) is ok because the file type is now being
stuffed in the directory entry, allowing ls (without any options) to
avoid stat()ing the file.
:> 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
There's another issue that you should look at - generally functionally
different caches work better as separate entities then as a single
entity. In this case it is far easier for the system to cache an inode
(or a set of inodes) then it is for the system to cache a data block. If
you force a system to cache both at the same time when it only needs one
type or the other (because one might already be cached), the result is
that neither cache is able to run optimally.
It might be interesting, as an exercise, to attempt to pre-cache the inode
space in the traditional unmodified system when a directory is
read and leave them as separate entities and see whether that gives you
the same performance boost.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199912070046.QAA73815>