Date: Tue, 03 Nov 1998 18:18:33 -0500 From: Graeme Tait <graeme@echidna.com> To: Dan Nelson <dnelson@emsphone.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: File system performance Message-ID: <363F8F49.EE1DD0EE@echidna.com> References: <363F7AA3.22254A9C@echidna.com> <19981103162515.A17979@emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?363F8F49.EE1DD0EE>