From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via lazy hashing) Date: Wed, 29 Nov 2006 15:33:26 -0500 Message-ID: <456DEE96.6060008@poochiereds.net> References: <4569980E.4020804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ms-smtp-01.southeast.rr.com ([24.25.9.100]:36062 "EHLO ms-smtp-01.southeast.rr.com") by vger.kernel.org with ESMTP id S967642AbWK2Ud3 (ORCPT ); Wed, 29 Nov 2006 15:33:29 -0500 Received: from mail.poochiereds.net (cpe-071-070-159-068.nc.res.rr.com [71.70.159.68]) by ms-smtp-01.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kATKXRCp001184 for ; Wed, 29 Nov 2006 15:33:27 -0500 (EST) Received: from [192.168.1.3] (tleilax.poochiereds.net [192.168.1.3]) by mail.poochiereds.net (Postfix) with ESMTP id 18662C0126 for ; Wed, 29 Nov 2006 15:33:27 -0500 (EST) To: linux-fsdevel@vger.kernel.org In-Reply-To: <4569980E.4020804@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jeff Layton wrote: > Here is a different approach to the problem of i_ino uniqueness. Again, > I'll refer to my original email and patch for a description of the > problem... > > With this patch, I'm taking the approach of only assigning out an i_ino > value when it's actually needed. This adds a lazy_getattr function. If > i_ino is 0, then this does an iunique and hashes the inode before doing > the actual getattr. > Actually, after having a closer look at this, I don't think this turns out to be feasible either. Some filesystems (including pipefs) want an i_ino value early on for generating the qstr passed to d_alloc. Since they want the value so early, there would be little benefit in attempting to delay assigning an i_ino value. It might be a win for some filesystems, but ones like pipefs and sockfs wouldn't be able to use this scheme, and those are the ones we're primarily concerned with performance-wise. I'm going to plan to clean up my IDR patch and resubmit it, as I think it's probably the best scheme we have that seems to actually fix the problem. Unless someone else has a better idea... :-) -- Jeff