From [EMAIL PROTECTED] Mon Dec 18 11:34:14 2000
On Nov 17, Linus Torvalds wrote:
> ...
better you'd have tested it;) while Andries' patch works fine (2 CDs of
data copied and checked a bit, seems to work ok with no obvious problems)
your new patch still shows a number
On Nov 17, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2000, Harald Koenig wrote:
> >
> > Linus: 0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
> > Andries:0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
>
> The biggest difference is just the system times and the
On Nov 17, Linus Torvalds wrote:
On Fri, 17 Nov 2000, Harald Koenig wrote:
Linus: 0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
Andries:0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
On Sat, 18 Nov 2000, Keith Owens wrote:
> On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >There's a test11-pre7 there now, and I'd really ask people to check out
> >the isofs changes because slight worry about those is what held me up from
> >just
On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>There's a test11-pre7 there now, and I'd really ask people to check out
>the isofs changes because slight worry about those is what held me up from
>just calling it test11 outright.
>
>It's almost guaranteed to
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be better than what we had before, but anyway..
Linus
-
To unsubscribe
>> I take it you'll also do the third part?
> Are you talking about isofs_lookup_grandparent()?
No, about isofs_read_inode.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the
header files to take some of the calling convention changes into account.
Linus
---
--- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000
+++ linux/include/linux/iso_fs.hFri
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
>
> But now that you did two-thirds of the job I take it you'll
> also do the third part? It is again precisely the same stuff.
Are you talking about isofs_lookup_grandparent()?
The code is now dead, and has been for a long time actually (as the
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> Linus:0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
> Andries: 0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
> BUT:
Linus:
> How about this version (full patch against test10 - it includes a
> slightly corrected version of my earlier dir.c patch)?
> It's entirely untested, but it looks good and compiles. Ship it!
There are three files that have to be changed.
You changed dir.c yesterday, and namei.c today
On Nov 17, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2000, Harald Koenig wrote:
> >
> > this seems to make things much worse: starting with ~90M free memory
> > "du" again started leaking (or maybe just using memory?) down to ~80M free
> > memory when the system suddently locked up
On Nov 17, [EMAIL PROTECTED] wrote:
>
> > > + if (cpnt)
> > > + kfree(cpnt);
>
> > this seems to make things much worse
>
> Yes, I meant
>
> if (cpnt) {
> kfree(cpnt);
> cpnt = NULL;
>
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> this seems to make things much worse: starting with ~90M free memory
> "du" again started leaking (or maybe just using memory?) down to ~80M free
> memory when the system suddently locked up completely, no console switch
> was possible anymore
On Nov 17, [EMAIL PROTECTED] wrote:
> > memory leak
>
> Aha. Must be a missing kfree().
> Does this help?
>
> --- namei.c~Fri Nov 17 00:48:37 2000
> +++ namei.c Fri Nov 17 21:59:49 2000
> @@ -197,6 +197,8 @@
> bh = NULL;
> break;
>
> memory leak
Aha. Must be a missing kfree().
Does this help?
--- namei.c~Fri Nov 17 00:48:37 2000
+++ namei.c Fri Nov 17 21:59:49 2000
@@ -197,6 +197,8 @@
bh = NULL;
break;
}
+ if (cpnt)
+
On Nov 17, [EMAIL PROTECTED] wrote:
> > both 2.2.x and 2.4.x kernels can't read `real sky' CDs
>
> Yes. 2.0.38 is OK. I just made a patch that seems to work.
>
> Harald, could you try
> ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch
> and report?
works -- sort of:( I've
On Nov 17, [EMAIL PROTECTED] wrote:
both 2.2.x and 2.4.x kernels can't read `real sky' CDs
Yes. 2.0.38 is OK. I just made a patch that seems to work.
Harald, could you try
ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch
and report?
works -- sort of:( I've tried
memory leak
Aha. Must be a missing kfree().
Does this help?
--- namei.c~Fri Nov 17 00:48:37 2000
+++ namei.c Fri Nov 17 21:59:49 2000
@@ -197,6 +197,8 @@
bh = NULL;
break;
}
+ if (cpnt)
+
On Fri, 17 Nov 2000, Harald Koenig wrote:
this seems to make things much worse: starting with ~90M free memory
"du" again started leaking (or maybe just using memory?) down to ~80M free
memory when the system suddently locked up completely, no console switch
was possible anymore (but
On Nov 17, [EMAIL PROTECTED] wrote:
+ if (cpnt)
+ kfree(cpnt);
this seems to make things much worse
Yes, I meant
if (cpnt) {
kfree(cpnt);
cpnt = NULL;
}
at that
On Nov 17, Linus Torvalds wrote:
On Fri, 17 Nov 2000, Harald Koenig wrote:
this seems to make things much worse: starting with ~90M free memory
"du" again started leaking (or maybe just using memory?) down to ~80M free
memory when the system suddently locked up completely, no
Linus:
How about this version (full patch against test10 - it includes a
slightly corrected version of my earlier dir.c patch)?
It's entirely untested, but it looks good and compiles. Ship it!
There are three files that have to be changed.
You changed dir.c yesterday, and namei.c today
but
On Fri, 17 Nov 2000, Harald Koenig wrote:
Linus:0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
Andries: 0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
BUT: there
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
But now that you did two-thirds of the job I take it you'll
also do the third part? It is again precisely the same stuff.
Are you talking about isofs_lookup_grandparent()?
The code is now dead, and has been for a long time actually (as the VFS
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the
header files to take some of the calling convention changes into account.
Linus
---
--- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000
+++ linux/include/linux/iso_fs.hFri
I take it you'll also do the third part?
Are you talking about isofs_lookup_grandparent()?
No, about isofs_read_inode.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be better than what we had before, but anyway..
Linus
-
To unsubscribe
On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
Linus Torvalds [EMAIL PROTECTED] wrote:
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be
On Sat, 18 Nov 2000, Keith Owens wrote:
On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
Linus Torvalds [EMAIL PROTECTED] wrote:
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it
> both 2.2.x and 2.4.x kernels can't read `real sky' CDs
Yes. 2.0.38 is OK. I just made a patch that seems to work.
Harald, could you try
ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch
and report?
Linus, Alan - I made patches for 2.2 and 2.4 but want to
polish and check
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
>
> If noone else does, I suppose I can.
Thanks.
>
> (> .. gets ENOENT ..
> and that is not because it only is a partial image?)
I don't think so, but I obviously have no way of actually confirming my
suspicion.
If the stat information was
> Anybody else willing to finish this one off?
If noone else does, I suppose I can.
(> .. gets ENOENT ..
and that is not because it only is a partial image?)
Andries
PS - Yesterday I complained that 2.4.0test9 was fine
but 2.4.0test11pre5 dies as soon as it has to forward a ping.
The effect
On Wed, 15 Nov 2000, Linus Torvalds wrote:
>
> Does this patch fix it for you?
>
> Warning: TOTALLY UNTESTED!!! Please test carefully.
Ok, I tested it with the broken image.
It looks like "readdir()" is ok now (but not really knowing what the right
output should be I cannot guarantee that).
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Also, I'd be interested to know whether somebody really knows if the zero
length handling is correct. Should we really round up to 2048, or should
we perhaps round up only to the next bufsize?
On Thu, 16 Nov 2000, Andries Brouwer wrote:
>
> Has there been a kernel version that could read these?
> It looks like it proclaims blocksize 512 and uses blocksize 2048 or so.
The (de_len == 0) check in do_isofs_readdir() seems to imply that the
blocksize is always 2048. So at the very least
On Wed, Nov 15, 2000 at 08:23:44PM +0100, Harald Koenig wrote:
> both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the
> Space Telescope Science Institute containing lotsof directories (~100)
> which each contain lots of small files (~700 files/dir).
> only ~10 directories with ~10
Hi,
both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the
Space Telescope Science Institute containing lotsof directories (~100)
which each contain lots of small files (~700 files/dir). only ~10 directories
with ~10 files each are displayed, all the other files/diretories can't be
Hi,
both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the
Space Telescope Science Institute containing lotsof directories (~100)
which each contain lots of small files (~700 files/dir). only ~10 directories
with ~10 files each are displayed, all the other files/diretories can't be
On Wed, Nov 15, 2000 at 08:23:44PM +0100, Harald Koenig wrote:
both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the
Space Telescope Science Institute containing lotsof directories (~100)
which each contain lots of small files (~700 files/dir).
only ~10 directories with ~10 files
On Thu, 16 Nov 2000, Andries Brouwer wrote:
Has there been a kernel version that could read these?
It looks like it proclaims blocksize 512 and uses blocksize 2048 or so.
The (de_len == 0) check in do_isofs_readdir() seems to imply that the
blocksize is always 2048. So at the very least
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Also, I'd be interested to know whether somebody really knows if the zero
length handling is correct. Should we really round up to 2048, or should
we perhaps round up only to the next bufsize?
On Wed, 15 Nov 2000, Linus Torvalds wrote:
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Ok, I tested it with the broken image.
It looks like "readdir()" is ok now (but not really knowing what the right
output should be I cannot guarantee that).
Anybody else willing to finish this one off?
If noone else does, I suppose I can.
( .. gets ENOENT ..
and that is not because it only is a partial image?)
Andries
PS - Yesterday I complained that 2.4.0test9 was fine
but 2.4.0test11pre5 dies as soon as it has to forward a ping.
The effect is
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
If noone else does, I suppose I can.
Thanks.
( .. gets ENOENT ..
and that is not because it only is a partial image?)
I don't think so, but I obviously have no way of actually confirming my
suspicion.
If the stat information was wrong due
45 matches
Mail list logo
