Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbbEEWJb (ORCPT ); Tue, 5 May 2015 18:09:31 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:35869 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751611AbbEEWJ1 (ORCPT ); Tue, 5 May 2015 18:09:27 -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> Date: Tue, 05 May 2015 18:09:18 -0400 In-Reply-To: <55493AC1.9090408@fb.com> (Jens Axboe's message of "Tue, 5 May 2015 15:48:49 -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: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1652 Lines: 36 >>>>> "Jens" == Jens Axboe writes: Jens> I'm not trying to make a shortcut. I deliberately do not want to Jens> make ID generation/assignment part of the kernel. There's no Jens> reason that can't exist outside of the kernel, in a libstreamid or Jens> similar. That just perpetuates the broken model, though. Why wouldn't we want to have stream ids readily available inside the kernel to tag journals, filesystem metadata, data migration, who knows what? Having storage micromanage the stream IDs is a non-starter. And it'll also break things like software RAID, btrfs, LVM, anything that involves multiple devices. ID X on first RAID disk then needs to be mapped to ID Y on the second, etc. The only sensible solution is for the kernel to manage the stream IDs. And for them to be plentiful. The storage device is free to ignore them, do LRU or whatever it pleases to manage them if it has an internal limit on number of open streams, etc. Jens> The current API doesn't have any real limits (it'll work from Jens> 1..MAX_UINT), and the transport part handles 255 streams at the Jens> moment. The latter can be easily extended, we can just steal a few Jens> more bits. Making it 1023 would be a one liner. I'm not so worried about the implementation. I'm more worried about it being conducive to the broken proposal that's on the table. -- 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/