From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 15 19:47:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB43537B401; Fri, 15 Aug 2003 19:47:58 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A85DF43F3F; Fri, 15 Aug 2003 19:47:57 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h7G2ltgh075104; Sat, 16 Aug 2003 12:47:56 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h7G2lrUC075103; Sat, 16 Aug 2003 12:47:53 +1000 (EST) Date: Sat, 16 Aug 2003 12:47:53 +1000 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20030816024753.GA74853@cirb503493.alcatel.com.au> References: <200308151204.h7FC42rq050760@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308151204.h7FC42rq050760@repoman.freebsd.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: cvs commit: src/sys/nfsclient bootp_subr.c nfs_diskless.c nfs_vfsops.c nfsdiskless.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 02:47:59 -0000 [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