HDTenEightyP/NetNews huggingface dataset:
From: miller@lsil.com (Lance Miller)
Newsgroups: comp.arch.storage
Subject: DFHSM
Date: 25 Aug 92 16:03:36 GMT
Reply-To: miller@lsil.com
Organization: LSI Logic Corporation


I'm not sure if this is the right place to post but is there anybody that has experience with this product?? (DFHSM).
From: rawn@manduca.neurobio.arizona.edu (Rawn Shah)
Newsgroups: comp.arch.storage
Subject: R/W Optical Drive file system compatibility
Date: 4 Sep 92 00:19:05 GMT
Organization: University of Arizona UNIX Users Group


    We recently were thinking of solutions for large storage capabilities
for our Confocal Microscope system. We presntly have one Sun station with
a magneto-optical r/w drive on it where we store our data. The data is 
collected on a 486 over at the microscope and then FTP'd over to the
Sun's MO drive.
    When I was looking to get a new MO system I thought of getting one for
the PC instead and have them write the data directly to this drive at the 
486 station. 

    One problem we came across immediately is that even if the drives were
compatible (same disk size & conforming to ISO), the actual file system on 
the disk as saved by the driver software differs; on the Sun its a SunOS 
file system and on the DOS-based 486, it uses the FAT tables and such.
So data stored on a disk on the DOS system cannot be read by the MO drive
on the Sun and vice versa.

    I had the idea that I might stick a DOS emulator on the Sun and have
it read the disks in DOS format. BUT as far as I know the DOS emulator
I looked up (SoftPC for SunOS 4) does not have any drivers for r/w optical
drives and even if I did NFS-mount the drive (the other option given by
SoftPC) the actual file format is still SunOS and so the disks wouldn't
be readable by the DOS machine.

    As far as I know so far there are no compatibility measures on such
kinds of drives. Now there're phase change r/w optical drives but I still
haven't heard of any compatibility between systems either.

    If anyone has any suggestions, they would be very welcome.

Rawn Shah
Neurobionetmgr, ARLDN, Univ. of Arizona, Tucson, AZ 85721
rawn@neurobio.arizona.edu
Newsgroups: comp.arch.storage
From: atk@tigger.cs.Colorado.EDU (Alan Krantz)
Subject: Re: Credit card sized media
Organization: University of Colorado, Boulder
Date: Thu, 3 Sep 1992 14:19:53 GMT

In article <6055@pdxgate.UUCP> hal@eecs.cs.pdx.edu (Aaron Harsh) writes:
>
>  I know that storage media the size of credit cards exist, but no press is
>ever given to any forms except flash memory.  In particular, I recall seeing
>an ad for small rectangular optical memories that could hold 1-2MB.
>
>  Can anyone point me to a company that manufactures these (or any other
>permanent memories of this size)?
>
>
>Aaron Harsh
>hal@eecs.cs.pdx.edu

There is a company called Drexlar (sp) that manufactor credit card style
optical disk. I forget all the details but basically they are WORMS that
can hold from 2 to 4 mb depending on the type of data (format you choose
for the cards). The cards can also be preprinted with data if needed.
I think the readers (and writers) will operate on a standard pc but i
don't know anyting about prices. I can try to dig up more information if
needed ....

Xref: sparky comp.arch.storage:613 comp.databases:6473
From: rod@isi.edu (Rodney Doyle Van Meter III)
Newsgroups: comp.arch.storage,comp.databases
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Date: 1 Sep 92 07:29:08 GMT
Reply-To: rod@venera.isi.edu (Rodney Doyle Van Meter III)
Organization: Information Sciences Institute, Univ. of So. California

In article <1992Aug31.043738.19685@psg.com> randy@psg.com (Randy Bush) writes:
>vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
>
>> I need to design a retrieval system for ~15TB of data, of which ~5TB are
>> retrieved with a high frequency (25 requests/second) and an access time
>> of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
>> 5TB are real random-access. The rest of the data is still accessed at a
>> rate of 5 requests/second.
>
>Optical RW store, a la HP.
>-- 
>randy@psg.com   ...!uunet!m2xenix!randy


The problem is not the volume -- 15 TB is huge but not enormous
(like the distinction?:-)), the problem is the access rate. Even
the fastest cart machines are ~15 seconds to replace a disk or tape
(remove the AND insert the new), so to get 25 reqs/sec., you're
looking at not 40 but 400 cart machines.

