[Info-vax] Anyone interested in another public access system

[Bill Gunshannon]

In article <gs2dlr$2nd$1 at pechter.motzarella.org>,
	pechter at bandit.pechter.dyndns.org.pechter.dyndns.org (Bill Pechter) writes:
> In article <74jo28F13th6fU1 at mid.individual.net>,
> Bill Gunshannon <billg999 at cs.uofs.edu> wrote:
>>In article <gs0quj$8en$1 at pechter.motzarella.org>,
>>	pechter at bandit.pechter.dyndns.org.pechter.dyndns.org (Bill Pechter) writes:
>>> In article <rdSdnTee6OfhV37UnZ2dnUVZ_jGdnZ2d at giganews.com>,
>>> Dennis Boone <drb at ihatespam.msu.edu> wrote:
>>>> > Unix provides no means to create a contiguous file; just splatter it
>>>> > all over the disk!.  Even <obligatory retching noises> Windows has
>>>> > a utility to make your files and free space contiguous.  Unix just
>>>> > doesn't care.
>>>>
>>>>All over the disk?  Nonsense.  Unices have always tried to keep files
>>>>(and their related inodes) contiguous or close together on the disk.
>>>>Defrag utilities exist for some filesystems, and though coverage could
>>>>be better, fixing it later with a defrag tool is a bass-ackwards fix.
>>>>In any event, the idea that the system has to *force* the file to be
>>>>contiguous can't be useful very often -- surely a best effort is better
>>>>than an abort.
>>>>
>>> 
>>> Really... Not true in AT&T based Unixes using the SystemV 1k filesystem.
>>> Fragmentation was an issue.  Before that it was even worse.
>>> I remember doing ncheck, icheck etc before there was FSCK.
>>
>>Yeah, and I remember doing SQUEEZE on my DEC disks.  Do we still have to
>>do that on VMS, I wonder?
> 
> Nope... Never did although DSC (Disk Save and Compress) was used before
> VMS Backup.  IIRC DSC may have been compatibility mode.  It was used for
> the initial install and compressing backups in the VMS 2.x days.
> 
> It did the equivalent of Dump/Restore...
> 
> Squeeze was RT11 which did only contiguous allocation for Real Time 
> fast disk access.

It was a rhetorical question.   :-)

> 
>>
>>> 
>>> Mount verification in progress and the bitmap check on VMS was a whole
>>> lot better.  BSD very different than the AT&T based Unix filesystems.
>>> 
>>> VMS and the BSD's were a bit better in trying to keep the allocations 
>>> together.
>>
>>Can't speak for VMS, but as regards BSD, that is a bit of an understatement.
>>From some of my systems: 
>>
>>1746 files, 44420 used, 10109779 free (2635 frags, 1263393 blocks, 0.0%
>>fragmentation)
>>19 files, 25064 used, 20286338 free (26 frags, 2535789 blocks, 0.0%
>>fragmentation)
>>6878 files, 289010 used, 25099511 free (5143 frags, 3136796 blocks, 0.0%
>>fragmentation)
>>789103 files, 79801403 used, 156703416 free (197312 frags, 19563263
>>blocks, 0.1% fragmentation)
>>
>>User fileserver.  Last one is the users directory.  1400 users filesystem
>>shared thru NFS on Unix systems and Samba on Windows system.  All faculty
>>and student files are here.
>>
>>
>>132495 files, 2163445 used, 54601550 free (41366 frags, 6820023 blocks,
>>0.1% fragmentation)
>>
>>Server set up for literacy students to put up web pages.  4100 students.
>>
>>
>>562 files, 2945723 used, 34908981 free (293 frags, 4363586 blocks, 0.0%
>>fragmentation)
>>
>>Our email spool.  1400 users.  ~40000 connections evey 24 hours.
>>
>>Note the percentage of fragmentation.  And, no, there are no de-frag
>>programs for BSD Unix.  The question does come up from a windows weenie
>>periodically in the BSD Newsgroups.
>>
> 
> Don't need 'em.

What defrag programs for windows or windows weenies?  :-)
Definitely need the defrag program.  Windows is the only OS I know of
that can completely fragment a disk installing the OS.
 
>>> 
>>> The BSD Fast Filesystem and it's decendants were a huge improvement over
>>> the AT&T filesystems which looked and acted like they were written for
>>> RK05's. (and they were...)
>>
>>But then, look at when AT&T actually stopped developing SYSV.
> 
> Uh... late 80's or so.  Spun off to USL in about 1990.  AT&T still
> had an interest back then...

I don't remember the date, but long before USL AT&T turned their computer
division over to NCR.  It was the death of the real 3B family and the
WE32000 processor family.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>