From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Attempt at "stat light" implementation Date: Sun, 12 Apr 2009 21:55:05 +0100 Message-ID: <20090412205505.GJ4394@shareable.org> References: <20090407062356.GA1336463@fiona.linuxhacker.ru> <20090407173248.GC31824@shareable.org> <49DB8F8E.9010605@garzik.org> <20090407175617.GF31824@shareable.org> <20090407182157.GW3204@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , Jeff Garzik , Oleg Drokin , linux-fsdevel@vger.kernel.org, LKML To: Ulrich Drepper Return-path: Received: from mail2.shareable.org ([80.68.89.115]:58810 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753412AbZDLUzJ (ORCPT ); Sun, 12 Apr 2009 16:55:09 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Ulrich Drepper wrote: > As for making the interface extendable. In all the years there hasn't > really been much need to extend the stat structure (ignoring extended > attributes). So, I'd not be worried about using a simple 32-bit > bitmask to select the fields to include in the fast stat. I agree about 32 bits being enough. I think there has been some demand for new fields, but it's not been strong enough to justify all the breakage from changing the normal stat structure. That's why we have generic filesystem ioctls: FS_IOC_GETFLAGS, FS_IOC_GETVERSION, which return things which would naturally go with stat if it were free to do so (but it isn't). -- Jamie