linux-ext4 - discard_zeroes

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-next>] [day] [month] [year] [list]

Date:	Mon, 9 Nov 2015 17:08:38 -0600
From:	Eric Sandeen <sandeen@...deen.net>
To:	"Martin K. Petersen" <mkp@....net>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: discard_zeroes_data questions

Hi Martin (and linux-ext4 list...) 

tl;dr:

mke2fs today thinks that if discard_zeroes_data == 1 and a BLKDISCARD ioctl of the whole device succeeds, then we have guarantees that any blocks read back will be full of zero, and we don't need to initialize them to zero.  Is this ok?  (barring crappy hardware, that is).

slightly longer:

Does discard_zeroes_data == 1 mean that a discard *request* will guarantee zeroes on a read, or does it mean that a discard-request-which-actually-was-executed-and-not-ignored-as-just-a-hint will give us back zeroes on a read?  (because UNMAP is a hint, right?  I don't know about SATA trim ...)

I did see 7985090 sd: disable discard_zeroes_data for UNMAP - so I think that for v3.19+, on *scsi*, what e2fsprogs is doing is ok (now).

But I'm wondering about dm-thin and SATA, too, so trying to figure out what discard_zeroes_data really implies.  That after a BLKDISCARD, a read *will* return zeros, or that it'll return zeros *iff* the hint is taken?

I hope that made sense, but I've been communicating badly today.  ;)

Thanks,
-Eric
--
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