MMC and reliable write - was: since when does ARM map the kernel memory in sections?

[pwaechtler@mac.com (Peter Waechtler)]

Am Montag, 6. Juni 2011, 12:28:55 schrieb Pavel Machek:
> Hi!
> 
> > > So basically add a new REQ_ flag - something like REQ_SAFE, which
> > > would ensure that data
> > > on block storage is not corrupted due to interrupting this write (or
> > > even, after the write, if the card does some optimizations). We
> > > already have a flag that ensures corruptions don't occur
> > > because of local-to-disk caches - REQ_FUA, so this would just thinking
> > > about what effects REQ_FUA  already has that's not considered. On a
> > > (spinning) disk, I can't image that interrupting a REQ_FUA write would
> > > cause data loss somewhere other than where data was written.
> > > 
> > > Then it would be as simple as a mount flag that would ensure all
> > > (write) accesses are FUA accesses, to ensure desired behavior for
> > > platforms where power could be cut at any moment.
> > 
> > I think you're mixing up different concepts.
> > 
> > On a spinning hard disk, _all_ writes don't cause data loss other than
> > where data is written, rounded up to the sector (512 or 4096 bytes).
> 
> ...
> 
> Yes, so on mmc there are two different problems:
> 
> * reliability of write itself (REL_WRITE solves that)
> 
> * reliability of data around write (there are for bits "controlling"
>   it in 4.4.1 MMC specs, unfortunately they are only writable by card
>   manufacturer AFAICS).
> 									Pavel

Yes - and there is another issue (but you could say that it fits to 2):

background operations

After programming a page the "pairing" page should be corrected.
Then there is garbage collection and wear leveling. If this is 
interrupted/disturbed by a sudden power loss "at the wrong moment": user data 
gets possibly corrupted.

The power supply has to give you a signal that power will be lost, say, in 30 
ms. Now a mechanism has to be specified how to tell the device to stop any 
programming in a timely fashion - the HPI (high prio interrupt) comes to mind.

	Peter