From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CA6C2220FB319 for ; Tue, 5 Dec 2017 20:33:42 -0800 (PST) Date: Tue, 5 Dec 2017 21:38:13 -0700 From: Ross Zwisler Subject: Re: [xfsprogs PATCH v2 3/3] xfs_io: add a new 'log_writes' command Message-ID: <20171206043813.GA31657@linux.intel.com> References: <20171205235651.17102-1-ross.zwisler@linux.intel.com> <20171205235651.17102-4-ross.zwisler@linux.intel.com> <20171206002946.GD5858@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20171206002946.GD5858@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dave Chinner Cc: Jan Kara , linux-nvdimm , fstests , linux-xfs List-ID: On Wed, Dec 06, 2017 at 11:29:46AM +1100, Dave Chinner wrote: > On Tue, Dec 05, 2017 at 04:56:51PM -0700, Ross Zwisler wrote: > > Add a new 'log_writes' command to xfs_io so that we can add dm-log-writes > > log marks. 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 > > Suggested-by: Dave Chinner > > having just looked at the xfs_io mess, this new command needs to set > "exitcode = 1" on failure. I haven't looked at anything else in the > patch. Ah, yea, I did think it was odd that when hitting errors in xfs_io it always still returned 0. I'll fix up for the next version. Is someone else working on making the rest of the error cases in xfs_io return 1 as well, or should I throw that at the front of the series? _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga07.intel.com ([134.134.136.100]:33568 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751894AbdLFEiO (ORCPT ); Tue, 5 Dec 2017 23:38:14 -0500 Date: Tue, 5 Dec 2017 21:38:13 -0700 From: Ross Zwisler Subject: Re: [xfsprogs PATCH v2 3/3] xfs_io: add a new 'log_writes' command Message-ID: <20171206043813.GA31657@linux.intel.com> References: <20171205235651.17102-1-ross.zwisler@linux.intel.com> <20171205235651.17102-4-ross.zwisler@linux.intel.com> <20171206002946.GD5858@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171206002946.GD5858@dastard> Sender: fstests-owner@vger.kernel.org To: Dave Chinner Cc: Ross Zwisler , linux-xfs , linux-nvdimm , fstests , Jan Kara , Dan Williams List-ID: On Wed, Dec 06, 2017 at 11:29:46AM +1100, Dave Chinner wrote: > On Tue, Dec 05, 2017 at 04:56:51PM -0700, Ross Zwisler wrote: > > Add a new 'log_writes' command to xfs_io so that we can add dm-log-writes > > log marks. 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 > > Suggested-by: Dave Chinner > > having just looked at the xfs_io mess, this new command needs to set > "exitcode = 1" on failure. I haven't looked at anything else in the > patch. Ah, yea, I did think it was odd that when hitting errors in xfs_io it always still returned 0. I'll fix up for the next version. Is someone else working on making the rest of the error cases in xfs_io return 1 as well, or should I throw that at the front of the series?