linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lukáš Czerner" <lczerner@redhat.com>
To: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Fast ext4 cleanup to avoid data loss after power failure
Date: Fri, 3 Oct 2014 16:08:59 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1410031550090.2333@localhost.localdomain> (raw)
In-Reply-To: <542EA00B.4040401@pqgruber.com>

On Fri, 3 Oct 2014, Clemens Gruber wrote:

> Date: Fri, 03 Oct 2014 15:09:31 +0200
> From: Clemens Gruber <clemens.gruber@pqgruber.com>
> To: linux-ext4@vger.kernel.org
> Subject: Fast ext4 cleanup to avoid data loss after power failure
> 
> Hi,
> 
> I am using ext4 as root filesystem of my TQMa28-based board with 2GB eMMC.
> In case of a power failure I have to clean up the filesystem in 1.5 to 2
> seconds, that's how long the caps can sustain the power.

What exactly is the problem you're trying to solve ? Does it concern
specific application ?

> 
> I pass the following rootflags on the kernel cmdline: data=journal,commit=1
> In my user space application I open important files with O_SYNC.

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

> 
> Is there something else I can or should do to avoid data corruption?
> 
> I can detect when the power fails over a GPIO line, so I close open file
> descriptors in one important application but doing a "normal"
> poweroff/shutdown takes too long.

That will help a little bit, but it's not reliable at all. Again
what do you expect to happen when the goes off in the middle of the
write to the eMMC ?

> 
> What would you do if you had 1.5 seconds until the power is gone?

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.

> 
> 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 ?

Regards,
-Lukas

> 
> Thanks for your help.
> 
> Best regards,
> Clemens
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2014-10-03 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-03 13:09 Fast ext4 cleanup to avoid data loss after power failure Clemens Gruber
2014-10-03 14:08 ` Lukáš Czerner [this message]
2014-10-03 15:39   ` Clemens Gruber
2014-10-03 15:44     ` Eric Sandeen
2014-10-04  3:47       ` Theodore Ts'o
2014-10-06 22:04         ` Clemens Gruber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1410031550090.2333@localhost.localdomain \
    --to=lczerner@redhat.com \
    --cc=clemens.gruber@pqgruber.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).