From owner-freebsd-fs  Mon Dec  6 12:58:28 1999
Delivered-To: freebsd-fs@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4523C15904; Mon,  6 Dec 1999 12:56:20 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id MAA72561;
	Mon, 6 Dec 1999 12:56:14 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 6 Dec 1999 12:56:14 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199912062056.MAA72561@apollo.backplane.com>
To: "Ronald G. Minnich" <rminnich@lanl.gov>
Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject: Re: ELF & putting inode at the front of a file
References:  <Pine.LNX.4.20.9912061325270.20185-100000@mini.acl.lanl.gov>
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

: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?
:
:ron

    Good god, is he joking?  Offsetting the entire file by 128 bytes will
    break mmap() and make I/O extremely inefficient.

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message