Date: Wed, 7 Oct 1998 13:38:06 -0400 From: "Christopher G. Petrilli" <petrilli@amber.org> To: freebsd-small@FreeBSD.ORG Subject: Flash and Configuration Ideas [Was: Re: New microdrives from IBM] Message-ID: <19981007133806.21614@amber.org> In-Reply-To: <Pine.BSF.4.02A.9810071925400.21617-100000@korin.warman.org.pl>; from Andrzej Bialecki on Wed, Oct 07, 1998 at 07:31:03PM %2B0200 References: <19981007100029.30754@amber.org> <Pine.BSF.4.02A.9810071925400.21617-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 07, 1998 at 07:31:03PM +0200, Andrzej Bialecki wrote: > On Wed, 7 Oct 1998, Christopher G. Petrilli wrote: > > > I think it's extreemly important to focus on a GOOD flash file > > system---I'd settle for something a'la RT-11 and contiguous > > files---that doesn't have huge impact on flash re-write lifetimes. > > Hmmm.. What's an RT-11? Oh dear, I date myself :-) RT-11 was an OS from DEC in the 70s and 80s that ran on PDP-11s and was used for real-time systems. I think at one point or another, about half the planet ran on it ;-) The file system was very simple, and didn't have directory structures, which was fine for the time, since RL02 disk packs weren't very big :-) Basically, it required that all files be contiguous (and if I recall, you couldn't append, so you sized it right up front), and if there wasn't enough contiguouos space available for your file (even if there was enough space overall) then you couldn't write it. On occasion you would compact the drive (a deliberate process) and recover space. The reason I rbing this up is multi-fold. One it's trivial simple to implement, even with a directory strucutre. Second it's perfect for configuration files, and such, that don't change much in size. It would reduce the number of read/write/erase cycles on a flash device. BTW, there's another reason for this style file system (Plan 9 offered it as well, I believe in their file server, and Amoeba---a'la Andy Tannenbaum used it as well)--- it's amazingly fast. It runs at the theoretical limits of the device itself. Common benchmarks put FFS at something UNDER 30% utilization because of the seaks, etc. NTFS/FAT are worse than that. A contiguous file system can run at 90%+. This can make a big difference if you have a slow sotrage medium---i.e. PCMCIA flash cards. Just an idea... I can work up some modified Amoeba ideas (no reason to totally reinvent the wheel) if we want. I implemented this once as a prototype for USENET as well, worked 3-4x faster, but was too weird for some people. > > BTW, for those worrying about cramming it onto a 1.44Mb floppy for > > reasons of flash size, I went looking, and it's damned hard to find > > anything under 2MB of flash any more, and many many many boards support > > up to 72MB of FlashDisk. While I understand the need to conservce > > space---if not the need to spell correctly <wink>---I think that it is > > important to focus on what the embedded world needs, and make sure we > > can STRIP it to fit on a floppy, but not that we obsess over making > > sure it fits in all forms. > > Good points! > > This touches one very important issue: currently used way to build the > target picobsd system is as inflexible and inconvenient as it could ever > get.. :-( We need _some_ way of making it more modular, and easier to > modify, without requiring a total recompile each time... Any ideas are > welcome (about half a year ago I tried to create a picobsd version which > used separate binaries and shared libs... and failed miserably - the whole I think what would be nice is a reduced configuration spec (less than the current kernel complexities), that could be used to define what you wanted to build. Maybe even a GNU autoconf style thing? You know, like this: ./configure --enable-ip --enable-routing --enable-ppp --enable-x Or, a simple file that could be parsed quickly to generate teh correct information. It's important I think to realise that it's not important how big the PicoBSD distribution is in it's full form, it's important to keep the CORE piece (kernel, basic utils, ip code) as small as possible, but let the rest grow as necessary. Additionally, a simple command line configuration tool to generate floppy images on the fly would be amazingly useful.... alas, I don't know enough to write such a thing :-) Chris -- | Christopher Petrilli | petrilli@amber.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981007133806.21614>