19 Jan
2007
19 Jan
'07
2:12 p.m.
Suppose the drives were from the Lilith/Eve workstations. Would the
unix trick of using dd still work?
--
nope. they had their own custom drive interface.
same is true for pretty much every disc before SCSI common command set.
while 512 byte block scsi or ide interfaced mass storage devices now
seem like the only things that ever existed, before the mid 80's there
was no real block-level hard disc standard across manufacturers.
the closest would have been hpib, but that was really only used by HP.
19 Jan
19 Jan
2:20 p.m.
Al Kossow wrote:
while 512 byte block scsi or ide interfaced mass
storage devices now
seem like the only things that ever existed, before the mid 80's there
was no real block-level hard disc standard across manufacturers.
Actually, I've never needed to try this - but is it reasonable to expect a
"modern" system to be able to archive (using dd) a SCSI drive that's been
formatted to something other than a 512 byte block size?
There were a few systems about that used SCSI drives formatted to 256 byte
block sizes, and I expect that 1024 byte blocks aren't unheard of either.
(plus there are many more systems with ST506/412 drives and SCSI bridge boards
that present something other than 512 byte blocks to the user)
I suppose dd should still cope OK - but the question's maybe one of whether
the underlying SCSI drivers will cope...
cheers
Jules
4:03 p.m.
Actually, I've never needed to try this - but is
it reasonable to
expect a "modern" system to be able to archive (using dd) a SCSI
drive that's been formatted to something other than a 512 byte block
size?
Depends on the system. :) Last tiem I looked, NetBSD, at least,
couldn't do anything sensible with a SCSI disk with other than 512-byte
blocks. That was quite a while ago, but I haven't heard anything on
the lists to make me think the status has changed.
I have a big/small (full-height 5?", but holding probably no more than
about 1G) drive formatted with 1K sectors, and a SCSI floppy drive that
uses 256-byte sectors, which I keep specifically as examples of
non-512-byte disks. I think the former came from a NeXT, but don't
recall definitely enough to be sure; the latter I forget the source of.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:13 p.m.
In article <200701192106.QAA06687 at Sparkle.Rodents.Montreal.QC.CA>,
der Mouse <mouse at rodents.montreal.qc.ca> writes:
I'm most likely to attach these to a Sun SPARCstation 5. I believe it
has Solaris on it, or maybe even SunOS. If that doesn't work (wrong
type of SCSI?), I may get out the Sun 3/110, which is definately SunOS
and not Solaris, but I haven't powered up either of these two systems
since I acquird them.
I just figured that Sun + SCSI + dd = least hassles.
Is that a reasonable assumption?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Actually,
I've never needed to try this - but is it reasonable to
expect a "modern" system to be able to archive (using dd) a SCSI
drive that's been formatted to something other than a 512 byte block
size?
Depends on the system. :) [...]
4:16 p.m.
der Mouse wrote:
I thought it might ;)
Actually,
I've never needed to try this - but is it reasonable to
expect a "modern" system to be able to archive (using dd) a SCSI
drive that's been formatted to something other than a 512 byte block
size?
Depends on the system. :) Last tiem I looked, NetBSD, at least,
couldn't do anything sensible with a SCSI disk with other than 512-byte
blocks. That was quite a while ago, but I haven't heard anything on
the lists to make me think the status has changed.
The thing that got me wondering though - surely in the PC world, SCSI CDROM
drives all use something like 2048-byte blocks? They're still mass storage
devices - albeit removeable ones - and so presumably the low level code *has*
to be capable of working with "odd" block sizes.
I'm sure there's lots of filesystem-level code that's hard-coded to expect 512
byte blocks, but it was the CDROM aspect that got me wondering whether at the
lowl level (dd <==> device) it's most likely to work.
I have a big/small (full-height 5?", but holding
probably no more than
about 1G) drive formatted with 1K sectors, and a SCSI floppy drive that
uses 256-byte sectors, which I keep specifically as examples of
non-512-byte disks. I think the former came from a NeXT, but don't
recall definitely enough to be sure; the latter I forget the source of.
I've got various things that operate at 256 byte block sizes - the problem
being that they're not quite "SCSI enough" to work with modern HBA BIOSes
and
OS low-level SCSI drivers. Until that problem's solved, there's just no way to
archive them using modern equipment, whether the archive step is done using
'dd' or something else. :-(
cheers
Jules
4:45 p.m.
On 19 Jan 2007 at 15:16, Jules Richardson wrote:
The thing that got me wondering though - surely in the
PC world, SCSI CDROM
drives all use something like 2048-byte blocks? They're still mass storage
devices - albeit removeable ones - and so presumably the low level code *has*
to be capable of working with "odd" block sizes.
Indeed--and add to that many of the MO drives--some use 1024 and some
2048 byte sectors. I can't imagine that any raw interface that has
to deal with these devices will be intolerant of disks with other
than 512 byte sectors.
Cheers,
Chuck
22 Jan
22 Jan
1:03 a.m.
Last time I
looked, NetBSD, at least, couldn't do anything sensible
with a SCSI disk with other than 512-byte blocks. That was quite a
while ago, but I haven't heard anything on the lists to make me
think the status has changed.
The thing that got me wondering though - surely in
the PC world, SCSI
CDROM drives all use something like 2048-byte blocks? They're still mass storage devices - albeit
removeable ones - and so
presumably the low level code *has* to be capable of working with
"odd" block sizes.
Sufficiently low level, yes. The common SCSI code that both cd and sd
use, that isn't what's causing the trouble. The problems are either in
the disk subsystem assuming DEV_BSIZE sectors or the sd driver assuming
that. (If the former, the cd driver must be faking it.)
The suggestion of using whatever generic SCSI facilities are available
strikes me as a good one. If I had the time and interest I'd hack
something together myself to do that.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6:22 a.m.
der Mouse wrote:
Yes. If you have a 2048-byte-sector disk and can convince the cd
driver to attach to it instead of the sd driver, it might work. :-)
Hmm, I'm not quite sure what you're getting at there - but I've never had any
problems whatsoever with Linux's SCSI CDROM / DVD-ROM support. I've never
poked deeply enough in the code though to see what's going on behind the scenes.
From what Brad said and what I found in sd.c, it looks like disks at least
support powers-of-2 raw sector sizes between 256 and 4096 bytes; any problems
dealing with those drives are either down to SCSI incompatibilities (SASI
devices and/or not-quite-complete device firmware support), incorrect setup
(device needs some vendor-specific voodoo to work), or in trying to impose a
filesystem on the device which is expecting a specific block size.
Last time I looked, NetBSD, at least, couldn't do
anything sensible
with a SCSI disk with other than 512-byte blocks. That was quite a
while ago, but I haven't heard anything on the lists to make me
think the status has changed.
The thing that got me wondering though - surely in
the PC world, SCSI
CDROM drives all use something like 2048-byte blocks? The suggestion of using whatever generic SCSI
facilities are available
strikes me as a good one. If I had the time and interest I'd hack
something together myself to do that.
Using Linux's sg interface to throw raw SCSI commands around is easy enough; I
wrote a userspace driver to do some data archival via a SCSI floppy controller
not so long ago.
However, the problem is that for old devices, they often not quite
SCSI-compliant which upsets the HBA drivers themselves; Linux chokes on
anything that doesn't support Inquiry, for instance - which results in the
kernel not giving you a sg device handle to work with for such a device. It
would seem that (from Al's example) the Mac is perhaps a bit better, in that
you can throw a command at any SCSI device on the bus whether the OS thinks
there's one there or not.
To get oddball SCSI devices going, what's almost needed is a way of
intercepting the kernel boot process such that the user can send a few
vendor-specific setup commands, fake Inquiry data etc. between HBA driver load
and subsequent kernel querying of attached devices. One the kernel thinks
there's a valid device there it'll give you a sg handle to it and you can do
whatever you like. As I recall that's how the Linux OMTI bridge drivers worked
(they were before the days of sg, but allowed the board to appear as a two-LUN
disk device to the HBA driver), but unfortunately the kernel's changed beyond
all recognition since those patches were current.
There is of course the additional problem that a lot of vintage equipment's
actually SASI rather than SCSI, and Linux HBA drivers probably won't cope with
that (even if there's just the HBA and SASI device on the bus). I haven't
tried though because it's a lost cause without some way of faking Inquiry data
anyway :-)
What I'd really like I suppose is a user-space driver for a widget that
provided SCSI and SASI support via a *totally* dumb HBA (i.e. polled I/O and
twiddling of bus lines "directly") - in other words, one step less intelligent
still than most "dumb" HBAs (which still use some sort of SCSI IC). It'd be
slow as molasses, but speed isn't the critical factor compared to flexibility
and ease of driving.
Unfortunately a PC parallel port doesn't quite have enough I/O lines, I
wouldn't have a clue how to make a USB solution (ick!), and building an ISA
card (say) would require kernel drivers (and all the complexity involved
there). One possibility is just to use two parallel ports, but that severely
limits the portability of the device - although I'm getting to the point where
that's preferable to not having any solution at all.
cheers
Jules
7:10 a.m.
Jules Richardson wrote:
What I'd really like I suppose is a user-space driver for a widget that
provided SCSI and SASI support via a *totally* dumb HBA (i.e. polled I/O and
twiddling of bus lines "directly") - in other words, one step less intelligent
still than most "dumb" HBAs (which still use some sort of SCSI IC). It'd be
slow as molasses, but speed isn't the critical factor compared to flexibility
and ease of driving.
There's no reason you can't do this now using linux (and other *nix's no
doubt).
You just mmap the device space into user space and start poking. You
can't use interrupts but you can poll. And it's not that slow, to be honest.
I do this all the time to debug embedded h/w - sometimes even for
production code if the need is just to wack a few things do something
simple.
and simple 5380 style isa scsi cards 9 (i.e. DTC) are easy to find on ebay.
-brad
12:54 p.m.
On 22 Jan 2007 at 5:22, Jules Richardson wrote:
Unfortunately a PC parallel port doesn't quite
have enough I/O lines, I
wouldn't have a clue how to make a USB solution (ick!), and building an ISA
card (say) would require kernel drivers (and all the complexity involved
there). One possibility is just to use two parallel ports, but that severely
limits the portability of the device - although I'm getting to the point where
that's preferable to not having any solution at all.
...or you can use one of the commodity data acquisition boards for a
PC. Plenty of I/O lines and simple enough to program from MS-
DOS/Windows 9x (lmits you to a file size of 4GB, but that should be
enough for older drives). I've got a PCI model here that uses 3 8255
PPI's (please, I know they're far from perfect) that cost about $60.
The ISA version of the card is even cheaper.
Cheers,
Chuck
2:56 p.m.
Chuck Guzis wrote:
On 22 Jan 2007 at 5:22, Jules Richardson wrote:
Hmm. DOS does have the advantage of not getting in the way of doing such
things (and I've already got a DOS PC for Imagedisk work). Plus it's nice to
have short startup times (and even faster shutdown ;)
The only downsides:
1) Lack of long filename support (if I'm archiving something I prefer to
give it a long name rather than having to poke into the archive contents to
see what something is),
2) Lack of remote administration (control via serial port or network would
be handy in some cases).
Longer term I could get around problem #1 if I built some sort of network
support into the application (FTP is perhaps the easiest) - I've been thinking
about doing this with Imagedisk anyway. So far I've not stumbled across any
good programming information for the various DOS TCP/IP stacks, though.
Problem #2 isn't a showstopper - it's just nice to be able to tuck the box out
of the way and control it via another system rather than it needing its own
keyboard / display taking up space.
So yes... DOS may well be the way forward (something probably not heard often :-)
cheers
Jules
Unfortunately a PC parallel port doesn't
quite have enough I/O lines, I
wouldn't have a clue how to make a USB solution (ick!), and building an ISA
card (say) would require kernel drivers (and all the complexity involved
there). One possibility is just to use two parallel ports, but that severely
limits the portability of the device - although I'm getting to the point where
that's preferable to not having any solution at all.
...or you can use one of the commodity data acquisition boards for a
PC. Plenty of I/O lines and simple enough to program from MS-
DOS/Windows 9x (lmits you to a file size of 4GB, but that should be
enough for older drives). I've got a PCI model here that uses 3 8255
PPI's (please, I know they're far from perfect) that cost about $60.
The ISA version of the card is even cheaper. 
3:20 p.m.
It was thus said that the Great Jules Richardson once stated:
Hmm. DOS does have the advantage of not getting in the way of doing such
things (and I've already got a DOS PC for Imagedisk work). Plus it's nice
to have short startup times (and even faster shutdown ;)
The only downsides:
1) Lack of long filename support (if I'm archiving something I prefer to
give it a long name rather than having to poke into the archive contents to
see what something is),
2) Lack of remote administration (control via serial port or network
would be handy in some cases).
You can do #2---in the late 80s/early 90s, I used to log in to my friend's
BBS and drop to DOS to fix problems. The limitations were pretty tough
though---I couldn't run any programs that bypassed MS-DOS for I/O (so the
only editor I could use was EDLIN for instance).
But yes, it's fairly straightforward.
-spc (Which, horrid as it was, was much more user friendly than Unix's
ed ... )
4:39 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Jules Richardson
Sent: Monday, January 22, 2007 11:56 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Archiving workstation hard drives
-snip-
Hmm. DOS does have the advantage of not getting in the way of doing such
things (and I've already got a DOS PC for Imagedisk work). Plus it's nice to
have short startup times (and even faster shutdown ;)
The only downsides:
1) Lack of long filename support (if I'm archiving something I prefer to
give it a long name rather than having to poke into the archive contents to
see what something is),
2) Lack of remote administration (control via serial port or network
would
be handy in some cases).
-----
Ok, to get around #1, use IBm dos 7, DR-DOS, I think there's also OPENDOS,
all of which support LFN IIRC.
And on #2, there were remote control utilities for dos, I don't have any of
them handy anymore unfortunately that allowed remote use of a dos box via
serialport (modem) or network.
23 Jan
23 Jan
8:30 a.m.
Hmm. DOS does have the advantage of not getting in the
way of doing such
things (and I've already got a DOS PC for Imagedisk work). Plus it's nice
to
have short startup times (and even faster shutdown ;)
The only downsides:
2) Lack of remote administration (control via serial port or network
would
be handy in some cases).
Who told you? You can run "doorway" or do a pipe of ctty to comx: but I
don't remember how. Maybe mode ctty>com1: ?
9:13 a.m.
Alexandre Souza wrote:
:) You know I figured there were probably a few things out there, at least for
console apps. Presumably stuffing received input from the network into the
keyboard buffer though and handling video updates direct from video memory
(even in text mode) raises some interesting issues.
It's a tricky thing to do I suppose if the DOS machine happens to support more
than one app, and in this case I could see there being at least a couple
(something to do SCSI/SASI archive and retrieval, something to do floppy disk
archive/retrieval).
At the end of the day if it has to have its own display and keyboard then
that's the way it has to be :) I just like the idea of being able to just
flick the switch on the box to power it off and on, boot from something like a
CF card (remember archive reads/writes will be to a remote system, and DOS
itself won't place high write demands on a CF card), and just telnet/serial
link "into" the machine to control it.
That sort of thing lends itself much better to a Unix environment, but
unfortunately Linux (at least) just puts too much stuff inbetween the user and
the bare metal to make data recovery type work easy.
I keep going round in circles here :)
Hmm. DOS does
have the advantage of not getting in the way of doing such
things (and I've already got a DOS PC for Imagedisk work). Plus it's
nice to
have short startup times (and even faster shutdown ;)
The only downsides:
2) Lack of remote administration (control via serial port or network
would
be handy in some cases).
Who told you? You can run "doorway"
11:50 a.m.
On 23 Jan 2007 at 10:30, Alexandre Souza wrote:
Who told you? You can run "doorway" or
do a pipe of ctty to comx: but I
don't remember how. Maybe mode ctty>com1: ?
How about MODE CON:=COMx: ? (IIRC)
And there were numerous facilities for BBS sysops to run commands
remotely; and there were packagesthat periodically scanned the (text)
display buffer and set VT-100 style updates out the com port. And
there's always PC-anywhere; Remote and about a gazillion other
utilities.
You need only a display card installed--you can leave the monitor
off.
Cheers,
Chuck
12:31 p.m.
At 10:50 AM 1/23/2007, Chuck Guzis wrote:
How about MODE CON:=COMx: ? (IIRC)
And there were numerous facilities for BBS sysops to run commands
remotely; and there were packages that periodically scanned the (text)
display buffer and set VT-100 style updates out the com port. And
there's always PC-anywhere; Remote and about a gazillion other
utilities.
I seem to remember that simple MODE commands don't cut it
when it comes to redirection and cursor behavior. I remember
using a function within my ol' fave Pro-YAM that did a good
job of hosting the DOS prompt out the serial port to my Amiga.
I think I could also dial in to one of the machines to get
to the other. Good times.
- John
22 Jan
22 Jan
4:57 p.m.
On 22 Jan 2007 at 13:56, Jules Richardson wrote:
The only downsides:
1) Lack of long filename support (if I'm archiving something I prefer to
give it a long name rather than having to poke into the archive contents to
see what something is),
2) Lack of remote administration (control via serial port or network would
be handy in some cases).
(1) Just load DOSLFN in your config.sys--you get long filename
support (at least under DOS 7.x) without having to run Windoze.
(2) Run under Win9x--you get TCP/IP support as well as support for a
few other protocols. Win9x doesn't get in the way of doing direct
port access, generally speaking.
No, I'm not an MS booster, but I do like as little interference as
possible when I'm twiddling bits on ports.
Cheers,
Chuck
5:11 p.m.
Chuck Guzis wrote:
On 22 Jan 2007 at 13:56, Jules Richardson wrote:
Hmm, that's interesting. Might give that one a try.
The only downsides:
1) Lack of long filename support (if I'm archiving something I prefer to
give it a long name rather than having to poke into the archive contents to
see what something is),
2) Lack of remote administration (control via serial port or network would
be handy in some cases).
(1) Just load DOSLFN in your config.sys--you get long filename
support (at least under DOS 7.x) without having to run Windoze. (2) Run under Win9x--you get TCP/IP support as well as
support for a
few other protocols. Win9x doesn't get in the way of doing direct
port access, generally speaking.
I'm wary of going anywhere near Win95 to be honest - seems like that would be
asking for stability issues, particularly for any machine that might be left
on for any length of time.
DOS on the other hand was always pretty stable :)
cheers
Jules
6:11 p.m.
[...]
What I'd really like I suppose is a user-space
driver for a widget that
provided SCSI and SASI support via a *totally* dumb HBA (i.e. polled I/O and
twiddling of bus lines "directly") - in other words, one step less intelligent
still than most "dumb" HBAs (which still use some sort of SCSI IC). It'd be
slow as molasses, but speed isn't the critical factor compared to flexibility
and ease of driving.
The lack of a decent 'user port' on PCs is a major pain for hardware
hackers like me :-). Peronally, I'd probably use something like an
HP9000/200 series machine (neat, repairable, and has an exceellent 16 bit
parallel I/O card availalbe), but that's hardly a universal solution.
Unfortunately a PC parallel port doesn't quite have enough I/O lines, I
Could yuo not add some latches/buffers to tha parallel port to get more
I/O lines, and use a couple of the 'handshake' outputs to select between
them?
-tony
19 Jan
19 Jan
3:52 p.m.
In article <45B1181C.50503 at bitsavers.org>,
Al Kossow <aek at bitsavers.org> writes:
Suppose the drives were from the Lilith/Eve
workstations. Would the
unix trick of using dd still work?
--
nope. they had their own custom drive interface.
Are you sure this is the case for the Eve? I mean, this thing has
Bernoulli cartridge disks on it, which certainly would not have been
made custom for the Eve. It looks like a standard SCSI interface and
the discs look stock SCSI as well. How would I differentiate the
custom disk interface from a stock SCSI interface?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6391
days inactive
6395
days old
20 comments
11 participants
participants (11)
-
aek＠bitsavers.org -
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
brad＠heeltoe.com -
cclist＠sydex.com -
geoffr＠zipcon.net -
jfoust＠threedee.com -
julesrichardsonuk＠yahoo.co.uk -
legalize＠xmission.com -
mouse＠Rodents.Montreal.QC.CA -
spc＠conman.org