linux-kernel - RE: [PATCH 3/3] target/iblock: Add WRITE

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

Date:	Mon, 19 Nov 2012 23:19:28 +0000
From:	"Elliott, Robert (Server Storage)" <Elliott@...com>
To:	Paolo Bonzini <pbonzini@...hat.com>
CC:	Christoph Hellwig <hch@....de>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Christoph Hellwig <hch@...radead.org>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: RE: [PATCH 3/3] target/iblock: Add WRITE_SAME w/ UNMAP=0 emulation
 support



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@...il.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, 19 November, 2012 5:38 AM
> To: Elliott, Robert (Server Storage)
> Cc: Christoph Hellwig; Nicholas A. Bellinger; Christoph Hellwig; target-devel;
> linux-scsi; linux-kernel; Martin K. Petersen
> Subject: Re: [PATCH 3/3] target/iblock: Add WRITE_SAME w/ UNMAP=0
> emulation support
> 
> Il 15/11/2012 21:01, Elliott, Robert (Server Storage) ha scritto:
> > WRITE SAME always has a payload, regardless of the UNMAP bit value.
> >
> > For WRITE SAME with UNMAP=0, it's extremely important; that's how
> > what to write is specified.
> >
> > For WRITE SAME with UNMAP=1, the device server is required to check
> > that the payload matches the data that is returned for unmapped LBAs.
> > lf LBPRZ=1 (read zeros for unmapped LBAs), that means checking that
> > the payload has all zeros.  In sbc3r33, this rule is tucked away in
> > model section 4.7.3.4.3, not the command section 5.41.
> 
> Does that mean that LBPRZ=0, LPBWS=1 is practically an invalid
> combination?  Because there's no real way for the device server to
> perform the check successfully.
>

Yes; that would only be practical if the device server knows the pattern
(e.g., all ones) that it will return for reads of unmapped LBAs. It's not
very useful if the pattern is simply the last content and could differ
for every LBA.

For consumer SSDs, the data returned for unmapped (i.e. trimmed)
LBAs didn't really matter.

For SSDs to be used in RAID arrays, however:
a) non-deterministic data is unworkable (RAID parity would never be right);
b) deterministic data can be accommodated, but the RAID stack needs to read the
LBA after unmapping to see what pattern resulted and recalculate parity, hurting
performance; and
c) deterministic zeros are ideal (0 XOR n = n).



> Paolo
> 
> > I would like to change that rule (it's a nuisance and a performance
> > burden), but that's the current rule going into SBC-3 letter ballot.
> >
> > Changing WRITE SAME with UNMAP=1 to ignore the payload would
> provide
> > essentially the same functionality as changing the UNMAP command to
> > be mandatory, not just a hint; both approaches have been discussed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/