From owner-freebsd-questions Sun Jan 10 06:05:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23809 for freebsd-questions-outgoing; Sun, 10 Jan 1999 06:05:56 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from loviatar.webcom.com (loviatar.webcom.com [209.1.28.41]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA23801 for ; Sun, 10 Jan 1999 06:05:55 -0800 (PST) (envelope-from u@webcom.com) Received: from eresh.webcom.com (eresh.webcom.com [209.1.28.49]) by loviatar.webcom.com (8.9.1/8.9.1) with SMTP id GAA05963; Sun, 10 Jan 1999 06:05:11 -0800 Received: from [204.143.69.49] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 16059061; Sun Jan 10 06:03 PST 1999 Message-Id: <3698B3EB.502A@webcom.com> Date: Sun, 10 Jan 1999 09:06:35 -0500 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 2.02 (Win95; I) Mime-Version: 1.0 To: Greg Lehey Cc: Dan Busarow , "Michael G." , "freebsd-questions@FreeBSD.ORG" Subject: Re: FreeBSD Cluster Size References: <199901100629.GAA119060@out4.ibm.net> <19990110195247.X8886@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > I believe that a UFS fragment would correspond to a FAT cluster. > > The default value for fragments is 1024 bytes and is independent > > of the filesystem size. > > It's dependent on the block size, though. If you have a file system > with lots of small files, you can save by allocating 4 kB blocks and > 512 byte frags. I think this may be one of those rare ;-) occasions where having more filesystems could be justified. I have lots of small (~1000 to ~1800 byte) files in a webserver system. Following Greg's instructions, I rebuilt the system to have 512 byte fragments, and more inodes (as there weren't enough with default newfs setting). However, I restricted this to a special filesystem /usr/www, partly because the modified settings are less efficient for larger files, and also to allow mounting this file system async and noatime. The "async" *greatly* improves speed of file deletion/creation from tar archives. I'll try soft updates when I move to 3.x . BTW, the site owner presently generates these files on a Windows system. Until he switched to a third-party partitioning program, it was impossible to fit more than a few hundred MB of these files in 6GB of disk! Another thought about having multiple filesystems. If you had a certain class of files (say in /usr/www) that were heavily used, would it not be more efficient to have a dedicated filesystem slightly larger than necessary to fit the files? This would confine head movements for accessing these files to a smaller range of cylinders. With a single large file system on the disk, and frequent file modification, I assume eventually the files would end up scattered over a much wider range of cylinders, at least if the disk was fairly full. A question in this regard. If I do ls -li on a new filesystem, I notice files and directories at the file system root are widely spaced in inode number, even when the disk is relatively empty. Doesn't this mean more head movement than might otherwise be achieved? -- Graeme Tait - Echidna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message