From owner-freebsd-hackers Sun Oct 29 23:26:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 73B9737B4C5 for ; Sun, 29 Oct 2000 23:26:54 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U7Qsc73333; Sun, 29 Oct 2000 23:26:54 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 23:26:54 -0800 (PST) From: Matt Dillon Message-Id: <200010300726.e9U7Qsc73333@earth.backplane.com> To: David Preece Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem holes References: <5.0.0.25.1.20001030172530.00a06070@mail.afterswish.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Presumably writing into these holes repeatedly is a none-too-efficient :affair (requiring moving all the stuff on either side), or am I missing the :point slightly? : :Dave :) It isn't quite that bad, but it isn't a walk in the park either. Since data blocks are referenced from a block table, inserting new blocks is cheap. However, this means that data may not be physically ordered in the file -- if your read crosses a block boundry it may require an extra seek. FreeBSD's FFS does have the reallocblks feature turned on and this will cause the filesystem to try to reorder nearby blocks, but it was never designed to handle sparse files so.... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message