linux-kernel - Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

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: <20131124001033.56252143@alan.etchedpixels.co.uk>
Date:	Sun, 24 Nov 2013 00:10:33 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	unlisted-recipients:; (no To-header on input)
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

> > And the 520 doesn't claim this feature (look for "enhanced power loss
> > protection" at http://ark.intel.com/products/66248), so that wouldn't
> > explain these results anyway.
> 
> Correct i think intel simply ignores CMD_FLUSH on that drive - no idea 
> why an they fixed this for their 330, 530, DC S3500 (all tested)

You are not as I read the standard allowed to "ignore" it. In fact if you
advertise the property you are obliged to implement it. The late Andre
Hedrick made sure the standard was phrased the way it was to stop it
being abused for benchmarketing. The goal was that anyone cheating would
be non-compliant.

Now its entirely possible to do clever stuff and treat it merely as a
write barrier, providing you can't lose what is queued up. What the actual
drives do I don't know.. all deep magic and not my department.

A second thing to be careful about is that certain kinds of I/O barriers
and atomic write patterns that force lots of commits to flash and erase
cycles are going to wear the drive out faster and I've been told by
manufacturers that drives do respond to such patterns by limiting the
transaction rate in self defence (and presumably in the hope the OS will
then begin to block stuff up better).

Pavel - what is lost/kept over the reset of a device is also fairly
clearly defined in the standard. Much is lost because if you committed a
permanent configuration change that the controller couldnt support you
would be a bit screwed!

If you are driving an SSD I'd work very hard to avoid the need for any
kind of O_SYNC or O_DSYNC type behaviour for exactly the same reason you
avoid uncached memory accesses - the hardware can't do its job properly
without the needed freedom. Use minimal barriers and proper sync points
and your performance will be far higher.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/