On 2011-07-25, at 10:34 AM, Round Robinjp wrote: > Many Thanks for the reply. > > In both the ways you have shown, the eMMC device needs > to be zeroed in advance. But so far as I know, writing > 4G bytes of zeros and writing 4G bytes of real data has > no difference. So this does not solve the problem. > Please correct me if I am wrong. I was hoping that MMC had some sort of "TRIM" or "UNMAP" command. It might also be possible to use/modify the QCOW2 tools so that they don't _save_ zero blocks in the image file, but write them out at restore time? Alternately, with the "lazy_itable_init" option if you have a new enough kernel (maybe 2.6.38 or 2.6.39?), it will zero the inode table blocks for you. > Any other options? > > Thanks > Robin > > > --- Andreas Dilger wrote: >> If you can wipe the MMC device to be all-zero efficiently, then you can format it quickly with "mke2fs -E lazy_itable_init,lazy_journal_init ..." and restore from a tarball. >> >> Alternately, Lukas recently added support for QCOW2 sparse image format, and it should be possible to restore this to the device efficiently, if it is zeroed in advance. I don't know if his code skips all-zero blocks in the image, but that should be possible to add fairly easily. >> >> Cheers, Andreas >> >> On 2011-07-22, at 9:49 AM, Round Robinjp <roundrobinjp@xxxxxxxxxxx> wrote: >> >>> Hi >>> >>> I have a question regarding making ext4 image for >>> large eMMC partition. >>> >>> We have a 4G partition in our embedded device >>> in which we want to use ext4 filesystem. >>> But for that we have to create a 4G image. >>> flashing this 4G image to the eMMC takes a long >>> time. Is there any way to reduce this time? >>> >>> For vfat, you can truncate the image leaving only >>> non zero-filled blocks which makes the image very >>> short and the time for flashing is reduced. >>> Is something similar to that possible for ext4? >>> >>> Thanks >>> Robin Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
