Re: XO-1.75 - Flash, Java?
On Thu, Apr 14, 2011 at 12:47 AM, Carlos Nazareno object...@gmail.com wrote: Will Flash Flash Player Java SE (not JavaME) run on the XO-1.75, it being non-x86? For Android, Flash Player requires an ARMv7 (Cortex) + to run. Flash Player 9 was running on the N900 which ran Maemo. Video calls streaming over internet is now one of the most important uses for developing countries and for children to talk to family members like parents who work overseas like here in the Philippines. Aside from Skype, Flash facilitates this for streaming. AFAIK Youtube will also be rolling out more livestreaming soon and will probably do full streaming for anyone a la Ustream in the future. Java should be OK. The version that Fedora ships is based on the open GPL version that is called IcedTea and is fully certified by the Java group. We'll know more in the next month or so. Flash might be a little more difficult as the version on the n900 wasn't generally downloadable. gnash and/or lightspark should work though. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 RAM [Devel Digest, Vol 62, Issue 25]
-- Message: 4 Date: Thu, 14 Apr 2011 10:36:10 +1000 From: Sridhar Dhanapalan srid...@laptop.org.au Subject: Re: XO-1.75 RAM To: mi...@bga.com Cc: OLPC Devel devel@lists.laptop.org Message-ID: BANLkTi=_aasxf7++bmxoysaxvmxga4p...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On 14 April 2011 06:16, Mikus Grinbergs mi...@bga.com wrote: Might 1GB of RAM ?become a performance bottleneck? I myself am skeptical of efforts to use the OLPC where a desktop system might be more effective. ?I've run various large applications on an XO-1.5 system, and have not myself experienced memory shortage. Unless the RAM chips on the XO-1.75 are socketed (and thus easily replaceable), it seems to me that it would be easier to add swap space (rather than RAM) to those systems used to run particularly memory-hungry applications (such as video editing). Flash storage is mush slower than spinning hard drives and wears out far more quickly. I don't think using flash for swap is a good idea. For what it worths I have the same SDcard on the XO-1 with more than 1500 hours of swap use of a 256MB partition, with no problem so far. On the XO-1.5 and its 1GB RAM a rarely see any swap use at all. If anything I would rather see the extra cost towards a proper small SSD to replace SDcards, than extra RAM ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO1 | Same hardware, slower internet [Devel Digest, Vol 62, Issue 25]
-- Message: 5 Date: Wed, 13 Apr 2011 19:52:55 -0500 From: Mikus Grinbergs mi...@bga.com Subject: Re: [Sugar-devel] [DESIGN] XO1 | Same hardware, slower internet To: Anish Mangal an...@activitycentral.org Cc: Lucian Branescu lucian.brane...@gmail.com, OLPC Devel devel@lists.laptop.org, Sugar Devel sugar-de...@lists.sugarlabs.org Message-ID: 4da64567.20...@bga.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hmm, it'd be interesting to see how much of a performance improvement webkit offers. It's no big deal to run webkit-based browsers on the XO. For instance, all of my XO-1s have Midori installed. The question is - what is this performance improvement that you are looking for? I believe that in practice, it is the usability of a browser that is noticed the most, not the performance. What Midori has is a smaller footprint - what it does not have is a richer experience than Firefox - the result is that I myself prefer using Firefox on the XO-1 to using Midori on the XO-1. [In my opinion, the performance of the two is roughly equivalent (e.g., in showing YouTube videos).] It is worth noting that the Google Chrome browser, which *does* have the reputation (in the general public) of better performance, does not stand out on the XO (perhaps because its footprint is large). Performance is indeed a preference but speed is not. And Midori really blows away Firefox both in F11 and F14 XO-1 builds. Google Chrome is also considerably faster than firefox on the XO-1 and on the XO-1.5, Iron is is no-contest (too bad it does not run on the XO-1). So webkit does look faster than gecko on both XO-1 and XO-1.5. Of course none of them will improve youtube/flash performance on the XO-1. But maybe the new geode-driver, being currently discussed, will. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 RAM
On Thu, Apr 14, 2011 at 12:01:47AM -0700, Yioryos Asprobounitis wrote: For what it worths I have the same SDcard on the XO-1 with more than 1500 hours of swap use of a 256MB partition, with no problem so far. Cool. What was the unit cost of the SD card, what size was it, and how many writes were made over those 1500 hours to the SD card as a whole? (... not just the swap partition, since endurance of the card relates to total writes to the card). -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 RAM
--- On Thu, 4/14/11, James Cameron qu...@laptop.org wrote: From: James Cameron qu...@laptop.org Subject: Re: XO-1.75 RAM To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: devel@lists.laptop.org Date: Thursday, April 14, 2011, 3:33 AM On Thu, Apr 14, 2011 at 12:01:47AM -0700, Yioryos Asprobounitis wrote: For what it worths I have the same SDcard on the XO-1 with more than 1500 hours of swap use of a 256MB partition, with no problem so far. Cool. What was the unit cost of the SD card, what size was it, That was/is a $15 Transcend 4GB class 6 card that not only can have 5 erase blocks open but also has an impressive random w/r speed (full flashbence data is attached) and how many writes were made over those 1500 hours to the SD card as a whole? (... not just the swap partition, since endurance of the card relates to total writes to the card). Sorry no data on this, but the card is also holding an OS. Ubuntu 8.10 till recently and XOpup the last couple of weeks. Probably 1000 of the 1500 hours where run with this alternative OS, so I would think a lot of writes. Two caveats though, the card spend half of its life with an ext2 file system and the other half with an ext3. My Ubuntu OS was configured with `vm.swappiness=0' (no swappiness settings for the OLPC builds in the NAND). Transcend 4GB class6 Size: 3905536 /sys/devices/pci:00/:00:0c.0/mmc_host/mmc2/mmc2:8c10/name SU04G /sys/block/mmcblk0/device/ name SDC oemid 0x5356, manfid 0x1c, hwrev 0x1, fwrev 0x0, serial 0x05593bca, scr 0235, csd 400e00325f591dcb7f800a40 bash-4.1# ./flashbench -a /dev/mmcblk0 --blocksize=1024 align 1073741824pre 604µs on 669µs post 576µs diff 79.1µs align 536870912 pre 586µs on 658µs post 568µs diff 81.3µs align 268435456 pre 579µs on 658µs post 567µs diff 85.1µs align 134217728 pre 585µs on 655µs post 563µs diff 81.3µs align 67108864 pre 582µs on 661µs post 554µs diff 92.6µs align 33554432 pre 582µs on 653µs post 563µs diff 80.6µs align 16777216 pre 587µs on 660µs post 562µs diff 85.5µs align 8388608 pre 584µs on 669µs post 566µs diff 93.7µs align 4194304 pre 589µs on 664µs post 567µs diff 86.6µs align 2097152 pre 585µs on 659µs post 569µs diff 81.3µs align 1048576 pre 588µs on 643µs post 594µs diff 52.2µs align 524288pre 588µs on 640µs post 584µs diff 54.3µs align 262144pre 580µs on 638µs post 587µs diff 54.4µs align 131072pre 584µs on 635µs post 586µs diff 49.9µs align 65536 pre 594µs on 635µs post 588µs diff 43.8µs align 32768 pre 571µs on 614µs post 563µs diff 46.9µs align 16384 pre 574µs on 609µs post 565µs diff 39.6µs align 8192 pre 572µs on 614µs post 562µs diff 46.9µs align 4096 pre 573µs on 610µs post 565µs diff 41.3µs align 2048 pre 560µs on 564µs post 558µs diff 5.55µs bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[16 * 1024] /dev/mmcblk0 --open-au-nr=4 2MiB9.38M/s 1MiB8.67M/s 512KiB 8.88M/s 256KiB 8.49M/s 128KiB 8.63M/s 64KiB 9.83M/s 32KiB 10.6M/s 16KiB 8.59M/s bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[16 * 1024] /dev/mmcblk0 --open-au-nr=5 2MiB9.96M/s 1MiB9.28M/s 512KiB 9.5M/s 256KiB 9.06M/s 128KiB 9.22M/s 64KiB 10.2M/s 32KiB 10.5M/s 16KiB 8.7M/s bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[16 * 1024] /dev/mmcblk0 --open-au-nr=6 2MiB6.65M/s 1MiB5.93M/s 512KiB 2.45M/s 256KiB 1.35M/s 128KiB 720K/s 64KiB 381K/s 32KiB 194K/s 16KiB 97.6K/s bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[16 * 1024] /dev/mmcblk0 --random --open-au-nr=4 2MiB5.96M/s 1MiB5.55M/s 512KiB 5.1M/s 256KiB 4.91M/s 128KiB 4.8M/s 64KiB 4.75M/s 32KiB 4.09M/s 16KiB 3.3M/s bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[16 * 1024] /dev/mmcblk0 --random --open-au-nr=5 2MiB6.05M/s 1MiB5.61M/s 512KiB 5.12M/s 256KiB 4.91M/s 128KiB 4.8M/s 64KiB 4.7M/s 32KiB 4.11M/s 16KiB 3.28M/s bash-4.1# ./flashbench -O --erasesize=$[2 * 1024 * 1024] --blocksize=$[4 * 1024] /dev/mmcblk0 --random --open-au-nr=6 2MiB7.97M/s 1MiB4.28M/s 512KiB 2.52M/s 256KiB 1.36M/s 128KiB 722K/s 64KiB 378K/s 32KiB 193K/s 16KiB 97.5K/s bash-4.1# ./flashbench --erasesize=$[2 * 1024 * 1024] --findfat --random /dev/mmcblk0 2MiB5M/s 7.62M/s 7.14M/s 12.6M/s 12.5M/s 12.3M/s 1MiB4.78M/s 4.85M/s 4.82M/s 3.46M/s 3.47M/s 3.52M/s 512KiB 3.52M/s 3.54M/s 3.53M/s 3.53M/s 3.53M/s
XO-1.5 Q3A64 released
G'day, I've released Q3A64, which compared to the previous stable Q3A62 includes the following [1] [2]: - active maximum power point tracking for solar panel charging, on XO-1.5 D5 and D6, - integrated bat-recover tool, - device tree adjustments for RTC and DCON, - a few SDHCI and USB changes, such as a fix for hot plug behind a hub, - fs-update can now properly handle .zd files that write MBR as last step. [1] http://wiki.laptop.org/go/OLPC_Firmware_q3a63 [2] http://wiki.laptop.org/go/OLPC_Firmware_q3a64 -- James Cameron http://quozl.linux.org.au/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 RAM
On Thu, Apr 14, 2011 at 01:21:23AM -0700, Yioryos Asprobounitis wrote: That was/is a $15 Transcend 4GB class 6 card that not only can have 5 erase blocks open but also has an impressive random w/r speed (full flashbence data is attached) Okay, thanks. I don't know a deployment willing to fork out an extra $15 per laptop for performance ... but others in my team might know. Sounds like a very nice card if one can afford it, and if the current batch persists in the same endurance and performance. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 - Flash, Java?
On Thu, Apr 14, 2011 at 2:33 AM, Peter Robinson pbrobin...@gmail.com wrote: Java should be OK. The version that Fedora ships is based on the open GPL version that is called IcedTea and is fully certified by the Java group. We'll know more in the next month or so. Yep. Also to note that it is missing in the F13 ARM build so it may be held up with some problem. Flash might be a little more difficult as the version on the n900 OTOH, I have seen Flash running on Ubuntu on ARM (on the Freescale Cortex SOC), so it is possibly within reach... of Adobe. Nothing we can do on that front. Carlos -- please make sure you chase Adobe on this topic. And Skype. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: zhashfs: write first block last
On Wed, Apr 13, 2011 at 6:03 PM, Daniel Drake d...@laptop.org wrote: OFW is now fixed in svn (accepts this new format without any confusing error), a release should be made soon. As for zhashfs, writing block 0 as all-zero was unnecessary as the entire SD card gets blanked at the start of fs-update. (tweaked this locally) Excellent -- hope we leave the format migration niggles behind quickly and without too much confusion. This is a much welcome improvement to fs-update! m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 - Flash, Java?
Carlos -- please make sure you chase Adobe on this topic. And Skype. m Will re-initiate talks w/ Adobe folks. Btw, congrats on the recent developments in South America guys! Really cool stuff! :) -Naz -- carlos nazareno http://twitter.com/object404 http://www.object404.com -- core team member phlashers: philippine flash actionscripters http://www.phlashers.com -- poverty is violence ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SD cards and DATA_STAT_AFTER_ERASE
Hi Arnd, As you've obviously been working with a large range of SD cards, I wonder if you have any comments/knowledge on erase behaviour. The SD card spec says that CMD32/CMD33 erase can leave the data as either all-zero or all-one, depending on bit 55 (DATA_STAT_AFTER_ERASE) of the SCR. Do you have any comments on the general trend is for DATA_STAT_AFTER_ERASE? Do most vendors erase as 0 or erase as 1? I've seen the discussions around badly manufactured SD cards; do you know how reliably this bit is set by the vendors? If they set it incorrectly it would be quite inconvenient for my plans. Currently, when installing software, OLPC firmware erases the entire disk then writes the entire disk contents, even if most of that is zeroes. I am looking at an optimization where we can simply avoid writing those 0 blocks, greatly speeding up the flashing process. In my test case of 1 SD card, DATA_STAT_AFTER_ERASE=0 and the vendor is not lying about this, so I managed to cut down the time needed to install an OS image by more than 50%. Hopefully this can apply on a wider basis... Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-1.5 users: need your SD card data
Hi, I may have found a way to make fs-update run on steroids. But I need to know if all/most SD cards are like mine. Please open your XO-1.5 and run: cat /sys/devices/pci:00/:00:0c.0/mmc_host/mmc2/mmc2:*/scr And post the output here. Please state clearly if this is a SD card that you installed yourself, or if its the one that was shipped in the laptop by default from OLPC. The optimization I'm looking at is that fs-update first erases the disk (which only takes a split second) and then spends most of its time writing zeroes, but for some SD cards (hopefully most of them), erasing the disk zeroes out the whole thing anyway. So no need to spend loads of time writing zeroes. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data
On Thu, Apr 14, 2011 at 5:26 PM, Daniel Drake d...@laptop.org wrote: Hi, I may have found a way to make fs-update run on steroids. But I need to know if all/most SD cards are like mine. Please open your XO-1.5 and run: cat /sys/devices/pci:00/:00:0c.0/mmc_host/mmc2/mmc2:*/scr And post the output here. Please state clearly if this is a SD card that you installed yourself, or if its the one that was shipped in the laptop by default from OLPC. The optimization I'm looking at is that fs-update first erases the disk (which only takes a split second) and then spends most of its time writing zeroes, but for some SD cards (hopefully most of them), erasing the disk zeroes out the whole thing anyway. So no need to spend loads of time writing zeroes. Do you want that sort of data just for the SD cards used specifically in the XO. I have around 20 cards used for various linux hosts and I can give you the info for them all if its useful. Also generally writing zeros to any flash memory that implements its own wear levelling algorithms I would have though wouldn't be of much use. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data
original from olpc (the same value in 3 XOs) 02358000 Gonzalo On Thu, Apr 14, 2011 at 4:26 PM, Daniel Drake d...@laptop.org wrote: Hi, I may have found a way to make fs-update run on steroids. But I need to know if all/most SD cards are like mine. Please open your XO-1.5 and run: cat /sys/devices/pci:00/:00:0c.0/mmc_host/mmc2/mmc2:*/scr And post the output here. Please state clearly if this is a SD card that you installed yourself, or if its the one that was shipped in the laptop by default from OLPC. The optimization I'm looking at is that fs-update first erases the disk (which only takes a split second) and then spends most of its time writing zeroes, but for some SD cards (hopefully most of them), erasing the disk zeroes out the whole thing anyway. So no need to spend loads of time writing zeroes. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
11.2.0 development build 16 released
http://wiki.laptop.org/go/11.2.0 http://build.laptop.org/11.2.0/os16 Notable changes: Firmware q3a64 - includes major changes in battery charging code. We are looking for testing for charging with both AC power and solar panels. A handful of Fedora updates Added some diagnosis in the kernel logs for #10748 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 16 released
No new activities? http://dev.laptop.org/ticket/10790 Do you need anything more? Gonzalo On Thu, Apr 14, 2011 at 2:20 PM, Daniel Drake d...@laptop.org wrote: http://wiki.laptop.org/go/11.2.0 http://build.laptop.org/11.2.0/os16 Notable changes: Firmware q3a64 - includes major changes in battery charging code. We are looking for testing for charging with both AC power and solar panels. A handful of Fedora updates Added some diagnosis in the kernel logs for #10748 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 16 released
On Thu, Apr 14, 2011 at 12:27 PM, Gonzalo Odiard gonz...@laptop.org wrote: No new activities? http://dev.laptop.org/ticket/10790 Do you need anything more? Just a reminder on helloworld activity, that is not working for older sugars because lacking of new toolbars compatibility. Cheers!. Gonzalo On Thu, Apr 14, 2011 at 2:20 PM, Daniel Drake d...@laptop.org wrote: http://wiki.laptop.org/go/11.2.0 http://build.laptop.org/11.2.0/os16 Notable changes: Firmware q3a64 - includes major changes in battery charging code. We are looking for testing for charging with both AC power and solar panels. A handful of Fedora updates Added some diagnosis in the kernel logs for #10748 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 16 released
On Thu, Apr 14, 2011 at 3:04 PM, Rafael Ortiz raf...@activitycentral.comwrote: On Thu, Apr 14, 2011 at 12:27 PM, Gonzalo Odiard gonz...@laptop.orgwrote: No new activities? http://dev.laptop.org/ticket/10790 Do you need anything more? Just a reminder on helloworld activity, that is not working for older sugars because lacking of new toolbars compatibility. Yes, say 0,86 - 0,92 in ASLO. Patches welcomed :) Cheers!. Gonzalo On Thu, Apr 14, 2011 at 2:20 PM, Daniel Drake d...@laptop.org wrote: http://wiki.laptop.org/go/11.2.0 http://build.laptop.org/11.2.0/os16 Notable changes: Firmware q3a64 - includes major changes in battery charging code. We are looking for testing for charging with both AC power and solar panels. A handful of Fedora updates Added some diagnosis in the kernel logs for #10748 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data [Devel Digest, Vol 62, Issue 28]
original from olpc (the same value in 3 XOs) 02358000 Same on 2 XO-1.5. One C2 one C3 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD cards and DATA_STAT_AFTER_ERASE
Currently, when installing software, OLPC firmware erases the entire disk then writes the entire disk contents, even if most of that is zeroes. I am looking at an optimization where we can simply avoid writing those 0 blocks, greatly speeding up the flashing process. In my test case of 1 SD card, DATA_STAT_AFTER_ERASE=0 and the vendor is not lying about this, so I managed to cut down the time needed to install an OS image by more than 50%. Hopefully this can apply on a wider basis... I suggest writing paranoia into your code. Check the flag bit if you like, but also, read back an erased block and see if it's 1's or 0's. Hmm! You can make it perfectly symmetrical: Erase the drive, read back a block, then compare each block (that you consider writing), to that block which you read back. If it erases to all ones, you won't write any all-one blocks to the drive. If it erases to all zeroes, you won't write any all-zero blocks to the drive. (Of course, when doing these writes, don't do one-block writes to the drive; accumulate a bunch of them into a single larger write. If you know the erase block size, the code could seek to do writes of that size, aligned on that boundary - particularly after recovering from a series of blocks it doesn't need to write to. But some cards may be able to erase several blocks simultaneously, and may thus prefer a write of N erase blocks. Or cards may or may not care whether your writes are aligned (since they're remapping the blocks anyway through the flash translation layer), and may just prefer that you always write one or more erase-blocks' worth of data, no matter what the alignment. Since reading flash is much faster than writing (and since one of the nasty aspects of flash is that writing block X can screw up the contents of block X-1 or X+1), would you consider reading back the entire drive after you're done, making sure the whole thing checksums properly? (And also making sure that your checksum detects substitutions of entire all-1 blocks for entire all-0 blocks and vice verse!) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data
G'day Daniel,
As an alternative, consider identifying the unused blocks in the
filesystem, and avoid including them in the .zd file. This would make
it unnecessary to know whether the bits will be set or cleared by the
card. ext2, ext3, and ext4 care nothing for the bits in unused blocks.
zerofree [1] demonstrates how to identify the unused blocks. The
attached patch to zerofree-1.0.1 lets me dump the block numbers of the
unused blocks without changing the filesystem:
zerofree -nd filesystem.img filesystem-free-blocks
The block numbers might then be used by a modified zhashfs, or zhashfs
might make the same block bitmap test calls that zerofree makes.
It is said by the author [1] and in various places that zerofree can
work with ext4 ... I've run it against the ext4 partition of an SD card
that contains os14 ... with no apparent ill-effects.
However, Richard Jones suggests [2] that files with extents may not be
handled. I'm not sure if that is a concern for olpc-os-builder images.
References:
1. http://intgat.tigress.co.uk/rmy/uml/
2. http://www.redhat.com/archives/libguestfs/2010-June/msg00019.html
--
James Cameron
http://quozl.linux.org.au/
--- zerofree.c.orig 2011-04-15 11:40:12.0 +1000
+++ zerofree.c 2011-04-15 11:40:44.0 +1000
@@ -36,8 +36,9 @@
int old_percent ;
int verbose = 0 ;
int dryrun = 0 ;
+ int dump = 0 ;
- while ( (c=getopt(argc, argv, nv)) != -1 ) {
+ while ( (c=getopt(argc, argv, nvd)) != -1 ) {
switch (c) {
case 'n' :
dryrun = 1 ;
@@ -45,6 +46,9 @@
case 'v' :
verbose = 1 ;
break ;
+ case 'd' :
+ dump = 1 ;
+ break ;
default :
fprintf(stderr, USAGE, argv[0]) ;
return 1 ;
@@ -114,6 +118,10 @@
++free ;
+ if ( dump ) {
+ fprintf(stderr, %ld\n, blk);
+ }
+
percent = 100.0 * (double)free/
(double)current_fs-super-s_free_blocks_count ;
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
