[geeks] Cheap Dell Servers

[Sridhar Ayengar]

der Mouse wrote:
>> 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 I thought the whole point of FFS's method of minimizing 
fragmentation was that when it goes to allocate the next sector it needs 
to allocate, it calculates what would be the optimal sector to allocate 
from based on the drive parameters, and if that sector is not free, it 
picks a free sector to allocate which is as close to optimum as possible 
(probably still in the same cylinder but on a different head or something)?

My understanding may be completely wrong, so please correct me.

>> 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.

Bleh.  Makes things a little unpredictable.

> 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.

My main concern in this exercise is to decode compressed HD video, which 
can be a bit sensitive to fragmentation at times, according to my own 
experience.  If the difference in streaming video performance will be 
negligible, I won't worry too much about it.

NTFS seems *extrmeely* sensitive to fragmentation even on 
fairly-high-performance drives which support NCQ, but Microsoft might 
just have screwed up royally.  Quite possible.

>>> 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....)

Yeah, that was my understanding.  (Your explanation definitely refined 
it a bit in my mind...)

So, on ZBR drives, does it become wholly irrelevant?  If so, I won't 
worry about what parameters are in my disklabels.

Peace...  Sridhar