xfs
[Top] [All Lists]

Re: endian conversion work

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: endian conversion work
From: Steve Lord <lord@xxxxxxx>
Date: Tue, 23 May 2000 08:51:58 -0500
Cc: Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx> of "Tue, 23 May 2000 09:48:26 +1000." <200005222348.JAA37777@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
> 
> Steve Lord writes:
>  => 
>  => Daniel,
> 
>  => We could just use xfs_xlate_dinode_core() on the inode core to convert it
,
>  => we then need to look at all the other fields in the inode which can get 
> ...
> 
> Happily, the dinode_core is the only part of the dinode that is stored
> in in-core format at any time. So currently, the inode log records
> consist of an in-core inode core and the on-disk version of the rest of
> the inode. The dinode_core is easy to move between in-core and on-disk
> forms but the rest would be nasty.
> 
> For now, I've fixed the recovery to convert the core to on-disk before
> writing it out. This is an efficient way of doing things, but if we
> ever want to be able to move dirty disks between architecture, we'll
> have to make sure the whole log is in on-disk format.
> 


I think your pointer arithmetic is broken:

        bcopy(item->ri_buf[1].i_addr + sizeof(xfs_dinode_core_t),
              dip                    + sizeof(xfs_dinode_core_t),
              item->ri_buf[1].i_len  - sizeof(xfs_dinode_core_t));

dip is a xfs_dinode_t pointer, just adding to it like this will walk a
long way down memory, however, since the size of the field is always
sizeof(xfs_dinode_core_t) this does not matter.

from xfs_inode_item_format():

        vecp->i_addr = (caddr_t)&ip->i_d;
        vecp->i_len  = sizeof(xfs_dinode_core_t);
        vecp++;


So I think we can lose the bcopy. Also what about the line:

        dip->di_u.di_dev = in_f->ilf_u.ilfu_rdev;

I think this needs to be:

        INT_SET(dip->di_u.di_dev, ARCH_CONVERT, in_f->ilf_u.ilfu_rdev);

I was running with similar code - I will fix this up and check in - there
was also a panic in the cleanup from failed mount path which was coming out.

Steve



<Prev in Thread] Current Thread [Next in Thread>