Date: Sat, 18 Nov 1995 12:31:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: terry@lambert.org, brandon@tombstone.sunrem.com, questions@FreeBSD.ORG Subject: Re: Disk De-Fragmenter...? Message-ID: <199511181931.MAA09407@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.91.951117211348.13386D-100000@cappuccino.eng.umd.edu> from "Chuck Robey" at Nov 17, 95 09:20:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, I have a friend who got relocated to work in Utah, for a company > that had as a major product a VMS disk defragmenter. My friend was brought > in to help in doing one for Unix. I know this to be true, I don't know > if it was FFS, but there must be SOME kinda truth behind this. > > I just can't remember the company name ... Oh, I know, Raxco. That would mean they work with a friend of mine who also got located to Orem to the same company. Tell him or her to "say 'Hi' to Phil". 8-). --------------------------------------------------------------------------- Here's my take on the whole idea: What does a disk/file defragmenter do? Well, lets talk about a disk defragmenter, since files will only ever contain one frag in UFS. It relocates the data blocks on the disk so as to reduce seeking, typically for sequential access. Most UNIX access (and even Windows95 and WindowsNT access) is random (executables are not loaded fully into memory to cause them to run). Strike one. But UFS lays out the disk in terms of cylinder groups and clusters anyway, as long as you have it doing time optimation. And since it is multitasking, the cluster size is intentional to fit with the locality of reference model trade between access time for one application and another. "Optimization" this way will typically not help. Especially if there is something like SCSI or ESDI sector sparing and the media insn't perfect. Strike two. Well when does a seek occur? When one sector and the next logically adjacent sector are seperated by a physical track boundry. Which means to do placement optimization, you need to know some information about the disk (which is available, though not commonly available) regarding physical time for various operations. You also have to know the real physical geometry for the device. Which is impossible for ZBR or other translated geometry drives, unless they are SCSI II and support the geometry query extension. Strike 3. Seems like a terrifically limited applicability for the amount of work required and hardware specific nature of the resulting program. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511181931.MAA09407>