linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] mke2fs: use lazy inode init on some discard-able devices
Date: Mon, 23 Aug 2010 09:32:40 -0500	[thread overview]
Message-ID: <4C728688.6080007@redhat.com> (raw)
In-Reply-To: <D416033E-58F9-46F8-B8B0-546C949CB6BE@mit.edu>

Theodore Tso wrote:
> On Aug 20, 2010, at 5:41 PM, Eric Sandeen wrote:
> 
>> If a device supports discard -and- returns 0s for discarded blocks,
>> then we can skip the inode table initialization -and- the inode table
>> zeroing at mkfs time, and skip the lazy init as well since they are
>> already zeroed out.
>> 
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> 
> This needs to be configurable in /etc/mke2fs.conf.  Without naming 
> the manufacturer, I'm aware of at least one device which claims that
> discard works, and will even return zeros --- but after a power
> cycle, if the block has not been reallocated, will once again return
> the old, pre-discard values that had been stored in that block.
> 
> In other words, the discard is not power-cycle persistent...
> 
> -- Ted
> 
> 

yes, I've seen issues like that too.

TBH in that case I'd rather just drop the patch than make another
tunable for the user to figure out...

Making tunables for every permutation of broken hardware doesn't 
scale IMHO. Users will get it wrong often as not, if they even know 
it's there (they'll find out it's there via some web forum or other, 
and it'll become a meme like "set this to go faster" rather than 
understanding all the implications.)

-Eric

  reply	other threads:[~2010-08-23 14:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20 21:41 [PATCH] mke2fs: use lazy inode init on some discard-able devices Eric Sandeen
2010-08-23 10:49 ` Theodore Tso
2010-08-23 14:32   ` Eric Sandeen [this message]
2010-08-24  0:27     ` Andreas Dilger
2010-09-20 13:23 ` Ted Ts'o
2010-09-21  5:15   ` Andreas Dilger
2010-09-21 16:01     ` Eric Sandeen

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=4C728688.6080007@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).