linux-ext4 - Re: [PATCH v2] ext4: Deprecate data=journal mount option

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]

Message-ID: <alpine.LFD.2.00.1106291338270.6151@dhcp-27-109.brq.redhat.com>
Date:	Wed, 29 Jun 2011 13:49:27 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Bruce Guenter <bruce@...roubled.org>
cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2] ext4: Deprecate data=journal mount option

On Tue, 28 Jun 2011, Bruce Guenter wrote:

> On Tue, Jun 28, 2011 at 01:26:03PM +0200, Lukas Czerner wrote:
> > Data journalling mode (data=journal) is known to be neglected by
> > developers and only minority of people is actually using it. This
> > mode is also less tested than the other two modes by the developers.
> > 
> > This creates a dangerous combination, because the option which seems
> > *safer* is actually less safe the others. So this commit adds a warning
> > message in case that data=journal mode is used, so the user is informed
> > that the mode might be removed in the future.
> 
> When I last benchmarked it, data=journal mode was considerably faster
> than the other modes for sync heavy work loads, such as mail servers.
> Have there been improvements to other (safe) modes that reverse this?
> 

No, not any specific change that I know of. The problem with
data=journal from performance perspective is that, it can improve fsync
heavy loads, however just for a limited bandwidth. Because as you
probably know in this mode it will write all data twice, however it will
generate fewer seeks. So yes, for sync heavy work load with small writes
(such as mail servers might do) the performance might be better. But it
is always the matter of benchmarking your particular case to decide if
it really helps, it is not like this is a general fact that
data=journal implies better performance for fsync heavy writes.

Also note that the even though bandwidth limit might go away (or scale
up significantly) for newer drives like SSD's, the same is true for
seeks, so I guess data=journal would not have any benefits on future
drives. Also as I said those code paths are not as well tested as the
other modes.

Thanks!
-Lukas

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