First RSPRO deployed !

[Adrian Chadd]

On 21 November 2010 21:58, Aleksandr Rybalko <ray at ddteam.net> wrote:

>> * aim to get geom_ulzma into the base :-)
> No problem to add geom_ulzma into base, problem with lzma.
> LZMA decoder currently stored in geom_ulzma.c, this one has style(9)
> problems.
> Another one decoder live in libarchive, this one inaccessible by
> kernel.
> So we need something middle, like zlib in kernel code (why it in net
> subdir, but uses with many parts)

Well, it may be possible to create a liblzma for the kernel, if
someone's willing to do the legwork to tidy up the style(9) stuff.

>> * modify it a bit so it exports two GEOM devices - a read-only device
>> with the lzma'ed FS in it, and a read-write'able "rest";
> For what?
> flash splited by parts by geom_map (old name geom_mtd, loos@ name
> geom_flash IIRC), that parts rw, parts where stored ulzma compressed
> data handled by GEOM_ULZMA, that RO.

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.

> I also use small hack enabled writing for overlapped parts.
> Biggest part named "upgrade" overlapped with "kernel" part and "rootfs",
> so we can upgrade box when "kernel" and "rootfs" are opened.

How do you overwrite "rootfs" if you're running from it?
(Without remounting root into a ramdisk and upgrading, openwrt-style.)

>> * modify GEOM to pass through disk parameters from the provider, so
>> the flash device can export attributes (read size, write sizes, etc);
>> * modify the flash driver to have a small default block size (say, 128
>> bytes) so small transactions don't require huge amounts of SPI bus
>> access;
> I use BS=4, since I know many devices that map their FS not to block
> boundary.

:( Yup. But I can't help but think BS=4 is going to be very
inefficient for any FSes which do lots of small IO.

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?


Adrian