All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Crawford <billc@netcomuk.co.uk>
To: "H. Peter Anvin" <hpa@transmeta.com>
Cc: Alexander Viro <viro@math.psu.edu>, Pavel Machek <pavel@suse.cz>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Daniel Phillips <phillips@innominate.de>
Subject: Re: Hashing and directories
Date: Thu, 01 Mar 2001 21:26:23 +0000	[thread overview]
Message-ID: <3A9EBE7F.2DFF728E@netcomuk.co.uk> (raw)
In-Reply-To: <Pine.GSO.4.21.0103011547200.11577-100000@weyl.math.psu.edu> <3A9EB984.C1F7E499@transmeta.com>

 Before I reply: I apologise for starting this argument, or at least
making it worse, and please let me say again that I really would like
to see improvements in directory searching etc. ... my original point
was simply a half-joking aside to the effect that we should not
encourage people to put thousands of files in a single directory ...

"H. Peter Anvin" wrote:

> >         * userland issues (what, you thought that limits on the
> > command size will go away?)

> Last I checked, the command line size limit wasn't a userland issue, but
> rather a limit of the kernel exec().  This might have changed.

 Actually this is also a serious problem.  We have a ticketing system
at work that stores all its data in files in large directories, and I
discovered recently that I can only pass about a tenth of the current
file names on a command line.  Yes, we have xargs, but ...

 Also (this happens to be Solaris on a 8 x 40MHz Sparc system) there
is a significant delay just to read the directory.

> >         * portability

 Also an issue.  Fortunately we store a lot of data on NetApps, so
the performance of the filesystem as such is less of an issue; but,
that means the size of the data transfer across the network involved 
in reading a directory can become an issue too.

> > The point being: applications and users _do_ know better what structure
> > is there. Kernel can try to second-guess them and be real good at that, but
> > inability to second-guess is the last of the reasons why aforementioned
> > strategies are used.

 All good points ...

> However, there are issues where users and applications don't want to
> structure their namespace for the convenience of the kernel, for good or
> bad reasons.

 But there are other reasons (besides the kernel's and filesystems'
handling of directories and name lookups).  I think you're spot on
about the performance issues and on-disk structures, though.

>         -hpa

-- 
/* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */
#include "stddiscl.h"

  parent reply	other threads:[~2001-03-01 21:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-22 23:08 Hashing and directories Bill Crawford
2000-01-01  2:02 ` Pavel Machek
2001-03-01 20:54   ` Alexander Viro
2001-03-01 21:05     ` H. Peter Anvin
2001-03-01 21:13       ` Alexander Viro
2001-03-01 21:24         ` H. Peter Anvin
2001-03-02  9:04         ` Pavel Machek
2001-03-02 12:01           ` Oystein Viggen
2001-03-02 12:26             ` Tobias Ringstrom
2001-03-02 12:58           ` David Weinehall
2001-03-02 19:33           ` Tim Wright
2001-03-12 10:05           ` Herbert Xu
2001-03-12 10:43             ` Xavier Bestel
2001-03-01 21:23       ` Andreas Dilger
2001-03-01 21:26       ` Bill Crawford [this message]
2001-03-01 21:05     ` Tigran Aivazian
2001-03-02  8:56       ` Pavel Machek
2001-03-07  0:37         ` Jamie Lokier
2001-03-07  4:03           ` Linus Torvalds
2001-03-07 13:41             ` Jamie Lokier
2001-03-02  9:00     ` Pavel Machek
2001-03-03  0:03   ` Bill Crawford
2001-03-08 12:42   ` Goswin Brederlow
2001-04-27 16:20     ` Daniel Phillips
2001-02-22 23:22 ` H. Peter Anvin
2001-02-22 23:54   ` Bill Crawford
2001-03-10 11:22 ` Kai Henningsen
  -- strict thread matches above, loose matches on Subject: below --
2001-03-07 15:56 Manfred Spraul
2001-03-07 16:10 ` Jamie Lokier
2001-03-07 16:23   ` Manfred Spraul
2001-03-07 18:21     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A9EBE7F.2DFF728E@netcomuk.co.uk \
    --to=billc@netcomuk.co.uk \
    --cc=hpa@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=phillips@innominate.de \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.