block size for dd

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Sun Dec 26 08:43:52 1999
Xref: world comp.unix.sco.misc:112702
Newsgroups: comp.unix.sco.misc
Path: world!news
From: Tony Lawrence <tony@aplawrence.com>
Subject: Re: how do I store disk images of unix disk on w95 cdrom
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <38661A6F.6644A738@aplawrence.com> 
Date: Sun, 26 Dec 1999 13:38:55 GMT
Content-Transfer-Encoding: 7bit
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
References: <840km7$mcc$1@nnrp1.deja.com> <3863DF9A.2D9B9039@NOSPAM-howie.org.uk> <3863E15D.BEDFC33C@NOSPAM-howie.org.uk> <19991224163930.H1689@jpradley.jpr.com> <38641337.8A8223B5@NOSPAM-howie.org.uk> <19991224234515.B13997@jpradley.jpr.com> 
Nntp-Posting-Host: world.std.com
Mime-Version: 1.0
X-Mailer: Mozilla 4.7 [en] (X11; I; SCO_SV 3.2 i386)
Organization: A.P. Lawrence
Lines: 42
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

Jean-Pierre Radley wrote:

> 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 (tony@aplawrence.com)
SCO articles, help, book reviews, tests, 
job listings and more : http://www.ApLawrence.com

Take Control of Your iPhone Apps

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.