On Fri, Feb 02, 2018 at 05:36:40PM -0600, Eric Sandeen wrote: > > > On 2/2/18 4:35 PM, Dave Chinner wrote: > > On Fri, Feb 02, 2018 at 04:45:33PM -0500, Todd Gill wrote: > >> > >> Hi, > >> > >> I'd like to be able to take a snapshot of an XFS filesystem on top of > >> dm-thin. > >> > >> The goal for the snapshot is: > >> > >> - fast to complete (couple seconds or better) > >> - independent of origin (UUID updated?) > >> - read/write > >> > >> To satisfy the independent goal, I'm updating the UUID on the snapshot. > >> Currently "xfs_admin -U xxx" takes in the ballpark of 14 seconds on my > >> test system. > > > > There's a very good chance that this is caused by dm-thinp doing > > COW for the storage underlying the superblocks modified by the UUID > > change. > > It's actually because we rewrite the whole log, because it has the > user-facing superblock stamped in it. > > I looked at this a bit, and didn't immediately see an easy way around > xfs_db's need to rewrite the whole log. > > uuid_f() > /* clear the log (setting uuid) if it's not dirty */ > if (!sb_logzero(&uu)) > return 0; > > so I think that's taking the bulk of the time. I haven't looked closely > enough at all the mount-time log parsing to see if we could maybe write > less of it and still be valid. Ah, I forgot we added that. Originally the uuid in the log was only used to identify external log devices (or Irix based filesystems). > >> Or can the UUID update > >> be changed to be faster? > > > > Not sure - there's a fixed amount of modification we need to make > > to change the UUID so I'm not sure there is any optimisations we > > can make here. > > In retrospect I think we (I) should have left the "metadata" uuid as > the one to match the log, not the user-facing one. I suspect we can just change the log recovery code to accept either sb_uuid or sb_metauuid if the metauuid feature bit is set and change xfs_db to not rewrite the log when metauuid is used.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
