public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ben Myers <bpm@sgi.com>, Eric Sandeen <sandeen@sandeen.net>,
	xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 1/2 V2] xfs_logprint: Handle multiply-logged inode fields
Date: Mon, 28 Jan 2013 14:47:42 -0600	[thread overview]
Message-ID: <5106E3EE.2030601@redhat.com> (raw)
In-Reply-To: <20130122210511.GK2498@dastard>

On 1/22/13 3:05 PM, Dave Chinner wrote:
> On Tue, Jan 22, 2013 at 11:55:30AM -0600, Ben Myers wrote:
>> Hey Eric,
>>
>> On Thu, Nov 01, 2012 at 11:33:46AM -0500, Eric Sandeen wrote:
>>> As xlog_print_trans_inode() stands today, it will error
>>> out if more than one flag is set on f->ilf_fields:
>>>
>>> 	xlog_print_trans_inode: illegal inode type
>>>
>>> but this is a perfectly valid case, to have i.e. a data and
>>> an attr flag set.
>>>
>>> Following is a pretty big reworking of the function to
>>> handle more than one field type set.
>>
>> I'm trying to wrap my head around this one.  I have a few stupid questions.
>>
>>> I've tested this by a simple test such as creating one
>>> file on an selinux box, so that data+attr is set, and
>>> logprinting; I've also tested by running logprint after
>>> subsequent xfstest runs (although we hit other bugs that
>>> way).
>>>
>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>> ---
>>>
>>> V2: Fix subject, sigh.
>>>
>>> diff --git a/logprint/log_misc.c b/logprint/log_misc.c
>>> index e42e108..be2426e 100644
>>> --- a/logprint/log_misc.c
>>> +++ b/logprint/log_misc.c
>>> @@ -657,97 +657,84 @@ xlog_print_trans_inode(xfs_caddr_t *ptr, int len, int *i, int num_ops)
>>>  
>>>      /* does anything come next */
>>>      op_head = (xlog_op_header_t *)*ptr;
>>> -    switch (f->ilf_fields & XFS_ILOG_NONCORE) {
>>> -	case XFS_ILOG_DEXT: {
>>> -	    ASSERT(f->ilf_size == 3);
>>> -	    (*i)++;
>>> -	    xlog_print_op_header(op_head, *i, ptr);
>>> -	    printf(_("EXTENTS inode data\n"));
>>> -	    *ptr += be32_to_cpu(op_head->oh_len);
>>> -	    if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS))  {
>>> -		return 1;
>>> -	    }
>>> -	    break;
>>> -	}
>>> -	case XFS_ILOG_DBROOT: {
>>> -	    ASSERT(f->ilf_size == 3);
>>> -	    (*i)++;
>>> -	    xlog_print_op_header(op_head, *i, ptr);
>>> -	    printf(_("BTREE inode data\n"));
>>> -	    *ptr += be32_to_cpu(op_head->oh_len);
>>> -	    if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS))  {
>>> -		return 1;
>>> -	    }
>>> +
>>> +    if (f->ilf_fields & (XFS_ILOG_DEV | XFS_ILOG_UUID)) {
>>> +	switch (f->ilf_fields & (XFS_ILOG_DEV | XFS_ILOG_UUID)) {
>>
>> Here you kept only XFS_ILOG_DEV and XFS_ILOG_UUID...
>>
>>> +	case XFS_ILOG_DEV:
>>> +	    printf(_("DEV inode: no extra region\n"));
>>>  	    break;
>>> -	}
>>> -	case XFS_ILOG_DDATA: {
>>> -	    ASSERT(f->ilf_size == 3);
>>> -	    (*i)++;
>>> -	    xlog_print_op_header(op_head, *i, ptr);
>>> -	    printf(_("LOCAL inode data\n"));
>>> -	    if (mode == S_IFDIR) {
>>> -		xlog_print_dir_sf((xfs_dir_shortform_t*)*ptr, size);
>>> -	    }
>>> -	    *ptr += be32_to_cpu(op_head->oh_len);
>>> -	    if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS)) {
>>> -		return 1;
>>> -	    }
>>> +	case XFS_ILOG_UUID:
>>> +	    printf(_("UUID inode: no extra region\n"));
>>>  	    break;
>>> +	case XFS_ILOG_DEXT:
>>> +	case XFS_ILOG_DBROOT:
>>> +	case XFS_ILOG_DDATA:
>>
>> Do you need to test for these other flags here?
> 
> It's defensive code - ensuring that they never overlap as the fields
> are mutually exclusive. i.e if XFS_ILOG_DEV or XFS_ILOG_UUID is
> set, the data fork format flags should not be set as the other two
> fields indicate the data fork contents....
> 
>>> +	default:
>>> +	    xlog_panic(_("xlog_print_trans_inode: illegal inode type 0x%x"),
>>> +			f->ilf_fields);
>>>  	}
>>> -	case XFS_ILOG_AEXT: {
>>> -	    ASSERT(f->ilf_size == 3);
>>> +    }
>>> +
>>> +    if (f->ilf_fields & (XFS_ILOG_DFORK | XFS_ILOG_AFORK)) {
>>> +	ASSERT(f->ilf_size <= 4);
>>
>> Can you explain this ASSERT?  I saw only ilf_size == 3 in the old code.  Under
>> what circumstances can it be 4?  Maybe when multiple ilf_fields are set?
> 
> XFS_ILOG_CORE | XFS_ILOG_TIMESTAMP | XFS_ILOG_DFORK | XFS_ILOG_AFORK
> 
>>> +	ASSERT((f->ilf_size == 3) || (f->ilf_fields & XFS_ILOG_AFORK));
>>
>> I also don't understand this ASSERT.  It seems like in the old code all of the
>> AFORK related cases had an ASSERT for ilf_size == 3.
> 
> It's valid - if the size is not 3, the the attribute for must be
> logged - it's the only way to get 4 format items.
> 
>>
>>> +	if (f->ilf_fields & XFS_ILOG_DFORK) {
>>>  	    (*i)++;
>>>  	    xlog_print_op_header(op_head, *i, ptr);
>>> -	    printf(_("EXTENTS inode attr\n"));
>>> -	    *ptr += be32_to_cpu(op_head->oh_len);
>>> -	    if (XLOG_SET(op_head->oh_flags, XLOG_CONTINUE_TRANS))  {
>>> -		return 1;
>>> +
>>> +	    switch (f->ilf_fields & XFS_ILOG_DFORK) {
>>> +	    case XFS_ILOG_DEXT:
>>> +		printf(_("EXTENTS inode data\n"));
>>> +		break;
>>> +	    case XFS_ILOG_DBROOT:
>>> +		printf(_("BTREE inode data\n"));
>>> +		break;
>>> +	    case XFS_ILOG_DDATA:
>>> +		printf(_("LOCAL inode data\n"));
>>> +		if (mode == S_IFDIR)
>>> +		    xlog_print_dir_sf((xfs_dir_shortform_t*)*ptr, size);
>>> +		break;
>>> +	    case XFS_ILOG_DEV:
>>> +	    case XFS_ILOG_UUID:
>>
>> ILOG_DEV and ILOG_UUID aren't in ILOG_DFORK.  You needn't test for them, correct?
> 
> See above.
> 
> Cheers,
> 
> Dave.
> 

Ben, Mark -

Where are we at with this one?  We have a partner who is interested in the fix.
Do you want anything more from me before it can be merged?

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-01-28 20:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-01 16:22 [PATCH 0/2] xfsdump: 2 fixes Eric Sandeen
2012-11-01 16:26 ` [PATCH 1/2] xfsdump: Handle multiply-logged inode fields Eric Sandeen
2012-11-01 16:33   ` [PATCH 1/2 V2] xfs_logprint: " Eric Sandeen
2012-11-02 13:01     ` Christoph Hellwig
2012-11-02 14:39       ` Eric Sandeen
     [not found]     ` <20130122175530.GR27055@sgi.com>
     [not found]       ` <20130122210511.GK2498@dastard>
2013-01-28 20:47         ` Eric Sandeen [this message]
2013-01-28 21:31           ` Ben Myers
2012-11-01 16:32 ` [PATCH 2/2] xfs_logprint: Handle continued inode transactions Eric Sandeen
2012-11-02 13:04   ` Christoph Hellwig
2012-11-02 14:35     ` Eric Sandeen
2012-11-01 16:33 ` [PATCH 0/2] xfs_logprint: 2 fixes Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5106E3EE.2030601@redhat.com \
    --to=sandeen@redhat.com \
    --cc=bpm@sgi.com \
    --cc=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox