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

[Bill Pechter]

In article <74jsodF13dn0hU4 at mid.individual.net>,
Bill Gunshannon <billg999 at cs.uofs.edu> wrote:
>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>   

I think the NCR buyout was in the end of 1990 or Winter of 91.

Killed my job at Pyramid pretty much. AT&T had resold our Pyramid MIS
boxes and were moving to SVR4 on Mips on the MIS-S series... Up to 20 
R3000 cpus...

Killed in an instant. My job -- teaching the hardware and software sysadmin
to classes that were 50 to 80 percent AT&T or AT&T customers. (They resold
the boxes as System 7000's...

Bill



-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
              pechter-at-pechter.dyndns.org