"Squashed" versions of FreeBSD

[Brett Glass-3]

All:

Several years ago, I developed several embedded systems using
"PicoBSD," a "squashed" version of FreeBSD. I then was diverted
from embedded UNIX development for a few years and am finally
returning to it. I need to upgrade/revamp some of my older work and
then develop some new things. I'd like to use a derivative of
FreeBSD 7.0 (or the upcoming 7.1), and need to come up to speed on
the various existing schemes for reducing FreeBSD 7.x to manageable
size and putting it on a CF card. All of the systems I'll be
developing will need to be configured remotely, and I may need to
do remote firmware updates, so I'm especially interested in schemes
which accommodate these things. I expect to build the systems
around Soekris boards, PC-compatible "set top boxes," or similar hardware.

So far, I've seen two possibilities: "miniBSD" and a "nanoBSD". Are
there others of which I should be aware? What are their pros and
cons? How does each of them handle issues involving
nonvolatile/read-only media vs. read/write media? Are good "howtos"
and architecture papers available for them, so that I do not have
to reverse engineer them to fully understand how they work? Any
input would be MUCH appreciated.

--Brett Glass

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Crist J. Clark-3]

On Wed, Jul 02, 2008 at 12:37:18PM -0600, Brett Glass wrote:

> All:
>
> Several years ago, I developed several embedded systems using
> "PicoBSD," a "squashed" version of FreeBSD. I then was diverted
> from embedded UNIX development for a few years and am finally
> returning to it. I need to upgrade/revamp some of my older work and
> then develop some new things. I'd like to use a derivative of
> FreeBSD 7.0 (or the upcoming 7.1), and need to come up to speed on
> the various existing schemes for reducing FreeBSD 7.x to manageable
> size and putting it on a CF card. All of the systems I'll be
> developing will need to be configured remotely, and I may need to
> do remote firmware updates, so I'm especially interested in schemes
> which accommodate these things. I expect to build the systems
> around Soekris boards, PC-compatible "set top boxes," or similar hardware.
>
> So far, I've seen two possibilities: "miniBSD" and a "nanoBSD". Are
> there others of which I should be aware? What are their pros and
> cons? How does each of them handle issues involving
> nonvolatile/read-only media vs. read/write media? Are good "howtos"
> and architecture papers available for them, so that I do not have
> to reverse engineer them to fully understand how they work? Any
> input would be MUCH appreciated.

Given the size of your typical CF card these days (I walked
into Frys and got 4 GB for $40 (not the cheapest either), and
a Atheros-based wireless NIC for $10!), there does not seem to
be much of a need to restrict size at the CF end of things.

For systems with small RAM, say < 64M, there may be advantages
to keeping the runtime footprint of the kernel and userland
code small, but again, with my net5501 with 512 MB of RAM,
I don't need to worry much about that either.

I've got a read-only root file system, /var is a live read-
write, noatime file system in the CF, but I made an effort
to put stuff in /var that does not need to be persistent
across reboot or just does to many write cycles in MFS,
specifically, /var/run is loaded with the usual data plus
other stuff that usually resides elsewhere in /var.

My only real worry is that I've not broken out all of the
stuff from the /var that I should and I may get "dead
spots" on my CF from too many write-cycles earlier than I
need to, but at $40, it's a risk I can take. I'd be curious
about any advice on that front.

But to get back on point, given how hardware capabilities
in embedded devices have scaled in the last decade (RAM,
CF, and CPU can easily be as big or bigger than your PC
server from a few years ago) compared to with how FreeBSD
resource consumption has (really not much when you look
at the OS itself), the need to pare things down has been
greatly reduced or may not even exist.

Of course, YMMV given the specific hardware and application.
--
Crist J. Clark                     |     cjclark@...
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Jed Clear-2]

On Wed, 2 Jul 2008, Brett Glass wrote:

