Date: Tue, 12 Nov 2002 10:54:47 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Jason Vervlied <jvervlied@boca.verio.net>, current@freebsd.org Subject: Re: Samba on -current Message-ID: <3DD14E77.55B5EA1A@mindspring.com> References: <20021112085104.V52417-100000@bertha.boca.verio.net> <20021112140219.GR64153@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > It's a known problem. Consider reading the -current mailing list to > keep up to date with known problems. It was discussed last week. > > No solution is known at this time. Use dd(1) instead of cp(1) as an > interim workaround. Actually, it's fixable 3 ways: o Full fix for "cp", ugly Remove the getpages/putpages from the implementation of the SMBFS' VOPs table. This will force it to fall back to code that uses read/write instead, which doesn't have the problem. Performance will suck, but the copies will work as expected, though "mmap" won't. o Incomplete fix, ugly, may be enough anyway Put a retry loop in the getpages/putpages code (mostly, the getpages code), to retry the operation at that level; if the failure does not occur at the session or handle level, then this will cover up the problem. If the session or handle reference is failing, there is insufficient data to rewind state to the point where it can be retried, due to the fact that you would need to go up several calls, and then back down into the VOP, to reestablish the handle to retry the call again. If you had to reestablish the session, you'd have to go even higher. o Complete fix, a lot of work The code needs to be refactored, so that a restart with the handle or session invalid works. This means seperating out the session and handle management from the standard code path, so that it can be restarted at any point, so that the state doesn't need to be unwound. The problem here is that you are in a trap handler of a write on another FS, faulting on a page that's backed by the SMBFS, so it's not like you can recover enough information otherwise to recreate the handle or session, if necessary. So you would have to ask for the handle from the cache, and then the session for the handle from the cache, if the handle was not valid. -- 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?3DD14E77.55B5EA1A>