As pointed out, you probably want MO, not tape; VHS, 8mm, D-1, and
D-2 are all fairly slow to load (I think Ampex' D-2 is the fastest),
plus the seek times... w/ 400 cart machines, you'll have enough
drives that seek time isn't a problem with your latency.

An important question is the size of an average data request --
if it's a bank account balance, the throughput of the device is irrelevant.
If it's CAD files or fluid-flow simulation, you need one of the
higher-speed alternatives.

Are you prepared to handle acres of floor space, hundreds of
drives, all the power, etc.?

By the time you add it all up, I think the only realistic solution
is RAID arrays. Yes, they're small and expensive, but I think it's
the only way to get that kind of throughput.  Oh, you'll need
one mini-super for every several RAID arrays, too, don't forget.

What's the timeframe for implementation?  The capacity is
easy, if not quite off-the-shelf, but meeting those performace
characteristics is damn near impossible in the current generation
of devices.

		--Rod

disclaimer: I work for a company with a vested interest in this
area, but you don't know which one, so there! It's not the only
company mentioned by name in this article.
Newsgroups: comp.arch.storage
From: chip@osh3.OSHA.GOV (Charles Yamasaki)
Subject: Re: Information for mass storage systems. 
Organization: U.S. D.O.L - Occupational Safety & Health Admin.
Date: Fri, 04 Sep 1992 03:53:54 GMT

In <BtztqL.F4J@iai.kfk.de> nondas@kfk.de (Nondas Kapetanios, IAI, Zi. 237, Tel. 5743) writes:
>we want to come in contact with vendors providing mass storage systems suitable for accomodating
>at least 3-4 TBytes and at most 10-12 TBytes. Addresses, telefon numbers or email-addresses are
>useful. We would also like to know about the software data management provided by each environment.
>Especially, environments that can support UniTree or any other system approaching the IEEE reference
>model for mass storage systems. 

>Any responses, please, to my email-address:  nondas@kfk.de

I'd love to see a summary on this one (please).
-- 
-----------------------+---------------------------------------------------
Charles "Chip" Yamasaki| The opinions expressed here are my own and are not
chip@osh1.OSHA.GOV     | supported or even generally accepted by OSHA. :-)
-----------------------+---------------------------------------------------
Newsgroups: comp.arch.storage,comp.databases
From: cwm@beta.lanl.gov (Christina W Mercier)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Organization: Los Alamos National Laboratory
Date: Thu, 3 Sep 1992 17:19:15 GMT

In article <1992Sep03.033736.10559@osh3.OSHA.GOV> chip@osh3.OSHA.GOV (Charles Yamasaki) writes:
>In <22302@venera.isi.edu> rod@isi.edu (Rodney Doyle Van Meter III) writes:
>
>Any more info on the optical jukebox scene?  I need to provide backup
>for as many as 20 networked Unix systems with an average of about 1GB
>each.  I'd like to be able to do a complete backup of all the systems
>overnight. 

There is an interesting article on backup in "Corporate Computing"  They
rated the following products:
Erasable Optical : <Good for archive not backup>
  Pros: excellent selective restore time, high data integrity and shelf life
  Con:  low performance, expensive 
Digital Audio Tape (4mm DAT)  <Not safe for backup>
  Pros: cheap drive and media, good performance in selective restore
  Cons: Low performance in full backup and restore, poor data integrity
9 Track  <too slow> 
  Pros: interchange format
  Cons: Low capacity per tape, bad performance, not cheap
8 mm <bad performance>
  Pros: Good capacity per tape
  Cons: Bad performance
Quarter Inch Cartridge (QIC)
  Pros: Cheap, Good performance
  Cons: only available for Suns
VHS
  Pros: Good performance, high capacity per cartridge
  Cons: Expensive
IBM 3480 compatible
  Pros: High Performance
  Cons: Low capacity per tape, expensive
Digital Linear Tape 
  Pros: High performance, low cost, high tape capacity
  Cons: new technology.

The ZD lab (Trinity College) raved about the Digital Linear Tape,
specifically the T860X by Cipher Data Products that sells for
$6,550 and works on Suns, Vaxs, and Novell NetWare.  They claim
6 GB per tape, backup rates of 26.7 MB/minute on the Sun, very
fast selective restore rates, and very sturdy tapes.          

