Custom Search
|
Date: January 30, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.62.0601292252360.30690@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<Pine.LNX.4.62.0601292252360.30690@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
That was a recent global kernel change (new function introduced that reduces the common call sequence first calling filemap_fdatawrite then filemap_fdatawait to one call) that affects the cifs code among others.
You can probably simply use the following equivalent version of 1.40a that I created for 2.6.13 (probably should work on 2.6.15)
http://pserver.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-2.6.13.tar.gz
If it does not work on 2.6.15 let me know. FYI if you are running in production or in stress tests you should probably check to make sure that two small recent patches are in that 1.40a tar.gz (if not they in it they are easy to apply):
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -498,7 +498,6 @@ SendReceive2(const unsigned int xid, str
else
*pRespBufType = CIFS_SMALL_BUFFER;
iov[0].iov_len = receive_len + 4;
- iov[1].iov_len = 0;
dump_smb(midQ->resp_buf, 80);
/* convert the length into a more usable form */
and second that the patch:
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1754,7 +1754,10 @@ static int cifs_readpages(struct file *f
/* need to free smb_read_data buf before exit */
if (smb_read_data) {
- cifs_buf_release(smb_read_data);
+ if(buf_type == CIFS_SMALL_BUFFER)
+ cifs_small_buf_release(smb_read_data);
+ else if(buf_type == CIFS_LARGE_BUFFER)
+ cifs_buf_release(smb_read_data);
smb_read_data = NULL;
}
is also in
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Martin Koeppe <mkoeppe@xxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 01/29/2006 03:54 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 29, 2006
From: Martin Koeppe <mkoeppe@xxxxxx>
Hello Steve, for supporting sfu symlinks, I tested the following on sfu shell: perl -e 'symlink "\001\002\n\\+<>\"|*?", sl5' which results in the following symlink special file (hex dump): 00000000 49 6E 74 78 . 4C 4E 4B 01 . 01 00 02 00 . 0A 00 5C 00 IntxLNK.......\. 00000010 2B 00 3C 00 . 3E 00 22 00 . 7C 00 2A 00 . 3F 00 +.<.>.".|.*.?.So in the special file, the unix name of the link target is stored, not the NTFS remapped name. I didn't yet understand the handling of non-ASCII (>0x7f chars) link targets, e.g. with german umlauts. These seem to be weird.
For linux-cifs I suggest to begin with symlink support for link targets being completely plain ASCII (0x01-0x7f). Are there other difficulties on implementing symlink support?
Martin
Date: January 29, 2006
From: Martin Koeppe <mkoeppe@xxxxxx>
Hello Steve, some days ago I tried to compile cifs-1.40 (not 1.40a) for kernel 2.6.15. I enabled all but CONFIG_CIFS_EXPERIMENTAL and got "unknown symbol filemap_write_and_wait" while linking. Martin
Date: January 27, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<43D9E462.1030304@xxxxxxxxxxxxx>
References:
<43D9E462.1030304@xxxxxxxxxxxxx>
This is probably closer to what you want:
http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-2.6.13.tar.gz
There are two minor, but important fixes that are not in the various 1.40a tar.gz's (that are in the cifs development tree, and hopefully mainline soon as soon as Linus gets back)
The one line fix removing the set which can go off the end of the stack in transport.c (iov[1].len = 0) and the set of the default wsize to 52K (for servers which support large write X) are not in the various cifs1.40a.tar.gz
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Steven Scholz <steven.scholz@xxxxxxxxxxxxx> wrote on 01/27/2006 03:14:10 AM:
> Steven,
>
> > I also created a
> > http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a.tar.gz
> > for those with 2.6.15 or later.
>
> IIUC then cifs-1.40a.tar.gz is for >= 2.6.15 and cifs-1.40.tar.gz would
> work with 2.6.14 !?
>
> --
> Steven Scholz
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 27, 2006
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<OF6DBBC786.FA1CA2C5-ON872570FB.0082BEEE-862570FB.0082FE03@xxxxxxxxxx>
References:
<OF6DBBC786.FA1CA2C5-ON872570FB.0082BEEE-862570FB.0082FE03@xxxxxxxxxx>
Steven, > I also created a > http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a.tar.gz > for those with 2.6.15 or later. IIUC then cifs-1.40a.tar.gz is for >= 2.6.15 and cifs-1.40.tar.gz would work with 2.6.14 !? -- Steven Scholz
Date: January 24, 2006
From: "Wagner, Chris (GE Infra, Non-GE)" <chris.wagner@xxxxxxxxx>
We've been having some CIFS client performance issues. It takes 4 min 30 secs to copy a 42 meg test file. That's only 150KB/sec. Now if we copy the same file with ssh it will take about 1 min 20 secs. Same file, same machines, different protocol. So we're trying to determine why ssh is different than cifs for copying files, we've played with the rsize and wsize a bit and that hasn't helped significantly. When we do packet captures we get a lot of [Unreassembled Packet (incorrect TCP checksum): SMB] and some say this may be a network driver issue however under SSH that does not show up at all, it looks really clean in SSH and looks like a spagetti mess in SMB. Its also only a client issue. The smb server on linux works fine when a Windows client attaches to it. We're running RHEL3 Update 5 64 and 32 bit. The server is a Windows workstation. When a HPUX system connects to it the transfer is normal. Since it's 2.4 kernel I compiled the CIFS module myself directly against these systems. Any ideas?
Date: January 19, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20060118150236.GG11323@xxxxxxxxxxxxxxxxxxx>
References:
<20060118150236.GG11323@xxxxxxxxxxxxxxxxxxx>
> We are very interested on testing cifs 1.40 on RHEL4/CentOS4 (kernel
> 2.6.9-22.0.2.ELsmp).
OK - it is on the download site. It should be nearly identical to the version in mainline (and in cifs-2.6.git) as of the moment (ie what will be in 2.6.16-rc2)
http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-forFC3orRHEL4orSuSEWrk9.tar.gz
cifs_writepages (multipage write is disabled if you are built as a module due to the two missing exports in the older 2.6.9 (actually 2.6.14 or earlier) page manager).
Please let me know feedback (testing results etc.) on this. I ran fsx and connectathon on the module (to Samba 3.0.14) but did not do extensive tests as I want to get working on some other critical code.
I also created a
http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a.tar.gz
for those with 2.6.15 or later.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 18, 2006
From: Mark Brown <bmark@xxxxxxxxxx>
In-reply-to:
<OF29E38C03.EF136311-ON872570F9.005BA4A3-862570F9.005D6C94@LocalDomain>
References:
<OF29E38C03.EF136311-ON872570F9.005BA4A3-862570F9.005D6C94@LocalDomain>
The POSIX Portable Filename Character Set is Base Definitions Section 3.276 Portable Filename Character Set The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - The last three characters are the period, underscore, and hyphen characters, respectively. ------------------- Mark Brown/Austin/IBM STSM, UNIX/Linux OS Standards IBM Systems Group, Linux Technology Center bmark@xxxxxxxxxx (512) 838-3926 [TL 678-3926) Steven French/Austin/IBM 01/17/2006 11:01 AM To "Sanjeev Sharma" <ansiknr@xxxxxxxxxxx> cc linux-cifs-client@xxxxxxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx Subject Re: [linux-cifs-client] any way to get mapchars to handle double quote? This is an interesting question. It looks like Windows should take double quote in its C shell or Korn shell in SFU but I have not been successful trying to do that locally on Windows - it may be that it is controlled by a registry setting that I have forgotten about. Over the network Windows returned "STATUS_OBJECT_NAME_INVALID" when I tried to create a directory with double quotes in it which implies that the double quote character should be remapped (with mapchars mount option) but there may be some POSIX history on this topic of which I am unaware. The SFU help says File names can contain any of the characters specified by the POSIX portable character set. In Interix, file names can contain any character except the following: \ / " < > which implies that the POSIX portable character set does not require the filesystem to support double quote (although I can create such a file in Linux/ext3 locally). Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com "Sanjeev Sharma" <ansiknr@xxxxxxxxxxx> Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 01/16/2006 09:40 PM To linux-cifs-client@xxxxxxxxxxxxxxx cc Subject [linux-cifs-client] any way to get mapchars to handle double quote? I've read the archives on the issue and none seem to discuss the double-quote character " This appears illegal on Windows 2k at least (don't have a winXP to test on). _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 18, 2006
From: Juan José Villaplana Querol <villapla@xxxxxxxxx>
In-reply-to:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx>
References:
<OF7B708931.9D90D914-ON872570F4.0082438E-862570F4.0082314A@LocalDomain> <OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx>
On Thu, Jan 12, 2006 at 06:18:20PM -0600, Steven French wrote: > I put a 1.40 tar.gz for the cifs kernel code on > http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40.tar.gz > > This requires quite current kernel in order to compile due to a couple new > kernel functions but will be easy to change to compile on earlier kernels > (at least the last few point releases require only minor changes). Hi Steven, We are very interested on testing cifs 1.40 on RHEL4/CentOS4 (kernel 2.6.9-22.0.2.ELsmp). Have you planed to release cifs-1.40rhel4.tar.gz? Regards, Juanjo -- Juan José Villaplana Querol/Servei d'Informàtica/Universitat Jaume I Powered by Mutt [http://www.mutt.org/] Dilbert: ... and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises.
Date: January 17, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<01d601c61bb9$679733e0$14ce21c7@TOMCAT
>
References:
<01d601c61bb9$679733e0$14ce21c7@TOMCAT
>
-9 is EBADF (bad file handle).
I would expect this to happen only when the session to the server drops. That can happen for a few reasons but usually due to the network connection (tcp session) dropping (e,g. temporary router, hardware, network problem) or due to the request to the server timeing out (server resonds slowly - over 20 seconds or so to respond). You can check to see if the session to the server dropped by looking at /proc/fs/cifs/Stats
The cifs client code can usually reconnect transparently (reopening file handles, rewriting the files).
The most important cases to look at are cases in which cifs client does not reconnect/reopen (there is a case to think through e.g. when user changed the password between the time the mount occurred and when the session failure occurred)
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
"Kory Hamzeh" <kory@xxxxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 01/17/2006 04:57 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 17, 2006
From: "Kory Hamzeh" <kory@xxxxxxxxxx>
In-reply-to:
<1137535443.5197.10.camel@xxxxxxxxxxxxxxxxxxxxx>
References:
<1137535443.5197.10.camel@xxxxxxxxxxxxxxxxxxxxx>
> > > hi @all > > i have a problem with my server i have mount 5 windows pc > with cifs to one linux pc after some minutes > > > Jan 17 22:56:55 last message repeated 5 times > Jan 17 22:56:55 kernel: CIFS VFS: Send error in Close = -9 > Jan 17 22:56:55 onlinetvrecorder kernel: CIFS VFS: Send > error in read = -9 > Jan 17 22:56:55 kernel: CIFS VFS: Send I was seen these errors also (and -13 errors). They seem to happen randomly. I'd be interested if there is a solution to this issue. Kory
Date: January 17, 2006
From: Arnold Putz <arnold.putz@xxxxxxxxx>
hi @all i have a problem with my server i have mount 5 windows pc with cifs to one linux pc after some minutes Jan 17 22:56:55 last message repeated 5 times Jan 17 22:56:55 kernel: CIFS VFS: Send error in Close = -9 Jan 17 22:56:55 onlinetvrecorder kernel: CIFS VFS: Send error in read = -9 Jan 17 22:56:55 kernel: CIFS VFS: Send error in Close = -9 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21811 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21808 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 162 mid 9841 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 162 mid 10055 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21814 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21813 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21812 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21810 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 46 mid 21809 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 162 mid 9563 Jan 17 22:57:07 kernel: CIFS VFS: No response for cmd 162 mid 9613 Jan 17 22:57:07 kernel: CIFS VFS: Send error in read = -9 Jan 17 22:57:07 last message repeated 6 times Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49665 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49664 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49663 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 23191 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 23161 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22494 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22291 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22239 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49668 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49667 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49666 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49662 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 46 mid 49661 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -11 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22786 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22596 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22194 Jan 17 22:57:34 kernel: CIFS VFS: No response for cmd 162 mid 22026 Jan 17 22:57:34 kernel: CIFS VFS: Send error in read = -9 Jan 17 22:57:34 last message repeated 5 times Jan 17 22:57:34 kernel: CIFS VFS: Send error in Close = -9 filename: /lib/modules/2.6.15-1-k7/kernel/fs/cifs/cifs.ko author: Steve French <sfrench@xxxxxxxxxx> license: GPL description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows version: 1.39 vermagic: 2.6.15-1-k7 K7 gcc-4.0 depends: srcversion: BAA2B662E133E679F5A6DF9 parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 (int) parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int) parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int) parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int i hope anybody can help me with this problem or i can help to find a solution thx whwi
Date: January 17, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<BAY104-F20C6ED74A83A0C46930EF1AD1A0@xxxxxxx>
References:
<BAY104-F20C6ED74A83A0C46930EF1AD1A0@xxxxxxx>
This is an interesting question. It looks like Windows should take double quote in its C shell or Korn shell in SFU but I have not been successful trying to do that locally on Windows - it may be that it is controlled by a registry setting that I have forgotten about.
Over the network Windows returned "STATUS_OBJECT_NAME_INVALID" when I tried to create a directory with double quotes in it which implies that the double quote character should be remapped (with mapchars mount option) but there may be some POSIX history on this topic of which I am unaware.
The SFU help says
\ / " < >
"Sanjeev Sharma" <ansiknr@xxxxxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 01/16/2006 09:40 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 17, 2006
From: "Sanjeev Sharma" <ansiknr@xxxxxxxxxxx>
" This appears illegal on Windows 2k at least (don't have a winXP to test on).
Date: January 16, 2006
From: Steven French <sfrench@xxxxxxxxxx>
Benoit Boissinot wrote:
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 16, 2006
From: Wilhelm Meier <meier@xxxxxxxxxxxxxxxxxxx>
Hello, this is somewhat off topic, but does someone know something new about CIFS-client support for OpenSolaris? -- Wilhelm Meier email: meier@xxxxxxxxxxxxxxxxxxx
Date: January 13, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200601130958.52438.maxy@xxxxxxxxxxxxx>
References:
<200601130958.52438.maxy@xxxxxxxxxxxxx>
With LookupCacheEnabled IIRC file size (or other inode metadata) for a multiply open (for write) file is only out of date for at most 1 second - which I believe is a reasonable compromise. NFS allows their timeout for revalidate to be configured.
Even locally for applications with multiple processes writing to the same file there can be races between seek in one process and write.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 13, 2006
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
In-reply-to:
<OF8908DB85.A4F96679-ON872570F4.007B6566-862570F4.007BCD75@xxxxxxxxxx>
References:
<OF8908DB85.A4F96679-ON872570F4.007B6566-862570F4.007BCD75@xxxxxxxxxx>
On Thursday 12 January 2006 19:33, you wrote: > I don't believe it is a good idea to mix the "forcedirectio" concept (no > data caching) with the concept of /proc/fs/cifs/LookupCacheEnable (no > metadata/timestamp caching) - so would like to keep those distinct - even > though file size updates can be 1 second late by default it can be > configured via /proc to disable that size caching. The problem is that if a file is growing in size, using "directio" with LookupCacheEnable=1, does not cause cifs to re-read the end of the file, so you are implicitly caching data (or, actually, the absence of data). The last patch I sent does not modify the meaning of "LookupCacheEnable" in the rest of the code. The new code just makes sure that the size is not cached when using "directio". Implementing the "notify" behaviour might be a better solution to this problem (as is already commented in the code), but I guess this might imply a lot of changes in the code. -- Saludos, /\/\ /\ >< `/
Date: January 13, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<OF7B708931.9D90D914-ON872570F4.0082438E-862570F4.0082314A@LocalDomain>
References:
<OF7B708931.9D90D914-ON872570F4.0082438E-862570F4.0082314A@LocalDomain>
I put a 1.40 tar.gz for the cifs kernel code on http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40.tar.gz
This requires quite current kernel in order to compile due to a couple new kernel functions but will be easy to change to compile on earlier kernels (at least the last few point releases require only minor changes).
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 12, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<OF8908DB85.A4F96679-ON872570F4.007B6566-862570F4.007BCD75@LocalDomain>
References:
<OF8908DB85.A4F96679-ON872570F4.007B6566-862570F4.007BCD75@LocalDomain>
The first part of this patch is in cifs-2.6.git on kernel.org
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 12, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200601051217.29543.maxy@xxxxxxxxxxxxx>
References:
<200601051217.29543.maxy@xxxxxxxxxxxxx>
I don't believe it is a good idea to mix the "forcedirectio" concept (no data caching) with the concept of
/proc/fs/cifs/LookupCacheEnable (no metadata/timestamp caching) - so would like to keep
those distinct - even though file size updates can be 1 second late by default it can be configured
via /proc to disable that size caching.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Maximiliano Curia <maxy@xxxxxxxxxxxxx> wrote on 01/05/2006 01:17:29 PM:
> On Wednesday 04 January 2006 17:00, you wrote:
> > Your patch picked up the other places llseek needs to be exported from (I
> > had added those in my testing) - the is size safe to change needs to be
> > modified in two ways
>
> I've been polishing the previous patch, and I'm about to put it in production
> for my clients, I would like to hear comments before doing so.
>
> The changes are simple, one to avoid having to set LookCacheEnable to 0, the
> other makes is_size_safe_to_change return 1 when the resource was mounted
> with directio.
>
> It would be nice to have a "right way" to use mmap over directio, but as I
> only need it to exec elf files, any generic mmap would do what I need. It
> might be a good idea to use a readonly mmap.
>
> > 1) always allow files open forcedirectio to update file size (no page cache
> > issues so should be safe)
>
> > 2) for the default case (local caching, ie using page cache) if file is not
> > dirty update the file size if file is dirty write the file data out and
> > then update the file size - hard part is we have to check the locking
> > around this operation and make sure we match all other locations that could
> > be updating the filesize and we may have to lock all potentially affected
> > pages (especially the final page in the file if it is a partial page) so we
> > don't continue to reuse them.
>
> Well, I didn't mention it before, but, I've also been toying with
> commit_write, avoiding the call to setpagedirty (by calling cifs_write),
> so I don't have a pending write behind. And I could not "fix" the data-loss.
>
> But I agree with the proposed changes, anyway.
>
> --
> Saludos,
> /\/\ /\ >< `/
> [attachment "cifs-direct-2.patch" deleted by Steven
> French/Austin/IBM] No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/06
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 09, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<5a59ce530601081819j78c7acbct73bfe2602676bb00@xxxxxxxxxxxxxx>
References:
<5a59ce530601081819j78c7acbct73bfe2602676bb00@xxxxxxxxxxxxxx>
thanks - this needs to be updated along with quite a bit of the project web page - it has not been touched in a while.
The newer mount.cifs (1.10 may be most recent) is in the samba 3 svn
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
studdugie <studdugie@xxxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 01/08/2006 08:19 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 09, 2006
From: studdugie <studdugie@xxxxxxxxx>
The mount.cifs.c file from http://linux-cifs.samba.org/cifs/cifs_download.html is reporting that it's version 1.7 not 1.8. This is as of 8 Jan 06 21:18. Dane
Date: January 06, 2006
From: studdugie <studdugie@xxxxxxxxx>
In-reply-to:
<20060106024225.GA17369@xxxxxxxxxxxxxxxx>
References:
<20060106024225.GA17369@xxxxxxxxxxxxxxxx>
On 1/5/06, Hujer <hujer@xxxxxxxxxxxx> wrote: > Hi, > > i have just found a bug in cifs > from the mailing list archive it seems you are already working on this but > this i will just repeat it here to > make sure > > i used 2.6.15 kernel from debian unstable on both boxes and cifs is 1.39 (i > guess the one from vanilla 2.6.15) > > i created share with samba (latest samba in debian unstable) > and mounted it using cifs with directio option > when i do > echo "blabla" >file > echo "t" >>file > the result is > > cat file > t > abla > > it seems that using >> doesnt seek to the end, > same happens if you make small app that uses fopen with "a+" > > without directio it seems to work properly with result > blabla > t > > > i found other problem with permissions, do this as root on cifs mount: > G2:/mnt/tsa# touch file > G2:/mnt/tsa# chmod a-rwx file > G2:/mnt/tsa# echo "test" >>file > -bash: file: Permission denied > > if you do the same on non-cifs fs it works > G2:/mnt/tsa# cd .. > G2:/mnt# touch file > G2:/mnt# chmod a-rwx file > G2:/mnt# echo "test" >>file > G2:/mnt# cat file > test > (yes it may be crazy to do it, but still it should work) > > > sysinfo: > Linux MONSTER 2.6.15-1-k7 #1 Tue Jan 3 10:46:46 UTC 2006 i686 GNU/Linux > > MONSTER:~# modinfo cifs > filename: /lib/modules/2.6.15-1-k7/kernel/fs/cifs/cifs.ko > author: Steve French <sfrench@xxxxxxxxxx> > license: GPL > description: VFS to access servers complying with the SNIA CIFS > Specification e.g. Samba and Windows > version: 1.39 > vermagic: 2.6.15-1-k7 K7 gcc-4.0 > depends: > srcversion: BAA2B662E133E679F5A6DF9 > parm: cifs_max_pending:Simultaneous requests to server. Default: 50 > Range: 2 to 256 (int) > parm: cifs_min_small:Small network buffers in pool. Default: 30 > Range: 2 to 256 (int) > parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to > 64 (int) > parm: CIFSMaxBufSize:Network buffer size (not including header). > Default: 16384 Range: 8192 to 130048 (int) > > > thanks > Hujer > _______________________________________________ > linux-cifs-client mailing list > linux-cifs-client@xxxxxxxxxxxxxxx > https://lists.samba.org/mailman/listinfo/linux-cifs-client > I've just confirmed that this bug also affects the cifs code bundled with kernel 2.6.14.2. Dane
Date: January 06, 2006
From: "Tim Barton" <tbarton@xxxxxxxxxxxxxx>
|
TO: Steve French, I read your post regarding the kernel: cifsd: page allocation failure. order:3, mode:0xd0 errors and what to do about it – if you are using the 2.6.11.
kernel or later. http://lists.samba.org/archive/linux-cifs-client/2005-March/000730.html I am a Red Hat 4 user – so I have the 2.6.9-22 kernel –
and the 1.20 version of the cifs.ko module. I have just had a system crash with this error and am
wondering what I can do to resolve this issue with my version of kernel and
cifs module. Any thoughts/advice will be appreciated. Tim. |
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 06, 2006
From: Hujer <hujer@xxxxxxxxxxxx>
Hi, i have just found a bug in cifs from the mailing list archive it seems you are already working on this but this i will just repeat it here to make sure i used 2.6.15 kernel from debian unstable on both boxes and cifs is 1.39 (i guess the one from vanilla 2.6.15) i created share with samba (latest samba in debian unstable) and mounted it using cifs with directio option when i do echo "blabla" >file echo "t" >>file the result is cat file t abla it seems that using >> doesnt seek to the end, same happens if you make small app that uses fopen with "a+" without directio it seems to work properly with result blabla t i found other problem with permissions, do this as root on cifs mount: G2:/mnt/tsa# touch file G2:/mnt/tsa# chmod a-rwx file G2:/mnt/tsa# echo "test" >>file -bash: file: Permission denied if you do the same on non-cifs fs it works G2:/mnt/tsa# cd .. G2:/mnt# touch file G2:/mnt# chmod a-rwx file G2:/mnt# echo "test" >>file G2:/mnt# cat file test (yes it may be crazy to do it, but still it should work) sysinfo: Linux MONSTER 2.6.15-1-k7 #1 Tue Jan 3 10:46:46 UTC 2006 i686 GNU/Linux MONSTER:~# modinfo cifs filename: /lib/modules/2.6.15-1-k7/kernel/fs/cifs/cifs.ko author: Steve French <sfrench@xxxxxxxxxx> license: GPL description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows version: 1.39 vermagic: 2.6.15-1-k7 K7 gcc-4.0 depends: srcversion: BAA2B662E133E679F5A6DF9 parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 (int) parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int) parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int) parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int) thanks Hujer
Date: January 06, 2006
From: studdugie <studdugie@xxxxxxxxx>
In-reply-to:
<OFC7F28072.DCF9A5F8-ON872570ED.0062D33D-862570ED.006328F9@xxxxxxxxxx>
References:
<5a59ce530601042045j5a2fe379x48b9d4e4c4936234@xxxxxxxxxxxxxx> <OFC7F28072.DCF9A5F8-ON872570ED.0062D33D-862570ED.006328F9@xxxxxxxxxx>
Thanx. On 1/5/06, Steven French <sfrench@xxxxxxxxxx> wrote: > > > > difference between directio and forcedirectio > They are synonyms when used as mount parms for cifs. > > Most lkml kernel discussion about directio refers to the open flag though - > not a mount option which affects all opens on the mount. For cifs it was > easier to get most of the benefit of directio by disabling local caching for > the whole mount via the directio (forcedirectio) mount option. Some > filesystems (unlike cifs) also restrict directio to be on block boundaries > which seemed counterproductive. > > > Steve French > Senior Software Engineer > Linux Technology Center - IBM Austin > phone: 512-838-2294 > email: sfrench at-sign us dot ibm dot com
Date: January 05, 2006
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
In-reply-to:
<OF33B29570.2D8A8030-ON872570EC.006D6A53-862570EC.006DDC19@xxxxxxxxxx>
References:
<OF33B29570.2D8A8030-ON872570EC.006D6A53-862570EC.006DDC19@xxxxxxxxxx>
On Wednesday 04 January 2006 17:00, you wrote: > Your patch picked up the other places llseek needs to be exported from (I > had added those in my testing) - the is size safe to change needs to be > modified in two ways I've been polishing the previous patch, and I'm about to put it in production for my clients, I would like to hear comments before doing so. The changes are simple, one to avoid having to set LookCacheEnable to 0, the other makes is_size_safe_to_change return 1 when the resource was mounted with directio. It would be nice to have a "right way" to use mmap over directio, but as I only need it to exec elf files, any generic mmap would do what I need. It might be a good idea to use a readonly mmap. > 1) always allow files open forcedirectio to update file size (no page cache > issues so should be safe) > 2) for the default case (local caching, ie using page cache) if file is not > dirty update the file size if file is dirty write the file data out and > then update the file size - hard part is we have to check the locking > around this operation and make sure we match all other locations that could > be updating the filesize and we may have to lock all potentially affected > pages (especially the final page in the file if it is a partial page) so we > don't continue to reuse them. Well, I didn't mention it before, but, I've also been toying with commit_write, avoiding the call to setpagedirty (by calling cifs_write), so I don't have a pending write behind. And I could not "fix" the data-loss. But I agree with the proposed changes, anyway. -- Saludos, /\/\ /\ >< `/
cifs-direct-2.patch
Description: Text Data
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/06
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 05, 2006
From: "Roper, Adam D" <Adam.Roper@xxxxxxxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 05, 2006
From: studdugie <studdugie@xxxxxxxxx>
In-reply-to:
<OF33B29570.2D8A8030-ON872570EC.006D6A53-862570EC.006DDC19@xxxxxxxxxx>
References:
<200601041127.39637.maxy@xxxxxxxxxxxxx> <OF33B29570.2D8A8030-ON872570EC.006D6A53-862570EC.006DDC19@xxxxxxxxxx>
What's the functional difference between directio and forcedirectio and why would one choose one over the other? On 1/4/06, Steven French <sfrench@xxxxxxxxxx> wrote: > > > Your patch picked up the other places llseek needs to be exported from (I > had added those in my testing) - the is size safe to change needs to be > modified in two ways > > 1) always allow files open forcedirectio to update file size (no page cache > issues so should be safe) > 2) for the default case (local caching, ie using page cache) if file is not > dirty update the file size if file is dirty write the file data out and then > update the file size - hard part is we have to check the locking around this > operation and make sure we match all other locations that could be updating > the filesize and we may have to lock all potentially affected pages > (especially the final page in the file if it is a partial page) so we don't > continue to reuse them. > > I don't think we can add mmap for the forcedirectio case unless we walk > through the complex distinctions between private vs. public mmaps and the > analogy with directio behavior in other fs to validate the right behaviors > > > > > Steve French > Senior Software Engineer > Linux Technology Center - IBM Austin > phone: 512-838-2294 > email: sfrench at-sign us dot ibm dot com > _______________________________________________ > linux-cifs-client mailing list > linux-cifs-client@xxxxxxxxxxxxxxx > https://lists.samba.org/mailman/listinfo/linux-cifs-client > > >
Date: January 04, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200601041127.39637.maxy@xxxxxxxxxxxxx>
References:
<200601041127.39637.maxy@xxxxxxxxxxxxx>
Your patch picked up the other places llseek needs to be exported from (I had added those in my testing) - the is size safe to change needs to be modified in two ways
1) always allow files open forcedirectio to update file size (no page cache issues so should be safe)
2) for the default case (local caching, ie using page cache) if file is not dirty update the file size if file is dirty write the file data out and then update the file size - hard part is we have to check the locking around this operation and make sure we match all other locations that could be updating the filesize and we may have to lock all potentially affected pages (especially the final page in the file if it is a partial page) so we don't continue to reuse them.
I don't think we can add mmap for the forcedirectio case unless we walk through the complex distinctions between private vs. public mmaps and the analogy with directio behavior in other fs to validate the right behaviors
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 04, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.56.0601021251570.31652@xxxxxxxxxxxxxxxx>
References:
<20051227120021.7FD6D163A6E@xxxxxxxxxxxxxxx> <43B7084D.1070803@xxxxxxxxxx> <Pine.LNX.4.56.0601021251570.31652@xxxxxxxxxxxxxxxx>
Nicki Messerschmidt wrote:
There were various distro kernels (and the mm based kernels) which already exported __pagevec_release for experimental filesystems which were not in mainline, but for mainline cifs these exports were not added until the cifs writepages update went into 2.6.15 (since cifs writepages requires these two exports). If you can rebuild the kernel bzImage then it is easy enough to either-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 31 Dec 2005, Steve French wrote:allows 52K writes (13 pages) rather than 4K writes - cifs 1.39a e.g. may help a lot with write sizes.I now tried to build the 1.39a againt my 2.6.14.3 kernel. But when I try to load this module I get: cifs: Unknown symbol __pagevec_release cifs: Unknown symbol pagevec_lookup_tag Do you have an idea on how to fix this? I just copied the extracted source to /usr/src/linux-2.6.14.3/fs/cifs and started a "make clean; make bzImage; make modules; make modules_install". The "depmod -a" said nothing, but when loading the module the afore mentioned messages are in "dmesg". As of now the 2.6.14.3 kernel is not that old and it takes a while to find the source for the modules on http://linux-cifs.samba.org. I now took the source from http://pserver.samba.org/samba/ftp/cifs-cvs/. Is this the right place?
a) build cifs into bzImage instead of as a module or b) add the two line change to export into the mm directory of the kernel otherwise you have to disable cifs_writepages and fall back to 4K writes.
Date: January 04, 2006
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
Hi! After digging into the code for a long time, and also a lot of trial and error, we finally got to patch the client so that it works as we want it to. To achieve this, we had to apply the attached patch, mount the resources with "directio", and set /proc/fs/cifs/LookUpCacheEnabled to zero. The patch includes the previously mentioned lseek patch, plus a change to the revalidate() function and the inclusion of the mmap function even when "directio" access is being used. The change to the revalidate() function was done so that the size was always "safe_to_chage", this can be assumed on "directio", but would lead to data-loss if not. This needs to be rewritten and tidied up, so that it's always safe to change the size when mounting "directio", but keeps the old behaviour if not. If the mmap function was not part of the direct functions, ELF files could not be executed from the mounted resource, that's why we added it to the structure. This might need to be replaced by a direct_mmap or something of the sort, but it seems clear that some type of mmap needs to be present. -- Saludos, /\/\ /\ >< `/
cifs-direct.patch
Description: Text Data
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/06
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 04, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200512301808.07839.maxy@xxxxxxxxxxxxx>
References:
<200512301808.07839.maxy@xxxxxxxxxxxxx>
You are correct that your test case fails because the cifs client does not allow you to update the file size from the remote server while the file is open for writing and thus potentially being extended on the client. Changing this to allow updates from the remote server of a file that is growing on the server is doable but would require careful changes to avoid races with writepage/writepages.
Your patch was close to what was needed for the lseek part, but fixing serialization between is_size_safe_to_write and writepage/writepages and setattr is needed.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: January 04, 2006
From: moorse@xxxxxxxxxxxxxxxxx
In-reply-to:
References:
Hi, I previously sent the following message to the smb-clients list. I just found out about this list, and think it is more suited here. So here it is again: I hope some-one can help me with this issue: I am trying to mount a share (I believe this is an MS-DFS share) on my linux FC4 box, running a precompiled 2.6.14 kernel and using the latest samba software (3.0.21a) I could find. I was really happy to find out that smbclient can finally resolve the shares properly. Older versions never worked and always returned an error code. (Which I know now indicates that it is an MS-DS share) If I however try to mount the same share using cifs.mount I get the following behaviour: # sudo mount.cifs //cos/share/rem /home/me/rem -o user=rem,dom=rdom Password: retrying with upper case share name mount error 6 = No such device or address Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) This command succesfully connects to the share: # smbclient //cos/share/rem -Urem -Wrdom I am running a fairly recent kernel, I don't suspect that cifs.ko is too old, is it? (couldn't find a newer version of it) # uname -r 2.6.14-1.1653_FC4 # modinfo /lib/modules/2.6.14-1.1653_FC4/kernel/fs/cifs/cifs.ko filename: /lib/modules/2.6.14-1.1653_FC4/kernel/fs/cifs/cifs.ko parmtype: CIFSMaxBufSize:int parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 parmtype: cifs_min_rcv:int parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 parmtype: cifs_min_small:int parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 parmtype: cifs_max_pending:int parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 author: Steve French <sfrench@xxxxxxxxxx> license: GPL description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows version: 1.35 vermagic: 2.6.14-1.1653_FC4 686 REGPARM 4KSTACKS gcc-4.0 depends: srcversion: 410817CEE7E1AE3B2BE003B Is this the expected behaviour? Is MS-DFS support not yet available for cifs.mount? Or am I running into some completely different problem? Any insights available? thanks, Eric
Date: January 01, 2006
From: Steve French <smfrench@xxxxxxxxxxxxx>
We've developed yet another test-case in order to see what our problem with data-loss is (I'm attaching the code). It opens a file, and when the user presses ENTER, a newline is appended to the end of the file (locking the whole file to do this, then unlocking it)
I was able to reproduce your reported bug - I think adding the lseek entry may be a good example as you note. I will look at this along with evaluating your suggested patch over the new years day break - I do want to compare what happens in similar situations in other fs. Thanks for reporting this and putting together an easy test case.
On another topic - I have made an implementation of SMB NT Transact Query Security Descriptor - although I do not parse the data yet. I will check this in after the new years break. This should help get us closer to where cifs can query CIFS/NTFS style ACLs over the wire - translating to POSIX ACLs and/or mode bits. I will need help for this making the mapping perfect.
