xfs
[Top] [All Lists]

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

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH v3 0/4] xfsprogs: v4 inode type in directory
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 18 Oct 2013 14:19:50 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52605FF8.2000301@xxxxxxx>
References: <20131017152804.204045257@xxxxxxx> <52605FF8.2000301@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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