From owner-freebsd-questions Tue Nov 3 15:17:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01490 for freebsd-questions-outgoing; Tue, 3 Nov 1998 15:17:58 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from hecate.webcom.com (hecate.webcom.com [209.1.28.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01485 for ; Tue, 3 Nov 1998 15:17:57 -0800 (PST) (envelope-from graeme@echidna.com) Received: from kigal.webcom.com (kigal.webcom.com [209.1.28.57]) by hecate.webcom.com (8.9.1/8.9.1) with SMTP id PAA16420; Tue, 3 Nov 1998 15:17:42 -0800 Received: from [209.122.117.150] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 19473789; Tue Nov 03 15:16 PST 1998 Message-Id: <363F8F49.EE1DD0EE@echidna.com> Date: Tue, 03 Nov 1998 18:18:33 -0500 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 4.02 [en]C-DIAL (Win95; U) Mime-Version: 1.0 To: Dan Nelson Cc: freebsd-questions@FreeBSD.ORG Subject: Re: File system performance References: <363F7AA3.22254A9C@echidna.com> <19981103162515.A17979@emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson wrote: > > In the last episode (Nov 03), Graeme Tait said: > > I have a situation that involves manipulating large numbers of small > > files of about 1k each. I recently noticed a strange performance > > comparison between my "play" system (a 486-DX2/66/16MB with > > run-of-the-mill IDE drives and a Promise caching controller, running > > 2.2.6R) and "production" system (Pentium-II/400/256MB with Ultra 2 LVD > > SCSI and 4.5GB Seagate Cheetah drives, running 2.2.7S/CAM). > > When you say caching controller, do you mean that it's got a write > cache? If so, then you're probably running your filesystem in the > equivalent of async mode, which would explain the speed increase. Yes, it does do write caching (2MB of cache). You can disable the write caching, or disable caching altogether. When I have time, I will experiment with this and mounting the file systems async. > > When deleting these files (rm -rf), the 486 does it with a minimum of > > fuss (no trashing of the disk heads) at about 120 files a second. Disk > > operations occur ever second or so with intervals between. > > Looks like a write cache to me. A single file deletion only writes a > few parts of the disk, but it does it synchronously. So a thousand > deletes in the same directory results in at least two thousand seeks, > back and forth to the same couple disk blocks. Your caching controller > is probably just caching the writes. Aha! I've learned something. I notice the vendor who configured this system with FreeBSD had set up fstab to mount usr/obj,ports and src as follows (/usr/www is a slice I created where the small files reside): /dev/da1s1f /usr/www ufs rw 2 2 /dev/da1s1e /usr/obj ufs rw,noauto,async,noatime 2 2 /dev/da0s1g /usr/ports ufs rw,noauto,async,noatime 2 2 /dev/da0s1f /usr/src ufs rw,noauto,async,noatime 2 2 So I assume this is advantageous (and any risk acceptable) during a make. I guess the question is though, in the present situation, whether the writes are being performed efficiently. There are less than a thousand cylinders on these disks (and the area occupied by the files being deleted would encompass far fewer cylinders). So, at least in principle, you would think only a small number of head movements should be required. Couldn't CAM/SCSI provide some help here, by allowing the writes to be performed in a more efficient sequence? > Try rerunning the test on both systems with your filesystems mounted in > async mode, and see how the numbers change on both systems. Consider > whether this type of activity is all that common on a production > machine. If it is (and your machine is stable enough), you might want > to run in async mode all the time, or upgrade to 3.0 and use > softupdates instead. This is to be a production web server - I don't want to take any significant chances. Manipulating these files en masse is an occasional activity. I guess I would like to have a sense of the risk involved, and in particular the chance of unrecoverable filesystem damage in async mode. Could you explain (to a beginner) what "softupdates" are? I would prefer to wait for 3.0 to stabilize, but will switch when practical. In fact, is there some place where synch/async operation are explained? -- Graeme To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message