On 10/11/2011 12:05 AM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> That being said, if the home routers have to discover their IPv6
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
As to storing in flash, since most in homenet have not typically worked
on embedded systems, worse luck...
There is typically a read/write file system that can store state on a
current Linux home router (e.g. OpenWrt); it may or may not mapped over
the entire flash (which is desirable, as you'd like wear levelling to
use all blocks on the flash).
The bulk of the firmware is likely contained in a read-only file system
called Squashfs, which does LZW compression on a per file basis;
overlayed on top may be a read/write file system.
Most commonly the read/write file system has been a file system called
jffs2 over bare flash, originally implemented on the Compaq iPAQ
handheld, a project I helped lead after I got sick of HTTP. And OLPC
had a gigabyte of flash (which pushes jffs2 to/beyond it's design
limits). There are later flash file systems under development, but I
don't have first hand experience with any of them.
Flash has the characteristic that write is relatively slow, and erase is
generally glacial. Most interesting flash file systems try to do lazy
erasure (erase freed blocks when they have a chance later, rather than
at the time you may free a file).
Since you don't want to wear out the flash, the jffs2 does journaling;
one write will commit (potentially) a bunch of changes to multiple
files, rather than each write generating one write.
How many writes you get depends on the flash technology, whether the
flash is "bare" or has some "smart" controller, and the wear levelling
technology (if any) in use, along with whether all blocks participate in
the wear levelling or not (jffs2 does good wear levelling; but using a
big squashfs file system + a very small jffs2 file system will reduce
the effectiveness; some cheap USB storage devices only do wear levelling
on the free blocks, and try to hide the fact it is flash from the system
above. I put "smart" in quotes, because they've often been hideously
stupid, with their smarts limited to looking like IDE with a very lame
flash translation layer. The most recent "smart" flash disks for
laptops are actually getting very smart, with some help from the OS to
help with the erasure problem. But they still cost substantially more,
I suspect.
I think most home routers currently use bare flash, though it's not
clear to me if this will continue or not since the volume market may
make the economics change.
In any case, with flash of any sort, you don't want to sit there and
demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
for example).
All this being said, storing state at the rate of machines/routers
appearing or disappearing on a home network, or your ISP going down,
isn't likely to cause a problem. You just have to be careful enough to
not do anything really stupid; e.g. you map daemons with chatty logs to
run their logs to /dev/null, or to tempfs in RAM. And you might take a
big latency hit if you have to guarantee the write is stable before
continuing an algorithm (if you run into needing to erase a block for
some reason). And obviously you don't write tons of data when you don't
half to. And update in place may be a bad idea relative to other
techniques (which is why journaling file systems such as jffs2 are so
desirable).
- Jim
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
