linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/4 v2] ext4: Do not discard group with BLOCK_UNINIT set
Date: Wed, 7 Mar 2012 12:22:20 -0500	[thread overview]
Message-ID: <20120307172220.GC11457@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1203070807220.5117@dhcp-27-109.brq.redhat.com>

On Wed, Mar 07, 2012 at 08:10:00AM +0100, Lukas Czerner wrote:
> 
> Ok, if there is a plan to implement that, I am fine with dropping th
> patches. But since this optimization would be helpful for discard, we
> can introduce BLOCK_DISCARDED/UNPROVISIONED flag maybe ? Which would be
> sen only after discard and cleared with the first allocation ?

Heh, great minds think alike.  I was thinking about a the possibility
of having a BLOCK_DISCARDED flag this morning, with exactly the
semantics that you are suggesting.  There may be devices in the future
that have fast trims which will prefer to always get the duplicate
trim requests, but there is no question there are a lot of crappy
devices out there right now where trims are extremely expensive, so
that seems fair.

Something else to think about for the future, for battery driven
devices (such as handsets) automatically sending tirm commands might
not be a good idea when the device is sleeping/has the screen turned
off.  Given that we don't have an easy way of determining whether or
not the device is in a low powered state (ideally we only send the
trims right after work has been queued to the device, so it's woken up
already, but when there isn't anything else that needs to be sent to
the device).

					- Ted

  reply	other threads:[~2012-03-07 17:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-02 12:11 [PATCH 1/4 v2] ext4: fix start and len arguments handling in ext4_trim_fs() Lukas Czerner
2012-03-02 12:11 ` [PATCH 2/4 v2] ext4: Fix trimmed block count computing Lukas Czerner
2012-03-05 12:38   ` Jan Kara
2012-03-22  1:22     ` Ted Ts'o
2012-03-02 12:11 ` [PATCH 3/4 v2] ext4: Always set then trimmed blocks count into len Lukas Czerner
2012-03-05 12:38   ` Jan Kara
2012-03-22  1:23     ` Ted Ts'o
2012-03-02 12:11 ` [PATCH 4/4 v2] ext4: Do not discard group with BLOCK_UNINIT set Lukas Czerner
2012-03-05 12:41   ` Jan Kara
2012-03-05 13:12     ` Lukas Czerner
2012-03-06 22:18   ` Ted Ts'o
2012-03-07  7:10     ` Lukas Czerner
2012-03-07 17:22       ` Ted Ts'o [this message]
2012-03-05 12:37 ` [PATCH 1/4 v2] ext4: fix start and len arguments handling in ext4_trim_fs() Jan Kara
2012-03-22  1:22   ` Ted Ts'o

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=20120307172220.GC11457@thunk.org \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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).