Date: Mon, 3 Aug 1998 17:26:02 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, rock@cs.uni-sb.de Subject: Re: IO performance (UFS read clustering), bad ZIP drive performance Message-ID: <199808030726.RAA16337@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I get unacceptable performance from my SCSI ZIP drive (compared to other >operating systems). While UFS writing is OK (up to the capabilities of the >drive: 600-1000 kB/s), everything else (UFS read, MSDOSFS r/w, mtools) >is extremely slow (down to 80 kB/s). ufs clustered reads have been broken (except on wd drives) since rev.1.18 (1998/01/24) of ufs_bmap.c. SCSI ZIPs have a huge command overhead (20 msec here on an ncr 53c810) and don't seem to support tags, so performance without clustering is poor. Fix: diff -c2 ufs_bmap.c~ ufs_bmap.c *** ufs_bmap.c~ Mon Jul 6 14:07:01 1998 --- ufs_bmap.c Mon Aug 3 16:08:26 1998 *************** *** 164,168 **** } ! if (maxrun == 0) { vp->v_maxio = DFLTPHYS; maxrun = DFLTPHYS / blksize; --- 164,168 ---- } ! if (maxrun <= 0) { vp->v_maxio = DFLTPHYS; maxrun = DFLTPHYS / blksize; Performance is poor for other normal disk file systems because clustering is only implemented for ufs (including ffs and ext2fs). Performance is poor for specfs since it uses a too-small block size and doesn't implement clustering. Since ufs normally uses clustered reads instead of plain read-ahead, even read-ahead has been broken. This is probably unimportant on modern drives, since the drive does the read-ahead. The breakage may even be an optimization - O/S read-ahead takes more CPU and may confuse the drive. Similarly for O/S read clustering except on drives with a large command overhead - it takes even more CPU and is even more likely to confuse the drive. This is probably why the breakage wasn't noticed before. >Why does the (now simulated?) block device divide I/O into chunks of only 2k? It has to use a fixed block size for various reasons. The size seems to be 2K for historical reasons. 2K was a lot of memory 20 years ago. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808030726.RAA16337>