linux-ext4 - Re: [PATCH] mke2fs: use lazy inode init on some discard-able devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Aug 2010 18:27:26 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Theodore Tso <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] mke2fs: use lazy inode init on some discard-able devices

On 2010-08-23, at 08:32, Eric Sandeen wrote:
> 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@...hat.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...
> 
> 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...

What else we discussed is to have mke2fs validate whether the discard+zero works (i.e. write some small non-zero data, discard the whole device, read back previously written data).  Granted it wouldn't handle this "it only fails after a power-cycle" problem, but it should detect gratuitously broken hardware.

That should be sufficiently safe until such a time that inode checksums are available.  Note also that non-zero inode table blocks are only a major problem if some additional corruption causes the itable_uninit numbers to become invalid (e.g. bad group checksum) at which case the old itable blocks will be used.

We also discussed doing this at least for sparse files, which makes a lot of sense for testing in any case, even if the default is not to do this for SSD devices until they smarten up.

Cheers, Andreas

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html