From: Phillip Susi <psusi@ubuntu.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Dave Chinner <david@fromorbit.com>, Tejun Heo <tj@kernel.org>,
Martin 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: Thu, 08 Jan 2015 09:09:47 -0500 [thread overview]
Message-ID: <54AE8FAB.7030702@ubuntu.com> (raw)
In-Reply-To: <6B6B37A7-B853-4E9C-A5EE-EC03555BB539@dilger.ca>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/7/2015 11:58 PM, Andreas Dilger wrote:
>> 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.
>
> That is only partially correct. While it is true that mke2fs sets
> the UNINIT flag at format time, the "lazy" part of that means there
> is a kernel thread still does the zeroing of the inode table
> blocks, but after the filesystem is mounted, for any group that
> does not have the ZEROED flag set. After that point, the "UNINIT"
> flag is an optimization to avoid reading the bitmap and unused
> blocks from disk during allocation.
That is pretty much what I said, except that I was pointing out that
it does not *read* first to see if the disk is already zeroed, as that
would be a waste of time. It just writes out the zeros for block
groups that still have the uninit flag set.
> This is needed in case the group descriptor or inode bitmap is
> corrupted, and e2fsck needs to scan the inode table for in-use
> inodes. We don't want it to find old inodes from before the
> filesystem was formatted.
>
> The ext4_init_inode_table() calls
> sb_issue_zeroout->blkdev_issue_zeroout(), so if the underlying
> storage supported deterministic zeroing of the underlying storage,
> this could be handled very efficiently.
Again, that's pretty much what I said.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJUro+rAAoJENRVrw2cjl5RDcMIAIF/qOjB4FfQ1v1NPLnbYrwa
MeGxmAGIq8ftOlfOpSo8W/Adal4eegPwiBzE/8JciTHli2hZFkboG96lCGLL2GHd
51gqADIcSUmPHleLP3L/MSleFLvOAC4xYWYi00idZF5UVK3tt6m07+T/DCkoku1L
8Yg0BH5rxxRyPMRe3a/Y3WoI3PFFQDiDhz/7PSFH1W6JrEmiZutIDfm/U4h6zFWU
tlNUMyiya8DrJt4katjBTa74EPWdZQjT/dOuUGGslAgOro69ZZQ4jmEXeJGN96Ly
mMhbzkw9mjvSHYWuH2Hf1QlxoMKgq1hxaNbwEtImBzYeQTb9VSqM6BSO1ru0m9M=
=X07B
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-01-08 14:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 2:44 [PATCH] libata: Whitelist SSDs that are known to properly return zeroes after TRIM Martin K. Petersen
2014-12-04 3:02 ` Phillip Susi
2014-12-04 3:24 ` Martin K. Petersen
2014-12-04 3:28 ` Phillip Susi
2014-12-04 3:35 ` Martin K. Petersen
2014-12-04 4:40 ` Phillip Susi
2014-12-05 1:53 ` Martin K. Petersen
2014-12-04 21:49 ` One Thousand Gnomes
2014-12-05 2:46 ` Martin K. Petersen
2014-12-04 17:06 ` Tejun Heo
2014-12-05 2:13 ` Martin K. Petersen
2014-12-05 14:51 ` Tejun Heo
2014-12-10 4:09 ` James Bottomley
2014-12-10 14:29 ` Tejun Heo
2014-12-10 20:34 ` James Bottomley
2014-12-10 21:02 ` Martin K. Petersen
2014-12-12 8:35 ` Ming Lei
2015-01-05 16:28 ` Tejun Heo
2015-01-07 0:05 ` 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
2015-01-08 4:58 ` Andreas Dilger
2015-01-08 14:09 ` Phillip Susi [this message]
2015-01-08 22:31 ` Andreas Dilger
2014-12-10 15:43 ` Tim Small
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=54AE8FAB.7030702@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=adilger@dilger.ca \
--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 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.