On Mon, Jun 12, 2017 at 08:42:10AM -0400, Jeff Layton wrote: > The writeback error handling test requires that you put the journal on a > separate device. This allows us to use dmerror to simulate data > writeback failure, without affecting the journal. > > xfs already has infrastructure for this (a'la $SCRATCH_LOGDEV), so wire > up the ext4 code so that it can do the same thing when _scratch_mkfs is > called. > > Signed-off-by: Jeff Layton <jlay...@redhat.com> > Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com> > --- > common/rc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/common/rc b/common/rc > index 87e6ff08b18d..08807ac7c22a 100644 > --- a/common/rc > +++ b/common/rc > @@ -676,6 +676,9 @@ _scratch_mkfs_ext4() > local tmp=`mktemp` > local mkfs_status > > + [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \ > + $mkfs_cmd -O journal_dev $SCRATCH_LOGDEV && \ > + mkfs_cmd="$mkfs_cmd $MKFS_OPTIONS -J device=$SCRATCH_LOGDEV"
This $MKFS_OPTIONS should be added to the first command when creating the journal device so that journal dev has the same block size as data dev, there's no need to update mkfs_cmd string. The external log dev support for ext3 patch has similar issue. Thanks, Eryu > > _scratch_do_mkfs "$mkfs_cmd" "$mkfs_filter" $* 2>$tmp.mkfserr > 1>$tmp.mkfsstd > mkfs_status=$? > -- > 2.13.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
