From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: Attempt at "stat light" implementation Date: Tue, 07 Apr 2009 11:22:25 -0400 Message-ID: <49DB6FB1.1060504@hp.com> References: <20090407062356.GA1336463@fiona.linuxhacker.ru> <20090407102340.GT3204@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleg Drokin , linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from g4t0015.houston.hp.com ([15.201.24.18]:35160 "EHLO g4t0015.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761342AbZDGPXn (ORCPT ); Tue, 7 Apr 2009 11:23:43 -0400 In-Reply-To: <20090407102340.GT3204@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Sorry our travel budget didn't allow me to be there for the spirited discussion ;) I don't have anything against a selective stat function except that it adds extra conditional code that my experience says won't be much benefit. We have a selective getattr in Tru64 for clusters with the same idea that it would save a lot of expensive operations in the cluster. It did *not*. The problems are: - applications are not smart (except maybe on luster). - applications find it easier and usually faster to get all the stat info and sort it themselves, particularly when they are tested exclusively on local systems. - who is going to fix (and keep fixed) those gui file managers (and stop users from "ls -l" or viewing properties)? - even internal kernel getattrs would often make a "light" call, then the next operation needed the "heavy" attrs, so we sent 2 RPCs instead of 1 and had to do a lot more complicated local attr cache management of what fields were valid in cache and what were not. And I spent a lot of time fixing attr cache and cluster locking problems in the cluster FS and NFS code. So by trying to save expensive operations, it made it worse. One practical suggestion: for fields that were not requested, we sent back the "illegal/ignore" (usually -1) value that could be used in a subsequent setattr. jim