Date: Fri, 29 Oct 1999 08:55:57 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes Message-ID: <99Oct29.085056est.40332@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.10.9910280018120.10856-100000@current1.whistle.com> References: <99Oct28.135145est.40328@border.alcanet.com.au> <Pine.BSF.4.10.9910280018120.10856-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1999-Oct-28 19:33:22 +1000, Julian Elischer wrote: >we'd have the code to read it turned on by default for 6 months before we >turned on the default to write them. This is fairly messy. I see them implemented as a new FS format. In which case the schedule would be: - update fsck(8), fsdb(8), dump(8), libstand/ufs.c and the kernel to know how to handle the new FS format. fsck should also gain the ability to convert FS_44INODEFMT to the new format and dumpfs(8) to report the new format. - update newfs(8) to be able to create an FS in the new format (ie a different constant in fs_inodefmt), but still default to FS_44INODEFMT - remind everyone to update their bootblocks before converting their root FS - wait a few releases (6-12 months) - update newfs(8) to default to the new FS format. You would still need to manually convert existing filesystems - either by dump/newfs/restore or 'fsck -c 4'. >I vaguely remember a paper on the topic. I was sure I wasn't the first one to think of this. >Maybe kirk can tell us more. I was hoping that some of the FS gurus would comment. They would have a much better feeling for the complexity of the changes - I have a nasty suspicion that the code to handle a file growing from 60 to 61 bytes (or vice versa) and mmap'ing a short file would be non-trivial. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Oct29.085056est.40332>