Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!panda!genrad!decvax!decwrl!amdcad!amd!pesnta!peora!joel
From: joel@peora.UUCP
Newsgroups: net.arch
Subject: Re: paging and loading
Message-ID: <2461@peora.UUCP>
Date: Wed, 8-Oct-86 10:04:23 EDT
Article-I.D.: peora.2461
Posted: Wed Oct  8 10:04:23 1986
Date-Received: Thu, 9-Oct-86 03:38:36 EDT
References: <832@hou2b.UUCP> <7597@lanl.ARPA> <78@alberta.UUCP> <950@usl.UUCP>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 33

>>desireable to make the pages large.  That way you can take advantage  of
>>the fact that most I/O comes from consecutive disk locations - therefore
>>there are fewer seeks with large page size.
>
>I have never seen a disk system that did not fragment.  Unless the  disk
>page  size was also similiarly large.  Upon which you get lots of wasted
>space, because most files are about 1K long or so, and you'd have  these
>mungo  16K  disk pages only 1/16th full...  Imagine, a 160 megabyte disk
>with only 10 megabytes used on it, totally full.
>      Eric Green {akgua,ut-sally}!usl!elg

	You seem to assume that all disk I/O is done with a fixed block
	size. On our drives you can do a disk I/O transfer using a block
	size from 256 bytes up to 16MB. We have a file type that lets
	you specify how large the file will be at allocation and reserves
	a contiguous block of disk space for it. We also have another
	file type that will allocate new blocks as required for the file,
	but even there the block size can be specified when the file
	is allocated.  The fixed disk block size used by Unix seems to
	designed to simplfy the operating system, rather than for efficent
	disk I/O.

	I'm not familar with the internals of virtual memory versions of
	Unix. It would seem reasonable to me that paging I/O would
	attempt to bypass most of the file system overhead and use a
	more primitive level of disk access. It therefore seems to me
	that the isn't any necessary relationship between the blocking
	factors used by the file system and the system page size.
-- 
     Joel Upchurch @ CONCURRENT Computer Corporation (A Perkin-Elmer Company)
     Southern Development Center
     2486 Sand Lake Road/ Orlando, Florida 32809/ (305)850-1031
     {decvax!ucf-cs, ihnp4!pesnta, vax135!petsd, akgua!codas}!peora!joel