Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1067922pxb; Wed, 6 Apr 2022 08:00:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5At7bDhL4Hg2Y02hooIF77F3UG6L+gsXDpBIKpX34aFD9QfIB6T716wUt6yhYeoBxHBpd X-Received: by 2002:a17:90b:4a46:b0:1c7:3b81:fc6 with SMTP id lb6-20020a17090b4a4600b001c73b810fc6mr10173403pjb.243.1649257227101; Wed, 06 Apr 2022 08:00:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649257227; cv=none; d=google.com; s=arc-20160816; b=hwj6Dtp2JlxSw8yD82C4ncjNtZUadZMcnAdV6eI2EDigAX4WuhGnha0IwCU3EKRnzU ju46Q5wtg3HBy01nq4x9JqAtXkU0l3KsENne/UuPNQ8ldD6bdMjdbL1UHntW5KkQy7e3 bPVdXFORgGiQBTIgbST0Bmpe8PVznhfQogqp+0B3VHk47PctLQLMmF6Z03Ugg4szS4Bs j/WbRwwyK/qCPK4PcctWuxc+E39jbUzy/53NwwlA/HuHN2J6GOMNU7HUwmLe1jCEiHha LBDvr0TjgsJaWxdId9RgVTNA4QwR78XCJJPZBfesPgFx9DT223KjV6QRibg6Hh321NQ4 32KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=2AnasPa64zSOyhX++0KDJekLuK5Gj2xl3xEHxqe/G8Q=; b=TSWxQcM0hO8vSVCQgf/xwnCb2ROOraS7XzAQmRvTAv+2VpnmdbUjseaVQej8rUKJ3V vwPm/E6tJTVMCuUxGv75UY6jx/hAN7+ApnFe/5wMDZmrWxrjGMW/aViSMaMVQxtLMd9y GPXLfmAJ2Y2rycMh20iMdDVA5mEdn4kK+nXKEW5ewb6sKH7cTVVegnx8MyP/aq57czVi BypFxQxmZh/WWjiy7IjQ0z4DcaTG/W35Wf8Jr0+NFyl5mOAXvVEHdPgfgJnRGiSPy9GZ /oE7xLWbHpzE4sDTLlxfwmk591nLq2QIH5LztChemGivYwCpFDWa+rq1OSm+pJw23xF0 Z51g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w24-20020a63af18000000b003816043f036si14708914pge.555.2022.04.06.08.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 08:00:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2E18D6BC3A0; Wed, 6 Apr 2022 05:47:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231180AbiDFMev (ORCPT + 99 others); Wed, 6 Apr 2022 08:34:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233622AbiDFMdS (ORCPT ); Wed, 6 Apr 2022 08:33:18 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 283B92DCC87; Wed, 6 Apr 2022 01:31:48 -0700 (PDT) Received: from canpemm500005.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KYHjz45tKzDqMd; Wed, 6 Apr 2022 16:29:27 +0800 (CST) Received: from [10.174.178.134] (10.174.178.134) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 6 Apr 2022 16:31:46 +0800 Subject: Re: [PATCH -next] ext4: Fix symlink file size not match to file content To: Jan Kara CC: Ye Bin , , , , , References: <20220321113408.4112428-1-yebin10@huawei.com> <20220321113703.cibgeac5ipslg3df@quack3.lan> <5b3e0bb7-370b-a950-1d2f-b0e31357cc01@huawei.com> <20220321151141.hypnhr6o4vng2sa6@quack3.lan> From: Zhang Yi Message-ID: <75227a4a-2e32-463a-ade7-57c37a3fbf4b@huawei.com> Date: Wed, 6 Apr 2022 16:31:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20220321151141.hypnhr6o4vng2sa6@quack3.lan> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.134] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500005.china.huawei.com (7.192.104.229) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2022/3/21 23:11, Jan Kara wrote: > Hello Yi! > > On Mon 21-03-22 22:38:49, Zhang Yi wrote: >> On 2022/3/21 19:37, Jan Kara wrote: >>> On Mon 21-03-22 19:34:08, Ye Bin wrote: >>>> We got issue as follows: >>>> [home]# fsck.ext4 -fn ram0yb >>>> e2fsck 1.45.6 (20-Mar-2020) >>>> Pass 1: Checking inodes, blocks, and sizes >>>> Pass 2: Checking directory structure >>>> Symlink /p3/d14/d1a/l3d (inode #3494) is invalid. >>>> Clear? no >>>> Entry 'l3d' in /p3/d14/d1a (3383) has an incorrect filetype (was 7, should be 0). >>>> Fix? no >>>> >>>> As symlink file size not match to file content. If symlink data block >>>> writback failed, will call ext4_finish_bio to end io. In this path don't >>>> mark buffer error. When umount do checkpoint can't detect buffer error, >>>> then will cleanup jounral. Actually, correct data maybe in journal area. >>>> To solve this issue, mark buffer error when detect bio error in >>>> ext4_finish_bio. >>> >>> Thanks for the patch! Let me rephrase the text a bit: >>> >>> As the symlink file size does not match the file content. If the writeback >>> of the symlink data block failed, ext4_finish_bio() handles the end of IO. >>> However this function fails to mark the buffer with BH_write_io_error and >>> so when unmount does journal checkpoint it cannot detect the writeback >>> error and will cleanup the journal. Thus we've lost the correct data in the >>> journal area. To solve this issue, mark the buffer as BH_write_io_error in >>> ext4_finish_bio(). >>> >> >> Thinking about this issue in depth, the symlink data block is one kind of >> metadata, but the page mapping of such block is belongs to the ext4 inode, >> it's not coordinate to other metadata blocks, e.g. directory block and extents >> block. This is why we have already fix the same issue of other metadata blocks >> in commit fcf37549ae19e9 "jbd2: ensure abort the journal if detect IO error >> when writing original buffer back" but missing the case of symlink data block. >> So, after Ye Bin's fix, I think it's worth to unify the symlink data block >> mapping to bdev, any suggestions? > > Well, symlink with external block is essentially a case of data=journal > data block. So even if we would handle symlinks, we would still need to > deal with other inodes with journalled data. Also we need to keep the> symlink contents in the page cache to make it simple for generic VFS code > handling symlinks. So I don't see how we could substantially unify > things... > Yeah, this fix is still needed for other regular file's journalled data when we mounted filesystem with data=jouranl mode. But if we just consider whether if we could unify the journal mode of ext4's metadata blocks, it seems that using data=journal mode for symlink's external data block is also complicated and confused in the creating procedure. Instead, if we use ext4_bread(), it make things clear, and it seems also has no side effect of reading symlinks. I write a RFC patch to do this, please take a look at my latest mail "[RFC PATCH] ext4: convert symlink external data block mapping to bdev". Thanks, Yi.