rbriber@poly1.nist.gov (07/04/90)
pdi!shoshana@sgi.com asks about file fragmentation: AT&T filesystem was subject to serious fragmentation, ie, the longer a file had been around (assuming it grew gradually) the more fragmented it became (its blocks were all over the disk) and the slower its access time was. Over time, then entire operating system could be seen to gradually slow down. The only cure for this was to back the whole thing up on to tape, remake the filesystem and restore. Along came the Berkeley filesystem, with cylinder groups and other niceties. With the Berkeley fs, files were completely rewritten to disk when a size increase would have fragmented them - in other words, the old blocks were deallocated and new, contiguous blocks (in the cylinder group sense) were allocated. This system sustained performance over time, but slowed noticeably when the disk became more than 90% full. So here are my questions: 1) Assuming the above is correct, which scheme does SGI use? This is a question I am interested in also and haven't read/heard anything about on SGI machines. Is file fragmentation a problem and if it is what are the choices to correct it? -- ---------------------------------------------------------------------------- | Adios Amoebas, | "I've tried and I've tried and I'm still mystified, | | Robert Briber | I can't do it anymore and I'm not satisfied." | | 224/B210 NIST | --Elvis | | Gaithersburg, MD |------------------------------------------------------| | 20899 USA | rbriber@poly1.nist.gov (Internet) | |(301) 975-6775(voice)| rbriber@enh.nist.gov (Internet) | |(301) 975-2128 (fax) | rbriber@nbsenh (Bitnet) | ----------------------------------------------------------------------------