linux-ext4 - Re: process hangs in ext4_sync

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: <20131029170435.GA7681@infradead.org>
Date:	Tue, 29 Oct 2013 10:04:35 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Jan Kara <jack@...e.cz>
Cc:	Sandeep Joshi <sanjos100@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: process hangs in ext4_sync_file

On Tue, Oct 29, 2013 at 03:46:49PM +0100, Jan Kara wrote:
>   No, it isn't really recommended for ordinary SSDs. If you have one of
> those fancy PCIe attached SSDs, 'discard' option might be useful for you
> but for usual SATA attached ones it's usually a disaster. There you might
> be better off running 'fstrim' command once a week or something like that.

While some early consumer SSDs were indeed pretty bad just by
theselves, and the lack of queue TRIM on most devices doesn't help,
these days the biggest blame is with Linux itself.  Not only can't we
merge multiple requests into a single ranged TRIM, but we also execute
them all synchronously, meaning a constant stream of queue drains if
the discard option is used.

Once we've fixed those issue we can start blaming those vendors that
have issues again, but until that has happened we'd better shut up..

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