linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: squadra <squadra@gmail.com>
To: Ivan Baldo <ibaldo@adinet.com.uy>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	EXT3 Users <ext3-users@redhat.com>
Subject: Re: power loss protection
Date: Sun, 12 Oct 2014 19:53:52 +0200	[thread overview]
Message-ID: <CABx==A0U72TayJ9R1ET8-dYke4MYNUZ0E6Fsq9yTjH90JtcUtA@mail.gmail.com> (raw)
In-Reply-To: <543A8B33.7020401@adinet.com.uy>

dunno about any special tools, but misusing a mysql database could be
a good check for this. unplug/reset your device while inserts into the
db are ongoing (dont forget to use innodb for the tables). unplug /
reset your device, boot it up again and take a look into the mysql
log. theres a good chance that innodb gets wrecked... sure, this is
not perfect. but could be a impressive test if it ends like i think.

make sure your mysql instance is configured to be "safe":

http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_method
http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

and enable binlogs + sync binlogs

or in other words: make it as slow as possible :p

On Sun, Oct 12, 2014 at 4:07 PM, Ivan Baldo <ibaldo@adinet.com.uy> wrote:
>     Hello.
>
> El 11/10/14 21:19, Theodore Ts'o escribió:
>>
>> 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.
>>
>>
>     This got me worried!
>     How can we test if a device really stores all the data safely after a
> barrier and sudden power loss?
>     Is there a tool for that?
>     I am thinking something along the lines of a tool that does writes with
> some barriers in between and then I unplug the device and run the same tool
> but in a "check mode" that tells me if the requested data before the barrier
> is really there.
>     Something sysadmin friendly or maybe even user friendly, but not too
> hard to use.
>     Thanks for your insight!
>
> --
> Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
> From Montevideo, Uruguay, at the south of South America.
> Freelance programmer and GNU/Linux system administrator, hire me!
> Alternatives: ibaldo@codigolibre.net - http://go.to/ibaldo
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users



-- 
Sent from the Delta quadrant using Borg technology!
--
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-12 17:53 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
2014-10-12 14:07     ` power loss protection Ivan Baldo
2014-10-12 17:53       ` squadra [this message]

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='CABx==A0U72TayJ9R1ET8-dYke4MYNUZ0E6Fsq9yTjH90JtcUtA@mail.gmail.com' \
    --to=squadra@gmail.com \
    --cc=ext3-users@redhat.com \
    --cc=ibaldo@adinet.com.uy \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).