lkml.org 
[lkml]   [1997]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SMB oddness (patch attached)
Steven N. Hirsch wrote:
> Here's some more input on my ongoing saga with smbfs and WfW.

> 4) Umounted the smb share, shut down and restarted WfW, remounted and
> ran 'strace -o /tmp/output iozone auto':
>
> Nov 22 10:42:37 cy kernel: smb_newconn: server not locked, count=1
> Nov 22 10:42:37 cy kernel: smb_offerconn: server not locked, count=1
> Nov 22 10:42:37 cy kernel: smb_offerconn: state valid, pid=252
> Nov 22 10:42:52 cy kernel: smb_proc_open: BENCH/iozone.tmp R/W failed, error=-26, retrying R/O
> Nov 22 10:42:52 cy kernel: smb_open: BENCH/iozone.tmp access denied, access=0, wish=1
>

> This was the strace capture:
> creat("iozone.tmp", 0640) = 4
> times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 4428692
> times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 4428692
> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = -1 EACCES (Permission denied)

> This appears to be a WfW wart which occurs when writing to the first
> newly-created file on the server. Hopefully this information will suggest
> a workaround?

Hi Steve,
I've gone over your report and have a theory that would explain the
problems. The significant facts are that the smb_proc_open fails on a
R/W try, and that the open is being done implicitly in the write
operation.

The current smbfs saves the fileid obtained when it creates a file, so
the file should already be opened in R/W mode after the creat() call
succeeds. But obviously smbfs thinks the file isn't open, since it tries
to open it. If the server really does have the file open R/W, then of
course the second open attempt would fail.

My theory is that WfW is using fileid 0 for the first open after a
reboot, and the smbfs code doesn't think this is a legal fileid value.
I've changed the code to accept 0 as a fileid following a successful
create, but to print a message if this occurs. Hopefully this will take
care of that problem ...

BTW, are you having any time-stamp problems with your smbfs shares?
There seem to be some weird timestamp problems (not on NT) that I'm
trying to track down.

Regards,
Bill[unhandled content-type:application/x-gzip]
\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.046 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site