public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, psusi@ubuntu.com, sandeen@redhat.com
Subject: Re: [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last block group
Date: Mon, 27 Feb 2012 13:05:29 -0500	[thread overview]
Message-ID: <20120227180529.GE1651@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1202271838330.5540@dhcp-27-109.brq.redhat.com>

On Mon, Feb 27, 2012 at 06:57:48PM +0100, Lukas Czerner wrote:
> 
> exactly. I am trying to benefit from the same optimization e2fsck does.
> If the BLOCK_UNINIT is set then we can easily leave that group be and
> save some time. Even though that might not be a huge problem with small
> file systems, or some *really* fast SSD's, you'll certainly notice it on
> huge thin-provisioned storage, or generally any bigger discard capable
> device.

Well, maybe then the right answer is that we make it an option.  There
*are* times when you might want to issue a discard for every single
unused block, even if you think it may have already been discarded.

For example, there are some brain-damaged thin-provisioned storage
boxes that ignore discards that are smaller than 4 megabytes, and then
only discard on 4 megabyte aligned boundaries.  So even though the
space might have been previously discarded, one of the reasons why you
might want e2fsck -E discard to force a discard of the entire block
group is because the space might not have been released if the
previous TRIM commands (perhaps issued as various 1mb files were
deleted) didn't obey whatever arbitrary restrictions that are imposed
by the storage device.

I'll agree that as a default, the optimization might make sense.  But
it would be good if there's a way to really to bypass the optimization
and issue the discard for every single unused block.

    	      	      	  	       - Ted

  reply	other threads:[~2012-02-27 18:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-24  8:34 [RESEND] [PATCH 1/2 v2] e2fsck: Discard only unused parts of inode table Lukas Czerner
2012-02-24  8:34 ` [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last block group Lukas Czerner
2012-02-24 14:46   ` Phillip Susi
2012-02-24 14:57     ` Lukas Czerner
2012-02-24 15:56       ` Phillip Susi
2012-02-24 16:13         ` Lukas Czerner
2012-02-24 16:48           ` Phillip Susi
2012-02-27  7:39             ` Lukas Czerner
2012-02-27 16:35               ` Phillip Susi
2012-02-27 17:00   ` Ted Ts'o
2012-02-27 17:57     ` Lukas Czerner
2012-02-27 18:05       ` Ted Ts'o [this message]
2012-02-27 18:33         ` Lukas Czerner

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=20120227180529.GE1651@thunk.org \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=psusi@ubuntu.com \
    --cc=sandeen@redhat.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