linux-kernel - Re: [PATCH v2] Support for write stream IDs

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]

Message-ID: <yq1d226mrv3.fsf@sermon.lab.mkp.net>
Date:	Mon, 11 May 2015 22:50:24 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Jens Axboe <axboe@...com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Jeff Moyer <jmoyer@...hat.com>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <adilger@...ger.ca>,
	<david@...morbit.com>
Subject: Re: [PATCH v2] Support for write stream IDs

>>>>> "Jens" == Jens Axboe <axboe@...com> writes:

Jens,

Jens> There are actual technical challenges on the device side that
Jens> sometimes interferes. [...]

Right now we use the same protocol to speak to USB keys and million
dollar storage arrays. That's because the protocol was designed to be
abstract and completely device agnostic.

What's happening with flash devices and SMR is that all of a sudden
device implementation challenges are being addressed by putting them in
the protocol and punting them to the OS.

That's an obvious and cost-saving approach for a device vendor to take.
But the world would be a different place if we were still dealing with
MFM, RLL, C/H/S addressing and other implementation-specific horrors of
the past. And if that approach had continued we would explicitly have to
deal with erase blocks on USB sticks and manually drive RAID logic
inside disk arrays. But thankfully, with a few exceptions, we didn't go
there.

My beef with the current stream ID stuff and ZAC/ZBC is that those are
steps in the wrong direction in that they are both exclusively focused
on addressing implementation challenges specific to certain kinds of
devices.

The notion of letting the OS tag things as belonging together or being
independent is a useful concept that benefits *any* kind of device.
Those tags can easily be mapped to resource streams in a flash device or
a particular zone cache segment on an SMR drive or in an array.

I would just like the tag to be completely arbitrary so we can manage it
on behalf of all applications and devices. That puts the burden on the
device to manage the OS tag to internal resource mapping but I think
that's a small price to pay to have a concept that works for all classes
of devices, software RAID, etc.

This does not in any way preclude the device communicating "I'd prefer
if you only kept 8 streams going/8 zones open" like we do with all the
other device characteristics. My gripe is that the programming model is
being forcefully changed so we now have to get a permit before
submitting an I/O. And very aggressively clean up since the permits are
being envisioned as super scarce.

Jens> The reality is that we can't demand that devices support thousands
Jens> of streams.

Why not? It's just a number. Tracking a large number of independent
streams hasn't been a problem for storage arrays. Nobody says a 32-bit
ID requires you to concurrently track bazillions of streams. Pick a
reasonable number of live contexts given your device's actual resources.

Jens> The write streams proposal was already approved by t10...

Nope. It's still being discussed.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
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/