From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:33789 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757489AbcCDUgB (ORCPT ); Fri, 4 Mar 2016 15:36:01 -0500 Subject: Re: [PATCH 03/11] Add support for per-file/inode stream ID To: Shaun Tancheff References: <1457107853-8689-1-git-send-email-axboe@fb.com> <1457107853-8689-4-git-send-email-axboe@fb.com> CC: , , , , From: Jens Axboe Message-ID: <56D9F1AA.7040400@fb.com> Date: Fri, 4 Mar 2016 13:35:54 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 03/04/2016 11:53 AM, Shaun Tancheff wrote: > What do you think of falling back to i_ino for applications which don't > make use of setting stream_id yet? > > Something like this (or using a crc16 instead of the xor hack)? > > static inline unsigned int inode_streamid(struct inode *inode) > { > if (inode) { > if (inode->i_streamid) > return inode->i_streamid; > return ((inode->i_ino >> 16) ^ inode->i_ino) & 0xFFFF; > } > return 0; > } If the device supports a high enough number of concurrently open streams, that might work fine. But if the mask ends up being 0x7, then I think it'll just introduce randomness into the whole thing. But it's something that could be experimented with, certainly. -- Jens Axboe