Re: [PATCH v2 02/14] btrfs-progs: check: introduce function to find dir_item

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 03, 2016 at 09:58:21AM +0800, Qu Wenruo wrote:
> 
> 
> At 11/02/2016 11:21 PM, David Sterba wrote:
> > On Wed, Sep 21, 2016 at 11:15:52AM +0800, Qu Wenruo wrote:
> >> From: Lu Fengqi <lufq.fnst@xxxxxxxxxxxxxx>
> >>
> >> Introduce a new function find_dir_item() to find DIR_ITEM for the given
> >> key, and check it with the specified INODE_REF/INODE_EXTREF match.
> >>
> >> Signed-off-by: Lu Fengqi <lufq.fnst@xxxxxxxxxxxxxx>
> >> Signed-off-by: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>
> >> ---
> >>  cmds-check.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 140 insertions(+)
> >>
> >> diff --git a/cmds-check.c b/cmds-check.c
> >> index 998ba63..4e25804 100644
> >> --- a/cmds-check.c
> >> +++ b/cmds-check.c
> >> @@ -3848,6 +3848,146 @@ out:
> >>  	return err;
> >>  }
> >>
> >> +#define ROOT_DIR_ERROR		(1<<1)	/* bad root_dir */
> >> +#define DIR_ITEM_MISSING	(1<<2)	/* DIR_ITEM not found */
> >> +#define DIR_ITEM_MISMATCH	(1<<3)	/* DIR_ITEM found but not match */
> >
> > What's the reason for another definition of the error codes? They're
> > mostly copied from te I_ERR_* counterparts. I'd rather have one set of
> > error codes.
> 
> The main reason is, in lowmem fsck mode, we are not checking inodes or 
> ref/backref in batch.
> 
> If using I_ERR and REF_ERR, we can mixing them up as they share the same 
> bits.
> 
> So we introduced the new error bitmap, to make sure all error bits won't 
> cover each other.
> 
> It may be better if we rearrange I_ERR/REF_ERR to avoid conflicts.
> E.g, let REF_ERR_ starts from lowest bit and let I_ERR_ starts from high 
> bits.

Yes please. Third namespace for existing error bits is not a good
option. Move the I_ERR bits to start from 32 and use them in the low-mem
code that's been merged to devel.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux