Re: [PATCH 0/3] fix-up free space earlier in mount_ubifs()

[Ben Gardiner <bengardiner@nanometrics.ca>]

Hi Matthew,

On Tue, May 31, 2011 at 10:43 AM, Matthew L. Creech <mlcreech@gmail.com> wrote:
> On Mon, May 30, 2011 at 2:56 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
>> In testing Mattew Creech's free-space-fixup flag series I found that was unable
>> to boot a da850evm which had flashed to it's NAND a ubinized image containing a
>> UBIFS that has the free-space-fixup flag set.
>>
>> The cause of the problem was found to be the call to ubifs_write_master() from
>> mount_ubifs() as is evidenced the backtrace produced by the assertion
>> introduced in the first patch of this series; where the assertion introduced is
>> that c->space_fixup is false when ubifs_write_node() is called.
>>
>
> Interesting - so the problem is that if ubifs_read_master() resizes
> the master node, a subsequent attempt to read the first (c->mst_offs +
> c->mst_node_alsz) bytes from the master LEB fails?
>
> I wonder why this is the case when free-space fixup is enabled, and
> not otherwise?  The -EBADMSG seems to imply that this is the original
> problem that the fix-up is intended to solve - i.e. the master node
> has empty pages with non-empty OOB values, and writing to them results
> in a bogus ECC.

Right. I should have mentioned that it is also true that without
free-space-fixup the initial flash of a UBInized image containing a
UBIFS volume results in a bootable system which can mount the rootfs
_the first time only_ subsequent attemps at mounting result in a
failure to mount due to -74 errors.

> Just trying to fully understand the error.  :)  That aside, this patch
> set makes sense to me.  Thanks!

Thank you for your endorsement. Can we take that as a Reviewed-by ?

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca