Re: [PATCH] smbfs fsx'ed

From: Urban Widmark (
Date: Thu Jan 03 2002 - 17:49:34 EST

On Thu, 3 Jan 2002, Linus Torvalds wrote:

> Btw, Urban, is anybody working on trying to do "{read|write}page()"
> asynchronously? I assume that IO performance on smbfs must be quite
> horrible with totally synchronous IO..

Yes. My current list of work:
 ! Large File Support
 ! Unicode Support
 + Async requests
 + Fcntl locking + smb "oplock" support
 - Async readpage/writepage (and readahead)
 - Merge read or write requests for one file into a larger request.
   I am guessing that is how NFS does it.
 + smbconnect instead of smbmount. smbfs calls to a userspace program to
   set up the connection (a la modprobe) and is mounted by mount directly
   like any other fs.
 - Review of smbfs BKL use. I believe a lot of it is unnecessary and just
   an effect of the VFS-level changes.

! = ready, waiting for the previous patch to be accepted & released
+ = code is almost working (90% done, if that joke is familiar :)
- = not actual patches yet ... more like ideas and that I know where to
    find some code to borrow from :)

The current code synchronizes all threads on the same mount since all
threads use "server->packet" as a buffer for send and receive. I have some
code where I have tried to copy how I believe nfs does things with a
"struct request" for each caller.

The requests are filled in and put on a per-server transmit queue and the
caller goes to sleep or returns. There is a smbiod kernel thread that does
the actual send and receive and wakes up the callers. Currently just one
smbiod as that is a little bit easier than having, say, one per processor.

I'm currently looking at a race where it hangs if I run 4 fsx-linux
processes at once. But otherwise it seems to work.

This should be a big win for having more than one process at a time doing
something on a smbfs mount. But I haven't benchmarked it yet.

Oplocks are interesting, they can cause the server to send a request
(a break) to the client and the current smbfs sock.c code doesn't really
expect that. This is the original reason for smbiod and the async request

With an async request handling making readpage/writepage async shouldn't
be too horrible. NFS has some kind of callbacks ... how hard can it be :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:23 EST