Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!spool.mu.edu!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: Adding Swapspace ??
Message-ID: <1992Oct18.182528.27905@tfs.com>
Organization: TRW Financial Systems
References: <1992Oct16.201806.21519@fcom.cc.utah.edu> <Bw8Mw5.IFC@pix.com> <1992Oct18.082017.22382@fcom.cc.utah.edu>
Date: Sun, 18 Oct 1992 18:25:28 GMT
Lines: 112
Firstly:
Where is everybody?
has:
1/ everybody got 386bsd running flawlessly?
2/ everybody given up on 386bsd and gone to linux?
3/ everybody gon off to play with NT?
traffic on a meaningful level has really dropped away on this group.
In article <1992Oct18.082017.22382@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <Bw8Mw5.IFC@pix.com>, stripes@pix.com (Josh Osborne) writes:
>|> In article <1992Oct16.201806.21519@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>|> [...]
>
>|> >What we really need is the ability to swap to a file (any file -- say an
>|> >NFS mounted one, for instance) and get rid of the idea of a swap
>|> >partition altogether. Then you make a default swap file out of a
>|> >bunch of contiguous file system blocks; if you let it grow, you pay
>|> >for it being discontinuous then; at least you don't have to reinstall.
this is already supported to alarge extent by the addition of the
mach vm system. Expect to see it fully available soon.
>|>
>|> You also pay for going through the filesystem, the obvious costs of
>|> having to use the indirect blocks becuse FFS is optimised for SMALL
>|> files, not big ones. FFS will also limit how comtiguous your data
>|> blocks can be, part of each cyl group is reserved for inodes, and your
>|> swapfile is going to be large enough to cover scads of cyl groups. I also
>|> seem to remember something about the FFS not allowing a big file to fill
>|> an entire cyl group, to allow the inodes in that cyl group to be close
>|> to the data blocks FFS assumes you will someday want close to them (but
>|> I am unsure of this part).
Recent work makes the ffs a lot faster.. MACH swaps to the ffs
and gets reasonable throughput. I think Bill plans on implimentng
anonynmous-file swapping at some stage.
>
>I think this was the pre 4.3 code, before the introduction of cluster groups;
>in any case, the write to the disk is done through a write-through cache. If
>nothing else, you can certainly modify the allocation algorithm to make "swap"
>a file type unto itself ...0160000 isn't taken yet. The initial allocation
>(done during create with an lseek() or ioctl() to the created fd) could take
>care of it for you, getting arround the contiguity problem. The majority of
>interesting data should be in FS buffers off the vnode anyway.
>
In fact it's more than that.. you don't really need to preallocate first..
Mach doesn't.. (there lies the reason for a religious war) 8-)
>|> You will (prob) also have the wrong inode
>|> to data ratio. I also don't think LSFS would be good for swaping on
>|> either (but you could roll-back the swapfile :-). You would still
>|> want to be able to have >1 swap source so you can get multiple disks
>|> involved.
>
>Actually, a Log Structred File System (Sprite, maybe?) could be useful if
>memory was considered "write-through" to disk. It's likely that everything
>could be "resumed" after a crash right where the last valid transaction left
>off. This would be real nifty -- the power comes back on, vi comes back up
>with the cursor in the same position and still in insert mode... 8-).
I am working on getting the BSD4.4 LFS ported to 386bsd
(should be a drop-in). problem is that the USL-BSDI $#^%
has made it hard to get the stuff.
>
>
With coming changes, the following will happen:
Vnodes and VM-objects become the same thing. Therefore
all pages on all vm-objects are already in the buffer cache by definition..
in fact there stops being a separate buffer cache.
the pages are therefore directly available to the filesystems to write
to disk. The inode/vmobject they are attached to
simply writes it's oldest dirty page to backing store and the page is free.
LFS,NFS,FFS,SWAPFS... it doesn't matter, it's already allocated a place,
it just needs to be written to that place.
>|> That said, I think swaping on a file may be a good idea for (a) a stopgap
>|> fix, and (b) it may make us design a filesystem that works well for
>|> swap-like files, and (c) if you get a filesystem that does disk striping
>|> wouldn't you want swap on it? (Please don't try to put swap on a
>|> auto-compressing filesystem 'tho)
>|>
>|> Please find a better way to swap over the network then NFS 'tho...
>|> (ND anyone? RVD?)
>
I have often thought a simple TCP connection to a server that
knows what SWAPPING is might be simplest..
see above though.
>TFTP? 8-P. Actually, the idea of coming up totally diskless is *real*
>attractive. If you could get the boot to go on a single 1.2 Meg image, you
>could actually load 386BSD and mount NFS drives for / and family from a
>3.11 NetWare server with only the TCP/IP and NFS NLMs installed.
>
>
> Terry Lambert
> terry@icarus.weber.edu
> terry_lambert@novell.com
>---
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 2118 Milvia st. Berkeley CA. \___ ___ | country !
+- X_.---._/ USA+(510) 704-3137(wk) \_/ \\
v