Re: Problems mounting a Windows share *solved*
Well, after much testing I've found that the problem is the pcn(4) network driver. As I told you in the dmesg I was using VMware, specifically the ESX. I found that when I used heavily the network (such as a long ls from the shell), the output just freezes even with a listing of 1000 directories. # cd /mnt/remote # ls freezes after a while # cd /mnt/remote # ls | wc works in every case, no matter how much directories I have in the remote. So it seems that this driver just works but is not usable with heavy network traffic. I set up a physical machine, identical to the virtual but with the fxp(4) driver and everything works ok, even the ls of 20.000 directories. I found some other posts here recommending to use the le(4) driver or the vic(4) driver in the virtual machines, but I'm not sure of the troughput I will get with those drivers in case they work ok (I see posts doubting it). So the decision is switch to a physical machine and experiment sometime later with a virtual machine in the ESX server. Thanks to all of you for your aid in debugging. -Joaquin Herrero
Re: Problems mounting a Windows share
Joaquin Herrero wrote: Hi everyone, I'm trying to set up a sftp server for my boss using OpenBSD. It will be used for heavy work from 10 remote places in the country. The file repository is in a Windows 2003 Server, so I have to mount that repository to put there the files uploaded. As OpenBSD does not allow smbmount I first tried mounting the remote file system with sharity-light. The file repository has a very crowded top level with some 20.000directories in the root directory. I cannot change that. With sharity-light the remote machine gets mounted ok, but when I issue a ls on the root directory, I get a partial list of directories and then the listing hangs forever. I then installed the Services for Unix (SFU) in the Windows Server, and mounted the remote drive via NFS: # mount -t nfs -o -T winserver:/Data /mnt/winserver Then tried the ls. Same result: partial list and hangs. The NFS and sharity-light works ok for the normal operations, such as file upload and download and partial directory listing. But as you know, the graphical ftp clients show the list of directories in the first screen they show, so they are not usable with the OpenBSD machine. I tried the same from a Linux machine and it works ok in both tests: with smbmount and with a NFS mount. I have to wait some 30 seconds to get the full listing but it works ok. It seems to me that there's some kind of limit that I am reaching in OpenBSD with that ls. But I am completely lost. Can you help me with some ideas, please? Thanks -Joaquin Herrero [dmesg snipped] Are you committed to sftp? I investigated http://www.sslbridge.com/ for our company as a means to provide remote access to files. It was trivial to set up, and just worked. I was quite impressed. They actually have a very good demo site, so you don't even need to waste time installing software to make an evaluation if it will serve the purpose or not. Just thought it was worth mentioning. Good Luck, Steve Williams
Re: Problems mounting a Windows share
2007/2/28, Steve Williams [EMAIL PROTECTED]: Are you committed to sftp? I investigated http://www.sslbridge.com/ for our company as a means to provide remote access to files. I checked this product and it's really impressive. I will definitely try it but not for this project. I have to setup a secure FTP because the transfers are really big: hundreds of scans per day. People involved in this project are used to make bulk transfers in the background using programmable FTP clients, so for this project what I need is a robust and secure FTP. I used until now a Windows machine with a third party FTP server, but now I have to open this service to users in the Internet, so Windows is not an option in this new scenario. The options are Linux or OpenBSD, and I would like to use OpenBSD of course. Just thought it was worth mentioning. Many thanks for your idea. -Joaquin Herrero
Re: Problems mounting a Windows share
On Wednesday 28 February 2007, Joaquin Herrero wrote: I checked this product and it's really impressive. I will definitely try it but not for this project. I have to setup a secure FTP because the transfers are really big: hundreds of scans per day. People involved in this project are used to make bulk transfers in the background using programmable FTP clients, so for this project what I need is a robust and secure FTP. I used until now a Windows machine with a third party FTP server, but now I have to open this service to users in the Internet, so Windows is not an option in this new scenario. The options are Linux or OpenBSD, and I would like to use OpenBSD of course. Maybe both Linux and openBSD. Use Linux as an ftp server so that cifs is available for mounting the remote filesystem (smbfs would be useless anyway do to its 2GB limit and other issues - it's deprcated). Since the files are huge, a non-encrypted data stream (ftp vs. sftp) will be much faster. If some paranoia exists with ftp's use of non-encrypted password, place an openBSD box running authpf on the frontend (if you already have an openBSD firewall no need for a new box) allowing ftp access on authentication. Chris
Re: Problems mounting a Windows share
2007/2/28, Fred Crowson [EMAIL PROTECTED]: Hi Joaquin, Have you considered using authpf to authenticate users and then allow them to connect directly to the Windows 2003 through the OpenBSD box? Thus firewalling the 2003 server from the internet. Hi Fred, thanks for your answer. Your suggestion is another way of doing something that is already working. What I have now is a sftp-server accesible via SSH with a SFTP client, and the users have to use a certificate to authenticate, so the secure access to the FTP server from the Internet is configured and working. Authenticating also with the firewall is an extra protection that I can consider. But the problem that remains is to configure the OpenBSD machine so that when I access the internal Windows machine via NFS or via sharity-light it does not freeze reading a directory with 20.000 files on it. Regards, -Joaquin Herrero
Re: Problems mounting a Windows share
On Wed, Feb 28, 2007 at 05:38:28PM +0100, Joaquin Herrero wrote: Hi everyone, I'm trying to set up a sftp server for my boss using OpenBSD. It will be used for heavy work from 10 remote places in the country. The file repository is in a Windows 2003 Server, so I have to mount that repository to put there the files uploaded. As OpenBSD does not allow smbmount I first tried mounting the remote file system with sharity-light. The file repository has a very crowded top level with some 20.000directories in the root directory. I cannot change that. With sharity-light the remote machine gets mounted ok, but when I issue a ls on the root directory, I get a partial list of directories and then the listing hangs forever. I then installed the Services for Unix (SFU) in the Windows Server, and mounted the remote drive via NFS: # mount -t nfs -o -T winserver:/Data /mnt/winserver Then tried the ls. Same result: partial list and hangs. The NFS and sharity-light works ok for the normal operations, such as file upload and download and partial directory listing. But as you know, the graphical ftp clients show the list of directories in the first screen they show, so they are not usable with the OpenBSD machine. I tried the same from a Linux machine and it works ok in both tests: with smbmount and with a NFS mount. I have to wait some 30 seconds to get the full listing but it works ok. It seems to me that there's some kind of limit that I am reaching in OpenBSD with that ls. But I am completely lost. Can you help me with some ideas, please? Perhaps there's some strange MTU problem? Or a buffer in the NFS implementation that doesn't work correctly (in both cases, only directories with lots of files are problematic, but the cutoff point is likely very different)? You'll have to wait for someone with actual clue to work at a true solution, though. You could always try NFS/CIFS-exporting the disk from the OpenBSD box, but I'm not sure that would do what you want. Joachim
Re: Problems mounting a Windows share
On Wed, Feb 28, 2007 at 05:38:28PM +0100, Joaquin Herrero wrote:
Hi everyone,
I'm trying to set up a sftp server for my boss using OpenBSD. It will be
used for heavy work from 10 remote places in the country.
The file repository is in a Windows 2003 Server, so I have to mount that
repository to put there the files uploaded.
As OpenBSD does not allow smbmount I first tried mounting the remote file
system with sharity-light.
The file repository has a very crowded top level with some
20.000directories in the root directory. I cannot change that.
With sharity-light the remote machine gets mounted ok, but when I issue a
ls on the root directory, I get a partial list of directories and then the
listing hangs forever.
I then installed the Services for Unix (SFU) in the Windows Server, and
mounted the remote drive via NFS:
# mount -t nfs -o -T winserver:/Data /mnt/winserver
Then tried the ls. Same result: partial list and hangs.
The NFS and sharity-light works ok for the normal operations, such as file
upload and download and partial directory listing. But as you know, the
graphical ftp clients show the list of directories in the first screen they
show, so they are not usable with the OpenBSD machine.
I tried the same from a Linux machine and it works ok in both tests: with
smbmount and with a NFS mount. I have to wait some 30 seconds to get the
full listing but it works ok.
It seems to me that there's some kind of limit that I am reaching in OpenBSD
with that ls. But I am completely lost.
Can you help me with some ideas, please?
It might not actually be OpenBSD's fault.
I tried the following script, on a NFS share mounted from a Feb 17
4.1-beta/i386 box to another such box (this is a self-compiled version;
the second has RAIDframe built in):
#!/bin/sh
for j in `jot 101 0 100`; do
echo `date '+%H%M%S'`: ${j}000;
for i in `jot 1000 0 1000`; do # Yes, I realize that should
# have been 1 now... still, not
# a problem
mkdir /home/joachim/www/test-$j-$i || {
echo mkdir $j-$i failed;
exit 1; }
done
ls /home/joachim/www/testdir /home/joachim/out
done
The result was:
000602:
000612: 1000
000630: 2000
000643: 3000
000653: 4000
000710: 5000
000726: 6000
000745: 7000
000807: 8000
000830: 9000
000902: 1
000918: 11000
000947: 12000
001002: 13000
001017: 14000
001034: 15000
001102: 16000
001117: 17000
001138: 18000
001154: 19000
001221: 2
001238: 21000
001252: 22000
001307: 23000
001334: 24000
001349: 25000
001404: 26000
001419: 27000
001445: 28000
001501: 29000
001516: 3
001531: 31000
001557: 32000
mkdir: /home/joachim/www/test-32-763: Input/output error
mkdir 32-763 failed
This was on an almost-empty filesystem exported via NFS. The I/O error
occured when some table got too big, as I can create files and
directories other than on the root, and files on the root, but no
directories. This is true both via NFS and directly on the host. (It
appears there are 32765 directories on the root at this moment; this is
almost precisely 50% of all inodes available on the filesystem, which
may or may not mean anything.)
Also, the ls command in sftp works fine, both when sftp'ing to localhost
and to the NFS server.
In this case, the mount options are:
calliope:/var/www/users/joachim on /home/joachim/www type nfs (nodev, nosuid,
v3, udp, soft, intr, timeo=100)
Of course, everything does take a while; ls via sftp isn't particularly
fast, for example. (Looking at the various blinkenlights, I'd venture a
guess that this particular process is disk bound, especially towards the
end, which seems logical. Note that the mounting machine is *much*
faster than the server.)
Joachim
Re: Problems mounting a Windows share
On Wed, 28 Feb 2007, Joaquin Herrero wrote: Hi everyone, I'm trying to set up a sftp server for my boss using OpenBSD. It will be used for heavy work from 10 remote places in the country. The file repository is in a Windows 2003 Server, so I have to mount that repository to put there the files uploaded. As OpenBSD does not allow smbmount I first tried mounting the remote file system with sharity-light. The file repository has a very crowded top level with some 20.000directories in the root directory. I cannot change that. With sharity-light the remote machine gets mounted ok, but when I issue a ls on the root directory, I get a partial list of directories and then the listing hangs forever. I then installed the Services for Unix (SFU) in the Windows Server, and mounted the remote drive via NFS: # mount -t nfs -o -T winserver:/Data /mnt/winserver I have no windows machines, but I can try to recreate your problem using an OpenBSD NFS server. One question: can yo try with UDP mounts also (leave out the -T)? -Otto Then tried the ls. Same result: partial list and hangs. The NFS and sharity-light works ok for the normal operations, such as file upload and download and partial directory listing. But as you know, the graphical ftp clients show the list of directories in the first screen they show, so they are not usable with the OpenBSD machine. I tried the same from a Linux machine and it works ok in both tests: with smbmount and with a NFS mount. I have to wait some 30 seconds to get the full listing but it works ok. It seems to me that there's some kind of limit that I am reaching in OpenBSD with that ls. But I am completely lost. Can you help me with some ideas, please? Thanks -Joaquin Herrero Pd. Here you have the dmesg. - OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Opteron(tm) Processor 285 (AuthenticAMD 686-class, 1024KB L2 cache) 2.61 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT real mem = 267939840 (261660K) avail mem = 236662784 (231116K) using 3296 buffers containing 13500416 bytes (13184K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6f) BIOS, date 04/21/04, BIOS32 rev. 0 @ 0xfd880, SMBIOS rev. 2.31 @ 0xe4010 (45 entries) bios0: VMware, Inc. VMware Virtual Platform apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xfd880/0x780 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1a00! 0xca000/0x1000 0xdc000/0x4000! 0xe4000/0x4000! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x01 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 ignored (disabled) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: NECVMWar, VMware IDE CDR10, 1.00 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x08: SMBus disabled vga1 at pci0 dev 15 function 0 VMware Virtual SVGA II rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 Symbios Logic 53c1030 rev 0x01: irq 9 scsibus1 at mpi0: 16 targets sd0 at scsibus1 targ 0 lun 0: VMware, Virtual disk, 1.0 SCSI2 0/direct fixed sd0: 3072MB, 3072 cyl, 64 head, 32 sec, 512 bytes/sec, 6291456 sec total mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1 pcn0 at pci0 dev 17 function 0 AMD 79c970 PCnet-PCI rev 0x10, Am79c970A, rev 0: irq 10, address 00:50:56:bb:4d:4d isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask eb65 netmask ef65 ttymask ffe7 pctr: user-level cycle counter enabled dkcsum: sd0
Re: Problems mounting a Windows share
2007/3/1, Otto Moerbeek [EMAIL PROTECTED]: I have no windows machines, but I can try to recreate your problem using an OpenBSD NFS server. Thanks! One question: can yo try with UDP mounts also (leave out the -T)? Yes, i tried also with UDP. Same results.
Re: Problems mounting a Windows share
On Thu, 1 Mar 2007, Joachim Schipper wrote:
It might not actually be OpenBSD's fault.
I tried the following script, on a NFS share mounted from a Feb 17
4.1-beta/i386 box to another such box (this is a self-compiled version;
the second has RAIDframe built in):
#!/bin/sh
for j in `jot 101 0 100`; do
echo `date '+%H%M%S'`: ${j}000;
for i in `jot 1000 0 1000`; do # Yes, I realize that should
# have been 1 now... still, not
# a problem
mkdir /home/joachim/www/test-$j-$i || {
echo mkdir $j-$i failed;
exit 1; }
done
ls /home/joachim/www/testdir /home/joachim/out
done
The result was:
000602:
000612: 1000
000630: 2000
000643: 3000
000653: 4000
000710: 5000
000726: 6000
000745: 7000
000807: 8000
000830: 9000
000902: 1
000918: 11000
000947: 12000
001002: 13000
001017: 14000
001034: 15000
001102: 16000
001117: 17000
001138: 18000
001154: 19000
001221: 2
001238: 21000
001252: 22000
001307: 23000
001334: 24000
001349: 25000
001404: 26000
001419: 27000
001445: 28000
001501: 29000
001516: 3
001531: 31000
001557: 32000
mkdir: /home/joachim/www/test-32-763: Input/output error
mkdir 32-763 failed
This was on an almost-empty filesystem exported via NFS. The I/O error
occured when some table got too big, as I can create files and
directories other than on the root, and files on the root, but no
directories. This is true both via NFS and directly on the host. (It
appears there are 32765 directories on the root at this moment; this is
almost precisely 50% of all inodes available on the filesystem, which
may or may not mean anything.)
Also, the ls command in sftp works fine, both when sftp'ing to localhost
and to the NFS server.
In this case, the mount options are:
calliope:/var/www/users/joachim on /home/joachim/www type nfs (nodev, nosuid,
v3, udp, soft, intr, timeo=100)
Of course, everything does take a while; ls via sftp isn't particularly
fast, for example. (Looking at the various blinkenlights, I'd venture a
guess that this particular process is disk bound, especially towards the
end, which seems logical. Note that the mounting machine is *much*
faster than the server.)
A directory (or any file) can not have more than 2^15-1 hard links to
it. In the inode, di_nlink is a signed 16 bits type.
For directories, you have the . and .. link, so that leaves room for
32765 files and subdirectories. So (after fixing the counts in your
script ;-) I get (after about 2 minutes):
mkdir: lots/test-32-766: Too many links
mkdir 32-766 failed
I ran this locally on my file server.
The directory with 32765 dirs in it can be listed witout problems,
both locally and on a NFS client. This is using an UDP mount.
All this running current, the OP didn't say which version he is
running. There have been NFS related fixes put in the tree during this
year, iirc.
-Otto
