Date: Mon, 22 Nov 2010 15:54:25 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Aleksandr Rybalko <ray@ddteam.net> Cc: freebsd-mips@freebsd.org Subject: Re: First RSPRO deployed ! Message-ID: <AANLkTikVm7d=MzqSK=hsqgjFjahdwUFp0j_K6nB9gJCf@mail.gmail.com> In-Reply-To: <20101121155810.e615d4ad.ray@ddteam.net> References: <D74327E9-0A8A-4B46-B4DD-16D0FAF8E3BB@gmail.com> <CBBB7D88-210F-4706-A8FD-83FDA7EBA914@gmail.com> <AANLkTimAWM2UszxUsbnPkt0hra2pj0RqmbqhYMm7eCPv@mail.gmail.com> <201011191201.47230.freebsd-mips@dino.sk> <AANLkTi=58UpFdeGybZqeA0eTugq-B6ebPQ7McPET1QMc@mail.gmail.com> <AANLkTim3s5oW=w3%2ByWFn6BwKq=UoCROnyfS4kgBm8-aD@mail.gmail.com> <20101121155810.e615d4ad.ray@ddteam.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 November 2010 21:58, Aleksandr Rybalko <ray@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikVm7d=MzqSK=hsqgjFjahdwUFp0j_K6nB9gJCf>