linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, Sandeep Joshi <sanjos100@gmail.com>,
	linux-ext4@vger.kernel.org
Subject: Re: process hangs in ext4_sync_file
Date: Tue, 29 Oct 2013 18:53:19 +0100	[thread overview]
Message-ID: <20131029175319.GC6087@quack.suse.cz> (raw)
In-Reply-To: <20131029170435.GA7681@infradead.org>

On Tue 29-10-13 10:04:35, Christoph Hellwig wrote:
> 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..
  OK, right. I've checked the spec and indeed the original TRIM
specification already allows for several ranges in one trim command which
we aren't able to use. I thought the multi-range thing was only a recent
addition. Next time I'll be blaming our block layer then ;) Thanks for
correction.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2013-10-29 17:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 12:39 process hangs in ext4_sync_file Sandeep Joshi
2013-10-21 12:57 ` Zheng Liu
2013-10-22  3:24   ` Sandeep Joshi
2013-10-22  8:45     ` Sandeep Joshi
2013-10-23 10:20 ` Jan Kara
2013-10-23 14:58   ` Sandeep Joshi
2013-10-24  3:54     ` Zheng Liu
2013-10-29  5:36     ` Sandeep Joshi
     [not found]     ` <CAEfL3KmAXw+mE24kZkG4YHU3C98rU6pkbAwMhSO1pw1rg81HVw@mail.gmail.com>
2013-10-29 14:46       ` Jan Kara
2013-10-29 15:00         ` Sandeep Joshi
2013-10-29 15:26           ` Jan Kara
2013-10-29 17:04         ` Christoph Hellwig
2013-10-29 17:53           ` Jan Kara [this message]
2014-01-06 10:28 ` Sandeep Joshi
2014-01-06 14:32   ` Theodore Ts'o
2014-01-06 15:08     ` Sandeep Joshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131029175319.GC6087@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sanjos100@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).