Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!darwin.sura.net!bogus.sura.net!pandora.pix.com!stripes
From: stripes@pix.com (Josh Osborne)
Subject: Re: Adding Swapspace ??
Message-ID: <BwFMA9.5Fu@pix.com>
Sender: news@pix.com (The News Subsystem)
Nntp-Posting-Host: pandora.pix.com
Organization: Pix Technologies -- The company with no adult supervision
References: <Bw8Mw5.IFC@pix.com> <1992Oct18.082017.22382@fcom.cc.utah.edu> <1992Oct18.182528.27905@tfs.com>
Date: Tue, 20 Oct 1992 18:06:07 GMT
Lines: 125
In article <1992Oct18.182528.27905@tfs.com> julian@tfs.com (Julian Elischer) writes:
[...]
>1/ everybody got 386bsd running flawlessly?
Nope, but good enough to have fun with.
>2/ everybody given up on 386bsd and gone to linux?
Naw, but I'm not sure why not...
>3/ everybody gon off to play with NT?
Not until I can get it for free.
>traffic on a meaningful level has really dropped away on this group.
You don't think patent disscusions are meaningful either? (well, not dirrectly
applicable at least)
>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:
[Some said, swap on files, I said...]
>>|> 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
Faster for what? Random access to large sequental files (that's what swaping
normally amounts to, but it could offen be sequental access to large files),
or to the common case for Unix filesystems, small files? Do they get
around any of the problems I mentioned?
And most importantly of all, where can I read about this? (pref plan
text/nroff from a ftp site...)
>and gets reasonable throughput. I think Bill plans on implimentng
>anonynmous-file swapping at some stage.
If "reasonable" 80% of dirrect wapping? 90%? 98%?
Hopefully we can go farther then swaping to files, hopefully we can get
"user level pagers" (like Mach has), for example if you have a large table
of integers for doing fixed point trig functions it is offen faster to run
(and possably page in) code that does the floting point trig functions and
fills in the table then to read it from disk. Other tasks could be made
faster this way also (for example caching scaled fonts, or rotated bitmaps,
or backing store for windows).
>>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.
This will let you use all the data sections of a cyl group, but you still
lose the inode and allocation bitmaps. I think the space "lost" (the inodes
could be used for other files, but it would be slower then need be since a
seeek would be involved) is more important.
>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-)
Do you mean Mach will grow the swap file when needed, or something else?
[...]
>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.
Good, now all we need is a filesystem that deals well with large files
and random access to them.
[...]
>I have often thought a simple TCP connection to a server that
>knows what SWAPPING is might be simplest..
Would be nice if the client could be told when writes make it to the disk,
that way it would have a choice of recovery methods if the TCP/IP connection
gets reset by peer (indicating a server reboot):
* Kill processes that had unconfirmed writes that you deallocated the
pages to.
* Don't deallocate pages until confirmed.
Of corse when the connection gets reset you need to re-establish.
[...]
>>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.
Well anyone who can get tech info on how to use the 16K (or is it 8K?)
ROM/PROM/EEPROM socket that most WD ethernet cards seem to have could prob
make a bootp client + TFTP 1st stage booter. If someone does that you
should be able to boot off of any Unix box (that has UDP), since you can
get a free BOOTP server, and I think you can get a free TFTP. Does anyone
know if that's detected in the normal way by the BIOS (first 2 bytes size
in paragraphs, next 2 checksum, then entry point offset, or something like
that), or is it somehow special? Anyone have a EPROM burner/eraser for
sale, cheep?
[...]
--
stripes@pix.com "Security for Unix is like
Josh_Osborne@Real_World,The Multitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. - Larry Wall