Date: Thu, 16 Oct 2008 17:48:22 -0400 From: Isaac Levy <isaac@ceetoneresearch.com> To: Philip Mullis <philip.mullis@syx.ca> Cc: freebsd-embedded@freebsd.org Subject: Re: storage selection for embedded devices Message-ID: <FB221608-17EA-4105-A79C-177F9CAF3C78@ceetoneresearch.com> In-Reply-To: <48F4DBDC.9020904@syx.ca> References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> <dcfb161c0810141027s12219080wb403116c1f562aa@mail.gmail.com> <48F4DBDC.9020904@syx.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all, > Olivier Gautherot wrote: >> Philip, Warner, >> >> On Tue, Oct 14, 2008 at 3:00 PM, M. Warner Losh <imp@bsdimp.com> =20 >> wrote: >> >>> In message: <48F4C02F.1060407@syx.ca> >>> Philip Mullis <philip.mullis@syx.ca> writes: >>> : I was wondering if anyone has extended experience in this area =20 >>> with >>> : embedded devices. >>> : >>> : I have a fixed embedded image which runs happily out of a 1Gig =20 >>> compact >>> : flash card. >>> : >>> : However I have some applications that I want to install to my =20 >>> device >>> : that will perform writes alot to the cf. >>> >>> I've deployed CF cards into systems for a number of years (since >>> 2000). They are way more reliable than spinning media in the >>> environments that I deploy my company's gear into. >>> >>> We have most of the CF dedicated to a read-only partition. A small >>> modification partition was also provided. >>> >> >> I wonder if you're talking about the same thing (may be just me...) >> >> Philip, what frequency of writes are you talking about? I think this >> is key to the discussion. Are you planning enough RAM to avoid swap? >> Can your system count with a RAM disk and regular dump of the content >> to FLASH? If this is the case, a USB stick should be a safe approach. >> >> The algorithm Sandisk is referring to enhances the statistical >> lifespan by shuffling the cells and using spare ones when the main >> array wears out (trial-and-error algorithm). The typical lifespan =20 >> of a >> cell is 100k write cycles: try to evaluate whether this is compatible >> with the use you plan for your device. >> >> >> >>> I've also tried to wear out a CF part by writing to the part, both >>> directly and through a filesystem, millions of times. I was =20 >>> unable to >>> keep a machine running long enough to cause a failure (my mistake =20= >>> was >>> doing it in a lab where people liked to unplug things). >>> >> >> The technology has surely evolved since I last dealt with it in an >> industrial environment. However, I would not swear by the "millions =20= >> of >> times" as such: Sandisk is famous for leveling the writes over the >> whole array. Now, if your partition is relatively empty, your device >> will support more cycles. In any case, using 10% of the FLASH blocks >> can surely lead you to the millions of cycles without problem. >> >> >> >>> : Ive read the sandisk wear leveling white paper, yet I also hear =20= >>> many >>> : people such as professional photographers swearing by the write =20= >>> once >>> : rule with cf cards. >>> >> >> That's paranoia, especially with todays technologies. >> >> >> On Oct 14, 2008, at 1:50 PM, Philip Mullis wrote: > In a non-busy environment I am looking at just over 100 > writes,consisting of files ranging from a few 100kbytes to a max of > 40mbytes each. > > The calculated max writes that would ever be reached in one day =20 > would be > 8000. (Id love to leave these in memory and sync them of, however =20 > there > is not enough memory on the alix2c3 to do this in most scenarios). > > Ive got the whole system down to less than 80mb which gets loaded =20 > into a > read-only memory filesystem on boot leaving me with most of the cf =20 > to be > mounted in as rw. I used freebsd 6.4 for the image. > > The Alix2c3 has 256megs Ram and is a geode 500mhz processor, it runs > quite nicely, and eats less than 6watts most of the time :) > I just wanted to chime in with some metrics, (although lacking total =20 context/details): =46rom a presentation on the NanoBSD build scripts, on FreeBSD, here's =20= this: -- http://www.bsdcan.org/2006/papers/nanobsd.pdf Page 12 of the slides states: Counting flash writes + 200.000 writes, worst case: =96Superblock updated 1/s =3D 55 hours lifetime =96File written 1/m =3D 138 days lifetime =96File written 1/h =3D 22 years lifetime =96File written 1/d =3D 547 years lifetime -- Now, the details of the writes is not clear here, but the point is =20 clear- writes to CF cards *must* be minimized. After working with =20 Soekris boards for years, and now PCEngines, I can testify that =20 typical UNIX installs on CF cards, (lots of writes), wrecks the cards =20= fast. CF cards do funky wear-leveling stuff, so tricks I've seen people try =20= which move files around simply exacerbate the problem... -- Here's a general approach to CF as boot drive use, (and the purpose of =20= the NanoBSD build scripts on FreeBSD): 1) obviously: Tiny Kernel, userland, etc... stripped down system to =20 taste/sanity 2) 4 notable partitions on CF media: - boot sector - 1st half, read-only root and userland - 2nd half, read-only root and userland - a small partition to mount as needed and write config files to =20 (is unmounted unless a config needs to be written) For system updates, build a new image, and dd it to the second =20 partition- reset bootloader to boot from second partition, and =20 viola... minimal writes. This is very flexible, can be piped over =20 ssh, etc... 3) A couple of memory disks for /etc /var and /tmp, (5mb each is Nano =20= default)- /etc gets the files from the small r/w partition above. That's just a quick conceptual overview of one successful method of =20 running UNIX on CF cards- hope it's helpful! More info specifically =20 on NanoBSD can be found here: http://www.freebsd.org/doc/en/articles/nanobsd/index.html I'd love to know what similar systems exist for other UNIX systems if =20= anybody has done anything interesting?! (esp. any noteworthy PicoBSD =20= differences) Best, .ike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB221608-17EA-4105-A79C-177F9CAF3C78>