On Thu, Jul 07, 2016 at 12:09:56PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 07, 2016 at 11:12:27AM -0400, Brian Foster wrote:
> > On Thu, Jun 16, 2016 at 06:20:39PM -0700, Darrick J. Wong wrote:
> > > For the rmap btree to work, we have to feed the extent owner
> > > information to the the allocation and freeing functions. This
> > > information is what will end up in the rmap btree that tracks
> > > allocated extents. While we technically don't need the owner
> > > information when freeing extents, passing it allows us to validate
> > > that the extent we are removing from the rmap btree actually
> > > belonged to the owner we expected it to belong to.
....
> > > +/*
> > > + * Special owner types.
> > > + *
> > > + * Seeing as we only support up to 8EB, we have the upper bit of the owner field
> > > + * to tell us we have a special owner value. We use these for static metadata
> > > + * allocated at mkfs/growfs time, as well as for freespace management metadata.
> > > + */
> > > +#define XFS_RMAP_OWN_NULL (-1ULL) /* No owner, for growfs */
> > > +#define XFS_RMAP_OWN_UNKNOWN (-2ULL) /* Unknown owner, for EFI recovery */
> > > +#define XFS_RMAP_OWN_FS (-3ULL) /* static fs metadata */
> > > +#define XFS_RMAP_OWN_LOG (-4ULL) /* static fs metadata */
> > > +#define XFS_RMAP_OWN_AG (-5ULL) /* AG freespace btree blocks */
> >
> > How about XFS_RMAP_OWN_AGFL? OWN_AG confuses me into thinking it's for
> > AG headers, but IIUC that is covered by OWN_FS.
AG headers are static metadata, laid down by mkfs. They are always
owned by the filesystem, hence the "OWN_FS" name.
> or _SPACEBT for AG {free,rmap} space btrees?
IIRC, the reason I simply named them as "Owned by the AG" is that
the space tracking btree blocks are always considered free space. THey can
move between the freespace tree and the AGFL without consuming free
space and it's not trivial to separate their classification to
anything other than "blocks used by the AG but are free space" e.g.
in he middle of a transaction that allocates and free
blocks the same block can move like this:
bnobt block -> AGFL -> cntbt block -> AGFL -> rmapbt block
Hence blocks on the AGFL are considered to be the same as
bno/cnt/rmapbt blocks for the purpose of owner identification.
Otherwise we'd have to modify the rmapbt every time we move a block
to/from the AGFL, and that then leads to recursion problems and lots
of unnecessary overhead...
Feel free to change the names, but I don't think we can change owner
classifications of the blocks they represent...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
