On 11/17/17 3:14 PM, Ross Zwisler wrote: > On Fri, Nov 17, 2017 at 03:03:39PM -0600, Eric Sandeen wrote: >> On 11/17/17 2:48 PM, Ross Zwisler wrote: >>> On Fri, Nov 17, 2017 at 02:39:07PM -0600, Eric Sandeen wrote: >>>> On 11/17/17 2:25 PM, Ross Zwisler wrote: >>>>> Add a new 'log_writes' command to xfs_io so that we can add dm-log-writes >>>>> log marks via the external 'dmsetup' executable. It's helpful to allow >>>>> users of xfs_io to adds these marks from within xfs_io instead of waiting >>>>> until after xfs_io exits because then they are able to replay the >>>>> dm-log-writes log up to immediately after another xfs_io operation such as >>>>> mwrite. This isolates the log replay from other operations that happen as >>>>> part of xfs_io exiting (file handles being closed, mmaps being torn down, >>>>> etc.). This also allows users to insert multiple marks between different >>>>> xfs_io commands. >>>>> >>>>> Signed-off-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> >>>>> Suggested-by: Dave Chinner <david@xxxxxxxxxxxxx> >>>> >>>> Without reviewing in detail, what is the advantage of wrapping dmsetup >>>> into xfs_io? My first inclination is that there is none at all, and >>>> xfstests can call dmsetup as easily as they can call xfs_io. No? >>>> >>>> -Eric >>> >>> I commented on this a bit in the changelog for the 2nd patch: >>> >>> It's helpful to allow users of xfs_io to adds these marks from within xfs_io >>> instead of waiting until after xfs_io exits because then they are able to >>> replay the dm-log-writes log up to immediately after another xfs_io operation >>> such as mwrite. This isolates the log replay from other operations that >>> happen as part of xfs_io exiting (file handles being closed, mmaps being torn >>> down, etc.). This also allows users to insert multiple marks between >>> different xfs_io commands. >>> >>> I agree that the shell-out to dmsetup isn't awesome... For the current test I >>> have written I think we can get away with just assuming that the xfs_io exit >>> stuff won't interact too heavily with the dm-log-writes log, and we could >>> potentially move the dmsetup call back into the fstest. This is how I >>> initially had it, and moved it into the C program via shell-out in response to >>> Amir's feedback: >> >> Sorry, terrible of me to not have read that. :( Ok, so next question - >> DM_TARGET_MSG seems to be public, can we just invoke the ioctl directly >> instead of shelling out to dmsetup? >> >> I'm checking w/ the dm folks too, to make sure that's expected to work. As >> long as the use isn't too tricky it seems like that might be better. > > Yea, that seems like a better option - I'll take a look. Thanks for the > suggestion. FWIW, agk is saying the only right way to do it is to use libdevicemapper ... sounds like they don't expect anyone to use the ioctl directly, though I'm not sure why, or what the complexity is. -Eric -- 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
