The patch looks fine - but since it does not set obj_type any more - I
want to think about it a little more since it may be useful coming
back from the open path (although the mode is probably good enough).
jra added support to Samba for a new POSIX open/create/mkdir request
(which we only use for
On 2/15/08, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Fri, Feb 15, 2008 at 07:37:35PM +0300, Q (Igor Mammedov) wrote:
Here is what I've done the last weekend.
Attached:
fixed patch [5/5]
(0001-DFS-patch-that-connects-inode-with-dfs-handling-ops.patch).
Not merged yet.
fixed
On Feb 7, 2008 12:25 PM, Christoph Hellwig [EMAIL PROTECTED] wrote:
and while I'm at it a lot of the non-DFS additions to cifs aren't quite
up to standards for kernel code either, lots of useless braces, wierd
coding style and ifdef mania.
The useless braces should be removed now. The ifdef
On Feb 7, 2008 12:25 PM, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 07:43:01AM -0600, Steve French wrote:
I only remember missing a loop unwinding on exit style comment of
yours that was not addressed in what got integrated. I will go back
through your notes again
On Feb 7, 2008 12:25 PM, Christoph Hellwig [EMAIL PROTECTED] wrote:
and while I'm at it a lot of the non-DFS additions to cifs aren't quite
up to standards for kernel code either, lots of useless braces, wierd
coding style and ifdef mania.
Reducing ifdef mania would help (there are about 120
I only remember missing a loop unwinding on exit style comment of
yours that was not addressed in what got integrated. I will go back
through your notes again to see if I missed one.
I meant to merge the final patch last week but ran out of time. Will
try to finish that this week.
On Feb 5,
On Jan 28, 2008 2:17 AM, Andi Kleen [EMAIL PROTECTED] wrote:
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
The problem is pretty nasty unfortunately. To solve it properly I think
Don't you need to a spinlock/spinunlock(i_lock) or something similar
(there isn't a spinlock in the file struct unfortunately) around the
reads and writes from f_pos in fs/read_write.c in remote_llseek with
your patch since the reads/writes from that field are not necessarily
atomic and threads
PROTECTED] wrote:
On Sun, 2008-01-27 at 10:57 -0600, Steve French wrote:
Don't you need to a spinlock/spinunlock(i_lock) or something similar
(there isn't a spinlock in the file struct unfortunately) around the
reads and writes from f_pos in fs/read_write.c in remote_llseek with
your patch
On Jan 13, 2008 1:40 PM, Christoph Hellwig [EMAIL PROTECTED] wrote:
Unfortunately I couldn't find an mbox archive of the cifs client list
anywhere, so I'll send you the review in reply to this mail, with
one reply per patch.
+ * This library is free software; you can redistribute it and/or
on shrinkable mounts by using a pointer to
the parent's mountdata.
On Jan 11, 2008 3:07 AM, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 02:28:40PM -0600, Steve French wrote:
to CIFS not supporting DFS junction points. Any projected date for that
to be supported?
I
There seems to be a lot of activity in the cifs development team with
respect to acls. Does this mean that we can look forward to functional
acl permissions in a recent or forthcoming kernel?
Yes. 2.6.24 will have support for returning a more accurate mode for a file on a cifs
mount based on
=1004000 36.3 MB/sec
On the same machine with cifs mounted over localhost to Samba/ext3
instead of Samba/XFS
wsize=56K (default) 22 MB/sec
wsize=504000 33.5 MB/sec
wsize=1004000 39.5 MB/sec
On Nov 8, 2007 9:50 AM, Steve French [EMAIL PROTECTED] wrote:
I like your code much better than my quick
I have verified that it works for the case in which min receivefile
size is under 128K. When I set it to 25 and tried to read 148000
there were two or three problems (reply_write_and_X in Samba is
calling smb_len instead of smb_len_large and it is looking for
req-unread_bytes incorrectly in a
I suspect that bad things are happening in there
I doubt that it is too bad since various filesystems (including JFS
and CIFS) have always written over qstr-name in these dentries in
order to better handle case insensitive compares. Other than trying
to remove the compiler warning recently
Not sure why the cifs code sets the S_ISVTX bit when mounted to
Windows servers. I think the intent was to turn off all of the high
bits except that (S_ISGID) needed to indicate mandatory locking
(mandatory locking is set by having S_ISGID on and group execute,
S_IXGRP, off). When reviewing the
madvise_remove (in Linux) is used to free the backing store associated
with pages (punching a hole in a file). This is one of the vfs
operations that we do not send over the wire to Samba (so this call
would return -ENOSYS locally). Any thoughts on whether this could be
done with an obscure
On 10/27/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi,
I had me a little look at bdi usage in networked filesystems.
NFS, CIFS, (smbfs), AFS, CODA and NCP
And of those, NFS is the only one that I could find that creates
backing_dev_info structures. The rest seems to fall back to
cifs and nfs (probably others) have some mount options which are mount
order dependent ie may be invalid or ignored when you have more than
one mount to the same server, or mount the same resource in two places
with different options. In the long run, at least for cifs, we may be
able to better
One example (Samba bug # 2008) is so that Samba will follow symlinks
on the server side (rather than have the client resolve them).
On 7/17/07, J. Bruce Fields [EMAIL PROTECTED] wrote:
On Mon, Jul 16, 2007 at 05:40:46PM -0500, Steve French wrote:
I have seen various requests from users
On 7/17/07, Trond Myklebust [EMAIL PROTECTED] wrote:
In CIFS parlance, the equivalent would be to mount \\SERVER\SHAREA\foo
and \\SERVER\SHAREA\bar with different mount options: I'm not sure that
is really what Steve is proposing.
Yes - Or perhaps simply \\server\shareA being mounted twice to
I have seen various requests from users to disable part of the CIFS
Unix Extensions on mount (in some cases fall back to the more
primitive Windows behavior) but am wondering how far down this line of
thought I should go ... how many mount options to add to cifs and is
there a precedent in other
and is reconnected at which time
the server will see the Unix Extensions disabled)
4) mount succeeds and no Unix Extension requests are sent on the tree
id for shareB (the requests to shareA are unaffected)
etc.
Ideas?
On 7/16/07, Steve French [EMAIL PROTECTED] wrote:
I have seen various requests from users
Yehuda, I have added your patch for NTLMv2 signatures for CIFS. I had
to change about 10 places due to whitespace changes. It tested out
fine, but would appreciate one more check.
The patch is:
Jeff,
Not seeing any objections to your revised approach (to not allowing
signals for cifsd kernel thread), I just merged something similar to
your patch to the cifs-2.6.git tree (also fixed some nearby lines that
went past 80 columns).
Thanks
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
the same mount.
Thoughts?
Steve French wrote:
Thanks - it looks almost right but you missed mknod case and your
patch had some whitespace/formatting problems.
Could you try the following and make sure it works for you? If so
will merge.
-
To unsubscribe from this list: send the line
With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.
A patch for the cifs client to support larger reads follows. In this
patch, using very large reads is not the
' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of linux-cifs-client digest...
Today's Topics:
1. i_mutex and deadlock (Steve French (smfltc))
2. Re: i_mutex
A field in i_size_write (i_size_seqcount) must be protected against
simultaneous update otherwise we risk looping in i_size_read.
The suggestion in fs.h is to use i_mutex which seems too dangerous due
to the possibility of deadlock.
There are 65 places in the fs directory which lock an
From: Miklos Szeredi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] consolidate generic_writepages and mpage_writepages
Date: Fri, 16 Feb 2007 17:23:25 +0100
From: Miklos Szeredi [EMAIL PROTECTED]
Clean up massive
As noticed by Dmitry Torokhov, write() can not return ENOMEM
It turns out that Linux is ok here returning ENOMEM (even from a strict
POSIX perspective) so the patch is not needed.
I consulted our longstanding POSIX workgroup representative to see what
he could find out about this topic, and
Suparna Bhattacharya wrote:
cc'ing linux-aio, for the AIO part of the discussion. You might be able
to find some of your answers in the archives.
there are several tests for AIO - I tend to use Chris Mason's aio-stress
which can be used to compare performance in terms of throughput for
streaming
Christoph,
I had time to add the generic vectored i/o and async i/o calls to cifs
that you had suggested last month. They are within the ifdef for the
CIFS_EXPERIMENTAL config option for the time being. I would like to do
more testing of these though - are there any tests (even primitive
33 matches
Mail list logo
