From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Ric Wheeler <ricwheeler@gmail.com>,
Lukas Czerner <lczerner@redhat.com>,
linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] e2fsck: Discard free data and inode blocks.
Date: Fri, 22 Oct 2010 13:29:41 -0500 [thread overview]
Message-ID: <4CC1D815.2000808@redhat.com> (raw)
In-Reply-To: <386E61B0-BF4D-4F96-9541-A614F63DE808@dilger.ca>
Andreas Dilger wrote:
> On 2010-10-22, at 08:46, Ric Wheeler wrote:
>> On 10/22/2010 10:32 AM, Lukas Czerner wrote:
>>> Also there is a big win, when discard also zeroes data, because
>>> in that case we can just skip inode table initialization
>>> (zeroing) without any need of in-kernel lazyinit code enabled.
>>> And we get all this for free. It was introduced with Sandeens
>>> patch:
>>>
>>> http://marc.info/?l=linux-ext4&m=128234048208327&w=2
>>>
>>> So, I would rather leave it on by default.
>> You cannot 100% depend on discard zeroing blocks - that is not a
>> universal requirement of devices that support it. Specifically, for
>> ATA devices, I think that there are optional bits that specify how
>> a device will behave when you read from a trimmed region.
>
> That patch also checks for the zeroing feature. When this patch was
> first under discussion, I proposed that we validate that the device
> is actually zeroed by doing a write a non-zero block to the disk and
> then calling discard+zero for that region, and reading back the block
> and verifying it.
>
> Eric wasn't convinced that was necessary, maybe you can convince him
> more...
*grin* I wouldn't -veto- it, but I think we have to maintain a balance
between defensive programming and trying to handle every possible piece
of buggy hardware by doing too many extra gyrations in the code...
-Eric
> Cheers, Andreas
next prev parent reply other threads:[~2010-10-22 18:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 14:15 [PATCH] e2fsck: Discard free data and inode blocks Lukas Czerner
2010-10-21 18:07 ` Andreas Dilger
2010-10-22 9:12 ` Lukas Czerner
2010-10-22 11:30 ` Ric Wheeler
2010-10-22 11:43 ` Lukas Czerner
2010-10-22 14:12 ` Ric Wheeler
2010-10-22 14:32 ` Lukas Czerner
2010-10-22 14:46 ` Ric Wheeler
2010-10-22 15:37 ` Eric Sandeen
2010-10-22 15:41 ` Ric Wheeler
2010-10-22 17:03 ` Martin K. Petersen
2010-10-22 17:14 ` Ric Wheeler
2010-10-22 17:29 ` Martin K. Petersen
2010-10-22 18:23 ` Eric Sandeen
2010-10-22 17:50 ` Andreas Dilger
2010-10-22 18:01 ` Lukas Czerner
2010-10-22 18:17 ` Andreas Dilger
2010-10-22 18:23 ` Ric Wheeler
2010-10-22 21:19 ` Martin K. Petersen
2010-10-22 18:29 ` Eric Sandeen [this message]
2010-10-22 21:01 ` Martin K. Petersen
2010-10-22 18:00 ` Andreas Dilger
2010-10-22 18:27 ` Eric Sandeen
2010-10-22 18:31 ` Lukas Czerner
-- strict thread matches above, loose matches on Subject: below --
2010-10-11 10:37 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=4CC1D815.2000808@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ricwheeler@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.