On Wed, Jun 24, 2015 at 03:09:19PM -0400, Brian Foster wrote: > On Wed, Jun 03, 2015 at 04:04:45PM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > For the rmap btree to work, we have to fed 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. > > > > We also define a special set of owner values for internal metadata > > that would otherwise have no owner. This allows us to tell the > > difference between metadata owned by different per-ag btrees, as > > well as static fs metadata (e.g. AG headers) and internal journal > > blocks. > > > > There are also a couple of special cases we need to take care of - > > during EFI recovery, we don't actually know who the original owner > > was, so we need to pass a wildcard to indicate that we aren't > > checking the owner for validity. We also need special handling in > > growfs, as we "free" the space in the last AG when extending it, but > > because it's new space it has no actual owner... > > > > Any reason not to support passing the owner through the efi/efd log > structures? You've already plumbed it through the bmap_free struct. I > suppose that could make this a backwards incompatible feature rather > than read-only incompatible, though. That's an interesting idea that I didn't really consider. I'll have a think about it, along with a couple of other suggestions from Darrick (e.g. increasing the rmap record size and keeping owner-related location information (file offset) in it) as that will also impact on any changes to EFI/EFD structure. As for ro compat vs incompat, an EFI/EFD change would be a log incompat flag, so only be relevant if the log is dirty at mount time. Hence if the log was clean then the ro-compat flag would be used, and so a change of EFI/EFD format isn't a huge deal... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
