From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier Tarifa Subject: Re: Slow When accessing Samba Share Date: Tue, 16 Jun 2009 18:10:56 +0200 Message-ID: <4A37C410.9020009@adbosch.es> References: <23fd749a0906160642s22faf507i5f9377300012e9e2@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070701030608080203030102" Return-path: In-Reply-To: <23fd749a0906160642s22faf507i5f9377300012e9e2@mail.gmail.com> Sender: linux-msdos-owner@vger.kernel.org List-ID: To: Andrew Joakimsen Cc: dosEmu-list This is a multi-part message in MIME format. --------------070701030608080203030102 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable I think I had the same problem when accessing a novell netware volume. I=20 suppose that your problem is that file opening is very slow. I tracked the problem to the function scan_dir in the file mfs.c The problem is that when dosemu needs to open a file, to work around the=20 difference between the case sensitiveness between linux and DOS, the 8.3 filename convention etc etc, it loops through all the=20 files in the directory trying to find a match. When it's working on local it doesn't matter but when you're working with a network=20 filesystem like novell netware or windows shares you can see network traffic maxing out and file opening being pretty slow. As novell (like samba) does itself name translation (you can access a=20 file named testfile.txt as TESTFILE.TXT etc) I worked around the problem with the patch I attach, you could modify it as you see fit. Andrew Joakimsen escribi=F3: > I have an old DOS application (clipper/blinker) that runs well under > DOSEMU when the files are local. When the Samba share is mounted and I > use lredir for that share it is very slow -- slower than Windows XP > clients that access the same share on the same server. > > Furthermore I have a DOS error 5 when I try a function in that program > on a Linux client with the SMB share. If I select retry it works. What > seems to happen is that the program is creating a file and then tries > to read it. I think because access is so slow, the file is not created > until after it tries to access it. > > On the server is running dosemu-1.4.0.1 and like I said, it works with > no problems... it runs quicker than on the XP machines. On the client > it is dosemu-1.4.0.0 (which is odd, because I downloaded DOSEMU from > the site only a few days ago and the other one has been running over 6 > months) > > What can I do to solve this? > > Server: > > #smb.conf: > [drive_x] > comment =3D comment > inherit acls =3D Yes > path =3D /data/drive_x/ > read only =3D No > create mask =3D666 > guest ok =3Dyes > > > Client: > > #fstab: > //server/drive_x /mnt/win cifs > username=3Dlinstation01,password=3Danything,rw 0 0 > > #autoexec.bat: > lredir x: linux\fs\mnt\win > -- > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ------------------------------------------------------------------------ > > > Se certific=F3 que el correo entrante no contiene virus. > Comprobada por AVG - www.avg.es=20 > Versi=F3n: 8.5.339 / Base de datos de virus: 270.12.73/2180 - Fecha de la= versi=F3n: 06/16/09 07:41:00 > > =20 --------------070701030608080203030102 Content-Type: text/plain; name="scandir_patch.patch.old" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scandir_patch.patch.old" --- dosemu-1.4.0/src/dosext/mfs/mfs.c.orig 2009-01-29 09:10:16.000000000 +0100 +++ dosemu-1.4.0/src/dosext/mfs/mfs.c 2009-01-29 09:11:15.000000000 +0100 @@ -1788,6 +1788,13 @@ path = "/"; Debug0((dbg_fd,"scan_dir(%s,%s)\n",path,name)); + //Si busco en /mnt/novellf/DADES/.., lo daremos como bueno, + //si no existe devolvera false igual cuando intente hacer + //el stat + //Si busco en cualquier otro sitio, seguiremos normal + if( strncmp(path,"/mnt/novellf/DADES/",19) == 0){ + return(TRUE); + } /* check if name is an LFN or not; if it's 8.3 then dosname will contain the uppercased name, and --------------070701030608080203030102--