From owner-freebsd-current  Thu Apr 23 07:14:19 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA04161
          for freebsd-current-outgoing; Thu, 23 Apr 1998 07:14:19 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from aldan.ziplink.net (mi@kot.ne.mediaone.net [24.128.29.55])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA04156
          for <current@freebsd.org>; Thu, 23 Apr 1998 07:14:17 -0700 (PDT)
          (envelope-from mi@rtfm.ziplink.net)
Received: from rtfm.ziplink.net (rtfm [199.232.255.52])
	by aldan.ziplink.net (8.8.8/8.8.7) with ESMTP id OAA05570
	for <current@freebsd.org>; Thu, 23 Apr 1998 14:14:10 GMT
	(envelope-from mi@rtfm.ziplink.net)
Received: (from mi@localhost)
	by rtfm.ziplink.net (8.8.8/8.8.5) id KAA10503
	for current@freebsd.org; Thu, 23 Apr 1998 10:14:09 -0400 (EDT)
From: Mikhail Teterin <mi@aldan.algebra.com>
Message-Id: <199804231414.KAA10503@rtfm.ziplink.net>
Subject: Net swap protocol (was .... Booting a diskless client)
In-Reply-To: <9804231005.AA17031@poveri.tekla.fi> from "Sakari Jalovaara" at "Apr 23, 98 01:05:39 pm"
To: current@FreeBSD.ORG
Date: Thu, 23 Apr 1998 10:14:09 -0400 (EDT)
X-Face: 
	%UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
		 hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
		 y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Sakari Jalovaara once stated:

=>> let clients share a _single_ swap file efficiently and safely :)

=> Actually, that can be accomplished if you insert a layer in the
=> storage stack that redirects to allocation, much in the manner
=> that page maps do it for the allocation of virtual addresses to
=> real addresses.

=When the diskless kernel frees a swap page, it would tell the server
=to make a hole in the swap file at the appropriate place
=(if the server supports the operation.)

Or, a "brand new" net-swap protocol. Which will give the clients
new type of block devices (swapable onto), and who knows what to
the server. To repeat Sun, the network is a computer, why not have
a (possibility of) unified swap? An OS independent protocol with
FreeBSD as a "reference implementation". Can the current swap
functionality be carefully splitted into that of a client and a
server?

The server can then even try to do caching, so that a file loaded
into one of the client's virtual memory can quickly be mapped into
that of another, and all the other neat things FreeBSD's VM does
now on a single computer... Time to get off those drugs, though...

	-mi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message