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
handling.
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 :)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:23 EST