Re: Performance problem (I/O)

From: Bob Harris (harris_at_zk3.dec.com)
Date: 03/20/04 

Date: Sat, 20 Mar 2004 01:04:32 GMT

In article <c3g297$19vl$1@jeeves.eng.abbnm.com>,
 peter@abbnm.com (Peter da Silva) wrote:

> In article <harris-DCF0F6.18530419032004@cacnews.cac.cpqcorp.net>,
> Bob Harris <harris@zk3.dec.com> wrote:
> > Not having cylinder groups may not have anything to do with small file
> > write performance. This could be due to the way the last 8K allocation
> > of a small file is managed. For space efficency, files under 150K tend
> > to have the last 8K of the file stored in a frag of from 1K to 7K in
> > length. But while the is being written, a full 8K is allocated. When
> > the file is closed, the size of the file is checked and if a 10% saving
> > in space can be obtained by turning the last 8K into a frag, then a frag
> > is allocated, the end of the flie copied to the frag, and then the
> > original 8K is deallocated.
>
> UFS does that kind of thing as well, and for the case of small files (<8K)
> the write should be completed and the close performed before anything hits
> the disk... I wouldn't expect actual disk writes for the 8k blocks.

If UFS serves your needs for small files, then by all means use UFS.
Both file systems are fully supported.

> > In the newer versions of Tru64 UNIX, there is chfsets option to disable
> > this and make all files created from that point forward allocation
> > storage in multiples of 8K. For older versions there is a global
> > variable that can be patched in the kernel to disable frag'ing of a file.
>
> Huh, I'll see what that does. You know the variable name?

        AdvfsDoFrag

Change it to zero using dbx.

This will _ONLY_ affect files created or extended from this point
forward. It will not affect existing files.

                                        Bob Harris

Relevant Pages
Quantcast