[Ocfs2-tools-devel] [PATCH 4/4] Ocfs2-tools: Fix bug in libocfs2's swap code to let fswreck behave correctly in big endian machine.

tristan.ye tristan.ye at oracle.com
Wed Jun 24 19:40:28 PDT 2009


On Thu, 2009-06-25 at 09:58 +0800, Tao Ma wrote:
> Hi Tristan,
> 
> Tristan Ye wrote:
> > Currently, ocfs2_write_inode() and ocfs2_read_inode() in libocfs2 will swap
> > all its field to make it big-endian compatible when writting to disk or reading
> > from disk. It will be fine when we write/read the inode/extent in a normal case,
> > which means the field of inode we're going to write/read is correct. However, in
> > the fswreck's case, we corrupted some fields(such as cl_next_free_rec, tl_count etc)
> > which will be used later as a count number to swap rec[i]'s field in a loop. that will
> > definitely leads to an error in a big-endian platform where swap code being introduced.
> > 
> > The strategy we use here is to correct the count number in libocfs2 swap code just like
> > fsck.ocfs2 did. Note that we only correct the count number but leave the field which
> > corrupted by fswreck unchanged there.
> I don't think it is a good way. libocfs2 is used for a sane program 
> while fswreck is used to corrupt the file system. So I don't think we 
> should add some extra check in libocfs2 for the only user(fswreck). 
> fswreck should handle this by itself.

I also have tried to solve the problem in fswreck's code by leaving
libocfs2's swap code unchanged, but no luck to find a reasonable way...

For example, we corrupted the cl_count filed of an chain allocator
inode's chain list, then write the inode block back to disk by
ocfs2_write_inode() where swap code being introduced if we're in a
big-endian platform, the swap code will try to swap array cl_recs[i] one
by one by cl_count times, here we used a corrupted cl_count as count
number in the loop, and we in fact need a corrected one...

In such a situation, I really found it's difficult to solve the problem
without changing the libocfs2's swap code a bit..

There may be 2 ways to deal with the problem.

1. add extra checking code in libocfs2's swap code.

2. implement a similar ocfs2_write_inode function in fswreck's code to
make it fswreck unique.

method 1 may reduce the performance a bit in none-fswreck's case,
method2 makes the code look redundant.

Joel, 

Any idea?


Tristan.

 

> 
> Joel,
> 	What's your option?
> 
> Regards,
> Tao
> 




More information about the Ocfs2-tools-devel mailing list