> Several years ago, I developed several embedded systems using
> "PicoBSD," a "squashed" version of FreeBSD. I then was diverted
> from embedded UNIX development for a few years and am finally
> returning to it. I need to upgrade/revamp some of my older work and
> then develop some new things. I'd like to use a derivative of
> FreeBSD 7.0 (or the upcoming 7.1), and need to come up to speed on
> the various existing schemes for reducing FreeBSD 7.x to manageable
> size and putting it on a CF card. All of the systems I'll be
> developing will need to be configured remotely, and I may need to
> do remote firmware updates, so I'm especially interested in schemes
> which accommodate these things. I expect to build the systems
> around Soekris boards, PC-compatible "set top boxes," or similar hardware.
>
> So far, I've seen two possibilities: "miniBSD" and a "nanoBSD". Are
> there others of which I should be aware? What are their pros and
> cons? How does each of them handle issues involving
> nonvolatile/read-only media vs. read/write media? Are good "howtos"
> and architecture papers available for them, so that I do not have
> to reverse engineer them to fully understand how they work? Any
> input would be MUCH appreciated.

I'm using nanoBSD on a 5501-70 and it works fine.  I am using FreeBSD 6.3
as the base, though.  And I didn't find any problems finding pointers on
how to get it running.  Probably the biggest problem I see with is that
you have to "roll your own" to add non-base ports or packages.  Not that
it's hard to do, but it seems like a prime candidate to add to the stock
nanoBSD build process.

I did have the luxury of writiing the CF card on my build server the first
time, but you should be able to leverage the PXEboot if you need to load
the CF card with the 5501 the first time.  nanoBSD is designed to only use
half your CF at a time, allowing subsequent updated images to be loaded in
the other half and then boot over when complete.

This will get you rolling:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/howto.html

-Jed
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Arnt Gulbrandsen]

Crist J. Clark writes:
> My only real worry is that I've not broken out all of the stuff from
> the /var that I should and I may get "dead spots" on my CF from too
> many write-cycles earlier than I need to, but at $40, it's a risk I
> can take. I'd be curious about any advice on that front.

$40 isn't much. The sudden and unexpected downtime if/when the box
breaks may be a great deal worse. Depends how simple and cheap it will
be to get it back up.

Arnt
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Brian Candler]

On Wed, Jul 02, 2008 at 12:41:08PM -0700, Crist J. Clark wrote:
> Given the size of your typical CF card these days (I walked
> into Frys and got 4 GB for $40 (not the cheapest either), and
> a Atheros-based wireless NIC for $10!), there does not seem to
> be much of a need to restrict size at the CF end of things.

Squashing is worth it if you want to run from a ramdisk root though (like
Meraki Mini does).

Small image contains kernel and ramdisk => boots and expands to RAM

This lets you have a couple of partitions for storing your kernel/ramdisk
pairs (so 'upgrading' a machine is just a case of overwriting one of those
partitions), and a third partition for data which is to be persistent.

I think NanoBSD works this way.

Regards,

Brian.
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[K Kadow]

> Crist J. Clark writes:
> > My only real worry is that I've not broken out all of the stuff from
> > the /var that I should and I may get "dead spots" on my CF from too
> > many write-cycles earlier than I need to...

I've been told hardware "wear leveling" (found in name-brand CF cards)
eliminates the "dead spot" issue.

Now instead of being worried about killing any one cell, you instead
have to be concerned that you will "wear out" the entire card,
particularly with Static Wear leveling:
http://en.wikipedia.org/wiki/Static_Wear_Leveling
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Crist J. Clark-3]

On Fri, Jul 04, 2008 at 11:28:15AM +0200, Arnt Gulbrandsen wrote:
> Crist J. Clark writes:
> > My only real worry is that I've not broken out all of the stuff from
> > the /var that I should and I may get "dead spots" on my CF from too
> > many write-cycles earlier than I need to, but at $40, it's a risk I
> > can take. I'd be curious about any advice on that front.
>
> $40 isn't much. The sudden and unexpected downtime if/when the box
> breaks may be a great deal worse. Depends how simple and cheap it will
> be to get it back up.

I may be wrong, but I didn't think the failure mode would be
a "sudden and unexpected" downtime. I had assumed I'd start to
see read/write errors like you see when a HDD slowly gets
bad sectors. However, rethinking that, I'm not sure what to
expect.
--
Crist J. Clark                     |     cjclark@...
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Joel Jaeggli-3]

Crist J. Clark wrote:

> On Fri, Jul 04, 2008 at 11:28:15AM +0200, Arnt Gulbrandsen wrote:
>> Crist J. Clark writes:
>>> My only real worry is that I've not broken out all of the stuff from
>>> the /var that I should and I may get "dead spots" on my CF from too
>>> many write-cycles earlier than I need to, but at $40, it's a risk I
>>> can take. I'd be curious about any advice on that front.
>> $40 isn't much. The sudden and unexpected downtime if/when the box
>> breaks may be a great deal worse. Depends how simple and cheap it will
>> be to get it back up.
>
> I may be wrong, but I didn't think the failure mode would be
> a "sudden and unexpected" downtime. I had assumed I'd start to
> see read/write errors like you see when a HDD slowly gets
> bad sectors. However, rethinking that, I'm not sure what to
> expect.

