[patch] smbfs cache rewrite - 2nd try

[patch] smbfs cache rewrite - 2nd try

[Urban Widmark]

Hello again

This patch is more complete than the version posted earlier. It implements
support for OS/2 (and possibly things even older than that :) and have
been more tested. This borrows a lot from the ncpfs dircache code.

Smbfs testers wanted, with or without highmem boxes.


Bugs (believed) fixed vs 2.4.1-pre10:
+ cache code would oops/lockup on highmem machines (too many kmap'ed pages
  and possibly a few other things)
+ readpage/writepage could oops on highmem machines (missing kmap)
+ listing long directories would fail on some dirs on some types of servers
  (from 2.2.18, has nothing to do with the cache code)

Improvements:
+ new cache code creates dentries and inodes from the "findfirst" data,
  reducing the number of smb requests needed to list a directory (ls -l)
  from n/x + n to n/x (where x is the number of entries that fit in one
  request).
+ new mount option, ttl, allows control over how long the cache is
  considered valid, default ttl=1000 (1 second).

Bugs introduced:
- date conversion may need to do timezone conversion in smbfs
- 'd; touch dd; d; rm DD; d', where d is an alias for ls -alF, will crash
  on the rm if the server is "old", tested vs a samba server configured to
  talk "LANMAN1". Does not crash when using "NT1".
  Don't know if this is a new or old bug yet.
- more?
  (this is where you come in ...)


Download ~57k from:
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch
(Apply using 'patch -p1' from the linux directory.)

/Urban

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: [patch] smbfs cache rewrite - 2nd try

[Rainer Mager]

This is working great for me so far. I've now got my full 1G RAM and samba
seems to be working fine. Woohoo! One more oops dead.

Put it in the official kernel. Put it in the official kernel. Put it in
the.... err, excuse me. I was chanting again.


--Rainer


> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Urban Widmark
> Sent: Monday, January 29, 2001 1:23 AM
> To: linux-kernel@vger.kernel.org
> Cc: Rainer Mager; Scott A. Sibert
> Subject: [patch] smbfs cache rewrite - 2nd try
>
>
>
> Smbfs testers wanted, with or without highmem boxes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

/proc/stat missing disk_io info

[Rainer Mager]

Hi all,

	I was wondering why some of my disks don't show up in /proc/stat's disk_io
line. Specifically, my line says:

disk_io: (2,0):(144,144,288,0,0) (3,0):(35,35,140,0,0)

This equates to my floppy and first cdrom. I also have a second cdrom (RW)
and 2 hard disks. Looking at the code (kstat_read_proc in
fs/proc/proc_misc.c) it is looping only up to DK_MAX_MAJOR which is defined
as 16 in kernel_stat.h. The problem is that my 2 HDs have a major number of
22.

I don't know enough to produce a patch, that is, what should DK_MAX_MAJOR be
set to, but I believe the above is the problem.



Thanks,

--Rainer

RE: /proc/stat missing disk_io info

[Rainer Mager]

Not to be pushy or anything but since I received zero responses to this I
was wondering what else I can do. I'd be happy to patch the problem myself
but I have no idea what the correct value for DK_MAX_MAJOR  should be.

Anywho, if anyone has any thoughts I'd appreciate them.

--Rainer


> -----Original Message-----
> 	I was wondering why some of my disks don't show up in
> /proc/stat's disk_io
> line. Specifically, my line says:
>
> disk_io: (2,0):(144,144,288,0,0) (3,0):(35,35,140,0,0)
>
> This equates to my floppy and first cdrom. I also have a second cdrom (RW)
> and 2 hard disks. Looking at the code (kstat_read_proc in
> fs/proc/proc_misc.c) it is looping only up to DK_MAX_MAJOR which
> is defined
> as 16 in kernel_stat.h. The problem is that my 2 HDs have a major
> number of
> 22.
>
> I don't know enough to produce a patch, that is, what should
> DK_MAX_MAJOR be
> set to, but I believe the above is the problem.