Date: Thu, 24 Oct 2002 11:59:03 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Vitaly Markitantov <vm@dics.com.ua>, current@FreeBSD.ORG Subject: Re: smbfs broken? Message-ID: <3DB842F7.AFAD89D3@mindspring.com> References: <3DB664D0.FE0B8018@mindspring.com> <XFMail.20021023105107.jhb@FreeBSD.org> <20021023152144.GA10351@iron.del.local> <20021023160014.GM661@starjuice.net> <3DB6EB16.2025AAE3@mindspring.com> <20021024142639.GA46022@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > Well, a similar problem occurred with cat(1), which doesn't use mmap(). > > However, I should have included in my message that the following > messages are received from the kernel: > > Oct 23 17:53:02 axl kernel: smbfs_getpages: error 60 > Oct 23 17:53:02 axl kernel: vm_fault: pager read error, pid 8022 (cp) > Oct 23 17:58:18 axl kernel: smbfs_getpages: error 4 > Oct 23 17:58:18 axl kernel: vm_fault: pager read error, pid 8087 (cp) > > This supports your theory. Now that you have verified that there is no problem with "dd", and that the actual problem is in the paging code, an incredibly ugly workaround suggests itself. Try removing the desciptors for getpages/putpages from smbfs_vnodeop_entries[] in /sys/fs/smbfs/smbfs_vnops.c. The actual error codes you are seeing are: SMBR_REXMIT 0x0004 /* request should be retransmitted */ SMBR_RESTART 0x0010 /* request should be repeated if possible */ SMBR_NORESTART 0x0020 /* request is not restartable */ (the printf in smbfs_getpages() should really print in hex...) The naieve "fix" would be to loop with a "yield" for some number of times to retry the operation (e.g. create a "vfs.smbfs.pageretries"). The first problem with that approach is that this is in the paging path, as the result of a fault, so it's impossible to yield() the CPU to get a delay to permit whatever incomplete operation is outstanding to complete on the server side, or to free up ocal resources which are unavailable (this last is the killer). The second problem is that the SMBR_NORESTART bit implies that no matter what you do, the request will not succeed (this would have to be verified by someone familiar with the return code). The downside of doing the ugly workaround is that is makes the VM potentially decoherent. This means code that depends on working without explicit use of msync() may not work (and FreeBSD's msync() is indiscriminate, so it's very expensive, particularly on a remote FS like SMBFS). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB842F7.AFAD89D3>