ubifs robustness with early power cut warning

Doug Crawford dcraw101 at gmail.com
Mon Oct 2 09:14:28 PDT 2017


I think my use case might be a little different. This 500 millisecond
early power down warning is intended to be recoverable if the power is
restored in that period.  The effect I am looking for is that any new
fsync or sync commands made during this 500 ms window will pause or
block, but if the power is restored then the sync will be successful.

I am worried that if mtd_write() returns an EPERM error then any
outstanding fsync or syncs would fail instead of block?  I don't know
enough about the mtd layer or the locking/calling context of
mtd_write().  But, I am guessing I can't simply sleep or block in that
function while the powerdown gpio is low?

On Sat, Sep 30, 2017 at 9:19 AM, Richard Weinberger
<richard.weinberger at gmail.com> wrote:
> On Sat, Sep 30, 2017 at 1:20 AM, Doug Crawford <dcraw101 at gmail.com> wrote:
>> We have an embedded system with an early power loss warning.  The
>> power supply drives a powerdown signal connected to a GPIO pin on the
>> CPU.  When AC power is switched off the power supply drives this
>> signal low for 500 milliseconds before the CPU gets held in reset.  If
>> AC power is switched back on before 500 milliseconds the powerdown
>> signal goes high again and the system is expected to continue running
>> normally.
>>
>> I am wondering if there is a way to easily modify ubifs/ubi such that
>> when the powerdown gpio is low VFS or UBIFS or UBI freezes or pauses
>> further writes to the NAND.  If powerdown recovers to high again then
>> the filesystem would unfreeze and allow further writes?  Has anyone
>> implemented something like this before?  I know UBIFS/UBI is designed
>> to be very resilient to power cuts, but I am thinking this technique
>> might make the system even more resilient.  If I were to make this
>> change which file would be the right one to hook into:
>> fs/ubifs/super.c?
>
> UBI/UBIFS is the wrong layer, this needs to happen in MTD.
>
> --
> Thanks,
> //richard



More information about the linux-mtd mailing list