From patchwork Tue Aug 27 21:04:56 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 2850343 Return-Path: X-Original-To: patchwork-ocfs2-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 6749F9F495 for ; Tue, 27 Aug 2013 21:05:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F2F0C203F1 for ; Tue, 27 Aug 2013 21:05:46 +0000 (UTC) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 645CB203E9 for ; Tue, 27 Aug 2013 21:05:45 +0000 (UTC) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RL5bxm009179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 21:05:37 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RL5Zum025408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 21:05:35 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1VEQSF-0001fk-FR; Tue, 27 Aug 2013 14:05:35 -0700 Received: from ucsinet21.oracle.com ([156.151.31.93]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1VEQRf-0001ai-6h for ocfs2-devel@oss.oracle.com; Tue, 27 Aug 2013 14:04:59 -0700 Received: from aserp1030.oracle.com (aserp1030.oracle.com [141.146.126.68]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RL4ws6019498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Aug 2013 21:04:58 GMT Received: from mail-qa0-f73.google.com (mail-qa0-f73.google.com [209.85.216.73]) by aserp1030.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RL4v4B028832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 27 Aug 2013 21:04:57 GMT Received: by mail-qa0-f73.google.com with SMTP id o13so558741qaj.0 for ; Tue, 27 Aug 2013 14:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:subject:to:cc:from:date:mime-version :content-type:content-transfer-encoding:message-id; bh=wU1RVq2/0wTsHmtzjklq13KMW0BUvfohUaYY79GZq5Q=; b=O06wZAsrDP7dxvmyc7sMcJTOaozp/J2hzSKHPYrXzVrUowMRsBby8q/Fz0bX0f4TWW wsJ7IOYeuh0249v1hE12oYnsTrrFaC0St8Fmlp3rYDvzBxHMMEjUYjkkA7jzmNiGVaWa gHr7lNVGUNKIv2PkiDHC4HPbEgZLG3fuJ7N0Dco+I3+H16NpjmixQfG5m63+FqaoIXkH TamGCpnuqrjW5dpKGNO9KExnCI57zTbMDSLfelP7BhqwXDzbcrJCf+fTUemq7rektacF AjQlWIfoxsQlca5iJjkuVhmbQ9N/jfd1yZ4Obl1wUHIZhySWOs/NzuMNcdYNY6cXi+ut I/zQ== X-Gm-Message-State: ALoCoQmN9DEZPIAmfkEJ3zQ5coQOTTrzWwDNhIBJfADeJGdTbBL085ynqvop+OdcWDDI1vdAMdAe X-Received: by 10.236.156.138 with SMTP id m10mr8538477yhk.26.1377637497096; Tue, 27 Aug 2013 14:04:57 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id k45si1406219yhn.4.1969.12.31.16.00.00 (version=TLSv1.1 cipher=AES128-SHA bits=128/128); Tue, 27 Aug 2013 14:04:57 -0700 (PDT) Received: from localhost.localdomain (akpm3.mtv.corp.google.com [172.17.131.127]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 7EB3D31C1D6; Tue, 27 Aug 2013 14:04:56 -0700 (PDT) To: ocfs2-devel@oss.oracle.com From: akpm@linux-foundation.org Date: Tue, 27 Aug 2013 14:04:56 -0700 MIME-Version: 1.0 Message-Id: <20130827210456.7EB3D31C1D6@corp2gmr1-1.hot.corp.google.com> X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=209.85.216.73 ct-class=R6 ct-vol1=0 ct-vol2=0 ct-vol3=0 ct-risk=68 ct-spam1=0 ct-spam2=0 ct-bulk=0 rcpts=1 size=4760 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=D6B+dJhj c=1 sm=1 tr=0 a=UIbzyxYux8O4lTDDbScKfQ==:117 a=YudQMIlgdIUA:10 a=NEiEQogP1MkA:10 a=os2CZ2fo8YAA:10 a=Z4Rwk6OoAAAA:8 a=1XWaLZrsAAAA:8 a=yPCof4ZbAAAA:8 a=e6ffS3PuTIcA:10 a=i0EeH86SAAAA:8 a=iox4zFpeAAAA:8 a=IXr_WNlcAAAA:8 a=4QweHFx2po4wFhV_ArQA:9 a=e4xtJxf3HDoA:10 a=7DSvI1NPTFQA:10 a=hPjdaMEvmhQA:10 a=n9GBPR9yFnkA:10 a=T5ZRoNnfl4MA:10 a=jbrJJM5MRmoA:10 X-Sendmail-CT-Classification: not spam X-Sendmail-CT-RefID: str=0001.0A090204.521D147A.0018, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: mfasheh@suse.com Subject: [Ocfs2-devel] [patch 04/22] ocfs2: update inode size after zeroing the hole X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, 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 From: Junxiao Bi Subject: ocfs2: update inode size after zeronig the hole fs-writeback will release the dirty pages without page lock whose offset are over inode size, the release happens at block_write_full_page_endio(). If not update, dirty pages in file holes may be released before flushed to the disk, then file holes will contain some non-zero data, this will cause sparse file md5sum error. To reproduce the bug, find a big sparse file with many holes, like vm image file, its actual size should be bigger than available mem size to make writeback work more frequently, tar it with -S option, then keep untar it and check its md5sum again and again until you get a wrong md5sum. Signed-off-by: Junxiao Bi Cc: Younger Liu Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton --- fs/ocfs2/file.c | 40 ++++++++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 8 deletions(-) diff -puN fs/ocfs2/file.c~ocfs2-update-inode-size-after-zeronig-the-hole fs/ocfs2/file.c --- a/fs/ocfs2/file.c~ocfs2-update-inode-size-after-zeronig-the-hole +++ a/fs/ocfs2/file.c @@ -718,7 +718,8 @@ leave: * While a write will already be ordering the data, a truncate will not. * Thus, we need to explicitly order the zeroed pages. */ -static handle_t *ocfs2_zero_start_ordered_transaction(struct inode *inode) +static handle_t *ocfs2_zero_start_ordered_transaction(struct inode *inode, + struct buffer_head *di_bh) { struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); handle_t *handle = NULL; @@ -735,7 +736,14 @@ static handle_t *ocfs2_zero_start_ordere } ret = ocfs2_jbd2_file_inode(handle, inode); - if (ret < 0) + if (ret < 0) { + mlog_errno(ret); + goto out; + } + + ret = ocfs2_journal_access_di(handle, INODE_CACHE(inode), di_bh, + OCFS2_JOURNAL_ACCESS_WRITE); + if (ret) mlog_errno(ret); out: @@ -751,7 +759,7 @@ out: * to be too fragile to do exactly what we need without us having to * worry about recursive locking in ->write_begin() and ->write_end(). */ static int ocfs2_write_zero_page(struct inode *inode, u64 abs_from, - u64 abs_to) + u64 abs_to, struct buffer_head *di_bh) { struct address_space *mapping = inode->i_mapping; struct page *page; @@ -759,6 +767,7 @@ static int ocfs2_write_zero_page(struct handle_t *handle = NULL; int ret = 0; unsigned zero_from, zero_to, block_start, block_end; + struct ocfs2_dinode *di = (struct ocfs2_dinode *)di_bh->b_data; BUG_ON(abs_from >= abs_to); BUG_ON(abs_to > (((u64)index + 1) << PAGE_CACHE_SHIFT)); @@ -801,7 +810,8 @@ static int ocfs2_write_zero_page(struct } if (!handle) { - handle = ocfs2_zero_start_ordered_transaction(inode); + handle = ocfs2_zero_start_ordered_transaction(inode, + di_bh); if (IS_ERR(handle)) { ret = PTR_ERR(handle); handle = NULL; @@ -818,8 +828,22 @@ static int ocfs2_write_zero_page(struct ret = 0; } - if (handle) + if (handle) { + /* + * fs-writeback will release the dirty pages without page lock + * whose offset are over inode size, the release happens at + * block_write_full_page_endio(). + */ + i_size_write(inode, abs_to); + inode->i_blocks = ocfs2_inode_sector_count(inode); + di->i_size = cpu_to_le64((u64)i_size_read(inode)); + inode->i_mtime = inode->i_ctime = CURRENT_TIME; + di->i_mtime = di->i_ctime = cpu_to_le64(inode->i_mtime.tv_sec); + di->i_ctime_nsec = cpu_to_le32(inode->i_mtime.tv_nsec); + di->i_mtime_nsec = di->i_ctime_nsec; + ocfs2_journal_dirty(handle, di_bh); ocfs2_commit_trans(OCFS2_SB(inode->i_sb), handle); + } out_unlock: unlock_page(page); @@ -915,7 +939,7 @@ out: * has made sure that the entire range needs zeroing. */ static int ocfs2_zero_extend_range(struct inode *inode, u64 range_start, - u64 range_end) + u64 range_end, struct buffer_head *di_bh) { int rc = 0; u64 next_pos; @@ -931,7 +955,7 @@ static int ocfs2_zero_extend_range(struc next_pos = (zero_pos & PAGE_CACHE_MASK) + PAGE_CACHE_SIZE; if (next_pos > range_end) next_pos = range_end; - rc = ocfs2_write_zero_page(inode, zero_pos, next_pos); + rc = ocfs2_write_zero_page(inode, zero_pos, next_pos, di_bh); if (rc < 0) { mlog_errno(rc); break; @@ -977,7 +1001,7 @@ int ocfs2_zero_extend(struct inode *inod range_end = zero_to_size; ret = ocfs2_zero_extend_range(inode, range_start, - range_end); + range_end, di_bh); if (ret) { mlog_errno(ret); break;