Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752571AbbEFQu6 (ORCPT ); Wed, 6 May 2015 12:50:58 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:35591 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752457AbbEFQuv (ORCPT ); Wed, 6 May 2015 12:50:51 -0400 Message-ID: <554A4668.7040804@plexistor.com> Date: Wed, 06 May 2015 19:50:48 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Martin K. Petersen" , Jens Axboe CC: Jeff Moyer , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, adilger@dilger.ca, david@fromorbit.com Subject: Re: [PATCH v2] Support for write stream IDs References: <1430856181-19568-1-git-send-email-axboe@fb.com> <55493097.6040007@fb.com> <55493AC1.9090408@fb.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1533 Lines: 37 On 05/06/2015 01:09 AM, Martin K. Petersen wrote: >>>>>> "Jens" == Jens Axboe writes: <> > > 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. > Sometimes you do not have control over the "storage device" firmware and/or it is already too late. But in such a case the LLD of the device can do the state management (open/close) and translation (LRU). If there are a lot of broken devices with the same small size that need an LRU and/or state, bunch of LLDs can reuse a common library. But hey yes I'm with Martin here. It sounds like a filesystem thing and not an application thing. >From the application side we already have the O_TMP hint and other fadvise hits, but it is more the filesystem policy of what to do with this. Also current proposed solution for application is kind of a layering violation. I set an Id at the filesystem level API: Open a file, set an ID. But I acquire the ID from the block device under the FS. This will never map well. In fact it calls for only a very hard-coded hardware specific application that can use this. Thanks Boaz -- 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/