From owner-freebsd-fs@FreeBSD.ORG Sat Feb 7 15:10:25 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6992516A4CF for ; Sat, 7 Feb 2004 15:10:25 -0800 (PST) Received: from rdsnet.ro (smtp.rdsnet.ro [62.231.74.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D4E443D1F for ; Sat, 7 Feb 2004 15:10:24 -0800 (PST) (envelope-from itetcu@apropo.ro) Received: (qmail 28062 invoked from network); 7 Feb 2004 23:10:23 -0000 Received: from unknown (HELO it.buh.cameradicommercio.ro) (81.196.25.19) by mail.rdsnet.ro with SMTP; 7 Feb 2004 23:10:23 -0000 Date: Sun, 8 Feb 2004 01:12:16 +0200 From: Ion-Mihai Tetcu To: Bruce Evans Message-Id: <20040208011216.4c062e97@it.buh.cameradicommercio.ro> In-Reply-To: <20040208084754.O725@gamplex.bde.org> References: <20040207155819.186335d4@it.buh.cameradicommercio.ro> <20040208084754.O725@gamplex.bde.org> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org Subject: Re: Painful speed for copying to fat32 partitions with small cluster size. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 23:10:25 -0000 On Sun, 8 Feb 2004 09:19:04 +1100 (EST) Bruce Evans wrote: > On Sat, 7 Feb 2004, Ion-Mihai Tetcu wrote: > > > Does anyone know why this happens or what to do ? > > > > Setup: UDMA133 primary master, UFS2; UDMA100 secondary master, FAT32. > > > > Copying to FAT32 partitions is very slow with small cluster sizes (I was > > copying some 300 - 700MB files): > > > > FAT32 clustersize=4K 500KB/s > > FAT32 clustersize=32K 3.5MB/s > > FAT32 clustersize=64K 6.2MB/s > > FAT32 clustersize=128K 6.4MB/s > > FAT16 6.5MB/s > > > > Reading speed is the same. > > Lots of things are suboptimal, including your disk apparently not liking > small writes (or reads?). I don't think reads are the problem; I cannot say for sure, since I haven't done real testing, but I'll try. When I've said 'Reading speed is the same.' I meant that I get the same reading speed no mater the cluster size. For reference: Primary master (copying from) is: ATA-7 disk at ata0-master 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B 16 secs/int, 1 depth queue, UDMA133 and secondary slave (copying to) is: ATA-6 disk at ata1-master 152626MB (312579695 sectors), 310098 C, 16 H, 63 S, 512 B 16 secs/int, 1 depth queue, UDMA100 the controller is: VIA 8237 chip > Try this patch: Thank you, I'll try it in about a week or so, since I don't have the disk in anymore. > %%% > Index: msdosfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.147 > diff -u -2 -r1.147 msdosfs_vnops.c > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > +++ msdosfs_vnops.c 5 Feb 2004 08:11:38 -0000 > @@ -771,5 +791,9 @@ > (void) bwrite(bp); > else if (n + croffset == pmp->pm_bpcluster) > +#if 0 > bawrite(bp); > +#else > + bdwrite(bp); > +#endif > else > bdwrite(bp); > %%% > > With it, I get 3+ MB/sec from iozone with a write size of 4K to a file > system with a cluster size of 4K on an old 6.3GB drive with 9MB/sec max > transfer speed, and writing 512-blocks is not much slower. Without it, > writing 4K blocks goes fast enough but writing 2K blocks is 10 times > slower. > > It won't help reads. Reading seems ok, from both disks. > See ffs_write() for a more complete version of this. ffs_write() > normally uses cluster_write() for the full-block case where the original > version of the above uses foot-shooting; both ffs_write() and > msdosfs_write() use bdwrite() for partial blocks and ffs_write() also > sets B_CLUSTEROK for this and most other cases. As fair as I understand, > bdwrite() with B_CLUSTEROK is just as good as, if not better than > cluster_write() (the former gives a delayed clustered write and the > latter gives an immediate clustered write if the cluster is full and > is no different otherwise; the advantage of cluster_write() is that it > gives a better hint to vfs_bio that the write should be done soon). > > > Newfs_msdos on a 30G partition: > > > > itetcu@it> /home/itetcu [16:31:40] 1 > > # newfs_msdos -F32 -b65536 /dev/ad2s1 > > /dev/ad2s1: 167746176 sectors in 1310517 FAT32 clusters (65536 bytes/cluster) > > bps=512 spc=128 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=167766732 bspf=10239 rdcl=2 infs=1 bkbs=2 > > itetcu@it> /home/itetcu [16:34:48] 0 > > # > > > > The same with 4K clusters takes about 50 minutes ! > > Your disk apparently doesn't like writing 4K-blocks and mine apparently > doesn't like writing 2K-blocks. Write caching probably helps a lot here. True, hw.ata.wc=0. BTW, with this setting atacotrol says: Feature Support Enable Value Vendor write cache yes yes read ahead yes yes which confuses me. -- IOnut Unregistered ;) FreeBSD user