Date: Sat, 12 Feb 2011 19:45:27 -0800 From: perryh@pluto.rain.com To: tim@kientzle.com Cc: jhs@berklix.com, hackers@freebsd.org Subject: Re: memstick.img is bloated with 7% 2K blocks of nulls Message-ID: <4d5753d7.BT5wqP8CnfTD02s8%perryh@pluto.rain.com> In-Reply-To: <66758C9D-DCE2-4381-A4B1-956A48423CDD@kientzle.com> References: <201102111909.p1BJ9UAE097045@fire.js.berklix.net> <66758C9D-DCE2-4381-A4B1-956A48423CDD@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle <tim@kientzle.com> wrote: > The strategy used by libarchive's recent ISO writer > is to concatenate the file bodies into a temp file > (with minimal padding between entries to meet alignment > requirements) while storing directory information > in memory. The final output then consists of the > directory information followed by the concatenated > file bodies. > > I suspect a similar strategy could be used to lay > out and write a read-only optimized UFS image ... > I think it's probably feasible but I doubt very > much of the existing UFS code can be recycled for > such a project. There was at one time a capability in mkfs(8) -- which no longer even exists as a separate entity, having been absorbed into newfs(8) -- to pre-populate the filesystem with specified content. Dunno if it was ever in any BSD release -- it's not mentioned in the 4.2BSD-derived SunOS 4.1.1 manpage -- so I may be remembering it from Bell Labs 6th edition on the PDP-11. The code to collect and write all of an existing filesystem's directories, followed by all of its files, exists in dump(8).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d5753d7.BT5wqP8CnfTD02s8%perryh>