linux-ext4 - Re: Fast ext4 cleanup to avoid data loss after power failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <542EC343.7090905@pqgruber.com>
Date:	Fri, 03 Oct 2014 17:39:47 +0200
From:	Clemens Gruber <clemens.gruber@...ruber.com>
To:	Lukáš Czerner <lczerner@...hat.com>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Fast ext4 cleanup to avoid data loss after power failure

On 10/03/2014 04:08 PM, Lukáš Czerner wrote:
> What exactly is the problem you're trying to solve ? Does it concern
> specific application ?

It's a software to control and configure dispensing equipment in a bar.
The problem is that power is lost frequently and the only warning is the
mentioned GPIO about 1.5 to 2 seconds in advance, then the caps are drained.
This happens very often and I have to prevent it from damaging the
filesystem.

I did not mention it before, because I was not sure if it is relevant,
but I am running Linux 3.17-rc7 on the board.

> So what you expect to happen if the power failure happens in the
> middle of the write to the eMMC ?

With the 1.5 second delay, I'd like to stop the application, before that
happens.

> I'd avoid the need to deal with this at all. File system
> (journal) itself will protect you from metadata corruption (file
> system corruption). But the application has to protect it's own
> important files for data consistency (data=journal will not help
> you, nor commit=1).
> 
> The usual and simple way for the application to deal with this is to
> use temporary file, fsync the changes to make sure that everything
> hit the disk and then atomically rename the file to replace the
> original. That way your file will always by in consistent state. It
> will either have the new content, or the old one, not mix of both.

Thank you, this approach sounds good! I will change the application
accordingly.
So the only necessary step to do when the GPIO triggers, is to quit the
applications writing to the eMMC. If I use that write, fsync, rename
strategy, I guess I could even SIGKILL them.

And you would keep the default values for the commit and data flag,
because fsync flushes the buffers for data and metadata anyway?

Forcing fsck for the next boot, when I detect that a power-failure is
imminent, is also not necessary, right?

> 
>>
>> Maybe a read-only rootfs and a separate small data partition?
> 
> Well, if you do not need to write to the rootfs why you need to deal
> with data corruption ?

At the moment, my root filesystem is writable. I would need to change a
lot, so I'd rather find a solution to keep it writable and avoid
corruption / ensure durability.

Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html