[rhelv6-beta-list] My first experiences with RHEL6 beta

Bryan J. Smith b.j.smith at ieee.org
Tue Jun 15 14:32:29 UTC 2010


James Findley <james.findley at trans-axion.net> wrote:
> Ok, I didn't know that.  Thanks for the correction.

Every OS I've seen (even NT) will fix the blocks at creation time
(at least if it is a fixed size).  That means however contiguous/
fragmented the "file" is as creation time, it stays that way.  So
if it is contiguous at creation time, it's just as good.

The rest of the commentary is correct.  The kernel will consider
the files to be logically linear/contiguous, and bypass filesystem
operations.  The underlying, physical contiguous/fragmentation,
however, is still of concern.

[ I previously made a reference to DeviceMapper, because if you
understand the facilities in the kernel that DeviceMapper is
setting up, you understand how this can work. ]

Now with that said, going back to the original poster/points ...

Because of this, the alleged "flexibility" of a swap file, being
able to resize it, etc... is often mutually _exclusive_ with keeping
it contiguous and non-fragmented.  So whether you create a swap
slice (partition) or a swap file, you should _not_ change it after
you do.  In the case of a swap file, you should wholly re-create it,
and ensure it is contiguous (or at least only fragmented into a few,
large chunks).

It's in these specific details that I'm not very fond of theoretical
discussions.  It's those little, but exceedingly important details,
that vary between contexts and systems that make all-the-difference.
Hence why they should be left to specific systems.

If anything, vm.swappiness is the most important tunable to know of
when it comes to how often it swaps.  The buffer/cache settings are
also very important, because the kernel both tries to be lazy in
commits of buffer, as well as cache as many recently accessed or
written blocks as possible.  These settings can be tuned, as well
as actual memory reserved (versus having to drop caches), etc... 

They make more difference in many cases than these type of discussions
in my extensive experience with all major distributions.






More information about the rhelv6-beta-list mailing list