JORDAN@gmr.COM (02/13/90)
We work in a real time environment, and have noticed something strange in a particular "driving" loop. We have two files, exactly the same (visually). Let's call them a.c, and a.copy. a.copy was made from a.c by: cp a.c a.copy Then some extra info was added to a.copy from b.c: cat b.c >> a.copy This added info ruined the performance of the environment so b.c was deleted from a.copy. Therefore, a.copy looks the same as a.c. The Problem? a.copy still has the bad performance as if b.c were still a part of the code. A "diff a.c a.copy" outputs nothing; therefore, no difference. HELP!! TP MUGABI-JORDAN GM - SYSTEMS ENGR CENTER 1151 CROOKS ROAD TROY, MI 48084 (313)280-6766
pj@sam.sgi.com (Paul Jackson) (02/14/90)
In article <9002121455.aa22106@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: (to paraphrase) | We work in a real time environment, and have noticed something strange | in a particular "driving" loop. | a.c # a.c has OK performance | cp a.c a.copy # a.copy has OK performance | cat b.c >> a.copy # now a.copy has slow performance | "delete b.c from a.copy" # a.copy still has slow performance How did you delete b.c from a.copy? Unix has no way to shorten a file while it is in place on the disk. I presume you deleted b.c by using an editor (such as vi). All editors work by making copies of the file, applying the changes and linking or copying the result back. This reallocates the disk space used for that file. I would guess perhaps that a.copy, after b.c was added, spanned multiple extents. And I would also guess that after "deleting b.c ...", a.copy still took multiple extents. That it still took multiple extents is a little surprising, as our (yes - I work for SGI) Extent-based File System does a pretty good job of keeping files together that are written in one open-write-write-...-close sequence. But it certainly is possible. To further improve this guess, one would need to know the sizes of the files, and how much space was free on the disk partition after each of the above steps. Allocating contiguous extents is harder on a nearly full disk. Why don't you try calling our Geometry Hotline (800) 345-0222. These folks do a real fine job of handling such questions. I use them myself. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373