Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752334AbbELCug (ORCPT ); Mon, 11 May 2015 22:50:36 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:23542 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbbELCue (ORCPT ); Mon, 11 May 2015 22:50:34 -0400 To: Jens Axboe Cc: "Martin K. Petersen" , Jeff Moyer , , , , Subject: Re: [PATCH v2] Support for write stream IDs From: "Martin K. Petersen" Organization: Oracle Corporation References: <1430856181-19568-1-git-send-email-axboe@fb.com> <55493097.6040007@fb.com> <55493AC1.9090408@fb.com> <554A4DB7.7070202@fb.com> <554D0502.1080808@fb.com> Date: Mon, 11 May 2015 22:50:24 -0400 In-Reply-To: <554D0502.1080808@fb.com> (Jens Axboe's message of "Fri, 8 May 2015 12:48:34 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2925 Lines: 65 >>>>> "Jens" == Jens Axboe 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/