<HTML><HEAD>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type></HEAD>
<BODY dir=ltr bgColor=#ffffff text=#000000>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Tahoma'; COLOR: #000000">
<DIV>This is very good reading! Thank you for sharing it. As a System 
Administrator for a known hosting company I regularly install or supervise such. 
We use CentOS, which is the chosen standard for hosting providers. I don’t 
really know why since Apache is limited. Nonetheless, we have to format for 4096 
blocks so that we maximize disc use of Virtuozzo (OpenVZ; like VMWare). We are 
just beginning to use SD’s for booting machines and I am wondering if you tested 
CentOS? I am not asking for my job use but for Allstar, since I know CentOS and 
not much about FreeBSD or Debian.<BR><BR>Once again, a nice read. Thank 
you!</DIV>
<DIV 
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV style="FONT: 10pt tahoma">
<DIV><FONT size=3></FONT> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=fred@fmeco.com 
href="mailto:fred@fmeco.com">Fred Moore</A> </DIV>
<DIV><B>Sent:</B> Saturday, November 21, 2015 2:43 PM</DIV>
<DIV><B>To:</B> <A title=arm-allstar@hamvoip.org 
href="mailto:arm-allstar@hamvoip.org">arm-allstar@hamvoip.org</A> </DIV>
<DIV><B>Subject:</B> Re: [arm-allstar] faster SD card write</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV 
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>Rich, 
you might not be aware that all SD cards have an internal buffer of 128K.  
So when you transfer a block of data at 4M blocks, the SD card will re-block 
each 4M block to 128K blocks before it is written, this re-buffering takes LOTS 
of time.  I have done extensive testing both reading and writing of 
different block sizes and have found 128k to both read and write faster using 
both OSX, and FreeBSD to usb devices.  Your mileage may very, but mine 
seemed very constant, but only on my machine and OS<BR><BR>Multiple things occur 
that need to be timed to come up with the best figures for your 
system.   Lets look at what happens at the disk level when you are 
reading, if the disk is blocked at 4096, it requires how many blocks to be read 
if you tell it to get 4M you told dd to get, you can look at the disk 
specifications and come close to that estimation, but not so true if you don't 
have 4M consecutive of space in memory and have to page something else out and 
interrupt the disk read, or unknown to you your image file extends a cylinder on 
the drive.    Then what happens with you have one of the drives 
that the specifications show it to be 4096, but is fact reading and writing in 
512k blocks using internal buffering in the drive, it least one of the major 
drive manufactures is doing this (seagate).   Did I mention that on 
most systems the USB buffer's are 4096 again it takes time to re-block no matter 
where it happens.  So if you dump 4M into consecutive memory, it must then 
be read out using 4096 when writing to the USB driver.   Everything 
that is happening is complex. <BR><BR>Then we have some people using Windows, 
some Linux, some OSX, and even me who uses FreeBSD a lot.  These are all 
factors,  as well.  If you get into the kernel code you find that 
different Linux kernels r/w memory in different size blocks, requiring even 
further buffering (time)..  <BR><BR>I only bring this up, to show that 
there is nothing that is absolute best blocking factor and sync vs non-sync on 
each machine, as an example I can turn turn off buffering to my usb drive on osx 
by writing to the un-buffered device ie the raw device, this reduces my image 
writing by a factor of around 20.  No one even mentions this when talking 
about writing an image.  <BR><BR>example   
<BR>of=/dev/rusb1  vs  of=/dev/usb1  <BR><BR>prefixing your disk 
id with an r makes it a raw writing device which is about 20% faster than a 
buffered device.  This is only on the BSD's and OSX<BR><BR>There are lots 
of articles out there on optimizing hard disk and usb attached storage devices, 
some are very deep reading.. <BR>I think it is very hard to make an absolute 
statement what what is best with out testing.  In my case when I was 
wrestling with this it required about 3 days of testing, and reading some kernel 
code to understand all that was happening in my system.. There are scripts out 
that that help you test.. <BR><BR>regards... Fred<BR><BR><BR><BR><BR>
<DIV class=moz-cite-prefix>On 11/20/15 3:41 PM, Rich Prim wrote:<BR></DIV>
<BLOCKQUOTE cite=mid:15126a0f7aa-9c2-814d@webprd-m09.mail.aol.com 
  type="cite"><FONT color=black size=3 face="Arial, Helvetica, sans-serif"><FONT 
  size=3>Gentlemen<BR><BR>If in the dd command you add bs=4M, sync it is 
  faster<BR><BR>I E of=/dev/sdb bs=4M, sync<BR><BR>bs= block size writes the 
  file faster, sync makes sure the code is fully written to the SD 
  card.<BR><BR>Rich Prim WA3IWT<BR></FONT></FONT><BR>-- <BR>This message has 
  been scanned for viruses and <BR>dangerous content by <A 
  href="http://www.mailscanner.info/" 
  moz-do-not-send="true"><B>MailScanner</B></A>, and is <BR>believed to be 
  clean. <BR>
  <FIELDSET class=mimeAttachmentHeader></FIELDSET> <BR><PRE wrap="">_______________________________________________

arm-allstar mailing list
<A class=moz-txt-link-abbreviated href="mailto:arm-allstar@hamvoip.org">arm-allstar@hamvoip.org</A>
<A class=moz-txt-link-freetext href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar">http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</A>

Visit the BBB and RPi2 web page - <A class=moz-txt-link-freetext href="http://hamvoip.org">http://hamvoip.org</A></PRE></BLOCKQUOTE><BR><PRE class=moz-signature cols="72">-- 
Fred Moore
email: <A class=moz-txt-link-abbreviated href="mailto:fred@fmeco.com">fred@fmeco.com</A>
       <A class=moz-txt-link-abbreviated href="mailto:fred@safes.com">fred@safes.com</A>
phone:  321-217-8699
</PRE>
<P>
<HR>
_______________________________________________<BR><BR>arm-allstar mailing 
list<BR>arm-allstar@hamvoip.org<BR>http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar<BR><BR>Visit 
the BBB and RPi2 web page - http://hamvoip.org</DIV></DIV></DIV></BODY></HTML>