ubiblock RW

[Ezequiel Garcia]

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...
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar