[linux-cifs-client] Re: fsx-linux failing with latest cifs-2.6 git tree

[Steve French]

Trace makes it look like Nick's changes to write_begin/write_end (from
prepare_write, commit_write) could be the problem ...

See the trace below ... note that we issue a read (from
cifs_write_begin) starting at 0x2e42f (rather than ending at 0x2e42f)
... and then do a write at 0x2e42f leaving (apparently) the beginning
of this page unitialized

 CIFS VFS: SetFileSize (via SetFileInfo) 0x2e52c
 CIFS VFS: SetFileSize (via SetFileInfo) 0x2858c
 CIFS VFS: cifs_read at 0x42f
Pid: 27429, comm: fsx-linux Not tainted 2.6.28-rc5 #74
Call Trace:
 [<f8984d38>] cifs_readpage_worker+0x11c/0x2e6 [cifs]
 [<f8984fa7>] cifs_write_begin+0xa5/0xaf [cifs]
 [<c024dc33>] generic_file_buffered_write+0xc9/0x1ff
 [<c024e324>] __generic_file_aio_write_nolock+0x3d9/0x413
 [<c023b164>] ? mark_held_locks+0x45/0x5c
 [<c0595dc4>] ? mutex_lock_nested+0x20a/0x212
 [<c024e3ad>] ? generic_file_aio_write+0x4f/0xb8
 [<c024e3c2>] generic_file_aio_write+0x64/0xb8
 [<f897518b>] cifs_file_aio_write+0x19/0x37 [cifs]
 [<c026e97d>] do_sync_write+0xbb/0xf9
 [<c02715c5>] ? cp_new_stat64+0xe8/0xfa
 [<c02310dd>] ? autoremove_wake_function+0x0/0x30
 [<c0271a09>] ? sys_fstat64+0x22/0x28
 [<c026e8c2>] ? do_sync_write+0x0/0xf9
 [<c026f054>] vfs_write+0x8c/0x108
 [<c026f4a4>] sys_write+0x3b/0x60
 [<c0202df9>] sysenter_do_call+0x12/0x35
 CIFS VFS: write_end from 0x2e42f len 0xbd1


On Fri, Nov 21, 2008 at 10:46 AM, Steve French <smfrench at gmail.com> wrote:
> At least it is a small number of requests to wade through ...
>
> Total vfs operations: 91 maximum at one time: 2
>
> 1) \\localhost\stevef
> SMBs: 94 Oplock Breaks: 0
> Reads:  60 Bytes: 122880
> Writes: 7 Bytes: 186404
> Locks: 0 HardLinks: 0 Symlinks: 0
> Opens: 1 Closes: 1Deletes: 0
> Mkdirs: 0 Rmdirs: 0
> Renames: 0 T2 Renames 0
> FindFirst: 0 FNext 0 FClose 0
>
> The final write request has corrupt data in the middle which causes
> this ... the read requests to the server which precede this final
> write stopped at the previous page so this seems unitialized which
> can't happen ... but just did
>
> On Fri, Nov 21, 2008 at 10:22 AM, Jeff Layton <jlayton at redhat.com> wrote:
>> On Fri, 21 Nov 2008 10:20:25 -0600
>> "Steve French" <smfrench at gmail.com> wrote:
>>
>>> I just tried it and got the same corruption ... perhaps one of the 107
>>> (!) fixes to mm since 2.6.27 regressed us?
>>>
>>
>> Ok, going to see if I can do a bisect to figure it out.
>>
>> Thanks,
>> --
>> Jeff Layton <jlayton at redhat.com>
>>
>
>
>
> --
> Thanks,
>
> Steve
>



-- 
Thanks,

Steve