f2fs filesystem in bmap-tool

Artem Bityutskiy dedekind1 at gmail.com
Tue Jul 28 00:19:14 PDT 2015


On Wed, 2015-07-22 at 17:30 +0200, Alfredo Pons wrote:
> Hello,
> 
> The bmap-tool (version 3.2) reort this:
> 
> 
> root at atlantis:/home/apons/plastia# bmaptool create -o bmap intool
> -jessie-0.1.img 
> bmaptool: WARNING: all 7.2 GiB are mapped, no holes in 'intool-jessie
> -0.1.img'
> bmaptool: WARNING: was the image handled incorrectly and holes were
> expanded?
OK, so this is most probably not a bmaptool issue. I am not sure how
much docs are
you willing to read, but here
https://source.tizen.org/development/reference/bmaptool/introduction
you could find some explanations about how bmaptool works and why it
can be so fast.
Anyway, the point is that you image should be sparse, but  intool
-jessie-0.1.img is
apparently not a sparse file. Bmap tool cannot fix this situation, you
should improve
the tools that generate the image.
Usually it is as simple as just start with a sparse files. In shell a
7.2GiB file can be
created using something like
truncate -s 7730941132 intool-jessie-0.1.img
This file then would be one huge "hole". Then you would partition it
using something
like "parted", format file-systems, copy the initial contents. At the
end, the space
that was never written to would stay in the "hole" state, and bmaptool
would notice
this.
Not sure if you follow. If not, try to check the link above. Then
describe me how you
create your image and I can try helping you creating it sparse. Once it
is sparce,
not only it saves disk space, but there are opportunities to flash it
waay faster.
Or may be this is the point you are missing: bmap tool _does not_ work
on the file-system
level. It is FS-agnostic. It does not try looking inside your image.
Bmap tool really does not
care what is inside the image.
The point is that bmaptool looks for "holes", which represent the space
that is not needed.
And the point is that the image creation tools must carefully preserve
the holes.
HTH,
Artem

> Alfredo Pons
> Mòbil: 637367156
> Blog: http://gnodebian.blogspot.com.es/
> CV: http://es.linkedin.com/in/alfredopons
> 

> 2015-07-22 8:53 GMT+02:00 Artem Bityutskiy > <dedekind1 at gmail.com>> :
> > On Mon, 2015-07-20 at 13:35 +0200, Alfredo Pons wrote:
> > 
> > > It is planned to work with the f2fs filesystem?
> > 
> > > Currently it is not supported.
> > 

> > 
> > Do you want to use f2fs on the build host (the image is created on a
> > 
> > host which uses f2fs) or you want the image to contain f2fs, while the
> > 
> > build host uses something else like ext4?
> > 

> > 
> > Or please, elaborate some more what do you mean by not supported, what
> > 
> > are the symptoms?
> > 

> > 
> > From the build host side, bmap-tools relies on the FIEMAP or FIBMAP
> > 
> > ioctls. Does f2fs support them, if yes, then there should be no
> > 
> > problem. Otherwise, we'd need to see if f2fs offers any alternatives to
> > 
> > these ioctls.
> > 

> > 
> > Thanks!
> > 


> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/bmap-tools/attachments/20150728/9b100ed8/attachment.html>


More information about the Bmap-tools mailing list