From patchwork Mon Nov 30 10:17:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chandan Rajendra X-Patchwork-Id: 7722921 Return-Path: X-Original-To: patchwork-fstests@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id CDF2E9F39B for ; Mon, 30 Nov 2015 10:17:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B704C2054D for ; Mon, 30 Nov 2015 10:17:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6BC4520553 for ; Mon, 30 Nov 2015 10:17:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752473AbbK3KRl (ORCPT ); Mon, 30 Nov 2015 05:17:41 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:42440 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159AbbK3KRg (ORCPT ); Mon, 30 Nov 2015 05:17:36 -0500 Received: from localhost by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Nov 2015 15:47:34 +0530 Received: from d28dlp01.in.ibm.com (9.184.220.126) by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 30 Nov 2015 15:47:32 +0530 X-IBM-Helo: d28dlp01.in.ibm.com X-IBM-MailFrom: chandan@linux.vnet.ibm.com X-IBM-RcptTo: fstests@vger.kernel.org;linux-btrfs@vger.kernel.org Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 463C3E0058; Mon, 30 Nov 2015 15:48:11 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAUAHU311179920; Mon, 30 Nov 2015 15:47:30 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAUAHULG016518; Mon, 30 Nov 2015 15:47:30 +0530 Received: from localhost.in.ibm.com ([9.124.158.154]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tAUAHPBN016187; Mon, 30 Nov 2015 15:47:29 +0530 From: Chandan Rajendra To: fstests@vger.kernel.org Cc: Chandan Rajendra , linux-btrfs@vger.kernel.org, fdmanana@gmail.com, chandan@mykolab.com Subject: [PATCH 6/8] Fix btrfs/098 to work on non-4k block sized filesystems Date: Mon, 30 Nov 2015 15:47:22 +0530 Message-Id: <1448878644-16503-7-git-send-email-chandan@linux.vnet.ibm.com> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1448878644-16503-1-git-send-email-chandan@linux.vnet.ibm.com> References: <1448878644-16503-1-git-send-email-chandan@linux.vnet.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15113010-0009-0000-0000-0000092C8B89 Sender: fstests-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This commit makes use of the new _filter_xfs_io_blocks_modified filtering function to print information in terms of file blocks rather than file offset. Signed-off-by: Chandan Rajendra Reviewed-by: Filipe Manana --- tests/btrfs/098 | 67 +++++++++++++++++++++++++++++------------------------ tests/btrfs/098.out | 27 ++++++++++++++++----- 2 files changed, 58 insertions(+), 36 deletions(-) diff --git a/tests/btrfs/098 b/tests/btrfs/098 index 8aef119..49f6d16 100755 --- a/tests/btrfs/098 +++ b/tests/btrfs/098 @@ -58,43 +58,50 @@ _scratch_mkfs >>$seqres.full 2>&1 _init_flakey _mount_flakey -# Create our test file with a single 100K extent starting at file offset 800K. -# We fsync the file here to make the fsync log tree gets a single csum item that -# covers the whole 100K extent, which causes the second fsync, done after the -# cloning operation below, to not leave in the log tree two csum items covering -# two sub-ranges ([0, 20K[ and [20K, 100K[)) of our extent. -$XFS_IO_PROG -f -c "pwrite -S 0xaa 800K 100K" \ +BLOCK_SIZE=$(get_block_size $SCRATCH_MNT) + +# Create our test file with a single 25 block extent starting at file offset +# mapped by 200th block We fsync the file here to make the fsync log tree get a +# single csum item that covers the whole 25 block extent, which causes the +# second fsync, done after the cloning operation below, to not leave in the log +# tree two csum items covering two block sub-ranges ([0, 5[ and [5, 25[)) of our +# extent. +$XFS_IO_PROG -f -c "pwrite -S 0xaa $((200 * $BLOCK_SIZE)) $((25 * $BLOCK_SIZE))" \ -c "fsync" \ - $SCRATCH_MNT/foo | _filter_xfs_io + $SCRATCH_MNT/foo | _filter_xfs_io_blocks_modified + -# Now clone part of our extent into file offset 400K. This adds a file extent -# item to our inode's metadata that points to the 100K extent we created before, -# using a data offset of 20K and a data length of 20K, so that it refers to -# the sub-range [20K, 40K[ of our original extent. -$CLONER_PROG -s $((800 * 1024 + 20 * 1024)) -d $((400 * 1024)) \ - -l $((20 * 1024)) $SCRATCH_MNT/foo $SCRATCH_MNT/foo +# Now clone part of our extent into file offset mapped by 100th block. This adds +# a file extent item to our inode's metadata that points to the 25 block extent +# we created before, using a data offset of 5 blocks and a data length of 5 +# blocks, so that it refers to the block sub-range [5, 10[ of our original +# extent. +$CLONER_PROG -s $(((200 * $BLOCK_SIZE) + (5 * $BLOCK_SIZE))) \ + -d $((100 * $BLOCK_SIZE)) -l $((5 * $BLOCK_SIZE)) \ + $SCRATCH_MNT/foo $SCRATCH_MNT/foo # Now fsync our file to make sure the extent cloning is durably persisted. This # fsync will not add a second csum item to the log tree containing the checksums -# for the blocks in the sub-range [20K, 40K[ of our extent, because there was +# for the blocks in the block sub-range [5, 10[ of our extent, because there was # already a csum item in the log tree covering the whole extent, added by the # first fsync we did before. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo -echo "File digest before power failure:" -md5sum $SCRATCH_MNT/foo | _filter_scratch +echo "File contents before power failure:" +od -t x1 $SCRATCH_MNT/foo | _filter_od # The fsync log replay first processes the file extent item corresponding to the -# file offset 400K (the one which refers to the [20K, 40K[ sub-range of our 100K -# extent) and then processes the file extent item for file offset 800K. It used -# to happen that when processing the later, it erroneously left in the csum tree -# 2 csum items that overlapped each other, 1 for the sub-range [20K, 40K[ and 1 -# for the whole range of our extent. This introduced a problem where subsequent -# lookups for the checksums of blocks within the range [40K, 100K[ of our extent -# would not find anything because lookups in the csum tree ended up looking only -# at the smaller csum item, the one covering the subrange [20K, 40K[. This made -# read requests assume an expected checksum with a value of 0 for those blocks, -# which caused checksum verification failure when the read operations finished. +# file offset mapped by 100th block (the one which refers to the [5, 10[ block +# sub-range of our 25 block extent) and then processes the file extent item for +# file offset mapped by 200th block. It used to happen that when processing the +# later, it erroneously left in the csum tree 2 csum items that overlapped each +# other, 1 for the block sub-range [5, 10[ and 1 for the whole range of our +# extent. This introduced a problem where subsequent lookups for the checksums +# of blocks within the block range [10, 25[ of our extent would not find +# anything because lookups in the csum tree ended up looking only at the smaller +# csum item, the one covering the block subrange [5, 10[. This made read +# requests assume an expected checksum with a value of 0 for those blocks, which +# caused checksum verification failure when the read operations finished. # However those checksum failure did not result in read requests returning an # error to user space (like -EIO for e.g.) because the expected checksum value # had the special value 0, and in that case btrfs set all bytes of the @@ -106,10 +113,10 @@ md5sum $SCRATCH_MNT/foo | _filter_scratch # _flakey_drop_and_remount -echo "File digest after log replay:" -# Must match the same digest he had after cloning the extent and before the -# power failure happened. -md5sum $SCRATCH_MNT/foo | _filter_scratch +echo "File contents after log replay:" +# Must match the file contents we had after cloning the extent and before +# the power failure happened. +od -t x1 $SCRATCH_MNT/foo | _filter_od _unmount_flakey diff --git a/tests/btrfs/098.out b/tests/btrfs/098.out index 3aa0772..98a96de 100644 --- a/tests/btrfs/098.out +++ b/tests/btrfs/098.out @@ -1,7 +1,22 @@ QA output created by 098 -wrote 102400/102400 bytes at offset 819200 -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -File digest before power failure: -39b386375971248740ed8651d5a2ed9f SCRATCH_MNT/foo -File digest after log replay: -39b386375971248740ed8651d5a2ed9f SCRATCH_MNT/foo +Blocks modified: [200 - 224] +File contents before power failure: +0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +* +144 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa +* +151 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +* +310 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa +* +341 +File contents after log replay: +0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +* +144 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa +* +151 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +* +310 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa +* +341