[Info-vax] Anyone interested in another public access system

[Bill Gunshannon]

In article <btmdnYhpl48NJHnUnZ2dnUVZ_oGdnZ2d at giganews.com>,
	"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
> Bill Gunshannon wrote:
>> In article <g22Fl.7857$U5.87390 at newsb.telia.net>,
>> 	Jan-Erik Söderholm   <jan-erik.soderholm at telia.com> writes:
>>> Bill Gunshannon wrote:
>>>
>>>> 562 files, 2945723 used, 34908981 free (293 frags, 4363586 blocks, 0.0% fragmentation)
>>> How is the %-frag calculated ?
>>> And is the data inside the () a specification of "free"
>>> or of both "free" and "used" ?
>>>
>>> It's a bit weird that 562 files with 293 frags = 0.0% fragmentation...
>> 
>> I have not looked at how the calculation is done but my guess would be
>> that the 293 frags included unused areas of the files system that are
>> empty frags but might at some point hold an entire file, depending, of
>> course, on their size.  The 0.0% fragmentation I would take to mean the
>> fragmentation of the files, which is the only thing that really matters
>> when computing filesystem performance.
>> 
>> bill
>> 
> 
> The fragmentation of free space is also important!  If you don't have 
> contiguous free space you can't allocate contiguous space to put files in!

With a good best fit algorithm it is much less important.  I would guess
most fragmentation occurs when extending a file.  I expect that fragmentation
would go up when a BSD disk is getting close to full and there are less
empty frags of a large size to work with.  But then, when you start to
approach the max capacity of a disk you usually have other things on your
mind. :-)  Also, the "overflow" that is common on BSD type filesystems
may play a part in keeping fragmentation down, as well.  I suspect that
the reason for the low rate of fragmentation is due in part to de-fragging
on the fly as files are modified.  As was pointed out, in many cases an
entire text file will be loaded into memory for editing.  That would seem
to make it easy to avoid the fragmentation problem when writting it to
disk as a whole file as opposed to an extended file.  I guess the best
part of this is that it is done with so little overhead on the overall
performance of the filesystem.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>