On Mon, Sep 19, 2016 at 09:16:52PM -0700, Darrick J. Wong wrote:
> On Tue, Sep 13, 2016 at 06:28:42PM +1000, Dave Chinner wrote:
> > - __uint32_t xs_rmap_2_decrement;
> > - __uint32_t xs_rmap_2_lshift;
> > - __uint32_t xs_rmap_2_rshift;
> > - __uint32_t xs_rmap_2_split;
> > - __uint32_t xs_rmap_2_join;
> > - __uint32_t xs_rmap_2_alloc;
> > - __uint32_t xs_rmap_2_free;
> > - __uint32_t xs_rmap_2_moves;
> > +#define XFSSTAT_END_ABTB_V2 (XFSSTAT_END_BUF+__XBTS_MAX)
> > + __uint32_t xs_abtb_2[__XBTS_MAX];
> > +#define XFSSTAT_END_ABTC_V2 (XFSSTAT_END_ABTB_V2+__XBTS_MAX)
> > + __uint32_t xs_abtc_2[__XBTS_MAX];
> > +#define XFSSTAT_END_BMBT_V2 (XFSSTAT_END_ABTC_V2+__XBTS_MAX)
> > + __uint32_t xs_bmbt_2[__XBTS_MAX];
> > +#define XFSSTAT_END_IBT_V2 (XFSSTAT_END_BMBT_V2+__XBTS_MAX)
> > + __uint32_t xs_ibt_2[__XBTS_MAX];
> > +#define XFSSTAT_END_FIBT_V2 (XFSSTAT_END_IBT_V2+__XBTS_MAX)
> > + __uint32_t xs_fibt_2[__XBTS_MAX];
> > +#define XFSSTAT_END_RMAP_V2 (XFSSTAT_END_FIBT_V2+__XBTS_MAX)
> > + __uint32_t xs_rmap_2[__XBTS_MAX];
>
> Are you planning to merge this before or after the refcount btree?
Doesn't matter - either way I'll fix up one of them on merge into
the for-next tree...
>
> > #define XFSSTAT_END_XQMSTAT (XFSSTAT_END_RMAP_V2+6)
> > __uint32_t xs_qm_dqreclaims;
> > __uint32_t xs_qm_dqreclaim_misses;
> > @@ -229,26 +165,58 @@ struct xfsstats {
> > __uint64_t xs_read_bytes;
> > };
> >
> > +struct xfsstats {
> > + union {
> > + struct __xfsstats s;
> > + uint32_t a[XFSSTAT_END_XQMSTAT];
> > + };
>
> /me wonders if there ought to be a build time check to make sure that
> these two are really the same size? They look all right as is, but
> I can see myself forgetting to change something and screwing it up. :(
It isn't the same size, because struct __xfsstats has three u64
stats at the end that aren't part of the u32 array indexed by
XFSSTAT_END_XQMSTAT. If we get the calculation of
XFSSTAT_END_XQMSTAT wrong , then the output of the stats in the proc
and sysfs files is screwed up because it treats the stats as an
array of u32 items of that same size. So it's fairly obvious when
it gets broken...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
