[Ocfs2-tools-devel] Re: [Ocfs2-devel] [patch 1/1] offline de-fragmentation tool

[tao.ma]

wengang wang wrote:
> 
> 
> tao.ma wrote:
>>
>>
>> wengang wang wrote:
>>>
>>>
>>> tao.ma wrote:
>>>>
>>>>
>>>> wengang wang wrote:
>>>>> added/revised some lines.
>>>>> and what's important, I don't know how to write ordering -- make 
>>>>> use of jbd?
>>>> No, you just need to be very careful of your writing order so that 
>>>> any corruption after any operation will be either harmless or can be 
>>>> recovered by fsck.ocfs2. So this may means that you need to revise 
>>>> fsck.ocfs2 also to fix the corruption your tool do to the volume.
>>>> Good luck and enjoy it. ;)
>>> while, for example, power down when committing a group to disk, and 
>>> the bitmap was written to disk partially.
>>> for fsck.ocfs2, how to determine whether the bitmap is good?
>> Do you mean you change the group's bitmap and want to commit?
>> A group descriptor including its bitmap is contained in a block, not a 
>> cluster. so it is the block driver that guarantee this block is 
>> written as a whole not us.
>>
> I meant the above.
> block driver can not guarantee this.
> block concept in ocfs2 is not the same as it in block device.
> a block in ocfs2 can include 1,2,4... blocks of a block device.
> while, block device hardware can only guarantee one block (normally 512 
> bytes) to be written with consistency, not several blocks.
I know block device, but I think you go to the wrong direction. This 
isn't what we should handle as a user space tool. We only use "write" 
system call and don't go into it. Otherwise we may have to go directly 
to the block driver to avoid this issue. That way, this tool may become 
very very complicated. And to be frank, I am not sure whether there is a 
100% perfect solution for this problem.