On Thursday 08 March 2001 13:42, Goswin Brederlow wrote:
> > " " == Pavel Machek <[EMAIL PROTECTED]> writes:
> > Hi!
> >
> >> I was hoping to point out that in real life, most systems that
> >> need to access large numbers of files are already designed to
> >> do some
> " " == Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>> I was hoping to point out that in real life, most systems that
>> need to access large numbers of files are already designed to
>> do some kind of hashing, or at least to divide-and-conquer by
>> using
== Pavel Machek [EMAIL PROTECTED] writes:
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to
do some kind of hashing, or at least to divide-and-conquer by
using multi-level directory
On Thursday 08 March 2001 13:42, Goswin Brederlow wrote:
== Pavel Machek [EMAIL PROTECTED] writes:
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to
do some kind of hashing, or at
Le 12 Mar 2001 21:05:58 +1100, Herbert Xu a écrit :
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
> > . -name "12*" | xargs rm, which has terrible issues with files names
>
> Try
>
> printf "%s\0" 12* | xargs -0 rm
Or
Pavel Machek <[EMAIL PROTECTED]> wrote:
> xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
> . -name "12*" | xargs rm, which has terrible issues with files names
Try
printf "%s\0" 12* | xargs -0 rm
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:
Pavel Machek [EMAIL PROTECTED] wrote:
xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
. -name "12*" | xargs rm, which has terrible issues with files names
Try
printf "%s\0" 12* | xargs -0 rm
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu
Le 12 Mar 2001 21:05:58 +1100, Herbert Xu a crit :
Pavel Machek [EMAIL PROTECTED] wrote:
xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
. -name "12*" | xargs rm, which has terrible issues with files names
Try
printf "%s\0" 12* | xargs -0 rm
Or find -print0
[EMAIL PROTECTED] (Bill Crawford) wrote on 22.02.01 in
<[EMAIL PROTECTED]>:
> A particular reason for this, apart from filesystem efficiency,
> is to make it easier for people to find things, as it is usually
> easier to spot what you want amongst a hundred things than among
> a thousand or
In article <003701c0a722$f6b02700$5517fea9@local>,
Manfred Spraul <[EMAIL PROTECTED]> wrote:
>
>exec_mmap currenly avoids mm_alloc()/activate_mm()/mm_drop() for single
>threaded apps, and that would become impossible.
>I'm not sure how expensive these calls are.
They aren't that expensive:
From: "Jamie Lokier" <[EMAIL PROTECTED]>
> Manfred Spraul wrote:
> > I'm not sure that this is the right way: It means that every exec()
> > must call dup_mmap(), and usually only to copy a few hundert
> > bytes. But I don't see a sane alternative. I won't propose to
> > create a temporary file
Manfred Spraul wrote:
> I'm not sure that this is the right way: It means that every exec() must
> call dup_mmap(), and usually only to copy a few hundert bytes. But I
> don't see a sane alternative. I won't propose to create a temporary file
> in a kernel tmpfs mount ;-)
Every exec creates a
Jamie wrote:
> Linus Torvalds wrote:
> > The long-term solution for this is to create the new VM space for
the
> > new process early, and add it to the list of mm_struct's that the
> > swapper knows about, and then just get rid of the
pages[MAX_ARG_PAGES]
> > array completely and instead just
Linus Torvalds wrote:
> The long-term solution for this is to create the new VM space for the
> new process early, and add it to the list of mm_struct's that the
> swapper knows about, and then just get rid of the pages[MAX_ARG_PAGES]
> array completely and instead just populate the new VM
Linus Torvalds wrote:
The long-term solution for this is to create the new VM space for the
new process early, and add it to the list of mm_struct's that the
swapper knows about, and then just get rid of the pages[MAX_ARG_PAGES]
array completely and instead just populate the new VM directly.
Jamie wrote:
Linus Torvalds wrote:
The long-term solution for this is to create the new VM space for
the
new process early, and add it to the list of mm_struct's that the
swapper knows about, and then just get rid of the
pages[MAX_ARG_PAGES]
array completely and instead just populate
Manfred Spraul wrote:
I'm not sure that this is the right way: It means that every exec() must
call dup_mmap(), and usually only to copy a few hundert bytes. But I
don't see a sane alternative. I won't propose to create a temporary file
in a kernel tmpfs mount ;-)
Every exec creates a whole
From: "Jamie Lokier" [EMAIL PROTECTED]
Manfred Spraul wrote:
I'm not sure that this is the right way: It means that every exec()
must call dup_mmap(), and usually only to copy a few hundert
bytes. But I don't see a sane alternative. I won't propose to
create a temporary file in a kernel
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Pavel Machek wrote:
>> > the space allowed for arguments is not a userland issue, it is a kernel
>> > limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
>> > wanted to without breaking any userland.
Pavel Machek wrote:
> > the space allowed for arguments is not a userland issue, it is a kernel
> > limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
> > wanted to without breaking any userland.
>
> Which is exactly what I done on my system. 2MB for command line is
> very
Pavel Machek wrote:
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to without breaking any userland.
Which is exactly what I done on my system. 2MB for command line is
very nice.
In article [EMAIL PROTECTED],
Jamie Lokier [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to without breaking any userland.
Which is
Pavel Machek wrote:
> Hi!
> > I was hoping to point out that in real life, most systems that
> > need to access large numbers of files are already designed to do
> > some kind of hashing, or at least to divide-and-conquer by using
> > multi-level directory structures.
> Yes -- because their
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote:
>
> xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
> . -name "12*" | xargs rm, which has terrible issues with files names
>
> "xyzzy"
> "bla"
> "xyzzy bla"
> "12 xyzzy bla"
>
Getting a bit OffTopic(TM) here,
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > * 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
On 2 Mar 2001, Oystein Viggen wrote:
> Pavel Machek wrote:
> > xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
> These you work around using the smarter, \0 terminated, version:
Another example demonstrating why xargs is not always good (and why a
bigger command line is
Pavel Machek wrote:
> xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
> . -name "12*" | xargs rm, which has terrible issues with files names
>
> "xyzzy"
> "bla"
> "xyzzy bla"
> "12 xyzzy bla"
These you work around using the smarter, \0 terminated, version:
find . -name
Hi!
> > > * 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.
>
> I _really_ don't want to trust the
Hi!
> > > I was hoping to point out that in real life, most systems that
> > > need to access large numbers of files are already designed to do
> > > some kind of hashing, or at least to divide-and-conquer by using
> > > multi-level directory structures.
> >
> > Yes -- because their workaround
Hi!
> > * userland issues (what, you thought that limits on the
> > command size will go away?)
>
> the space allowed for arguments is not a userland issue, it is a kernel
> limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
> wanted to without breaking any userland.
Hi!
* userland issues (what, you thought that limits on the
command size will go away?)
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to without breaking any userland.
Which
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to do
some kind of hashing, or at least to divide-and-conquer by using
multi-level directory structures.
Yes -- because their workaround kernel
Hi!
* 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.
I _really_ don't want to trust the ability of
Pavel Machek wrote:
xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
. -name "12*" | xargs rm, which has terrible issues with files names
"xyzzy"
"bla"
"xyzzy bla"
"12 xyzzy bla"
These you work around using the smarter, \0 terminated, version:
find . -name "12*"
On 2 Mar 2001, Oystein Viggen wrote:
Pavel Machek wrote:
xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
These you work around using the smarter, \0 terminated, version:
Another example demonstrating why xargs is not always good (and why a
bigger command line is
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote:
Hi!
* 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
On Fri, Mar 02, 2001 at 10:04:10AM +0100, Pavel Machek wrote:
xargs is very ugly. I want to rm 12*. Just plain "rm 12*". *Not* "find
. -name "12*" | xargs rm, which has terrible issues with files names
"xyzzy"
"bla"
"xyzzy bla"
"12 xyzzy bla"
Getting a bit OffTopic(TM) here, but
Pavel Machek wrote:
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to do
some kind of hashing, or at least to divide-and-conquer by using
multi-level directory structures.
Yes -- because their workaround
H. Peter Anvin writes [re hashed directories]:
> I don't see there being any fundamental reason to not do such an
> improvement, except the one Alan Cox mentioned -- crash recovery --
> (which I think can be dealt with; in my example above as long as the leaf
> nodes can get recovered, the tree
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
Alexander Viro wrote:
>
> I _really_ don't want to trust the ability of shell to deal with long
> command lines. I also don't like the failure modes with history expansion
> causing OOM, etc.
>
> AFAICS right now we hit the kernel limit first, but I really doubt that
> raising said limit is a
On Thu, 1 Mar 2001, 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.
I
On Thu, 1 Mar 2001, Alexander Viro wrote:
> * userland issues (what, you thought that limits on the
> command size will go away?)
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to
Alexander Viro wrote:
> >
> > Yes -- because their workaround kernel slowness.
>
> Pavel, I'm afraid that you are missing the point. Several, actually:
> * limits of _human_ capability to deal with large unstructured
> sets of objects
Not an issue if you're a machine.
> *
On Sat, 1 Jan 2000, Pavel Machek wrote:
> Hi!
>
> > I was hoping to point out that in real life, most systems that
> > need to access large numbers of files are already designed to do
> > some kind of hashing, or at least to divide-and-conquer by using
> > multi-level directory structures.
>
Hi!
> I was hoping to point out that in real life, most systems that
> need to access large numbers of files are already designed to do
> some kind of hashing, or at least to divide-and-conquer by using
> multi-level directory structures.
Yes -- because their workaround kernel slowness.
I had
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to do
some kind of hashing, or at least to divide-and-conquer by using
multi-level directory structures.
Yes -- because their workaround kernel slowness.
I had to
On Sat, 1 Jan 2000, Pavel Machek wrote:
Hi!
I was hoping to point out that in real life, most systems that
need to access large numbers of files are already designed to do
some kind of hashing, or at least to divide-and-conquer by using
multi-level directory structures.
Yes --
Alexander Viro wrote:
Yes -- because their workaround kernel slowness.
Pavel, I'm afraid that you are missing the point. Several, actually:
* limits of _human_ capability to deal with large unstructured
sets of objects
Not an issue if you're a machine.
* userland
On Thu, 1 Mar 2001, Alexander Viro wrote:
* userland issues (what, you thought that limits on the
command size will go away?)
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to
On Thu, 1 Mar 2001, 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.
I _really_
Alexander Viro wrote:
I _really_ don't want to trust the ability of shell to deal with long
command lines. I also don't like the failure modes with history expansion
causing OOM, etc.
AFAICS right now we hit the kernel limit first, but I really doubt that
raising said limit is a good
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
H. Peter Anvin writes [re hashed directories]:
I don't see there being any fundamental reason to not do such an
improvement, except the one Alan Cox mentioned -- crash recovery --
(which I think can be dealt with; in my example above as long as the leaf
nodes can get recovered, the tree can
"H. Peter Anvin" wrote:
> Bill Crawford wrote:
...
> > We use Solaris and NFS a lot, too, so large directories are a bad
> > thing in general for us, so we tend to subdivide things using a
> > very simple scheme: taking the first letter and then sometimes
> > the second letter or a pair of
Bill Crawford wrote:
>
> A particular reason for this, apart from filesystem efficiency,
> is to make it easier for people to find things, as it is usually
> easier to spot what you want amongst a hundred things than among
> a thousand or ten thousand.
>
> A couple of practical examples from
Bill Crawford wrote:
A particular reason for this, apart from filesystem efficiency,
is to make it easier for people to find things, as it is usually
easier to spot what you want amongst a hundred things than among
a thousand or ten thousand.
A couple of practical examples from work
"H. Peter Anvin" wrote:
Bill Crawford wrote:
...
We use Solaris and NFS a lot, too, so large directories are a bad
thing in general for us, so we tend to subdivide things using a
very simple scheme: taking the first letter and then sometimes
the second letter or a pair of letters from
58 matches
Mail list logo
