From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wf-out-1314.google.com ([209.85.200.169]) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1JwTzO-0001Bp-Sr for linux-mtd@lists.infradead.org; Thu, 15 May 2008 03:18:43 +0000 Received: by wf-out-1314.google.com with SMTP id 28so192956wfc.24 for ; Wed, 14 May 2008 20:18:40 -0700 (PDT) Message-ID: Date: Thu, 15 May 2008 11:18:40 +0800 From: Nancy To: dedekind@infradead.org Subject: Re: ubifs image file confusion! In-Reply-To: <1210771200.5708.50.camel@sauron> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1210243730.3645.66.camel@sauron> <1210671861.5708.5.camel@sauron> <1210771200.5708.50.camel@sauron> Cc: linux-mtd List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 5/14/08, Artem Bityutskiy wrote: > If you want me to understand you and properly answer, you should try to > formulate things better. I understand language difficulties and this is > all right. I just ask you to try better, may be re-reading what you have > composed and trying imagine me reading your mail and imagine which part > could be not very clear for me. OK, I admit I was in a hurry and have tried to use my bad English to explain the issue, but failed. Then I think about to plase the "ubidumpvol" source code and tell you a way to reproduce the problem I met. Thank God we still have a common language C. 90% of "ubidumpvol" code are direct copy-plase from your tool "ubiupdatevol". It should be no problem for you to quickly grasp its idea. But you still push me hard to explain everything in English which makes me disappointed and a little angry. > > As I fool understand which I have plase after that mail: > Cannot parse this sentence, sorry. I mean I do not know the UBIFS implent detail. I just guess, maybe it designed that way. If you still can't parse, or still have questions about that, please just ignore the whole. I already run out of my brain to think about a suitable way to express. > > pls: > > 1. ubinize tool do not check whether vol_id or vol_name's > > uniqueness which may cause unexpected error. > > OK, will be fixed but a bit later. Thanks! > > 2. ubinize tool's volume size check do not aligned to LEB size. > Cannot parse this. > > > I can't use an image file which taken up of its all volume space. > > eg. LEB size =258048 , .cfg defined vol size = 100MiB , > > vfat.img(407LEBs) fail > > it say something like the image file size exceed the volume size. I'm > > home now, can't plase the original error message here. sorry. > Sorry, do not understand this. $ cat ubinize.cfg [ubifs] mode=ubi image=vfat.dump vol_id=0 vol_size=100MiB vol_type=dynamic vol_name=vfat vol_alignment=1 $ ./ubinize -o ubi.img ubinize.cfg -p 262144 -m 2048 ubinize: error!: error in section "vfat": size of the image file "vfat.dump" is 105025536, which is larger then the volume size 104857600 LEB size = 258048, volume 0 should contains 407 available lebs. The volume size should be 407*258048 = 105025535 not 104857600. The error message should not be triggered. pls: You seems miss one issue # ubiupdatevol /dev/ubi0_0 rootfs.img (generated by mkfs.ubifs) # mount -t ubifs ubi0:rootfs /mnt/1 # rm /mnt/1/* -rf # df The Use% of ubi0:rootfs is not 0%, but 2% which is unusual! -- Best wishes, Nancy