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 o
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
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 calli
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 b
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 http://www.tux.org/l
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 No
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 VF
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: the
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
bu
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 completel
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 (but
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
> 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 t
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
> 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 i
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 fil
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
ac
24 matches
Mail list logo
