[Top] [All Lists]

Re: TAKE 981498 - remove mounpoint UUID code

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: TAKE 981498 - remove mounpoint UUID code
From: Timothy Shimmin <tes@xxxxxxx>
Date: Mon, 28 Jul 2008 11:56:51 +1000
Cc: Niv Sardi-Altivanik <xaiki@xxxxxxx>, sgi.bugs.xfs@xxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <4889EAC9.5070304@xxxxxxxxxxx>
References: <20080725033841.D689558C4C3F@xxxxxxxxxxxxxxxxxxxxxxx> <48894C66.5060204@xxxxxxxxxxx> <20080725050149.GL5947@disturbed> <4889EAC9.5070304@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20080421)
Eric Sandeen wrote:
> Dave Chinner wrote:
>> On Thu, Jul 24, 2008 at 10:45:42PM -0500, Eric Sandeen wrote:
>>> Niv Sardi-Altivanik wrote:
>>>> remove mounpoint UUID code
>>> Are you sure this didn't change any disk structures?  The patch I sent
>>> was RFC and completely untested...  (and disclosed as such...) :)
>> Looking at the original patch, it definitely does change the format
>> of log structures on disk. it removes the union of the uuid and rdev
>> in the xfs_inode_log_format[32|64] which takes that entry from 16
>> bytes down to 4 bytes. So I'd suggest that thisss should be removed
>> immediately before it hits public and people start corrupting their
>> filesystems....
> Yep.  Well crud, I even knew that when I sent it, hence the
> RFC/untested/blah/blah but I suppose I shouldn't send a patch that I
> know to be busted even if it's just as a whaddya-think.  I'll pad out
> the union, check all the log structs, run qa & resend.

Well, I wouldn't think it is a problem for xfs_dinode_t, 
after di_next_unlinked the data structure is basically documentation
and certainly di_a really starts at the attribute fork offset :)

As Dave said, it is a problem for xfs_inode_log_format and friends,
(ones which were changed for 32/64 bit variants).
This is not good but it is only a problem if you need to do log replay
with a new kernel on a dirty log created on the old kernel
(or vice-versa).
I don't think I want to change log replay to handle yet another variant
of inode item :) But it aint as bad as before as there is a cutoff point
and it only becomes a problem on unclean mount at that cutoff point.
Then again, if rc-1 is unstable and we crash out with a dirty log
and then try to replay using a more stable old kernel, it would have
trouble in log replay. (Just thinking aloud of possiblities :-)

> And despite all the talk about community & contributors running qa and
> helping with test coverage - as a general rule do sgi devels run qa too
> before committing?


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