>X-Authentication-Warning: Consulate.UFP.CX: rhw owned process doing -bs
>Date: Mon, 6 Mar 2000 02:07:56 +0000 (GMT)
>From: Riley Williams <[EMAIL PROTECTED]>
>X-Sender: [EMAIL PROTECTED]
>To: Juanjo Marin <[EMAIL PROTECTED]>
>Subject: Re: dd command (it was Call for a README)
>
>Hi Juanjo.
>
> >> There are two points that need considering:
>
> >> 1. Larger block sizes are indeed faster up to a point.
> >> However, all floppy disks used on ix86 have a sector
> >> size of 512 bytes, so anything larger than that is
> >> meaningless. Remember that the time to write to the
> >> floppy will swamp any savings from reading the kernel
> >> image in larger blocks from the hard drive.
>
> >> 2. Some implementations of the dd command have a bug that
> >> results in their ignoring the final block if it is not
> >> the full blocksize in length, and would produce faulty
> >> floppies if used.
>
> >> My comments therefore pointed out that...
>
> >> a. If the dd command is used to write the floppies, it is
> >> ESSENTIAL that the bs=1 parameter be specified UNLESS
> >> we can guarantee that the raw kernel image size will be
> >> a multiple of some larger number.
>
>The alternative would be to specify the size of the kernel image
>as the blocksize and treat it as one large block. However, in
>this application, there's unlikely to be any speed difference
>between the two simply because the floppy drive is so much
>slower...
>
> >> b. Because of the problem mentioned in (2) above, I would
> >> NOT recommend the use of the dd command in the install
> >> guide.
>
> > I understand now what you say.
>
> >> Noting that the three commands are exactly equivalent as
> >> far as writing to floppy is concerned, I would recommedn
> >> the use of the `cp elks.img /dev/fd0` command for producing
> >> the floppies simply because doing so minimises the
> >> likelihood of producing a faulty floppy.
>
> > I sounds more sensible... Matt what do you think about
> > changing your INSTALL with this new process of creating the
> > disks? or anybody knows a good reason for not changing it?
>
> >>> My last question: it could be nicer/better to use
> >>> conv=noerror,notrunc,sync ?
>
> >> I'm not sure what you are referring to here, sorry?
>
> > These are options for the dd commands I read in the dd man
> > page.
>
>Ah...
>
> > conv=flags Convert the input according to one or more
> > (comma-separated) flags listed below
>
> > ...
>
> > noerror = continue processing when erros occur (up to 5 in
> > a row). Well, then I thin that this flag it's not useful
> > for us :-).
>
>To be honest, it'd do more harm than good - if an error occurs on
>the boot floppy we're creating, we want to know about it...
>
> > notrunc = Don't truncate output file
>
>Not really relevant when the output file is a device.
>
> > sync = Pad input blocks to ibs
>
>If that ensures that the whole kernel image is written out, then
>yes, it would be useful.
>
> > Well I this moment I think I am not quite sure if these
> > flags are useful for our purposes or not. All this stuff is
> > starting to be a bit of mess for me :-( ....
>
>I know the feeling, don't worry...
>
>
>Best wishes from Riley.
>
> * Copyright (C) 2000, Memory Alpha Systems.
> * All rights and wrongs reserved.
>
>+----------------------------------------------------------------------+
>| There is something frustrating about the quality and speed of Linux |
>| development, ie., the quality is too high and the speed is too high, |
>| in other words, I can implement this XXXX feature, but I bet someone |
>| else has already done so and is just about to release their patch. |
>+----------------------------------------------------------------------+
> * http://www.memalpha.cx/Linux/Kernel/
>
>
Juanjo Marín
Becario Monitor del Programa
de Formación de Personal de Apoyo
a la Investigación y más allá
teléfono: 954 55 10 17
email: [EMAIL PROTECTED]
_/_/_/ _/_/_/ _/_/_/
_/ de _/ _/ _/ _/
_/ _/_/_/ de _/ _/
_/ entro _/roceso _/atos _/
_/_/_/ _/ _/_/_/_/
Universidad de Sevilla
E S P A Ñ A / S P A I N / S P A N I A
