Custom Search
|
Date: December 31, 2005
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<20051227120021.7FD6D163A6E@xxxxxxxxxxxxxxx>
References:
<20051227120021.7FD6D163A6E@xxxxxxxxxxxxxxx>
Shrinking the socket RCVBUFFER will probably hurt performance. A few obvious things to try to narrow down the performance issues -1) does mounting with "forcedirectio" mount option improve the performance (this bypasses the page cache, reducing memory usage, on the client but will be slower if the data is reused by the application). In conjunction with increasing the default buffer size (which is an insmod parms for cifs.ko - try "/sbin/modprobe cifs.ko" to see more details) this can also allow cifs to use larger than the default sizes (4 pages ie 16K for reads and one page ie 4K for writes). More recent cifs than what you have allows 52K writes (13 pages) rather than 4K writes - cifs 1.39a e.g. may help a lot with write sizes.
An extra memory copy and bufalloc has also been eliminated in the read path in recent cifs.
On older kernels like you that which you were using the testing I have tried showed about 20% link utilization for the case of single process, large file writes and two or three times better for reads due to the bigger buffer (depends on link speed, latency and some other factors) - obviously that is better now with larger writes but still won't reach 80% or more utilization on gigabit due to a couple factors holding current cifs implementation back on very fast links (such as gigabit ethernet) in particular that cifs only sends one request on the wire at a time causes dead time on the wire waiting for acks. Multiprocess or multithreaded cases can do somewhat better of course. The cifs server implementation can be a problem too - so that is worth checking. I find that getting a network trace of the link from a third machine or - comparing network traces on the client and server of a large file copy to server (and similarly from server) is the easiest way to tell which is the more important problem - client or server delay.
There are some details of performance analysis profiling that I have added to the
Linux cifs client at: http://marc.theaimsgroup.com/?l=linux-cifs-client&m=112984422914324&w=2
Hi, I recently bought a NAS (network attached storage). This only supports ftp and smb/cifs. I can mount this device with no problems using cifs or smbfs, but the transferrate is far below of ftp. While transfering files using ftp I get rates of about 8-10mb/s but with cifs/smbfs I only get 1,5mb/s. As I intend to use this as a backup device this speed is not tolerable. Here are some specs to the "client system" running linux: Kernel 2.6.14.3 Samba: 3.0.14a-3 (debian) smbfs: 3.0.14a-3 (debian) Using any options like SND_RCVBUFFER=8192 did not bring any performance increase whatsoever. Can you point me in a direction how to debug this slow speed? Cheers and thanks, Nicki - --
Date: December 30, 2005
From: Maximiliano Curia <maxy@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). You can test this by running it over a cifs mounted resource in two different machines, or just running it in one machine and using "echo blablabla >> locktest.txt" in another. Unfortunately it's not possible to use any windows clients to test it. So, if you open this program in machine A, and then write some info into the file from machine B, and then press enter on machine A again: 1. With standard cifs/kernel, A overwrites the data from B, never even knowing that the file grew. 2. With the llseek patch (and commenting out the calls to "is_size_safe_to_change"), A overwrites the data, but leaving \0 chars in the place where the added data should be. (i.e. size is correct, data is not) 3. With the previous patch & commenting out the "PageUptodate" check that is done inside the cifs_prepare_write function, A sees B's changes and nothing is lost (but other test cases fail). Now, the solution proposed in 3. is not really good, because other test cases still fail, like running the "tlock" program -mentioned in a previous message- twice in the same machine. But this seems to show what's really going on: with the current cifs code, a client with an open file never gets to know if this file has grown (until it's closed and opened again); adding the llseek function makes the client see the change in the file size, but since the whole page is sent to the server and the rest of the page-data is not refreshed, the empty data is filled with \0. Possible solutions to this last problem would be to make the client send only the changed bytes (and not the whole page), or find a way to correctly update the pages. I'd say that the first one would be better, since it leaves the paging work to the server, and the amount of data transmitted is kept to what's really needed instead of a whole page for just a few bytes. But it might be that the second is simpler to implement. PS: the file is compiled with: gcc -o simplelock -lreadline simplelock.c -- Saludos, /\/\ /\ >< `/
simplelock.c
Description: Text Data
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29/12/05
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 30, 2005
From: studdugie <studdugie@xxxxxxxxx>
Hello. I'm using the CIFS client included with the 2.6.14 linux
kernel on the AMD64 Opteron processor. Every few weeks the CIFS client
crashes with the following message (from dmesg):
Unable to handle kernel paging request at 0000387294fa11c4 RIP:
<ffffffff8020e3c5>{small_smb_init+53}
PGD 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in:
Pid: 167, comm: cifsoplockd Tainted: G M 2.6.14 #1
RIP: 0010:[<ffffffff8020e3c5>] <ffffffff8020e3c5>{small_smb_init+53}
RSP: 0000:ffff81007feabe08 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff8102ff5fea00 RCX: ffff81007feabed8
RDX: 0000387294fa1180 RSI: 0000000000000008 RDI: 0000000000000024
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000024 R14: 0000000000000000 R15: 0000000000000000
FS: 00000000402bd960(0000) GS:ffffffff80563800(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000387294fa11c4 CR3: 000000014dde0000 CR4: 00000000000006e0
Process cifsoplockd (pid: 167, threadinfo ffff81007feaa000, task
ffff81007fea9620)
Stack: ffff81007feabed8 0000000880156b0b ffff81007feabe58 0000000000000000
ffff8102ff5fea00 ffffffffffffffff ffff81022934de50 ffffffff80162707
0000000000000000 ffffffff80162bf3
Call Trace:<ffffffff80162707>{pagevec_lookup+23}
<ffffffff80162bf3>{invalidate_mapping_pages+211}
<ffffffff8020fb07>{CIFSSMBLock+151}
<ffffffff8020e2f9>{cifs_oplock_thread+441}
<ffffffff8010ea9e>{child_rip+8} <ffffffff8020e140>{cifs_oplock_thread+0}
<ffffffff8010ea96>{child_rip+0}
Code: 83 7a 44 02 0f 84 21 02 00 00 48 8b 42 38 48 85 c0 0f 84 14
RIP <ffffffff8020e3c5>{small_smb_init+53} RSP <ffff81007feabe08>
CR2: 0000387294fa11c4
<6>Machine check events logged
general protection fault: 0000 [2] SMP
CPU 0
Modules linked in:
Pid: 20266, comm: cifsd Tainted: G M 2.6.14 #1
RIP: 0010:[<ffffffff8012ce39>] <ffffffff8012ce39>{try_to_wake_up+57}
RSP: 0018:ffff81024e399dd8 EFLAGS: 00010096
RAX: 33322e3631322f2f RBX: ffff8102ce5af980 RCX: 000000000000000f
RDX: 0000000000000000 RSI: 000000000000000f RDI: ffff81007fea9620
RBP: ffff81024e399e38 R08: ffff81007fe20a50 R09: ffff81007fe20a60
R10: 00000000000a757c R11: 0000000000000000 R12: ffffffff805a3640
R13: ffff81007fea9620 R14: ffff8102ce5af980 R15: 000000000000000f
FS: 00002aaaaade6ae0(0000) GS:ffffffff80563800(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aab5f4ce000 CR3: 000000022e1f5000 CR4: 00000000000006e0
Process cifsd (pid: 20266, threadinfo ffff81024e398000, task ffff8102f65b8960)
Stack: ffff8102fe4ca200 ffff810143fadd30 0000000000008009 0000000000000000
0000000086e0d980 0000000000000292 0000000000000296 ffff8102ce5af980
ffff81007ffb9840 ffff8102ce5af980
Call Trace:<ffffffff80221539>{is_valid_oplock_break+521}
<ffffffff802168ae>{cifs_demultiplex_thread+2158}
<ffffffff8010ea9e>{child_rip+8}
<ffffffff80216040>{cifs_demultiplex_thread+0}
<ffffffff8010ea96>{child_rip+0}
Code: 8b 40 18 48 c1 e0 07 48 8b 98 08 38 56 80 4c 01 e3 48 89 df
RIP <ffffffff8012ce39>{try_to_wake_up+57} RSP <ffff81024e399dd8>
The share to which the error refers is a Windows 2003 (SP1) box.
Unfortunately, I'm unable to reproduce the error at will, but I hope
what I've posted can still be benefical.
I'm not expecting a "fix" or anything like that but I would certainly
appreciate if someone could fill me in as to what side of the
communications channel is responsible for the error, CIFS or Windows.
Thanx,
Dane
Date: December 29, 2005
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
In-reply-to:
<200512291044.57048.maxy@xxxxxxxxxxxxx>
References:
<OF2BE90ED1.75B35FFE-ON872570E5.00128511-862570E5.00128071@xxxxxxxxxx> <200512291044.57048.maxy@xxxxxxxxxxxxx>
On Thursday 29 December 2005 10:44, Maximiliano Curia wrote: > I think that this might be related to an incorrect way of handling lockings > from dosemu/clipper, and I'm about to write a testcase in C to confirm > what's going on. I wrote two test programs that reproduce a part of my data-loss problem, both test failed, even on a 2.6.15-rc5. I'm not not an expert on record locking programming, so I might be making a mistake. Please take a look of them. The tests wait to have another client to start appending data to a file. The append is made with a lseek and a write. The main difference between the test is that in "tlocks1" I lock the whole file and in "tlocks" just the record and a lock in the first byte of the file is used as a sem. I don't know how to code an equivalent example in win32. Any suggestion would be appreciated. -- Saludos, /\/\ /\ >< `/
tlocks.c
Description: Text Data
tlocks1.c
Description: Text Data
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27/12/05
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 29, 2005
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
In-reply-to:
<OF2BE90ED1.75B35FFE-ON872570E5.00128511-862570E5.00128071@xxxxxxxxxx>
References:
<OF2BE90ED1.75B35FFE-ON872570E5.00128511-862570E5.00128071@xxxxxxxxxx>
On Wednesday 28 December 2005 00:22, Steven French wrote: > Does this also fail on more recent code (e.g. 2.6.15-rc cifs 1.39 or so)? I've tried applying the cifs 1.39a to the 2.6.14 kernel tree, and the lseek problem was still there. I applied the patch that I had mentioned before (I'm attaching it as a proper diff with this message), but it didn't fix the problem, not even for read-only files. So, I commented out the calls to is_size_safe_to_change(), and lseek works fine, but I'm still having data-loss problems. These problems are due to the fact that apparently the cifs client for Linux sends blocks of 4096 bytes to the server, of which only 52 bytes need to be written, and between the reading of the file and the writing of the record, some of those 4096 bytes have been changed by a remote app. I think that this might be related to an incorrect way of handling lockings from dosemu/clipper, and I'm about to write a testcase in C to confirm what's going on. But in any case, why does the cifs client send 4096 bytes over the network, when only 52 bytes are being modified? (those bytes aren't locked, neither by this client nor by any other) Is there a way to fix this? To be fair, I do not see the client sending the block of 4096 bytes, since I'm using strace, but I _do_ see the server writing the big block, but it only writes 52 bytes when windows clients send a similar request. -- Saludos, /\/\ /\ >< `/
cifs_llseek.patch
Description: Text Data
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27/12/05
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 28, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200512271406.00904.maxy@xxxxxxxxxxxxx>
References:
<200512271406.00904.maxy@xxxxxxxxxxxxx>
Does this also fail on more recent code (e.g. 2.6.15-rc cifs 1.39 or so)?
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: December 27, 2005
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
In-reply-to:
<200512271406.00904.maxy@xxxxxxxxxxxxx>
References:
<200512271406.00904.maxy@xxxxxxxxxxxxx>
On Tuesday 27 December 2005 14:06, Maximiliano Curia wrote: > I'm debugging some data-loss problems that I've been having, with old > clipper applications running inside dosemu. I work in a mixed-client > environment with some Windows and some Linux clients. All the servers run > Linux. As a follow up to the previous message, I've been reading more of the cifs code and I realized that the lseek call returns the wrong value when the file has been opened in *write mode*. This is explained in the comment section before the "is_size_safe_to_change" function (called from inside the revalidate function, that is used when doing an lseek), in the "inode.c" file: /* We do not want to update the file size from server for inodes open for write - to avoid races with writepage extending the file - in the future we could consider allowing refreshing the inode only on increases in the file size but this is tricky to do without racing with writebehind page caching in the current Linux kernel design */ I understand the reasoning behind this statement, but this doesn't seem to take into account that multiple stations might have the file open for writing and the file might have been modified externally. I'm dealing with all this because I'm experiencing severe data-loss, because the multiple-client situation is real: multiple stations are updating the same dbf files, and the Linux stations don't update the file sizes and therefore overwrite whatever was written by the other stations. So, I really need to work around this problem. I guess that I need to rewrite the "is_size_safe_to_change" function, but I'm not sure what the best approach to fixing it correctly is. Any advice will be appreciated. -- Saludos, /\/\ /\ >< `/
Date: December 27, 2005
From: Maximiliano Curia <maxy@xxxxxxxxxxxxx>
Hi!
I'm debugging some data-loss problems that I've been having, with old clipper
applications running inside dosemu. I work in a mixed-client environment with
some Windows and some Linux clients. All the servers run Linux.
Trying to find the root of the problem I've written some C code that
reproduces the bad behaviour.
One of the problems I've found is with lseek. For example, doing this:
end = lseek (fd, 0, SEEK_END);
over a file that changes externally (another client is adding records to it)
returns the same value as long as you don't do something else with the
cifs connection.
I've written an small test program [1] that checks the return value of lseek
and waits for it to change. To test it you have to make a change to a file
(tlseek.tst) remotely.
In order to fix the problem, I've added a simple cifs_llseek in cifsfs.c for
kernel tree 2.6.14 (based on the nfs code for the same purpose):
static loff_t cifs_llseek(struct file *file, loff_t offset, int origin)
{
/* origin == SEEK_END => we must revalidate the cached file length */
if (origin == 2) {
int retval = cifs_revalidate(file->f_dentry);
if (retval < 0)
return (loff_t)retval;
}
return remote_llseek(file, offset, origin);
}
And registered the cifs_llseek in cifs_file_ops.
This does fix the lseek problem inside the C program [2], but it does not fix
it for programs running under dosemu. When doing an strace of those [3], the
call to lseek still returns the same value every time, even if the file has
changed.
If I strace the file-server, each lseek triggers an fstat64 call, that
correctly returns the new file size. However, for some weird reason the
lseek function does not take this value.
I can't yet figure out what the difference might be. The output of strace is
quite similar, but the results are pretty different.
[1] http://gnuservers.com.ar/~maxy/linux/tlseek.c
[2] http://gnuservers.com.ar/~maxy/linux/tlseek.strace
[3] http://gnuservers.com.ar/~maxy/linux/dosemu.strace (filtered version,
that only includes the important data and some of the lseek calls, this was
actually running for a very long time, and there was never a change in the
lseek return value, no matter how large the file got)
--
Saludos,
/\/\ /\ >< `/
Date: December 27, 2005
From: Nicki Messerschmidt <cifsml@xxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I recently bought a NAS (network attached storage). This only supports ftp and smb/cifs. I can mount this device with no problems using cifs or smbfs, but the transferrate is far below of ftp. While transfering files using ftp I get rates of about 8-10mb/s but with cifs/smbfs I only get 1,5mb/s. As I intend to use this as a backup device this speed is not tolerable. Here are some specs to the "client system" running linux: Kernel 2.6.14.3 Samba: 3.0.14a-3 (debian) smbfs: 3.0.14a-3 (debian) Using any options like SND_RCVBUFFER=8192 did not bring any performance increase whatsoever. Can you point me in a direction how to debug this slow speed? Cheers and thanks, Nicki - -- Linksystem Muenchen GmbH info@xxxxxxxxx Schloerstrasse 10 http://www.link-m.de 80634 Muenchen Tel. 089 / 890 518-0 We make the Net work. Fax 089 / 890 518-77 PGP Keys: https://www.link-m.de/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Get keys at: https://www.link-m.de/pgp iD8DBQFDsSbW6zWc+bXuIEMRAl0gAKDB+OK+ZKzeDD9iyQ8WEEszUbxw5wCZActR 4BkxsWD7vFMd5rbeubFwN1E= =hmlZ -----END PGP SIGNATURE-----
Date: December 21, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<43A57863.9050903@xxxxxxxxxxxxx>
References:
<43A57863.9050903@xxxxxxxxxxxxx>
cifs_writepages is optional - if no cifs_writepages (larger than 4K writes, ie multiplage at a time) is exported it will fall back to cifs_writepage (write one page at a time ie 4K)
You can safely remove cifs_writepages
The pagevec stuff (as an export) was added fairly recently to the kernel
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>
12/18/2005 08:55 AM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 18, 2005
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<43A444E8.7000700@xxxxxxxxxxxxx>
References:
<OF8BAB04BD.0C4DDA2C-ON872570C9.00661D35-862570C9.0066748B@xxxxxxxxxx> <43A444E8.7000700@xxxxxxxxxxxxx>
Steven, I wrote: > On a vanilla 2.6.14 I get > > *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined! > *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined! > > when build CIFS as a module. I found out. cifs_writepages() in fs/cifs/file.c calls pagevec_lookup_tag() which is in mm/swap.c. Since I have a small embedded system _without_ any swap partition I disabled "Support for paging of anonymous memory (swap)" (CONFIG_SWAP). So because cifs_writepages() is wrapped CONFIG_CIFS_EXPERIMENTAL I must not enable this. Right? What does cifs_writepages() do? Swap partition on a Samba share? Would the rest of CIFS still work without the swap stuff? Cheers, Steven
Date: December 17, 2005
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<OF8BAB04BD.0C4DDA2C-ON872570C9.00661D35-862570C9.0066748B@xxxxxxxxxx>
References:
<OF8BAB04BD.0C4DDA2C-ON872570C9.00661D35-862570C9.0066748B@xxxxxxxxxx>
Steven, > I posted an updated version of cifs which matches what is in the > cifs-2.6.git tree on kernel.org > http://us1.samba.org/samba/ftp/cifs-cvs/cifs-1.39a.tar.gz > This will only compile on relatively recent kernels (perhaps 2.6.13 or > later). I do plan to post a version (which will work with earlier 2.6. > kernels) later this month. On a vanilla 2.6.14 I get *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined! *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined! when build CIFS as a module. What does that mean? -- Steven Scholz
Date: December 16, 2005
From: "Prof. Dr.-Ing. Wilhelm Meier" <meier@xxxxxxxxxxxxxxxxxxx>
In-reply-to:
<OFAE52567D.C27648BD-ON872570D8.00800086-862570D8.00800D9F@xxxxxxxxxx>
References:
<OFAE52567D.C27648BD-ON872570D8.00800086-862570D8.00800D9F@xxxxxxxxxx>
Am Freitag, 16. Dezember 2005 00:18 schrieb Steven French: > krb5 support is started but not dropped in to the devel tree yet - there is > still major surgery on the userlevel code necessary > > By the way where is pam_cifs source these days? pam_cifs is available from http://sourceforge.net/projects/pam-cifs/ > > > Steve French > Senior Software Engineer > Linux Technology Center - IBM Austin > phone: 512-838-2294 > email: sfrench at-sign us dot ibm dot com > > > > Wilhelm Meier > <meier@informatik > .fh-kl.de> To > linux-cifs-client@xxxxxxxxxxxxxxx > 12/15/2005 01:12 cc > PM Steven French/Austin/IBM@IBMUS > Subject > Re: [linux-cifs-client] updated > mount.cifs man page > > > > > > > > > > > I saw this new sec-option with krb5-support. Is this already usable? I > would > like to drop pam_cifs in the future for mounting cifs-shares at login and > use > pam_krb5 together with this new krb5-support in mount.cifs. > > Any experience? > > Am Mittwoch, 14. Dezember 2005 00:18 schrieb Steven French: > > man page for mount.cifs has been updated (see > > http://us2.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html) > > > > I see one typo already - corrections/clarifications/suggestions welcome. > > > > > > Steve French > > Senior Software Engineer > > Linux Technology Center - IBM Austin > > phone: 512-838-2294 > > email: sfrench at-sign us dot ibm dot com > > -- > -- > Wilhelm Meier > email: meier@xxxxxxxxxxxxxxxxxxx -- Prof. Dr.-Ing. Wilhelm Meier Fachhochschule Kaiserslautern | phone: 06332-914 326 Standort Zweibrücken | 06332-914 301 FB Informatik/Mikrosystemtechnik| fax: 06332-914 305 Amerikastraße 1 | email: meier@xxxxxxxxxxxxxxxxxxx 66482 Zweibrücken | w.meier@xxxxxxxx Germany | URL: http://mozart.informatik.fh-kl.de
pgpPflWdHaFsK.pgp
Description: PGP signature
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 15, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200512152012.32141.meier@xxxxxxxxxxxxxxxxxxx>
References:
<200512152012.32141.meier@xxxxxxxxxxxxxxxxxxx>
krb5 support is started but not dropped in to the devel tree yet - there is still major surgery on the userlevel code necessary
By the way where is pam_cifs source these days?
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Wilhelm Meier <meier@xxxxxxxxxxxxxxxxxxx>
12/15/2005 01:12 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 15, 2005
From: "Wagner, Chris (GEAE, CBTS)" <chris.wagner@xxxxxxxxx>
References:
<OF68D17DC7.9B80667A-ON872570D8.000F1415-862570D8.00116F64@xxxxxxxxxx>
My thoughts exactly. Not only put the 's but also pronounce it. When I'm writing something "formal" I make sure to not even end a sentence with a preposition. :) Steven French wrote: > I remember one phenomenal book, the once standard book on English writing, > "The Elements of Style," which addresses this very question on page one > (probably because it is the most common counter-intuitive style error in > common written English). It decrees: > > Form the possessive singular of nouns by adding 's. Follow this rule > whatever the final consonant. Thus write, > > Charles's friend > Burns's poems > the witch's malice > -- Chris Wagner CBTS GE Aircraft Engines Chris.Wagner@xxxxxxxxx
Date: December 15, 2005
From: Wilhelm Meier <meier@xxxxxxxxxxxxxxxxxxx>
In-reply-to:
<OFE78BFD34.78EC608F-ON872570D6.0080034F-862570D6.00800EEE@xxxxxxxxxx>
References:
<OFE78BFD34.78EC608F-ON872570D6.0080034F-862570D6.00800EEE@xxxxxxxxxx>
I saw this new sec-option with krb5-support. Is this already usable? I would like to drop pam_cifs in the future for mounting cifs-shares at login and use pam_krb5 together with this new krb5-support in mount.cifs. Any experience? Am Mittwoch, 14. Dezember 2005 00:18 schrieb Steven French: > man page for mount.cifs has been updated (see > http://us2.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html) > > I see one typo already - corrections/clarifications/suggestions welcome. > > > Steve French > Senior Software Engineer > Linux Technology Center - IBM Austin > phone: 512-838-2294 > email: sfrench at-sign us dot ibm dot com -- -- Wilhelm Meier email: meier@xxxxxxxxxxxxxxxxxxx
Date: December 15, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.62.0512150139370.30131@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<Pine.LNX.4.62.0512150139370.30131@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Martin,
Thanks for the feedback I will make most of these changes.
> If the word already ends in s, then no s follows the apostrophe, I think.
This brings back very fun memories. I finished my CS degree early so I had time and took extra English literature courses in University ... so if Computers ever go out of style I have other options :)
I remember one phenomenal book, the once standard book on English writing, "The Elements of Style," which addresses this very question on page one (probably because it is the most common counter-intuitive style error in common written English). It decrees:
Form the possessive singular of nouns by adding 's. Follow this rule
whatever the final consonant. Thus write,
Charles's friend
Burns's poems
the witch's malice
Exceptions are the possessives of ancient proper names ...
In the introduction they quote an example from a famous newspaper headline of the Times which got the same thing wrong too. The test is if "Windows" is a single thing (an operating system, or class of operating systems, rather than an assortment of portals with glass in them on the front and sides of a building). If it is singular then it gets 's no matter whether it ends in s. Of course for clarity the best strategy is to remove all doubt by rewording the sentence.
For those who love precision in language, and computer scientists are often among those who love precision, I highly recommend that still classic little book: "The Elements of Style" by Strunk and White. I know of no better book of its type. But I must confess that I break his simply stated, clear rules dozens of times each day in writing (and since there are only about 40 rules this can be embarrassing ...). This book is so good, so small - I wish people wrote programming manuals as clearly (although K&R was close) as those two geniuses wrote the standard 57 (!) page manual for written English.
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: December 15, 2005
From: Martin Koeppe <mkoeppe@xxxxxx>
In-reply-to:
<OFE78BFD34.78EC608F-ON872570D6.0080034F-862570D6.00800EEE@xxxxxxxxxx>
References:
<OFE78BFD34.78EC608F-ON872570D6.0080034F-862570D6.00800EEE@xxxxxxxxxx>
On Tue, 13 Dec 2005, Steven French wrote:
man page for mount.cifs has been updated (see http://us2.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html) I see one typo already - corrections/clarifications/suggestions welcome.
Currently, I see two: in "directio" description:Note that direct_io_ allows write operations larger than page size to be sent to the server.
in "mapchars" description: I think it should not read "Windows's POSIX emulation" but"Windows' POSIX emulation". If the word already ends in s, then no s follows the apostrophe, I think.
While looking at the mapchar documentation, I just remember a discussion about POSIX filename characters at:
http://cygwin.com/ml/cygwin/2005-12/msg00164.htmlIn short, this is about to even map 0x01-0x1F to 0xF001-0xF01F, and that the special chars are mapped differently by Windows SFU and SFM.
So maybe the manual should mention how the used sfu mapping is done, i.e. by adding 0xF000 to the special char ascii value,
and the mapping should be enhanced by the 31 ascii control chars. Martin
Date: December 14, 2005
From: Steve French <smfltc@xxxxxxxxxx>
The patch I put in cifs-2.6.git recentlyhttp://www.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=ec637e3ffb6b978143652477c7c5f96c9519b691 improved dbench performance about 10% in my limited testing. I think it should improve read performance somewhat more.
Date: December 13, 2005
From: Steven French <sfrench@xxxxxxxxxx>
man page for mount.cifs has been updated (see http://us2.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html)
I see one typo already - corrections/clarifications/suggestions welcome.
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: December 12, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<439D2CEB.4070901@xxxxxxxxx>
References:
<439D2CEB.4070901@xxxxxxxxx>
>Our test machines that have a number of read-only cifs mounts with
>various versions of windows and samba on the other end. We're running an
>application that walks the tree of mounts and spawns about 8 concurrent
>threads to visit all the leaf nodes.
...
> Dec 6 16:26:38 oyabox-2p6p14p2 kernel: fs/cifs/netmisc.c: !!Mapping smb error code 33 to POSIX err -13 !!
> Dec 6 16:26:38 oyabox-2p6p14p2 kernel: fs/cifs/file.c: CIFS VFS: leaving cifs_read (xid = 25555407) rc = -13
ERRlock on read is coming from the server - it would be useful to know which type of server(s) is returning this. This is a legal return code that would be intuitive if your application does posix byte range locks - e.g. it is possible that the application locked a byte range in the file (denying read) with a different handle than it is using to read the file (I have seen this kind of "bug" in a few Linux apps) which will work in POSIX (albeit not really what you want if you want to be clearest) but not in Windows (which expects that a byte range lock really means a byte range lock and enforces them and expects you to use the right file handle etc.). There are still some compensations that may be possible in the advisory (posix) -> mandatory (cifs) byte range lock code but I won't be convinced that this is the likely cause until I see whether mounting with "nobrl" mount option avoids the problem. If nobrl does not solve the problem, then we have to look at the server side and see how a file which is not byte range locked can return ERRlock on SMB ReadX (e.g. trace through the Samba smbd code which does the read handling) but I think it is more likely that the file is locked and the wrong file handle is being used by the application for the read (if so disabling sending locks remotely, they still work locally ala posix) via nobrl will help if the app can't be changed.
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: December 11, 2005
From: Steve French <smfrench@xxxxxxxxxxxxx>
Date: December 09, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<1134158783.2568.5.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1134158783.2568.5.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
It is possible that if existing mounts from the same client to that server were still around that mounting with a new password would be ignored (the mount ie "tree connection" to the smb share would be attempted but not the SMB "session setup") as we would try to reuse the existing tcp connection and smb user session. If the existing smb session were no longer valid (bad password) there may be a hole there.
I don't think there is an easy mechanism (yet) to "remount" with a different (new/changed) password when your old one that you originally mounted with is bad - usually this is harmless as smb sessions don't usually "time out" if there are open files (and even without open files can take hours to time out) so you can stay connected for quite a long time without having to resend a sessionsetup (transparently reconnect).
One place that needs to be checked in the code is whether "remount" or a second mount to a different share on the same server should
1) save off the new password, so future reconnects use the new password
2) try the old smb session
3) if that fails try to reconnect ie send a new session setup using the new password
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: December 07, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<200512071625.56449.josh.hamacher@xxxxxxxx>
References:
<200512071625.56449.josh.hamacher@xxxxxxxx>
> got CIFS 1.39a compiled into our 2.6.11.7 kernel. I
> had to wing it in a few spots but it seems to be running fine; no panics,
> nothing like that, so I don't think I messed it up too badly.
>
> And the good news: I've run my stress test twice (it takes roughly ten
> minutes per) and it didn't fail either time. I've always seen the failure
> before now with older CIFS versions, so apparently the latest-and-greatest
> did the trick. I'm going to keep testing (as this is something we need to be
> 100% reliable) but all indications are positive so far.
I am glad that current code, cifs version 1.39a, worked well.
Between coding and the software filesystem/server design work I do,
I have been having trouble the project website and backports up to date so not
all of the community may have seen the stability (not just functional)
progress yet - but I think it really is getting better and your feedback
is not the only one that sees pretty good results. I still would like to beat
NFS performance in more cases going Linux cifs to Samba :) not just beat
Windows client performance but there are enough functional/security features
that are necessary before we attack it full time. I probably need to put some
of the information about backports (how to most easily backport to
kernel version x.y) on the website and some of the testing info there too ...
My recent work has been on some buffer optimizations in read/readpages and readdir
which should help reduce some of the stress problems people see with lots (more
than 30 or so) of threads doing simultaneous big buffer operations (read and readdir
are probably the nastiest) during low memory conditions under extreme stress.
By eliminating one large buffer alloc and a memcopy this should not only help
performance but the last really.
The kerberos code and ACL code is also starting to be staged in ...
I really do appreciate the community help in any way you can. This is getting
to be a very interesting story (whether the server is Windows or Samba or Netapp
or something else).
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: December 05, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<439484E5.7CBCDF96@xxxxxxxxx>
References:
<439484E5.7CBCDF96@xxxxxxxxx>
> I would only point out that Cygwin does things this way to maintain
> compatability with FAT32 which doesn't support magic file types on the disk.
I believe that most of the SFU "magic file types" would work much the same
on FAT32 as they do on NTFS as they rely on
1) the system attribute (which FAT32 supports)
2) a small amount of file data indicating the type and e.g.
link target or device numbers (which should also work to FAT32)
The SFU approach to mode bits on the other hand would probably not work on FAT32
as it requires ACLs and sometimes OS/2 [NTFS] EAs - but it would be worth testing
to make sure (I am trying to find some FAT formatted USB storage around here,
I probably have some FAT formatted things somewhere). Similarly hard links
probably don't won't with FAT32 as they do with NTFS. Ideally cygwin like CIFS
would "fall back" to the more primitive mode of storing posix information if the
optimal ways do not work (ie cygwin can take a primitive fall back approach on
FAT32 that is worse than when on NTFS - it is easy for cygwin to tell which fs
it is on).
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: December 05, 2005
From: "Wagner, Chris (GEAE, CBTS)" <chris.wagner@xxxxxxxxx>
References:
<Pine.LNX.4.62.0511302100160.4106@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Martin Koeppe wrote: > A concrete problem on cygwin is that you can create device files, but > these device files are shown as symlinks instead of as device files > cygwin$ mkfifo myfifo && ls -l myfifo > prw-rw-rw- 1 martin mkpasswd 102 Nov 30 23:09 myfifo > The fifo is made correctly and shown as such, but has a file size of > 102 which is <>0, so not, what I would have expected. > It would be nice if Cygwin could store these files in the same way as > SFU. And Samba could then convert the SFU method to real device and > fifo files on the disk. For the cifs client, work has begun to include > the SFU way: > http://lists.samba.org/archive/linux-cifs-client/2005-November/001073.html > The only thing one could discuss is how to store symlinks. Cygwin's > symlinks can be followed in Windows Explorer, whereas SFU symlinks are > more consistent, as they are named exactly the same on the > underlying disk, no .lnk appended. I would only point out that Cygwin does things this way to maintain compatability with FAT32 which doesn't support magic file types on the disk. So the only way to do it is as normal files with special contents or attributes. I do believe however that Cygwin compiled apps (samba etc) will respect Cygwin's magic files. -- Chris Wagner CBTS GE Aircraft Engines Chris.Wagner@xxxxxxxxx
Date: December 05, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<9328bcc00512041131k7f69e270w1f37493634674e28@xxxxxxxxxxxxxx>
References:
<9328bcc00512041131k7f69e270w1f37493634674e28@xxxxxxxxxxxxxx>
> apologies if this has been considered before, also for not opening a
> bugzilla account. please consider adding a mount flag "intr" as in
> nfs, also an option to time out on reads.
cifs vfs does support hard/soft mount options which are helpful for some of the same reasons as intr, but I did not add an intr because I was not certain its effect on the tcp socket write api and I was not certain that the nfs approach to timing out requests would translate perfectly to the way wait_event is used in fs/cifs/transport.c SendReceive and SendReceive2
CIFS Reads of course do time out (15 seconds IIRC) see fs/cifs/transport.c the calls to wait_event - but until very recently (cifs version 1.39a) the wait queue was not woken up often enough when only a single process was accessing the mount - so requests could sit "ready to time out" but not actually waking up. This has changed recently - to have the notify thread wake up every 15 seconds and try to wakeup timedout requests (so could a bit more than 15 seconds depending on when the requests were sent to actually time out). Unfortunately there are a few cases (readdir for example) where the request will time out but retry (as if the "hard" mount option were specified). The cifs code does honor the "soft" (do not retry as much) mount option (which is the default) but only in the reconnection path (not in the case of a tcp and smb connnection which are still up - but the requests are timed out - cifs will retry those).
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: December 05, 2005
From: Amadeu Andrade Barbosa Junior <amadeu@xxxxxxxxxx>
In-reply-to:
<43945226.8000501@xxxxxxxxxx>
References:
<43945226.8000501@xxxxxxxxxx>
Hi Folks,
I am still stuck with my cifs/samba/ldap problem. Summarizing my answers
to Steven's questions:
> Does anything change if you try from a different client e.g.
>"smbclient //IP_SAMBA_SERVER/user -U user%BLA"
> or is it a similar error?
With smbclient, things appear to work. I am able to list files at the
prompt with ls.
>Does trying:
>"mount -t cifs //IP_SAMBA_SERVER/user /tmp/user -o
>username=user,password=BLA,domain=DCC"
>(ie adding the domain name) make any difference?
No, it doesn't.
> On the server have you verified that the account
>exists from the local systems perspective, not just from the Samba/LDAP
>perspective(e.g. you can su to the account)?
Yes, I can su to 'poxxxa' account.
Can anyone suggest something I could do to direct me towards the
solution. I am willing to try anything to get this working. I am
currently using smb with my 200 users and I get all sorts of problems
with permissions and file size reporting. That's why I am keen to move
into Cifs which someone told me could solve my problems. But I am stuck
on this permission problem.
--
|> Amadeu Jr. :: Estudante de Ciência da Computação - UFBa
Bolsista da Rede do DCC/UFBa - www.dcc.ufba.br
|> Mensagem :: "A desobediência é uma virtude necessária à criatividade"
Date: December 02, 2005
From: Martin Koeppe <mkoeppe@xxxxxx>
In-reply-to:
<Pine.LNX.4.62.0511302100160.4106@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<Pine.LNX.4.62.0511302100160.4106@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
[please cc me on replies] On Thu, 1 Dec 2005, Martin Koeppe wrote:
8. CreateHardLink() Windows API [cygwin] [ActivePerl] ======================================================The CreateHardLink() Windows API function isn't apparently able to create hardlinks on network drives, whereas with the sfu ln utility, you can. Both C:\sfu\common\ln.exe and C:\sfu\bin\ln work, where the former seems to call the latter internally. As CreateHardLink() is used by cygwin (and ActivePerl, too), you cannot with these.
I just verified that CreateHardLink() works correctly on network drives, IF you use WinXP or Win2003. I tested successfully WinXP-SP2 and Win2003-SP0.
On Win2000-SP4 however, it does not work. :-( Thank you, Corinna. Martin
Date: December 01, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.62.0511302100160.4106@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<Pine.LNX.4.62.0511302100160.4106@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Thanks for the useful summary. >The CreateHardLink() Windows API function isn't apparently able to >create hardlinks on network drives, Windows does support hardlinks over the network of course (via CIFS). I expect that they handle this from the Win32 API via a flag on the rename API call. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com
Date: December 01, 2005
From: Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>
In-reply-to:
<OF41398EC3.11338A21-ON872570CA.00594EB3-862570CA.0059C2B5@xxxxxxxxxx>
References:
<20051201150513.40a965fe@xxxxxxxxxxxxxxxxxxxx> <OF41398EC3.11338A21-ON872570CA.00594EB3-862570CA.0059C2B5@xxxxxxxxxx>
Le Thu, 1 Dec 2005 10:20:09 -0600 Steven French <sfrench@xxxxxxxxxx> écrivait: > > It is possible, and probably not even that hard to map the two (Samba > already has such code for the reverse case) - I can get you started, > but I am swamped. I sort of understood that already :) > ... so the only issue is that there are Windows ACLs which are hard > to represent perfectly in POSIX ACLs - but if the primary guy > writing and reading them are the remote clients you are probably ok. Excellent. The way the Samba server represents windows ACLs is "good enough" for me. Would you by any chance know where in the samba source tree the windows ACLS-to-POSIX ACLs mapping is done, so I can "reverse" it as accurately as possible ? > Take a look at the tool smbcacls in the samba tree as well. > Arrrrgh. I didn't know this tool, and it would have saved me countless headaches. I'm trying to achieve something that sounds all simple and easy, and would be useful to almost all and every samba users out there : first backup a window machine _from_the_samba_server_, files and ACLs. Then be able to share the saved files with samba, still preserving the ACLs. I think backing up the files first (using rsync or whatever), then the ACLs in a second pass will be a fine start. However I need to get the windows->POSIX mapping right, so that the samba server simulates accurately the windows share the other way around (was it clear? hum..) -- ---------------------------------------- Emmanuel Florac | Intellique ----------------------------------------
Date: December 01, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051201150513.40a965fe@xxxxxxxxxxxxxxxxxxxx>
References:
<20051201150513.40a965fe@xxxxxxxxxxxxxxxxxxxx>
It is possible, and probably not even that hard to map the two (Samba already has such code for the reverse case) - I can get you started, but I am swamped.
Jeremy Allison did a talk a few years ago on the topic of comparing POSIX to Windows ACLs (actually there is more than one flavor of Windows ACLs) and concluded it is reasonable to do such a mapping albeit with a small amount of lost information as the Windows ACLs are richer than POSIX ACLs in function - fortunately in the Linux client case this is not as much of a problem as POSIX ACLs are a subset of the Windows ACL function (Samba server has a harder job) so the only issue is that there are Windows ACLs which are hard to represent perfectly in POSIX ACLs - but if the primary guy writing and reading them are the remote clients you are probably ok.
Take a look at the tool smbcacls in the samba tree as well.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 12/01/2005 08:05 AM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: December 01, 2005
From: Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>
I'm still struggling to find a way to read the ACLs from a CIFS share (from a windows server or a NetApp). Is there any way to achieve this ? I'm OK to study the source code and write a patch if someone thinks it possible to write a (even temporary and ugly) hack for that (mapping windows ACLs to POSIX ACLs would be OK). -- ---------------------------------------- Emmanuel Florac | Intellique ----------------------------------------
Date: December 01, 2005
From: Martin Koeppe <mkoeppe@xxxxxx>
Hello, [please cc me on replies]while playing around with a Windows server (2003), a Linux server (2.6.11) with Samba (3.0.14a) and a Windows client (2000) with both Interix Services for Unix (SFU) (3.5) and Cygwin (1.5.19pre20051130) installed, I encountered the following problems or inconsistencies when using on the one hand SFU and Cygwin on Windows and Samba network shares, and on the other hand when using linux-cifs on Windows shares, where locally Cygwin or SFU are used.
Most of these problems have been already discussed, and some of them have been solved in between, but I'm cross-posting this summary now to all lists involved on that, I hope at least.
Here interoperability is meant as storing special unix file attributes (special files, mode bits and user/group ids) in such a way, that they ideally are interpreted in the same way by all Windows<->Unix connecting software.
(I have marked in [], which of the software mentioned in this mail's subject I think should be changed for better interoperability.)
1. storage of special files such as symlinks, fifos, devs [all] ================================================================ The way that SFU stores these special files, I tried to explore at: http://lists.samba.org/archive/linux-cifs-client/2005-May/000856.htmlCygwin has its own way which I observed by a quick look (so may not be completely correct):
http://lists.samba.org/archive/linux-cifs-client/2005-November/001080.htmlA concrete problem on cygwin is that you can create device files, but these device files are shown as symlinks instead of as device files (even on C:), i.e.
cygwin$ mknod myblock b 0 0 cygwin$ ls -l lrwxrwxrwx 1 martin mkpasswd 10 Nov 30 23:10 myblock -> :\0:0:61b6 cygwin$ test -b myblock && echo "block" [ does not echo "block", so is not seen as a block device file ] cygwin$ test -l myblock && echo "link" bash: test: -l: unary operator expected cygwin$ perl -e '-l "myblock" && print "link"' link So "test" dies unexpectedly, but perl doesn't. Another problem. cygwin$ mkfifo myfifo && ls -l myfifo prw-rw-rw- 1 martin mkpasswd 102 Nov 30 23:09 myfifo The fifo is made correctly and shown as such, but has a file size of 102 which is <>0, so not, what I would have expected.It would be nice if Cygwin could store these files in the same way as SFU. And Samba could then convert the SFU method to real device and fifo files on the disk. For the cifs client, work has begun to include the SFU way:
http://lists.samba.org/archive/linux-cifs-client/2005-November/001073.htmlThe only thing one could discuss is how to store symlinks. Cygwin's symlinks can be followed in Windows Explorer, whereas SFU symlinks are more consistent, as they are named exactly the same on the underlying disk, no .lnk appended.
2. test -l does not work [cygwin] ================================= I repeat this here from above for clarity: cygwin$ test -l a_link && echo "link" bash: test: -l: unary operator expected cygwin$ perl -e '-l "a_link" && print "link"' link So "test" dies unexpectedly, but perl doesn't. 3. set file bits [all] =======================SFU stores the set file bits in an extended attribute called SETFILEBITS, for details see:
http://lists.samba.org/archive/linux-cifs-client/2005-June/000865.htmlCygwin seems to store the set bits with the help of a special acl entry for the "NULL SID". At least chmod 07777 creates such an acl entry, and after manually deleting it, the file has no longer set bits set in cygwin's opinion.
While both of these methods can be used to store these infos on a windows server share, it would be nice, if it could be stored by a samba server as well, ideally in such a way, that locally on the samba server the file mode is the same as within SFU and/or Cygwin.
The cifs client ideally should show and set these mode bits as well from within linux, when one runs Cygwin and/or SFU on a Windows server. Work is in progress on that, see:
http://lists.samba.org/archive/linux-cifs-client/2005-November/001073.html 4. file and directory lower 9 mode bits [all] ==============================================While Corinna has written a good howto on mapping the mode bits on Windows ACL entries:
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping I found one issue not documented there though: Suppose you have on Windows the following directories: C:\temp\t1\t2 Now you change the permissions with explorer in the following way: t2: has access allowed for the current user (non-inherited) t1: all ACL entries are removed You can now do the following on a CMD.EXE: C:\temp> cd t1 Permission denied! C:\temp> cd t1\t2 C:\temp\t1\t2> So chdir into t2 is possible.On Cygwin t1 is shown by ls as d---------, but "cd t1/t2" nevertheless works.
On interix sfu, t1 is also shown as d---------, but "cd t1/t2" doesn't work. Even though it works via Windows Explorer or CMD.EXE.
I don't know which behaviour should be implemented here, I just wanted to document the differences.
Maybe the following on FILE_TRAVERSE and BYPASS_TRAVERSE_CHECKING is helpful:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp 5. normal files [samba] =======================Within the SFU environment, normal files from a samba server are incorrectly shown as directories, see: https://bugzilla.samba.org/show_bug.cgi?id=3295
6. uid/gid [samba] ==================On a samba (3.0.14a and 3.0.21rc1) mounted drive G: sfu's ls shows different uids when called with or without -n:
C:\SFU\common>ls.exe -l G:\file.txt -rwxr--r-- 1 3001 3001 6 Dec 1 11:37 /dev/fs/G/file.txt C:\SFU\common>ls.exe -ln G:\file.txt -rwxr--r-- 1 3000 3001 6 Dec 1 11:37 /dev/fs/G/file.txtThis is only on samba drives, on Windows drives, for the non -n call, Windows user names are shown:
C:\SFU\common>ls.exe -l C:\config.sys -rwxrwxrwx 1 +Administratoren +SYSTEM 0 May 11 2003 /dev/fs/C/CONFIG.SYS C:\SFU\common>ls.exe -ln C:\config.sys -rwxrwxrwx 1 131616 66834 0 May 11 2003 /dev/fs/C/CONFIG.SYS 7. hard links and inode numbers [cygwin] ========================================While Cygwin now reports link count and inode numbers on network drives correctly, SFU reports the inode numbers correctly (modulo an issue with samba), but the link count on network drives is always reported as "1". Maybe that's intentional. See: http://cygwin.com/ml/cygwin/2005-11/msg00854.html https://bugzilla.samba.org/show_bug.cgi?id=3287
8. CreateHardLink() Windows API [cygwin] [ActivePerl] ======================================================The CreateHardLink() Windows API function isn't apparently able to create hardlinks on network drives, whereas with the sfu ln utility, you can. Both C:\sfu\common\ln.exe and C:\sfu\bin\ln work, where the former seems to call the latter internally. As CreateHardLink() is used by cygwin (and ActivePerl, too), you cannot with these.
Unfortunately, the error returned by CreateHardLink() doesn't say "hardlinks not supported", but it says "file not found":
cygwin$ ln file file2 ln: creating hard link `file2' to `file': No such file or directory See for a possible solution: http://cygwin.com/ml/cygwin-patches/2005-q2/msg00091.html http://cygwin.com/ml/cygwin-patches/2005-q2/msg00093.html http://bugs.activestate.com/show_bug.cgi?id=39027 Martin
