This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: statvfs suggestion

From: Jim Meyering <jim at meyering dot net>
To: Ulrich Drepper <drepper at redhat dot com>
Cc: libc-hacker at sources dot redhat dot com,Aharon Robbins <arnold at skeeve dot com>
Date: Wed, 17 Sep 2003 14:00:43 +0200
Subject: Re: statvfs suggestion
References: <200309021423.h82ENWrV018980@skeeve.com><85isobj8b5.fsf@pi.meyering.net> <85smmx5ccp.fsf_-_@pi.meyering.net><3F67AFD9.5010007@redhat.com>

Ulrich Drepper <drepper@redhat.com> wrote:
> Jim Meyering wrote:
>> What do you think about changing internal_statvfs.c so that it first
>> reads/saves all entries from /proc/mounts without stat'ing each
>> corresponding directory?  Then it can stop if any mount point matches
>> the name of the file.
>
> This really is no solution.  The name passed to statvfs need not be the
> actual mount point.  And what about fstatvfs where we don't have a name?
>
> I added some code which cuts down on the number of stats by comparing
> another value we know must match: the filesystem name.
>
> While doing this, though, I found that adding additional tests for the
> name comparison isn't any more work so I added this as well.  It's no
> solution, but it might help in one situation or another.  The result is
> in CVS.

Thanks for doing that.  IMHO any change that converts an O(N^2)
process into an O(N) one is more than a partial solution :-)

References:
- statvfs suggestion
  - From: Jim Meyering
- Re: statvfs suggestion
  - From: Ulrich Drepper

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]