[DRBD-user] DRBD - on ARM (armel)

[Nick]

Lars Ellenberg wrote:
> On Fri, Jun 12, 2009 at 02:37:21PM +0100, Nick wrote:
>   
>> Thank-you very much for looking into this. I was preparing myself for a 
>> weekend, of delving into this stuff, which at first glance looked like 
>> it wasn't going to be too much fun ;-)
>>
>> I see you have removed the (short*) cast.... I am not sure if it is 
>> necessary, but I though it might be helpful on big-endian platforms, 
>> where hopefully the compiler would take the pointer to the 
>> least-significant  word???
>>     
>
> -static void add_tag(struct drbd_tag_list *tl, int tag, void *data, int data_len)                                                   
> +static void add_tag(struct drbd_tag_list *tl, short int tag, void *data, short int data_len)   
>
> they are now short.
> they should have been, anyways.
>   

Agreed. That is much cleaner.
>   
>> I will apply your fixes, and have a play over the weekend.
>>
>> With my fixes, the current issue I have is:
>>
>> Everything, claims to work, except data-changes are not propagated to 
>> the other peer....
>>     
>
> how to you check whether or not changes "propagate" ?
>   

Well I am in dual-primary mode.

I mounted the drbd device at both ends....

I touch a file at one end and would expect to see the file at the 
other......

My filesystem is just ext3 so I think I am right in assuming that this 
is actually an INCORRECT assumption, as far as the filesystem is 
concerned, so I tried combinations of unmounting (and remounting on the 
remote peer), and even restarting drbd.


Previously this was not working, however with your latest patch (I 
couldn't wait to test it ;-)))...this is working to some degree...

I now just have to unmount the ext3 filesystem, and remount it (-o 
remount has no effect) and I see changes propagated.

I hope moving from ext3 to OCFS2 will sort out this issue ?? Yes??

I will continue my testing over the weekend, and run the tests you asked.

Thanks

Nick


>   
>> in my setup however the peer is an i386, so I was 
>> concerned there may be issues there. However if I 'invalidate' one end, 
>> all changes are propagated, so perhaps your changes will address this.. 
>> I do hope so.
>>     
>
>