linux-ext4 - Re: Ext3 behavior on 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] [day] [month] [year] [list]

Message-ID: <20070418214904.GA10541@wolff.to>
Date:	Wed, 18 Apr 2007 16:49:04 -0500
From:	Bruno Wolff III <bruno@...ff.to>
To:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
	ext3-users@...hat.com, csar@...nford.edu, Ric Wheeler <ric@....com>
Subject: Re: Ext3 behavior on power failure

On Wed, Mar 28, 2007 at 09:17:27 -0400,
  "John Anthony Kazos Jr." <jakj@...-k-j.com> wrote:
> > If you fsync() your data, you are guaranteed that also your data are
> >safely on disk when fsync returns. So what is the question here?
> 
> Pardon a newbie's intrusion, but I do know this isn't true. There is a 
> window of possible loss because of the multitude of layers of caching, 
> especially within the drive itself. Unless there is a super_duper_fsync() 
> that is able to actually poll the hardware and get a confirmation that the 
> internal buffers are purged?

That is why you need to disable write caching of the drives or use cache
flushes via write barriers (if the stack of block devices all support them)
if the hardware cache isn't battery backed or the device doesn't support
returning the status of particular commands.

Of course nothing is perfectly safe.
-
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