Date: 07 Dec 1999 16:59:13 -0500 From: Randell Jesup <rjesup@wgate.com> To: freebsd-hackers@freebsd.org Subject: Re: ELF & putting inode at the front of a file Message-ID: <ybupuwie7ke.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Matthew Dillon's message of "Mon, 6 Dec 1999 12:56:14 -0800 (PST)"
next in thread | raw e-mail | index | archive | help
Matthew Dillon <dillon@apollo.backplane.com> writes:
>: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?
>
> Good god, is he joking? Offsetting the entire file by 128 bytes will
> break mmap() and make I/O extremely inefficient.
Very true; though providing locality of the metadata and the
beginning of the file has obvious benefits (and is used by many filesystems
and experiments). (See below.)
> Many filesystems over the years have mixed meta-data in the file data
> blocks on disk only to remove it later on when it was found to destroy
> performance. A good example of this is the Amiga's filesystem. The
> Amiga's old filesystem was emminently recoverable because each data
> block had a backpointer, but it was so inefficient due to all the copying
> required that the updated filesystem removed the metadata so disk blocks
> could be DMA'd directory into the buffer.
Each block in OFS had a backpointer and a checksum; it was designed
(apparently) for mass-storage systems that had no lower-level data
integrity mechanisms. Amiga FFS (no relation to Unix FFS) removed all the
data-block checksums and pointers, and as a result sequential file reads
were able to run at close to raw disk bandwidth. (Direct destination DMA
of reads/writes helps a lot here, and was used whenever possible -
sector-unaligned IO's would commonly have only the head and tail go through
the buffer cache; the middle portion would go direct to the user memory.)
The big benefits to locality of meta & file data are to allow
drive/driver caching to do sequential (or close to) reads in as large
blocks as possible. There was a recent SigOS paper on a modified Unix
filesystem that was designed to take advantage of modern disk systems,
reduced the number of inode indirection levels, and changed the allocation
patterns of data within cylinder groups. Looked nice.
<nostalgia mode on>
Ah, the days of multi-threaded (with co-routines) filesystems
written in ultra-tight (for space) assembler, complete with co-routine-
semaphores, and a built-in automatic fsck-equivalent. Not to mention
file-locking and notification on file-modification (pretty cool, actually).
<nostalgia mode off>
Shudder.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.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?ybupuwie7ke.fsf>