Interesting, thanks for the feedback on this.  

I just changed the way I do this to sectors and it worked without modification.  I know it was one of the things I tried
, not sure why it didn't work.

So, I guess I concur, we don't need the num_blocks functionality :)

Thanks Thomas,
Kevin

On Oct 1, 2014, at 12:39 AM, Thomas Haupt <community-noreply@qnx.com> wrote:

> Mea culpa, I think.
> 
> You wrote:
>> 1.  The file size wasn't matching the C*H*S*sector_size, even though I 
>> was using the right parameters in the blksize and num_blocks attributes.
>> An additional 15872 bytes were being added to the resulting image.  I 
>> modified the attributes so that the block size was reduced that amount 
>> and ti worked (reduced it by 32 blocks of blksize=512).
> 
> When I originally implemented mkqnx6fsimg, I didn't realize that an explicit "num_blocks" attribute would, at best, be
 mostly useless and usually and up badly confusing or even irritating the user - which is definitely nothing a good tool
 should do. The problem with num_blocks is that, as you have indirectly noticed, the net size of a QNX6 file system is 
greater than just the combined sum of its (data) blocks. It also contains some metadata (a "boot" and two "super" 
blocks) that will alone take up ~16k . Upon realizing how intricate it actually was to create an image of defined size 
using this attribute, I first tried to account for this by better documenting the relation between block- and sector 
count, but by now I've come to believe it'll probably be best to completely remove the "num_blocks" attribute to avoid 
any further confusion.
> 
> Instead, one should _always_ use the "num_sectors" attribute to define the file-system size. The relation between 
sector count and actually usable data space in the file system isn't much worse than for the block count, but 
num_sectors at allows you to tell exactly how many sectors the resulting image will take up. The tool will automatically
 account and adjust for "odd" sector counts, so you don't have to worry about sector counts that aren't exact multiples 
of the block size. Instead, just look at your target media's/partition's sector count and put that into the build file.
> 
> Best regards, and my sincere apologies for wasting your time with this useless feature:
> Thomas
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post111939
> To cancel your subscription to this discussion, please e-mail general-toolchain-unsubscribe@community.qnx.com