On Thu, 2005-07-21 at 17:04, Jesper Juhl wrote:
> On 7/21/05, Lasse Kärkkäinen / Tronic <[email protected]> wrote:
> > I mailed [email protected] (the guy who wrote the driver) about this a
> > month ago, but didn't get any reply. Is anyone working on that driver
> > anymore?
> >
> As far as I know Steve is still maintaining cifs. If you wrote him and
> didn't get a response, then try again after a while (you might have
> included him on CC for this mail) - maintainers don't always have time
> to answer all mail in a timely fashion (or at all), and it's your
> responsability to resend - that's not news.
CIFS is still being actively improved/maintained. I was out on vacation
for over a week. It might have gotten missed in the flood of email I
had to catch up on. I am still maintaining cifs and evaluating patches
from others as well. As you can see from the web git page, changesets
are still being added. You can see the list of CIFS changesets (most
recent first) by the query:
http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git&a=search&s=CIFS
> You could also have written to the [email protected]
> mailinglist (or copied it - it's listed in MAINTAINERS under "COMMON
> INTERNET FILE SYSTEM (CIFS)").
>
> [adding Stephen French to CC]
>
> Personally I'd probably have send the mail
> To: Steve French <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
Yes. CCing those lists is recommended. The best list to send to is and
which I and others in this area monitor regularly though is
[email protected]
> > not possible to umount with either smbumount (hangs)
smbumount can not be called on cifs vfs mounts (it is for the older
smbfs). Although there is a somewhat similar umount.cifs utility
(umount.cifs.c in the samba 3 source) it will be obsolete when
more general user umounting (of their own mounts) is permitted
in the kernel vfs itself.
> nor umount -f
> > (prints errors but doesn't umount anything).
What are the errors? What is the version of cifs.ko module?
> It won't recover without
> > reboot, even if the server becomes back online.
> >
> > This problem has been around as long as I have used SMBFS or CIFS. There
> > has only been slight variation from one version to another. Sometimes it
> > is possible to umount them (after some pretty long timeout), sometimes
> > it is not. It seems as if the problem was being fixed, but none of the
> > fixes really worked.
My tests of reconnection after server crash or network reconnection with
smbfs works (for the past year or two) and also of course for cifs.
cifs also reconnects state (open files) not just the connection to
\\server\share
> >
> > 2. Occassionally the transmission speeds go extremely low for no
> > apparent reason. While writing this, I am getting 0.39 Mo/s over a
> > gigabit network.
My informal tests (cifs->samba) showed a maximum of about 20%
utilization of gigabit doing large file writes and about double that for
large file reads with a single cifs client to Samba over gigabit. Should
be somewhat simalar to Windows server.
The most common cause of widely varying speeds are the following:
1) memory fragmentation - some versions of the kernel badly fragment
slab allocations greater than 4 pages (cifs by default allocates 16.5K
buffers - which results in larger size allocations when more than 5
processes are accessing the mount and the cifs buffer pool is exceeded)
2) write behind due to oplock - smbfs does not do oplock, cifs does -
which means that cifs client caching can cause a large amount of
writebehind data to accumulate (with great performance for a while) -
then when memory gets tight due to the inode caching in linux's mm
layer, the cifs client is asked to write out a large amount of file data
at one time (which it does synchronously).
Both of these are being improved. You can bypass the inode caching on
the client by using the cifs mount option
"forcedirectio"
> Using FTP to read the same file gives 40 Mo/s,
Similarly NFS was somewhat better than that (as long as the file was in
memory already on the server).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |