[geeks] Cheap Dell Servers

[Sridhar Ayengar]

der Mouse wrote:
>>> Yeah, worrying about RPM makes about as much sense as worrying about
>>> c/h/s geometry does - "none", unless you're using fairly old disks.
>> I thought FFS relies on the disklabel parameters for avoiding
>> fragmentation?
> 
> I don't think so.  How could it tell if you get them wrong?  Suppose I
> have a disk with (say) five 105-sector tracks per cylinder.  (Ignore
> ZBR for the moment.)  I build a filesystem and it's fine.  Then I dd
> the filesystem onto a disk that has (say) 73-sector tracks.  Does it
> magically become more fragmented?  The on-disk layout is exactly what
> I'd get from a filesystem of the same size constructed on the
> 73-sec/trk disk with a disklabel that incorrectly claims its geometry
> is that of the 105-sec/trk disk, after all.

How could you tell if you got them wrong?  You couldn't, and that's the 
point I'm trying to make.

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.

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?

> What it 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?

Peace...  Sridhar