linux-ext4 - Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

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]

Date:	Fri, 16 May 2008 17:03:06 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

Jamie Lokier wrote:
> Andrew Morton wrote:
>>> I suppose alternately I could send another patch to remove "remember
>>> that ext3/4 by default offers higher data integrity guarantees than
>>> most." from Documentation/filesystems/ext4.txt  ;)
>> We could add a big scary printk at mount time and provide a document?
> 
> Can I suggest making /proc/mounts say "barrier=0" when journal is not
> enabled, instead of omitting the option.
> 
> Boot logs are too large to pay close attention to unless it's really
> obvious.  (2.4 kernels _do_ have a similar message about "data
> integrity not guaranteed" with USB drivers - I never understood what
> it was getting it, and why it was removed for 2.6).
> 
> However, if I saw barrier=0 in /proc/mounts it would at least prompt
> me to look it up and then making an informed decision.

Right now, ext3_show_options has the scheme:

/*
 * Show an option if
 *  - it's set to a non-default value OR
 *  - if the per-sb default is different from the global default
 */

so only non-default is shown, so today barrier=0 is not shown.  I
suppose that could be changed...

FWIW, my patch would show barrier=0 if it's manually mounted that way
(against new proposed defaults), or if we are running w/o barriers due
to a failed barrier IO even though barriers were requested.

> Personally I had assumed barriers were enabled by default with ext3,
> as some distros do that, the 2.4 patches did that, and:
> 
>    I *have* experienced corruption following power loss without
>    barriers, and none with barriers.
> 
>    When I mentioned that turning off write cache or using barriers is
>    a solution to a programmer working on the same project, she said
>    "oh, yes, we've had reports of disk corruption too - thanks for the
>    advice", and the advice worked, so I am not the only one.
> 
>    (In the interests of perspective, that's with ext3 on patched 2.4
>    kernels on a ARM device, but still - the barriers seem to work).
> 
> On a related note, there is advice floating about the net to run with
> IDE write cache turned off if you're running a database and care about
> integrity.  That has much worse performance than barriers.

... and I've seen hand-waving about shortened drive life running this
way?  but who really knows....

Thanks,
-Eric

> I guess the patch which fixes fsync is particularly useful for those
> database users, as it means they can run with write cache enabled and
> depend on fsync() to give equivalent integrity now.  (Enabling
> journalling is not really relevant to this).
> 
> -- Jamie
> 
> --
> 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

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