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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