They were pretty pleased with Metrum Information Storage's VHS
which they found to be fast (30.6 MB/minute on a Sun), reliable, 
and high capacity (14.5 GB uncompressed). The RSP-2150 costs
$32,900.
 
Has anyone tried DLT or VHS for heavy backup work??
Newsgroups: comp.arch.storage,comp.databases
From: pease@amarna.gsfc.nasa.gov (Pease)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA Goddard Space Flight Center, Greenbelt, Md. USA
Date: Fri, 4 Sep 1992 16:47:00 GMT

In article <1992Sep03.033736.10559@osh3.OSHA.GOV>, chip@osh3.OSHA.GOV (Charles Yamasaki) writes...
> 
>Any more info on the optical jukebox scene?  I need to provide backup
>for as many as 20 networked Unix systems with an average of about 1GB
>each.  I'd like to be able to do a complete backup of all the systems
>overnight.  The whole thing must be able to operate completely
>unattended and should have multiple drives to help reduce contention. 
>Of course, with this I'm going to need backup software that will support
>multiple platforms (NCR SVR4 and SCO SVR3.2.4).
> 
>I realize I could use a tape jukebox and probably save some money, but
>I'm hoping to be able to use this as large scale on-line (albeit slow)
>storage as well.  Granted, I haven't checked if SCO or NCR can support
>optical as mounted filesystems.
> 
>Sorry to stray from the original topic, but there seemed to be such a
>pool of expertise here I couldn't resist.
>-- 
>-----------------------+---------------------------------------------------
>Charles "Chip" Yamasaki| The opinions expressed here are my own and are not
>chip@osh1.OSHA.GOV     | supported or even generally accepted by OSHA. :-)
>-----------------------+---------------------------------------------------

This is not responding to your direct querey; but I came across a backup
sofware package from Titan Client Server Technologies.  A 20 client
version cost $10k; but it can handle up to 250 clients.

I don't have their phone# handy; but their corp. headquarters is in
San Diego, CA.

Phil Pease 
My witty disclaimer - everything I perceive, through either sensory or
extrasensory means, has been filtered to such an extent that you had better not
attempt to attribute anything I say to anyone else.
Newsgroups: comp.arch.storage,comp.databases
From: randy@psg.com (Randy Bush)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Organization: Pacific Systems Group, Portland Oregon, US
Date: Mon, 31 Aug 1992 04:37:38 GMT

vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:

> I need to design a retrieval system for ~15TB of data, of which ~5TB are
> retrieved with a high frequency (25 requests/second) and an access time
> of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
> 5TB are real random-access. The rest of the data is still accessed at a
> rate of 5 requests/second.

Optical RW store, a la HP.
-- 
randy@psg.com   ...!uunet!m2xenix!randy
Newsgroups: comp.arch.storage,comp.periphs.scsi,comp.sys.atari.st.tech
From: adw3345@ultb.isc.rit.edu (A.D. Williams)
Subject: Dead Seagate 296N
Followup-To: poster
Originator: adw3345@ultb
Organization: Rochester Institute of Technology
Date: Sun, 30 Aug 1992 01:26:25 GMT


 Last week my Seagate 296N decided that it wanted to keel over and die.
I've had the drive for close to 5 years, and used it nearly every day
then.

 The drive wouldn't spin up, until I turned the platter. I figured the
lubrication gummed up the heads and was preventing it from spinning. 
(I spun the platter via the ratchet disk on the bottom of the drive,
not by opening it up.)

 However, when the hard drive spins up, it blinks the drive light
eight times. My computer reports that it can't find the drive on the
SCSI port, so I can't re-format it or otherwise salvage it via software
tools.

 I know that hard drives have a limited lifetime, but it's a bummer
that it only lasted 5 years wheras my other 3 MFM drives (on various
computers) lasted 8 years and are still going strong.

 Is there any hope for this drive, or is it only good for an art
project?

 If I have to buy another SCSI drive, is Seagate a good brand, or should
I consider a different brand?

                                                         Thanks,


                                                             Derrick 
-- 
-------------------------------------------------------------------------
- Derrick Williams   Rochester Institute of Technology | Insert snappy  -
- adw3345@ultb.isc.rit.edu     Computer Science        | quotation here -
-------------------------------------------------------------------------
Newsgroups: comp.arch.storage
Subject: Need info on Perkin Elmer MSM 80 Hard disk
From: hoffmann@nutmeg.cs.ntu.edu.au (Arthur Hoffmann)
Date: 29 Aug 92 21:46:08 +0900
Distribution: world
Organization: Information Technology, Northern Territory University

