Date: Mon, 22 Nov 2010 22:57:06 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Alexandr Rybalko <ray@dlink.ua> Cc: Aleksandr Rybalko <ray@ddteam.net>, freebsd-mips@freebsd.org Subject: Re: First RSPRO deployed ! Message-ID: <AANLkTikALjsVyamtBa_po3eBgSGMDSCzD7mWE0Q_%2BLm7@mail.gmail.com> In-Reply-To: <20101122135703.1487660c.ray@dlink.ua> 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> <AANLkTikVm7d=MzqSK=hsqgjFjahdwUFp0j_K6nB9gJCf@mail.gmail.com> <20101122135703.1487660c.ray@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 November 2010 19:57, Alexandr Rybalko <ray@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikALjsVyamtBa_po3eBgSGMDSCzD7mWE0Q_%2BLm7>