First RSPRO deployed !

[Adrian Chadd]

On 22 November 2010 19:57, Alexandr Rybalko <ray at dlink.ua> wrote:
>>> Can you explain it a bit better? The idea is to not have the RW
>>> offset/length hardcoded, it instead is based on whatever is left in
>>> the partition after the RO LZMA section.
> Ah, now I`m understand you. That possible with geom_map.
[snip]

> In that example GEOM_MAP setup 8 parts,
> part called rootfs_ro is where lzma-ed rootfs live,
> part called rootfs_rw is blank part for rw data.
> GEOM_MAP search for keyword "--some-delimiter--" in flash from searchstart=0x00130000 with step 64k (searchstep="65536")
> This require correct alignment of key.

Right. The openwrt board config code has things like the above hard
coded. I like the idea of having to above to list flash partitions but
not to go grovelling through the flash partition to find 'filesystem
markers'. :-)

Anyway, that's personal preference. Whatever works, works. :)

>>> The other thing to consider is what BIO_WRITE means. RIght now it's
>>> effectively BIO_READ_OVERWRITE_WRITE - ie, the disk devices handle
>>> this as "read in the underlying sector(s), modify what we need to, and
>>> write out the results." This is a bit inefficient for flash devices.
>>> It may be cleaner to add a new BIO for "flash writes" that have
>>> flash-write semantics - ie, depending upon the flash device behaviour,
>>> either bits get set 0->1 or they get set 1->0, but an ERASE is needed
>>> to reset them. That then begs the question - what about
>>> BIO_FLASH_ERASE?
>
> Good idea, but think we still need special FS for NOR like flash.

We still do. The point is, all of the above work is to lay a
foundation to let people experiment with "flash FSes". IMHO right now
the entry barrier is too high: a flash fs author would have to invent
an MTD layer as well as a flash filesystem layer. I'd rather we take
care of a basic MTD layer - whether it be a GEOM extension or
something else - and then open the floor to further experimenting. :)


Adrian