Re: [PATCH v3 0/4] xfsprogs: v4 inode type in directory

[Dave Chinner <david@fromorbit.com>]

On Fri, Oct 18, 2013 at 08:22:24AM -0500, Mark Tinguely wrote:
> On 10/17/13 22:19, Dave Chinner wrote:
> >On Thu, Oct 17, 2013 at 05:08:56PM -0500, Mark Tinguely wrote:
> >>On 10/17/13 10:28, Mark Tinguely wrote:
> >>>Here are the patches that enable the inode in the directory
> >>>feature in v4 superblocks.
> >>>
> >>>Unchanged
> >>>  patch 1: add the entries to xfs_sb.h (sync with kernel)
> >>>  patch 2: add the XFS_FSOP_GEOM_FLAGS_FTYPE to xfs_fs.h (sync with kernel)
> >>>	  add the entry to repair so that xfs_info reports the feature
> >>>New
> >>>  patch 3: add feature to the xfs_db version command.
> >>>
> >>>Fixed
> >>>  patch 4: add the feature to mkfs.xfs and manual page.
> >>>           note: this new feature is ignored for superblock v5
> >>>		automatically turns on this feature.
> >>
> >>FYI.
> >>
> >>I saw the request for adding the filetype entry to block/leaf after posting.
> >>
> >>I have it displaying unconditionally, but am trying to figure out
> >>how to make it display only for filesytems that support the ftype
> >>feature. I am missing something in the field.count().
> >
> >The count function only tells the code whether a structure is
> >present or not, but it does not tell you what the format of the
> >structure is.
> >
> >if you look at db/dir2.c, you'll see that the difference between the
> >dir2_flds[] and the dir3_flds[] is mainly in the type, count and offset
> >fields. For example:
> >
> >const field_t   dir2_flds[] = {
> >         { "bhdr", FLDT_DIR2_DATA_HDR, OI(BOFF(magic)), dir2_block_hdr_count,
> >           FLD_COUNT, TYP_NONE }
> >...
> >
> >const field_t   dir3_flds[] = {
> >         { "bhdr", FLDT_DIR3_DATA_HDR, OI(B3OFF(hdr)), dir3_block_hdr_count,
> >           FLD_COUNT, TYP_NONE },
> >...
> >
> >if you look at dir[23]_block_hdr_count(), you'll see that they
> >return a boolean value based on a magic number check. Hence when the
> >code is trying to determine the type of the block that has been read
> >(i.e. what the field definition is), if the magic number matches we
> >know exactly what type of contents they contain.
> >
> >For decoding the dtype, you need too look at how to select the
> >correct structure for the FLDT_DIR2_DATA_UNION. If you don't have
> >the feature set, you need to select the FLDT_DIR2_DATA_UNION
> >structure type, and if it is set you need to select the
> >FLDT_DIR3_DATA_UNION type. Hence you need both these types defined
> >in the dir2_flds[] array, and some manner to ensure the correct
> >values are returned from the count functions.
> >
> >And just to make it hard, both the dir2 and dir3 data union count
> >functions use the same function (dir2_data_u_count) so you're going
> >to have to be careful that you don't break the v5 superblock
> >directory decoding....
> >
> >Cheers,
> >
> >Dave.
> 
> 
> Thanks Dave. I did some RTFS and found I was having problems with
> the field_t.flag.
> 
> Can't we add a filetype to the dir2 dir2_data_union_flds entry and
> use the count to turn it on/off? The problem I was having with this
> was the flag. Something like:
> 
> Add the directory field type information to xfs_db directory
> displays.

Can you send this as a proper patch with SOB, etc?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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