Hi, 
I don't know if this is the right group to post this, but if it isn't could 
someone please give me the name of the right group?

The problem is: I wanted to buy a new HD for my computer, I was looking for a 
Quantum LPS240, when I came across those second hand Perkin Elmer MSM80 drives.
Now the thing is I don't know anything about them I only know they ar huge
and there are 5 packs of very large disk cartriges with them. They must have been
used on some mini or even mainframe computer. 
My question is: Could someone please let me know what sort of drives they are and 
on what computer they are normally used, the disk capacity would be interesting
to know as well. And the most important thing to know is can I connect them
somehow to a 286 based PC or an Amiga with Scsi port, or is it plain impossible.
Any response would be appreciated.

Bye

Arthur.

					Arthur Hoffmann
					hoffmann@pandanus.ntu.edu.au

Newsgroups: comp.arch.storage
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Reply-To: vhs@rhein-main.de
Date: Fri, 4 Sep 92 05:16:35 GMT

> I need to design a retrieval system for ~15TB of data, of which ~5TB are
> retrieved with a high frequency (25 requests/second) and an access time
> of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
> 5TB are real random-access.

Since our feed has been sucking mud for weeks now I'm unable to follow
any online discussion (if there is any). So far I have received several
very helpful comments per email. I'll summarize in a few days. Here's
answers to the most commonly-asked questions:
	1) Cost: We know it's expensive. Budget is ~$15 million.
	2) Access: Read-only, with few enough exceptions to handle
		them separately.
	3) Overall system load: ~4.5 MBytes per second, sustained
	4) File organization: Flat UNIX file system
	5) File size (~165 KB average)

I would appreciate it (if there is any online discussion about this topic)
if somebody would be willing to email the discussion to me. But please ask
me first, I don't want to drown in messages :-)

Thanks in advance,

---
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Newsgroups: comp.arch.storage,comp.databases
From: pease@amarna.gsfc.nasa.gov (Pease)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA Goddard Space Flight Center, Greenbelt, Md. USA
Date: Fri, 4 Sep 1992 16:27:00 GMT

In article <1992Aug29.210553.8744@rhein-main.de>, vhs@rhein-main.de writes...
>I need to design a retrieval system for ~15TB of data, of which ~5TB are
>retrieved with a high frequency (25 requests/second) and an access time
>of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
>5TB are real random-access. The rest of the data is still accessed at a
>rate of 5 requests/second. Here, too, access is completely random.
>So far I've come up with the following ideas:
> 
>1) Use large (10GB) WORM jukeboxes with many pickers (~40),
>   many drives (~150) and a *real* intelligent scheduler. No cache.
> 
>2) Use 1) for the less-often-retrieved data, and several 625MB-OD
>   jukeboxes with even more drives and a less intelligent scheduler.
> 
>I figure that doing some 25 media changes a second would be a real
>performance killer. Due to the response time restrictions (30 seconds)
>there is hardly a chance to build a decent queue for pending requests
>and schedule them appropriately.
>So what we really need is 5TB of something like a huge, if slow, hard disk.
>Is there any such kind of device? Any other ideas? Any help?
> 
>Any kind of information is greatly appreciated (hints, pointers, ideas, etc.)
> 
>--
>Volker Herminghaus-Shirai (vhs@rhein-main.de)

One system that I have discovered that may meet your needs is a system
that automates a library of 5.25" optical disks.  Their largest holds
2000 disks.  The factor that makes it applicable is that it can have
up to 100 drives per unit.  However, this unit can only have two
changers and it takes 5 seconds too exchange a disk.

With 1GB magneto-optical rewritable disks (2 GB disks expected by 
spring 93) you could get 2TB/system so you would need 5 systems.
Getting a computer system to handle 500 drives may be tough.

The company is Document Imaging Systems Corp.
               541 Weddell Dr.,
               Sunnyvale, CA., 94089
               tel. (408)734-5287

You have really tough requirements, but maybe if you have enough money
it could be done.

Phil Pease 
My witty disclaimer - everything I perceive, through either sensory or
extrasensory means, has been filtered to such an extent that you had better not
attempt to attribute anything I say to anyone else.
Newsgroups: comp.arch.storage
From: maynard@groo.msc.cornell.edu (Maynard J. Handley)
Subject: Re: Info on flopticals?
Organization: Cornell-Materials-Science-Center
Date: Fri, 28 Aug 1992 02:57:24 GMT

