SD card flashing time

[John Watlington]

[thread misdirected to an internal list, mea culpa.
 listed here in chronological order]

On Sep 15, 2010, at 8:17 AM, Esteban Arias wrote:

> Hi, 
> 
> it is possible reduce the time of flashing xo-1.5?
> Dextrose version, delays 20 mins.
> 
> thanks,
> 
> -- 
>     Esteban Arias
>     Investigación y Desarrollo - Plan Ceibal


On Sep 15, 2010, at 3:41 PM, John Watlington wrote:

> Possibly.   I don't know what SD card you have installed,
> but changing from a class 2 to a class 6 will greatly
> increase the speed of reflasing.
> 
> Otherwise, not really.  You are trying to program a
> 4GB storage device which has an average write speed
> of 2MB/s.   The reason it doesn't actually take 2000
> seconds is that the write speed is actually higher than rated.
> More information on this is available at:
> http://wiki.laptop.org/go/SD_and_USB_FLASH_Drive_Performance
> 
> The best approach to speeding up the existing cards
> is probably to write as small an image as possible,
> then resize it to fill the entire card.   This is not currently
> done for technical reasons described at:
> http://dev.laptop.org/ticket/10040
> We do believe that this is possible, but never agreed
> on the most reliable, least intrusive way to implement it.


On Sep 15, 2010, at 10:14 PM, James Cameron wrote:

> For interest, I've compared the time it takes to fs-update using
> OpenFirmware versus a Linux kernel and shell mediated installation
> method.
> 
> The input data was os852.zd, tested on a specific laptop SHC016013D9
> SKU99.
> 
> It took 00:19:42 to fs-update.  Using Linux, it took 00:24:17.
> 
> Conclusion is no improvement over fs-update.
> 
> Method, for the curious ...
> 
> - boot Ubuntu from USB HDD,
> 
> - capture filesystems using tar,
> 
> mkdir /a
> mount /dev/mmcblk0p1 /a && cd /a && tar cf /var/tmp/boot.tar . && cd && umount /a
> mount /dev/mmcblk0p2 /a && cd /a && tar cf /var/tmp/root.tar . && cd && umount /a
> rmdir /a
> 
> - recreate and restore filesystems using tar,
> 
> time (
> mke2fs -q -O dir_index,^resize_inode -L Boot /dev/mmcblk0p1
> mount /dev/mmcblk0p1 /mnt
> tar --extract --file /var/tmp/boot.tar --directory /mnt
> umount /mnt
> mke2fs -q -O dir_index,^huge_file -E resize=8G -m1 -L OLPCRoot /dev/mmcblk0p2
> mount /dev/mmcblk0p2 /mnt
> tar --extract --file /var/tmp/root.tar --directory /mnt
> umount /mnt
> tune2fs -j -o journal_data_ordered /dev/mmcblk0p2
> )
> 
> Adding the journal *before* extracting cost another ten minutes total
> time.

On 9/15/2010 4:51 PM, Martin Langhoff wrote:

> On Wed, Sep 15, 2010 at 10:14 PM, James Cameron<quozl at laptop.org>  wrote:
>> For interest, I've compared the time it takes to fs-update using
>> OpenFirmware versus a Linux kernel and shell mediated installation
>> method.
> Why not compared to (linux-based) dd? That'd be more fair and gives
> the linux kernel an opportunity to show us whether better IO
> scheduling helps, without gains being clobbered by FS.
> 
> Still, I think OFW is going as fast as possible.
> 
> Do we have numbers on resizing a small fs?
> 
> Could we implement this in the initramfs as a special codepath only
> for firstboot? So with a new OFW:
> 
>  - fs-update runs, completes
>  - if successful, checks for a signed "firstboot" initramfs - or
> passes a firstboot init param to the existing initramfs
>  - the work we described before as happening in the initramfs does not
> change but it is in a more controlled situation (rather than the
> literal firstboot in the hands of kids) and is not expected to
> continue the boot process.
> 
> cheers,
> m

On Sep 15, 2010, at 11:33 PM, Mitch Bradley wrote:

>  The time is heavily dominated by large-block-size sequential writes to the SD card,
> so there is little opportunity for better I/O scheduling.  OFW already overlaps the read
> from the USB device with SD writing, so there isn't much additional parallelism available
> for picking.
> 
> It's possible that writing a small filesystem image, then resizing it, would help, but I'm not
> expecting a huge gain,  because of the way that ext2/3/4 allocates block maps.  It's not as
> simple as just tacking free space onto the end.
> 

On Sep 15, 2010, at 11:39 PM, Paul Fox wrote:

> martin wrote:
>> Why not compared to (linux-based) dd? That'd be more fair and gives
>> the linux kernel an opportunity to show us whether better IO
>> scheduling helps, without gains being clobbered by FS.
>> 
>> Still, I think OFW is going as fast as possible.
>> 
>> Do we have numbers on resizing a small fs?
>> 
>> Could we implement this in the initramfs as a special codepath only
>> for firstboot? So with a new OFW:
>> 
>> - fs-update runs, completes
>> - if successful, checks for a signed "firstboot" initramfs - or
>> passes a firstboot init param to the existing initramfs
>> - the work we described before as happening in the initramfs does not
>> change but it is in a more controlled situation (rather than the
>> literal firstboot in the hands of kids) and is not expected to
>> continue the boot process.
> 
> all automagically?  interesting.  we'd have to think through how
> that changes things for:
>    - deployments doing local installs on thousands of laptops.
>    - classroom upgrades.
>    - the first boot at the factory.
> 
> someone with an 8G machine should time resizefs of a 2G install
> to fill the disk.  i suspect booting from a USB stick to do the
> resize after an initial fs-update would be sufficiently close to
> the timing we'd see from initramfs.  i believe the 2G-->4G resizes
> i saw were taking 40 seconds, but that was on a live filesystem --
> one hopes an unmounted fs would be faster.