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

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

 



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.

ISTR trying something like that previously when doing the dir3
changeover - I couldn't get it to work properly because parts of the
structure could not be easily discriminated and so both the v2 and
v3 count functions would return true because they were looking at
different locations in the structure due to the header size
differences.

In this case, because the structure itself doesn't have any child
dependencies and the format will always be considered a v2 directory
structure, I think what you propose should work. Did you test it
to see if it works?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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




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

  Powered by Linux