From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulrich Drepper Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Sun, 17 Dec 2006 11:07:27 -0800 Message-ID: <4585956F.80404@redhat.com> References: <20061205100748.GC5871@infradead.org> <4575E9B0.3060908@mcs.anl.gov> <20061205220538.GA1988@infradead.org> <45760702.6040805@redhat.com> <20061206100614.GX5937@schatzie.adilger.int> <4576FBB0.2070704@redhat.com> <4576FD78.4040603@mcs.anl.gov> <4577011F.6040107@redhat.com> <20061206180124.GM17226@vestdata.no> <45770850.4030003@redhat.com> <20061217144130.GN25199@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Rob Ross , Christoph Hellwig , Trond Myklebust , Sage Weil , Brad Boyer , Anton Altaparmakov , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:44421 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932453AbWLQTH4 (ORCPT ); Sun, 17 Dec 2006 14:07:56 -0500 To: =?UTF-8?B?UmFnbmFyIEtqw7hyc3RhZA==?= In-Reply-To: <20061217144130.GN25199@vestdata.no> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Ragnar Kj=C3=B8rstad wrote: > I think Andreas already wrote that "ls --color" is the default in mos= t > distributions and needs to stat every file. Remove the :ex entry from LS_COLORS and try again. > "find" is already smart enough to not call stat when it's not needed, > and make use of d_type when it's available. But in many cases stat is > still needed (such as with -user) >=20 > find kernel_old -not -user 1002: > 83.63% 173.11s 0.319ms 543338 lstat > 16.31% 33.77s 5.242ms 6442 getdents64 > 0.03% 0.06s 62.882ms 1 execve > 0.01% 0.03s 6.904ms 4 poll > 0.01% 0.02s 8.383ms 2 connect And how often do the scripts which are in everyday use require such a=20 command? And the same for the other programs. I do not doubt that such a new syscall can potentially be useful. The=20 question is whether it is worth it given _real_ situations on today's=20 systems. And more so: on systems where combining the operations really= =20 makes a difference. Exposing new data structures is no small feat. It's always risky since= =20 something might require a change and then backward compatibility is an=20 issue. Introducing new syscalls just because a combination of two existing one= s=20 happens to be used in some programs is not scalable and not the=20 Unix-way. Small building blocks. Otherwise I'd have more proposals=20 which can be much more widely usable (e.g., syscall to read a file into= =20 a freshly mmaped area). Nobody wants to go that route since it would=20 lead to creeping featurism. So it is up to the proponents of=20 readdirplus to show this is not such a situation. --=20 =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro S= t =E2=9E=A7 Mountain View, CA =E2=9D=96 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html