Am I the only one who wonders quite what niche flopticals are supposed to
fit. The most recent prices I've seen have the drive costing about as much
as a Syquest or Bernoulli drive, while each disk also cost about as much
per MB as a Syquest or Bernoulli cartridge. The 88MB Syquest or 90MB
Bernoulli systems are much larger- always more convenient than 4 or 5 20MB
disks- and are hard drive speed rather than floppy speed which I imagine
flopticals run at.

I remain mystified as to why anyone would want to buy these things.

Maynard Handley
From: shafer@CS.ColoState.EDU (spencer shafer)
Newsgroups: comp.arch
Subject: Error Correcting Memory
Date: 3 Sep 92 21:07:30 GMT
Organization: Colorado State University, Computer Science Department

I'm interested in learning about the difference in reliability
between parity memory and error checking-correction memory.  Can
anyone provide me with some pointers to related books/articles?
Or does anyone know straight off what the relative difference is?

Thanks

-- 
/\__________________________________________________________________/\
||                     SPENCER SHAFER                               ||
|| email:shafer@handel.cs.colostate.edu    Work Phone: 303-498-0901 ||
\/------------------------------------------------------------------\/
Newsgroups: comp.arch
From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
Subject: Program behaviour (was Re: trapping speculative ops
Organization: Bell Northern Research Ltd, Ottawa
Date: Thu, 27 Aug 1992 20:28:45 GMT

In article <l9q6e0INN919@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>As far as loads and stores go, I am similarly mystified by the
>insistence that each and every trap from the source program be
>preserved in "very-optimized" code (not code compiled for debugging,
>or at a "normal" level of optimization).

Some people (including me), believe that there is only *one* level
of optimization. One should always ship the same binary that one
tested; doing otherwise expresses immense faith in the ability of
one's process to recompile the same source as well as the correctness
of ones tools - the compilers, optimizes, linkers.

And then there are people who have to debug "very-optimized" code
because the program must interact with the outside world. E.g., when
writing a driver for gigabit per seond device, and the CPU chip can
barely keep up, how do you not debug "very-optimized" code?

Also, there are languages and systems that actually specify the
behaviour for incorrect programs - typically, trap if dereferencing
a wild pointer. Given that most MMUs do quite a good job, it is 
strange to force those compilers to generate slower code.

>For instance, (as has been
>noted by several people before me in more severely refereed forums),
>if page zero is mapped readable, then you can transform
>   [example deleted]
>No hardware support is required, but some other traps might be lost.

No hardware support is required in any case. Most systems already 
have an MMU that can map out page zero. The question is whether
the gain in performance justifies the lost in security. I expect
different people will answer differently.


>Note that the hardware support for what I described above is pretty
>damn cheap.  Note that no changes are needed to the architecture.  

I assume you mean no change to "Instruction Set Architecuture". You
are certainly implying changes to "System Architecture".

>Remember, we've got tools to help us debug our code.  

But only during the "debugging phase". What happens when the program
is released into user hands? OK, for a compiler, you could ask the
user to send you the source files. What if the program controls a 
chemical plant? Are you going to ask the user to ship you a copy of
the plant? Some debugging just *have* to be done on the target system.


--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
Newsgroups: comp.arch
From: nagle@netcom.com (John Nagle)
Subject: Re: 32 => 64 Transition
Date: Sun, 23 Aug 92 18:44:32 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 


       I've developed a nice way to make the transition, one which
produces portable results across machines.  But the effort of working
through the language politics exceeds the value to me of publishing it.

					John Nagle
From: ugurdag@ces.cwru.edu (Fatih Ugurdag)
Newsgroups: comp.arch
Subject: Indexing in microprocessors
Date: 2 Sep 1992 00:25:25 GMT
Organization: Computer Engineering and Science, Case Western Reserve University
NNTP-Posting-Host: mapping.ces.cwru.edu


Is there any microprocessor in which we can access registers in an
indexed fashion such as

"store source_register,register[index_register]"

if index_register holds the value of 3 then this becomes

"store source_register,register3"

This way we can support array operations in the register file.


-- 
Fatih Ugurdag
Case Western Reserve University
Newsgroups: comp.arch