ubiblock RW

[Ezequiel Garcia]

On 25 March 2016 at 17:50, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> On 25 Mar 01:51 PM, Artem Bityutskiy wrote:
>> On Thu, 2016-03-24 at 18:26 -0300, Ezequiel Garcia wrote:
>> > > > Richard, what do you think?
>> > > I'm definitely not fond of adding write support to ubiblock without
>> > > turning it into a proper FTL.
>> > > Otherwise it will be abused and will cause serious damage.
>> > >
>> > I'm not sure this statement makes much sense without actual numbers.
>>
>> Ezequel,
>>
>> could you re-summarize how the write support would be implemented? Read
>> entire LEB, modify data block (512 bytes), atomically write the LEB?
>> This would not perform well, but would probably work.
>>
>
> Yes, I was thinking in using atomic LEB change. The old write-support
> was implemented with a 1-LEB cache vmalloced at open, and freed at release.
>
> The flash device is written when the write cache is flushed on:
>   * block device release (detach)
>   * a different than cached leb is accessed (either through read or write)
>   * io-barrier is received through a REQ_FLUSH request
>
> It was expected that the block I/O scheduler would help mitigate
> the effects of a regular block oriented filesystem on flash sector
> erasecount.
>
> However, most likely UBIFS will do a far better job at preserving
> flash wear than any block oriented filesystem.
>
>> Or you want to avoid atomic LEB change and just erase the LEB and write
>> the entire LEB with the updated contents? This would probably be a bit
>> faster, but not power-cut safe.
>>
>
> Not sure dropping power-cut safeness a realistic option. I'd say
> most -if not all- users will want to be power-cut safe at all costs.
>
> Let me quote a mail here from Willy [1]:
>
> ""
> [..] I've been using ext2 on x86-based hardware and compact flash for
> something like 10 years with a great success (easy to mount, easy to
> fix, easy to save, easy to occasionally add a backup copy or an extra
> data file, etc).
>
> I contemplated ubifs on NAND devices as an alternative
> when starting to play with ARM-based devices, and lost the reliability
> and ability to fix. Switching back to the proven ext2 completely solved
> the issues in the end.
>
> Ubifs is nice when you need a real read/write FS,
> but most small devices do not need wear leveling or any of such nice
> features. When you just write 1-10 times a year, other solutions are
> fine enough. Using mtdblock directly is not reliable because of bad
> blocks which come from time to time. If your FS happens to be located
> on one of them, you're screwed. UBI solves such issues and ubiblock
> provides a nice interface for this.
> ""
>
> I guess we could have some UBI parameter to enable this support,
> and print a very noisy message to warn users about potential
> device wear out -- naively assuming users read messages...

Forgot to add Willy's quote:

[1] http://lists.infradead.org/pipermail/linux-mtd/2014-February/051909.html

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar