[geeks] Cheap Dell Servers

[der Mouse]

> If you were to have garbage parameters in your disklabel, created an
> FFS filesystem, created files of various sizes, grew and shrunk
> various files, the fsck fragmentation report would report almost no
> fragmentation.  However, there would be fragmentation there, because
> the cylinder groups would be allocated suboptimally.

Okay, this is a definition of "fragmentation" I'm not familiar with.
To me, fragmentation in an FFS means cases where file data is stored
non-contiguously: where the mapping from file-block number to
disk-block number has jumps.  This is independent of disk geometry, but
your definition clearly is not independent of disk geomketry, so I
can't say anything intelligent until I know what your definition of
fragmentation here is.

> But, then if you created a similar FFS filesystem on a disk with
> proper labels and performed identical operations, wouldn't you get
> much better performance (through less fragmentation) because it would
> be using sane cylinder groups?

"Much better"?  I suspect not, for even vaguely recent disks, though
I've never performed the experiment.  However, on ZBR disks (which
means, all but the very oldest), you have to make sure the filesystem
does not span multiple zones, or there is no single geometry you can
give to FFS which is accurate over the whole filesystem.

I do know that using the disk-provided geometry does not produce a
system that feels significantly faster than using my usual 64 sect/trk
32 trk/cyl "1M cylinders" geometry, for what little that may be worth.

>> What [FFS] does use the geometry for is attempts to compensate for
>> head-switch delay, rotational latency, seek times, and the like.
>> Things like ZBR, track caches, and drive-level reordering of
>> requests invalidate most of the assumptions underlying these
>> attempts anyway.
> Yes, it uses it for all of those things, to optimize placement of new
> allocations to the proper cylinder groups, no?

Not just "in the proper cylinder groups", but more specifically exactly
which sector of a track, and such, so that, for example, the desired
block is just coming up after the head-switch delay, rather than being
just past.  (Of course, that particular optmization is rendered almost
meaningless by track caches and rendered almsot impossible by variable
geometry....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B