Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Aug 2003 12:47:53 +1000
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        Poul-Henning Kamp <phk@freebsd.org>
Cc:        hackers@freebsd.org
Subject:   Re: cvs commit: src/sys/nfsclient bootp_subr.c nfs_diskless.c nfs_vfsops.c nfsdiskless.h
Message-ID:  <20030816024753.GA74853@cirb503493.alcatel.com.au>
In-Reply-To: <200308151204.h7FC42rq050760@repoman.freebsd.org>
References:  <200308151204.h7FC42rq050760@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
[Redirected to -hackers because this isn't directly relevant to the
 actual code committed]

On Fri, Aug 15, 2003 at 05:04:02AM -0700, Poul-Henning Kamp wrote:
>  Suggested replacement command sequence on the client:
>  
>          dd if=/dev/zero of=/swapfile bs=1k count=1 oseek=100000
>          swapon /swapfile

This results in a sparse swapfile.  Whilst this minimises diskspace
occupancy on the server (which is in keeping with the swap overcommit
principle used in the VM subsystem), there are other side-effects
which may not be so advantageous.

Firstly, the client VM system can receive ENOSPC - which can't occur
on a swap device.  How does the pager handle this?  Does it panic,
kill the task the owns the page in question or what?

Secondly, this effectively means that the physical disk blocks are
effectively being allocated by the client.  I recall reading a comment
that recommended against using ftruncate() and mmap() to extend files
because this resulted in sub-optimal block allocation compared to
write().  Will the same thing happen in this case?

Also, how are dirtied swap blocks reused?  Once a physical block has
been allocated, it is beneficial to reuse that block in preference to
allocating another block.  This only matters in the situation where
you are paging into a sparse file - which is probably not a common
case and therefore unlikely to have been taken into account when the
block reuse algorithm was developed.

Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030816024753.GA74853>