linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfltc@us.ibm.com>
To: akpm@osdl.org
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Shirish S Pargaonkar <shirishp@us.ibm.com>, simo <simo@samba.org>,
	Jeremy Allison <jra@samba.org>,
	linux-cifs-client@lists.samba.org
Subject: Re: -mm merge plans for 2.6.20
Date: Fri, 08 Dec 2006 12:32:05 -0600	[thread overview]
Message-ID: <4579AFA5.90003@us.ibm.com> (raw)

akpm wrote:
>deprecate-smbfs-in-favour-of-cifs.patch
>deprecate-smbfs-in-favour-of-cifs-docs.patch
>
> Am still waiting to hear from sfrench on the appropriateness of this.


smbfs deprecation is ok but there are a few things to consider:
1) Secure mounts:  although more secure mounts are possible now to
Windows (not just Samba) with the most recent NTLMv2 patch in the cifs
tree, implementation of Kerberized mounts are stuck in debates about the
right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size,
and userspace turned out to need to keep state across a sequence of two 
to three
upcalls before discarding its state which complicates things).   smbfs 
can handle
kerberos mounts in some cases so this is critical, even though in 
practice ntlmv2
is often good enough.

2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support
cifs is better in many cases than smbfs for this now, but cifs does
not handle utimes() remotely to them  yet  ie setting date/time the old 
style
DOS or OS/2 way (cifs can of course query the time fine).   This may not 
matter
for most cases and would be pretty easy to finish up

3) Documentation - minor cifs vs. smbfs differences in 
syntax/behavior.   I have
added some of this to the cifs documentation .odt file but have not 
posted the
pdf yet nor updated the shorter fs/cifs/README with some of this
helpful information (differences in syntax to help users migrating from 
smbfs).
I will post that to the cifs project site as PDF and .ODT this weekend.

4) Hot bugs ... For most users we should be ok here, but there is one major
unresolved bug that worries me: the cache_reap bug ("sleeping function
called from invalid context" in list_del+0x9/0x6c)
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622
Not sure whose bug that will turn out to be and ACPI settings seem to
affect it but it obviously affects some 2.6.19 users.

Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently 
already have.

             reply	other threads:[~2006-12-08 18:31 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 18:32 Steve French [this message]
2006-12-08 21:38 ` -mm merge plans for 2.6.20 Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-12-13  1:09 Chuck Ebbert
2006-12-11  9:32 Chuck Ebbert
2006-12-10  3:18 Chuck Ebbert
2006-12-11  4:19 ` Steve French
2006-12-05 23:55 Alessandro Guido
2006-12-06  0:13 ` Andrew Morton
2006-12-05  4:40 Andrew Morton
2006-12-05  4:56 ` Jeff Garzik
2006-12-05  5:41   ` Andrew Morton
2006-12-05  7:04     ` Jens Axboe
2006-12-05 15:00     ` Mark Lord
2006-12-06 19:19     ` Conke Hu
2006-12-06 19:26       ` Randy Dunlap
2006-12-06 19:40       ` Jeff Garzik
2006-12-06 22:36       ` Andrew Morton
2006-12-05  5:14 ` Paul Mackerras
2006-12-05  5:42   ` Andrew Morton
2006-12-05  5:53     ` Nick Piggin
2006-12-05  5:49   ` Nick Piggin
2006-12-05  8:36 ` Gautham R Shenoy
2006-12-05  8:47 ` Peter Zijlstra
2006-12-05 13:23 ` John W. Linville
2006-12-05 14:27 ` Roman Zippel
2006-12-06  3:46   ` Horst Schirmeier
2006-12-05 16:02 ` Dave Jones
2006-12-12 17:49   ` Dave Jones
2006-12-19  5:20     ` Nick Piggin
2006-12-19  6:44       ` Dave Jones
2006-12-19  7:02         ` Nick Piggin
2006-12-05 17:35 ` James Simmons
2006-12-05 18:01   ` Andrew Morton
2006-12-05 18:25     ` James Simmons
2006-12-05 19:43       ` Andrew Morton
2006-12-05 19:59         ` James Simmons
2006-12-05 20:20           ` Andrew Morton
2006-12-05 21:34             ` James Simmons
2006-12-06 23:40               ` Andrew Morton
2006-12-07 14:31                 ` James Simmons
2006-12-05 20:40       ` Miguel Ojeda
2006-12-06 14:42         ` James Simmons
2006-12-05 19:18 ` Josef Sipek
2006-12-05 21:00 ` Ingo Molnar
2006-12-06  2:59 ` Roman Zippel
2006-12-06  4:30   ` Andrew Morton
2006-12-06  8:32     ` Thomas Gleixner
2006-12-06 12:54       ` Roman Zippel
2006-12-06 13:11         ` Ingo Molnar
2006-12-06 14:33           ` Roman Zippel
2006-12-06 15:22             ` Ingo Molnar
2006-12-06 16:42               ` Roman Zippel
2006-12-06 16:58                 ` Ingo Molnar
2006-12-06 16:59                 ` Ingo Molnar
2006-12-06 12:33     ` Roman Zippel
2006-12-08 14:09 ` Stephen Smalley
2006-12-08 20:58   ` Andrew Morton
2006-12-10 15:07     ` Mimi Zohar
2006-12-09  9:30 ` Randy Dunlap
2006-12-09  9:44   ` Andrew Morton
2006-12-10 20:12     ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4579AFA5.90003@us.ibm.com \
    --to=smfltc@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=jra@samba.org \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shirishp@us.ibm.com \
    --cc=simo@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).