<html><head></head><body><div>On Wed, 2015-07-22 at 17:30 +0200, Alfredo Pons wrote:</div><blockquote type="cite"><div dir="ltr"><div><div>Hello,<br><br></div>The bmap-tool (version 3.2) reort this:<br><br><br>root@atlantis:/home/apons/plastia# bmaptool create -o bmap intool-jessie-0.1.img <br>bmaptool: WARNING: all 7.2 GiB are mapped, no holes in 'intool-jessie-0.1.img'<br>bmaptool: WARNING: was the image handled incorrectly and holes were expanded?<br></div></div></blockquote><div><br></div><div>OK, so this is most probably not a bmaptool issue. I am not sure how much docs are</div><div>you willing to read, but here</div><div><br></div><div><a href="https://source.tizen.org/development/reference/bmaptool/introduction">https://source.tizen.org/development/reference/bmaptool/introduction</a></div><div><br></div><div>you could find some explanations about how bmaptool works and why it can be so fast.</div><div><br></div><div>Anyway, the point is that you image should be sparse, but intool-jessie-0.1.img is</div><div>apparently not a sparse file. Bmap tool cannot fix this situation, you should improve</div><div>the tools that generate the image.</div><div><br></div><div>Usually it is as simple as just start with a sparse files. In shell a 7.2GiB file can be</div><div>created using something like</div><div><br></div><div>truncate -s <span style="color: rgb(0, 0, 0); font-family: monospace;">7730941132 </span>intool-jessie-0.1.img</div><div><br></div><div>This file then would be one huge "hole". Then you would partition it using something</div><div>like "parted", format file-systems, copy the initial contents. At the end, the space</div><div>that was never written to would stay in the "hole" state, and bmaptool would notice</div><div>this.</div><div><br></div><div>Not sure if you follow. If not, try to check the link above. Then describe me how you</div><div>create your image and I can try helping you creating it sparse. Once it is sparce,</div><div>not only it saves disk space, but there are opportunities to flash it waay faster.</div><div><br></div><div>Or may be this is the point you are missing: bmap tool _does not_ work on the file-system</div><div>level. It is FS-agnostic. It does not try looking inside your image. Bmap tool really does not</div><div>care what is inside the image.</div><div><br></div><div>The point is that bmaptool looks for "holes", which represent the space that is not needed.</div><div>And the point is that the image creation tools must carefully preserve the holes.</div><div><br></div><div>HTH,</div><div>Artem</div><div><br></div><blockquote type="cite"><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Alfredo Pons</div><div>Mòbil: 637367156</div><div>Blog: <a href="http://gnodebian.blogspot.com.es/" target="_blank">http://gnodebian.blogspot.com.es/</a></div><div>CV: <a href="http://es.linkedin.com/in/alfredopons" target="_blank">http://es.linkedin.com/in/alfredopons</a></div></div></div></div>
<br><div class="gmail_quote">2015-07-22 8:53 GMT+02:00 Artem Bityutskiy <span dir="ltr"><<a href="mailto:dedekind1@gmail.com" target="_blank">dedekind1@gmail.com</a>></span>:<br><blockquote type="cite"><span class="">On Mon, 2015-07-20 at 13:35 +0200, Alfredo Pons wrote:<br>
> It is planned to work with the f2fs filesystem?<br>
> Currently it is not supported.<br>
<br>
</span>Do you want to use f2fs on the build host (the image is created on a<br>
host which uses f2fs) or you want the image to contain f2fs, while the<br>
build host uses something else like ext4?<br>
<br>
Or please, elaborate some more what do you mean by not supported, what<br>
are the symptoms?<br>
<br>
From the build host side, bmap-tools relies on the FIEMAP or FIBMAP<br>
ioctls. Does f2fs support them, if yes, then there should be no<br>
problem. Otherwise, we'd need to see if f2fs offers any alternatives to<br>
these ioctls.<br>
<br>
Thanks!<br>
<br></blockquote></div><br></div>
</blockquote></body></html>