how do I store disk images of unix disk on w95 cdrom
bookofs...@yahoo.com
term reliable storage?
Sent via Deja.com http://www.deja.com/
Before you buy.
Richard Howlett
use "dd" to get the image off the floppy.
dd if=/dev/fd0135ds18 of=sensible_file_name_here
--
Richard Howlett
mailto:ric...@howie.org.uk
Richard Howlett
>
> bookofs...@yahoo.com wrote:
> >
> > How do I store images of unix floppies using w95 cdrom system for long
> > term reliable storage?
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> use "dd" to get the image off the floppy.
>
> dd if=/dev/fd0135ds18 of=sensible_file_name_here
Make that:
dd if=/dev/rfd0135ds18 of=sensible_file_name_here
^
^
An "r" has been added as indicated by the ^.
Jean-Pierre Radley
| Richard Howlett wrote:
| >
| > bookofs...@yahoo.com wrote:
| > >
| > > How do I store images of unix floppies using w95 cdrom system for long
| > > term reliable storage?
| > >
| > > Sent via Deja.com http://www.deja.com/
| > > Before you buy.
| >
| > use "dd" to get the image off the floppy.
| >
| > dd if=/dev/fd0135ds18 of=sensible_file_name_here
|
| Make that:
|
| dd if=/dev/rfd0135ds18 of=sensible_file_name_here
| ^
| ^
| An "r" has been added as indicated by the ^.
Why do you omit a bs=36 in that dd command, Richard?
The time savings for all of those 3.2v4.2 diskettes would be an entire
afternoon.
--
JP
Jeff Liebermann
>How do I store images of unix floppies using w95 cdrom system for long
>term reliable storage?
I've done this several times and had a few suprises. It can become very
tedious if you're not careful.
1. dd if=/dev/rfd0135ds18 of=N1 bs=36b (for 3.5")
dd if=/dev/rfd096ds15 of=N1 bs=30b (for 5.25")
The "N1" is the name of the floppy. For 3.2v4.2, you'll have N1, N2, M1,
and in my case, an image of the QIC-24 cartridge tape. Make sure you use
names that are in ISO 9660 format (8.3) with (8.0) directories, all in
upper case. If you use long filenames, or mulitple periods (VOL.000.000),
ISO9660 will convert the filenames to gibberish.
2. Make sure the directory structure makes sense. This is the ODT (Open
Desktop) section of my cdrom. Note the lack of decimal points (extensions)
in the directory names. (Oh-oh, the devsys is missing...).
odt/
324/ ms42/ tcp121/
odt/tcp121/
devsys ip2 net382e
ip1 ip3 readme
odt/ms42/
readme ub01 ub02 ub03 ub04
odt/324/
m1 n1 n2 readme
3. Note the "readme" files above. These explain exactly what the various
abreviations mean and offer some clues as to order of installation.
4. Make sure that your 3.5" image files are exactly 1,474,560 bytes and
your 5.25" files are exactly 1,228,800. Anything different means you
goofed somewhere.
5. Be sure to include RAWRITE.EXE to allow you to recreate the Unix
floppish from an MSDOS machine.
6. When you burn the cdrom, you will need to use ISO9660 format. This not
the default for most cdburner software which uses the Microsloth
proprietarized mutation of the Rockridge standard called Joliet. SCO Unix
currently does NOT support Joliet filesystems.
7. It should be possible to convert a cartridge tape QIC-24 format the the
weird "cd-tape" format found in 3.2v4.x. I've never tried it and just ran
a dd image of the entire tape.
8. When you ftp the files around, be sure to force a binary transfer and
not use "automatic". This is because some of the ftp software just looks
at the first few bytes and tries to guess if it's text or binary. The cpio
headers found on some floppy images will cause it to guess wrong.
Good luck
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Richard Howlett
>
> Richard Howlett wrote:
> >
> > bookofs...@yahoo.com wrote:
> > >
> > > How do I store images of unix floppies using w95 cdrom system for long
> > > term reliable storage?
> > >
> > > Before you buy.
> >
> > use "dd" to get the image off the floppy.
> >
> > dd if=/dev/fd0135ds18 of=sensible_file_name_here
>
> Make that:
>
> dd if=/dev/rfd0135ds18 of=sensible_file_name_here
> ^
> ^
> An "r" has been added as indicated by the ^.
I retract that last post after just having done some timings. DON'T use the
raw device!
Richard Howlett
>
> Richard Howlett propounded (on Fri, Dec 24, 1999 at 09:10:53PM +0000):
> | >
> | > bookofs...@yahoo.com wrote:
> | > >
> | > > How do I store images of unix floppies using w95 cdrom system for long
> | > > term reliable storage?
> | > >
> | > > Sent via Deja.com http://www.deja.com/
> | > > Before you buy.
> | >
> | > use "dd" to get the image off the floppy.
> | >
> | > dd if=/dev/fd0135ds18 of=sensible_file_name_here
> |
> | Make that:
> |
> | dd if=/dev/rfd0135ds18 of=sensible_file_name_here
> | ^
> | ^
> | An "r" has been added as indicated by the ^.
>
> The time savings for all of those 3.2v4.2 diskettes would be an entire
> afternoon.
JP, are you pulling my chain?
I've done some timings and found that the raw device idea was not a good
one. The bs=36 made no difference using /dev/fd0135ds18. 50 seconds for N1
from the 3.2v4.2 disk set with and without bs=36.
Nah, you must be pulling my chain :-)
Jean-Pierre Radley
I didn't mean to pull your chain.
I did, however, mean to type bs=36b; or for that matter bs=1440k.
bs=36 is just a rather stupid typo on my part.
--
JP
Stephen M. Dunn
$Richard Howlett wrote:
$>
$> Richard Howlett wrote:
$> > dd if=/dev/fd0135ds18 of=sensible_file_name_here
$>
$> ^
$> ^
$> An "r" has been added as indicated by the ^.
$
$I retract that last post after just having done some timings. DON'T use the
$raw device!
I agree :-)
I've always used the block device. Floppies are block devices
anyway - however many or few bytes you may wish to read, the hardware
still reads the whole block. So it makes sense to read/write them
in blocks.
As someone else (Jeff?) suggested, adding a bs parameter might
not be a bad idea. Personally, I use 15k for 1.2 MB and 18k for
1.44 MB; either one is twice the size of a track. As long as you
use something that's a multiple of the track size, you should
get decent performance.
--
Stephen M. Dunn (SD313), CNE, ACE ste...@bokonon.ussinc.com
----------------------------------------------------------------------------
Senior Manager United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7 (416) 750-7946 x251
Jeff Liebermann
Dunn) wrote:
> As someone else (Jeff?) suggested, adding a bs parameter might
>not be a bad idea. Personally, I use 15k for 1.2 MB and 18k for
>1.44 MB; either one is twice the size of a track. As long as you
>use something that's a multiple of the track size, you should
>get decent performance.
Not me. I use the raw device *AND* the bs=36b block size specification out
of habits dating back to the bad olde daze of Xenix and early 3.2.x Unix
running on 386 class hardware. The overhead required by the operating
system in dealing with the buffered IO was too much for these systems. The
disk will need to read a block (512bytes), juggle the buffers, get the next
block, etc. If the deblocking takes too long, the head may not be
properly positioned for the next read causing the disk to spin all the way
around before reading the next block. At one point, I was even formatting
my floppies with a -i 2 (interleave=2) to speed things up.
However, times, OS's and CPU's have changed. What was once considered to
be "substantial overhead" is now trivial on fast CPU's. I also vaguely
recall that there have been some improvements in the OS that eliminates the
"one block, one IRQ" bottleneck. Whatever the cause, using block devices
(buffered IO) is no longer considered to be a bad thing.
I have some ancient hardware floating around in my palatial office and can
run some floppy copy benchmarks for the curious. If I get inspired,
bribed, or make it to the office on Monday, I'll try it and post the
numbers. Meanwhile, my *GUESS* is that it doesn't matter on fast hardware,
but makes a big different on ancient iron.
Incidentally, bs=18k is the same as bs=36b. The 36b means 36 blocks. One
block is 512 bytes or 18Kbytes total.
Tony Lawrence
> I didn't mean to pull your chain.
>
> I did, however, mean to type bs=36b; or for that matter bs=1440k.
> bs=36 is just a rather stupid typo on my part.
I honestly had never thought to use a 1440k block size- in
fact, I haven't thought about it at all in a long time: my
fingers just automatically type "bs=18k" from years of
habit. The time difference on the machine I typically use
actually gives a slight edge to the "bs=18k", which probably
means that the 18k better matches the actual block size used
by the floppy driver, so I'm not going to re-train my
fingers.
The other thing I do on autopilot is "sum -r /dev/fd0" after
the dd. I tried timexing that against "dd if=/dev/fd0
bs=18k | sum -r" and found that the direct "sum -r
/dev/fd0" was marginally faster, though not by much.
That's interesting, because using no specific block size in
a dd read or write gives awful performance- therefore sum
must use a good sized read buffer itself. Given the
observed times, it seems unlikely that you could select a
block size that would override the extra time required for
the double read (once from the disk, once from the pipe),
but other programs and other situations might be worth the
trouble. Ideally, you want to read exactly what the driver
wants to give you in one block and read again exactly when
the driver is ready to give you the next block. On a
multi-user machine, "ideal" is impossible to achieve.
When running such tests, remember to consider the effects of
buffer caching; everything needs to be on an equal footing.
A simple way to account for that on a machine that is not
being used for other tasks is to run each test several times
consecutively.
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.ApLawrence.com
Stephen M. Dunn
article; this will bore you to tears.
In article <38661A6F...@aplawrence.com> Tony Lawrence <to...@aplawrence.com> writes:
$I honestly had never thought to use a 1440k block size- in
$fact, I haven't thought about it at all in a long time: my
$fingers just automatically type "bs=18k" from years of
$habit.
After reading Jeff's response about antique hardware, that
reminds me of antique software: the dd command in Xenix 2.3.4
(but not in 2.3.3) can't handle a block size that
large. I don't recall the exact details, but its limit was certainly
no more than 64k, because I recall wondering whether someone
had slipped an old Xenix 286 binary into the distribution media ...
On a clone Pentium 200 with whatever floppy controller and
floppy drive happen to be there, running OSR5.0.5, I tried all
eight permutations of:
fd0135ds18 vs. rfd0135ds18
and
no bs, bs=18b, bs=18k, bs=1440k
Seven of the eight returned times between 49.09 and 49.11
seconds; the only one that didn't was rfd, bs=1440k, which took
54.29 seconds (the sound of the head moving was somewhat
irregular with that one).
Larger block sizes _did_ reduce CPU utilization. For rfd,
0.07u+1.30s with no bs to 0.00u+0.09s with bs=18k or bs=1440k.
For fd, user time was either 0.00 or 0.01, and the only significant
change in system time was 0.28s (no bs) vs. 0.17-0.20 for the
rest.
Just for kicks, I tried bs=18, in the spirit of JP's typo.
On rfd, it was taking approximately 2 minutes per track, which
works out to roughly 2.5 hours to read a single floppy. On fd,
it was actually slightly _faster_ than any of the other ones
I tried.