lkml.org 
[lkml]   [2004]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ncpfs problems

Thanks for your quick response.

> > I'm having severe problems with ncpfs. What I'm trying to accomplish is to
> > run KDE with a NCP-mounted home directory. This actually worked with the 2.4
> > kernel, but the problem with "df"/"statfs" reporting zero bytes free
> > required patching of the startkde script.
>
> With 2.6.x you should get free space on a volume if you mount volume
> or subdirectory instead of all volumes from server (i.e. you used -V
> option to ncpmount).

Yes, this works.


> > * When shutting down KDE, the file system startas reporting EIO
> > (Input/output error). It's also very un-responsive; if one process runs
> > read() (returning EIO) in a tight loop, other processes hangs forever (well,
> > at least > 12 hours).
>
> Someone aborted process in the middle of ncpfs operation with SIGKIL.
> As ncp request/responses are handled in context of calling
> process, if you SIGKILL process after it sent request but before it
> received response, connection is invalidated.

This is _major_ drawback. The mount shouldn't stop working just because
you killed a process.


> But it should not hang other processes which have nothing to do with
> ncpfs.

Probably it doesn't; all hangs I've experienced has been with processes
using NCP mount.


> If you run in a loop process which does some (failing) ncpfs operation,
> other processes which want to use that mountpoint of course blocks:
> Linux semaphores are not fair.

So, the ncpfs client is sort of "single-threaded"?


> If you do not want SIGKILL to abort connection, replace
> sigmask(SIGKILL) with sigmask(0) in fs/ncpfs/sock.c. But then you may
> get unkillable process in the case TCP connected server dies, or if you'll
> set infinite timeout for UDP/IPX servers.

Not good. Are these two alternatives the only ones? Patching the kernel is
not an option for us; our customers are only using unmodified kernels from
their distribution or perhaps kernel.org.

Having unkillable processes are frustrating, but it's probably better than
being able to kill the entire mount by a single SIGKILL. So, if these are
the only options, I guess the unkillable process solution should be
default.


> > * Some files are impossible to remove, for example the files in
> > ~/.kde/socket-dhcp-253-234: An unlink returns EBUSY:
> >
> > unlink("kdeinit_maggie_2") = -1 EBUSY (Device or resource busy)
> >
> > Do you have any ideas what can cause this? Do you consider ncpfs stable
> > enough to be used for the home directory?
>
> File is open... You cannot remove opened files from Netware filesystem.

In my opinion, ncpfs should try to emulate POSIX semantics as close as
possible. This means that "strong" should be default, and it should be
possible to remove open files. Even if the Netware server refuses this
operation, why cannot it be simulated by ncpfs? At least this should be
possible to implement by using "silly deletes", as NFS does, but since NCP
is stateful, too me it seems like this shouldn't be necessary.


> I cannot think about any other reason why you should get EBUSY.

The glibc 2.3.3 manpage for unlink actually says that EBUSY shouldn't
happen on Linux.


(Please CC me on this topic.)

Regards, Peter


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.039 / U:1.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site