linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jelle de Jong <jelledejong@powercraft.nl>,
	EXT3 Users <ext3-users@redhat.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: CF Card wear optimalisation for ext4
Date: Sat, 11 Oct 2014 19:19:48 -0400	[thread overview]
Message-ID: <20141011231948.GC6262@thunk.org> (raw)
In-Reply-To: <08F28BC7-34FD-46BA-9D91-CC7D57A4A4D5@dilger.ca>

Something else that you might want to do is count the number of
journal commits that are taking place, via a command like this:

perf stat -e jbd2:jbd2_start_commit -a sleep 3600

This will count the number of jbd2 commits are executed in 3600
seconds --- i.e., an hour.

If you are running some workload which is constantly calling fsync(2),
that will be forcing journal commits, and those turn into cache flush
commands that force all state to stable storage.  Now, if you are
using CF cards that aren't guaranteed to have power-loss protection
(hint: even most consumer grade SSD's do not have power loss
protection --- you have to pay $$$ for enterprise-grade SLC SSD's to
have power loss protection --- and I'm guessing most CF cards are so
cheap that they won't make guarantees that all of their flash metadata
are saved to stable store on a power loss event) the fact that you are
constantly using fsync(2) may not be providing you with the protection
you want after a power loss event.

Which might not be a problem if you have a handset with a
non-removable eMMC device and a non-removable battery that can't fly
out when you drop the phone, but for devices which which can easily
have unplanned power failure, it may every well be the case that
you're going to be badly burned across a power fail event anyway.

So the next question I would ask you is whether you care about
unplanned power failures.  If so, you probably want to test your CF
cards to make sure they actually will do the right thing across a
power failure --- and if they don't, you may need to replace your CF card provider.

If you don't care (because you don't have a removable battery, and the
CF card is permanently sealed inside your device, for example), then
you might want to consider disabling barriers so you're no longer
forcing synchronous cache flush commands to be sent to your CF card.
This trades off power failure safety versus increased performance and
decreased card wear --- but if you don't need power failure safety,
then it might be a good tradeoff.

And if you *do* need power fail protection, then it's a good thing to
test whether your hardware will actually provide it, so you don't find
out the hard way that you're paying the cost of decreased performance
and increased card wear, but you didn't get power fail protection
*anyway* because of hardware limitations.

Cheers,

					- Ted

  reply	other threads:[~2014-10-11 23:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5435661D.2040905@powercraft.nl>
2014-10-10 19:02 ` CF Card wear optimalisation for ext4 Andreas Dilger
2014-10-11 23:19   ` Theodore Ts'o [this message]
2014-10-12 14:07     ` power loss protection Ivan Baldo
2014-10-12 17:53       ` squadra

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=20141011231948.GC6262@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=ext3-users@redhat.com \
    --cc=jelledejong@powercraft.nl \
    --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).