If your CF card supports smart you should see it report the remapping of
  bad sectors as well as correctable and uncorrectable errors.

At this point a high capacity industrial cf card with a decent write
shadowing and wear leveling implementation ought to last many years in
the role you're describing...
_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Brian W. Antoine]

> I may be wrong, but I didn't think the failure mode would be
> a "sudden and unexpected" downtime. I had assumed I'd start to
> see read/write errors like you see when a HDD slowly gets
> bad sectors. However, rethinking that, I'm not sure what to
> expect.

It depends on the filesystem.  The Flash FileSystem might be smart
enough to remap blocks on the fly when a read-after-write validation
fails, or it might simply be erasing and rewriting the same block
until it fails.  In that case you'll either loose a file or your
filesystem, depending on whether it was a data or inode block that
went bad.

Those cells can only be written to zero just so many times.  These
days it's a much larger number of times, but the limit still exists.

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Joel Jaeggli-3]

Brian W. Antoine wrote:

>> I may be wrong, but I didn't think the failure mode would be
>> a "sudden and unexpected" downtime. I had assumed I'd start to
>> see read/write errors like you see when a HDD slowly gets
>> bad sectors. However, rethinking that, I'm not sure what to
>> expect.
>
> It depends on the filesystem.  The Flash FileSystem might be smart
> enough to remap blocks on the fly when a read-after-write validation
> fails, or it might simply be erasing and rewriting the same block
> until it fails.  In that case you'll either loose a file or your
> filesystem, depending on whether it was a data or inode block that
> went bad.

There's been a lot of work done by ssd manufacturers that bleeds over
into cf cards (which use the same chipsets) to implement these features
in the controller... The result is:

1. you can use your normal filesystem

2. you flash specific filesystem optimizations may work at cross
    purposes to a controller firmware implementation that's been designed
    to support a windows vista pagefile on ntfs on flash media.

> Those cells can only be written to zero just so many times.  These
> days it's a much larger number of times, but the limit still exists.

The bigger the media the more cells there are for the wear leveling
algorythm to work across... you can write continously to an 8GB flash
card at 30MB/s (about the fastest you can buy when you factor in the
erase cycle) for .84 years before you hit 100,000 cycles.

> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech@...
> http://lists.soekris.com/mailman/listinfo/soekris-tech
>

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech

[Bill Maas-2]

Hi Crist,

On Tue, 2008-07-08 at 11:41 -0700, Crist J. Clark wrote:
> On Fri, Jul 04, 2008 at 11:28:15AM +0200, Arnt Gulbrandsen wrote:
> > Crist J. Clark writes:
> > > My only real worry is that I've not broken out all of the stuff from
> > > the /var that I should and I may get "dead spots" on my CF from too

Set up an experimental box, mount everything except /var R/O, leave it
running for a few days and see what happens? A properly set up system
(e.g. OpenBSD) would not give any errors, but yes, there are always a
few hardheaded programs that want to write to /usr/progname/etc and the
like...

> > > many write-cycles earlier than I need to, but at $40, it's a risk I
> > > can take. I'd be curious about any advice on that front.
> >
> > $40 isn't much. The sudden and unexpected downtime if/when the box
> > breaks may be a great deal worse. Depends how simple and cheap it will
> > be to get it back up.
>
> I may be wrong, but I didn't think the failure mode would be
> a "sudden and unexpected" downtime. I had assumed I'd start to
> see read/write errors like you see when a HDD slowly gets
> bad sectors.

That's exactly what I've seen with a TakeMS cheaper-then-cheap CF card
with no wear-leveling, going bad. It took about 6 weeks going from 1
recoverable read error every 2 days to a torrent of error messages (>
100/24 hrs), so keeping an eye on the logs should do. Of course with a
strong YMMV reservation, depending on the card you are using.

Bill

>  However, rethinking that, I'm not sure what to
> expect.

_______________________________________________
Soekris-tech mailing list
Soekris-tech@...
http://lists.soekris.com/mailman/listinfo/soekris-tech