[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<qu...@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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel