From: Phillip Susi <psusi@ubuntu.com>
To: Dave Chinner <david@fromorbit.com>, Tejun Heo <tj@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-ide@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] libata: Whitelist SSDs that are known to properly return zeroes after TRIM
Date: Wed, 07 Jan 2015 23:05:03 -0500 [thread overview]
Message-ID: <54AE01EF.8050106@ubuntu.com> (raw)
In-Reply-To: <20150107041537.GH31508@dastard>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/06/2015 11:15 PM, Dave Chinner wrote:
> (e.g. in ext4 inode tables because mkfs used to zero them) if they
> haven't been used, so when it reads them it detects that
> initialisation is needed because the blocks are empty....
No, it knows that the inode table needs initialized because there is a
flag in the group descriptor that says this inode table is still
uninitalized. It never reads the blocks to see if they are full of
zeros. mke2fs sets the flag when it does not initialize the table
with zeros, either by direct writes ( which it doesn't do if
lazy_itable_init is true, which it defaults to these days ), or by
discarding the blocks when the device claims to support deterministic
discard that zeros.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJUrgHvAAoJENRVrw2cjl5RWUUH/076fhOAYW8vRB285cz+UwrE
L7o3uteYa9OctoWZTctWAVueuISJaNsxzmbu04btznETkR/YbkkexpmXRKvYt6RZ
rlCzRLWLTOC4h57jZteczn9pBf0RBeeizU0pEdTdZP/IVxOqA6NDG1qywDCE9A+I
3frFg54alaZ4MCGH0jmPVbVxM6jY3/UhA8DnOoMSlIOXatV1X7UMPK3lMJ4Ih/Yx
e3yDWJjNHjAn88TRAGD6WJ2066t7DBGnLOOF9PscaZNW6f4hbuvEG9teAPk51OfS
cwypcLsk6Mj7WU8cSQ0T/6a7Qx84g9JC6wLR0QZCUCSau6ZfWf3ZuSI26i/Xlfc=
=BRqd
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-01-08 4:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <yq18uiojfq9.fsf@sermon.lab.mkp.net>
[not found] ` <20141204170611.GB2995@htj.dyndns.org>
[not found] ` <yq14mtahmil.fsf@sermon.lab.mkp.net>
[not found] ` <20141205145148.GI4080@htj.dyndns.org>
[not found] ` <1418184578.2121.3.camel@HansenPartnership.com>
[not found] ` <20141210142927.GA6294@htj.dyndns.org>
[not found] ` <yq1oarbcj6f.fsf@sermon.lab.mkp.net>
[not found] ` <20150105162830.GP15833@htj.dyndns.org>
2015-01-07 0:05 ` [PATCH] libata: Whitelist SSDs that are known to properly return zeroes after TRIM Martin K. Petersen
2015-01-07 2:54 ` Tejun Heo
2015-01-07 4:15 ` Dave Chinner
2015-01-07 15:26 ` Tejun Heo
2015-01-08 14:28 ` Martin K. Petersen
2015-01-08 15:11 ` Tejun Heo
2015-01-08 15:34 ` Martin K. Petersen
2015-01-08 15:36 ` Tejun Heo
2015-01-08 15:58 ` Tim Small
2015-01-09 20:52 ` Martin K. Petersen
2015-01-09 21:39 ` Tejun Heo
2015-01-08 14:29 ` Martin K. Petersen
2015-01-08 4:05 ` Phillip Susi [this message]
2015-01-08 4:58 ` Andreas Dilger
2015-01-08 14:09 ` Phillip Susi
2015-01-08 22:31 ` Andreas Dilger
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=54AE01EF.8050106@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=tj@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).