From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D523ECE587 for ; Mon, 14 Oct 2019 09:45:19 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CEB66206A3 for ; Mon, 14 Oct 2019 09:45:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEB66206A3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46sDF766QgzDqhD for ; Mon, 14 Oct 2019 20:45:15 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=suse.cz (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=jack@suse.cz; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.cz Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46sDBy3d0szDqRn for ; Mon, 14 Oct 2019 20:43:15 +1100 (AEDT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 79792BE14; Mon, 14 Oct 2019 09:43:11 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 339E81E4A86; Mon, 14 Oct 2019 11:43:11 +0200 (CEST) Date: Mon, 14 Oct 2019 11:43:11 +0200 From: Jan Kara To: Pingfan Liu Subject: Re: [PATCH] xfs: introduce "metasync" api to sync metadata to fsblock Message-ID: <20191014094311.GD5939@quack2.suse.cz> References: <1570977420-3944-1-git-send-email-kernelfans@gmail.com> <20191013163417.GQ13108@magnolia> <20191014083315.GA10091@mypc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191014083315.GA10091@mypc> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eric Sandeen , "Darrick J. Wong" , Dave Chinner , linux-xfs@vger.kernel.org, Jan Kara , linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Hari Bathini Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon 14-10-19 16:33:15, Pingfan Liu wrote: > On Sun, Oct 13, 2019 at 09:34:17AM -0700, Darrick J. Wong wrote: > > On Sun, Oct 13, 2019 at 10:37:00PM +0800, Pingfan Liu wrote: > > > When using fadump (fireware assist dump) mode on powerpc, a mismatch > > > between grub xfs driver and kernel xfs driver has been obsevered. Note: > > > fadump boots up in the following sequence: fireware -> grub reads kernel > > > and initramfs -> kernel boots. > > > > > > The process to reproduce this mismatch: > > > - On powerpc, boot kernel with fadump=on and edit /etc/kdump.conf. > > > - Replacing "path /var/crash" with "path /var/crashnew", then, "kdumpctl > > > restart" to rebuild the initramfs. Detail about the rebuilding looks > > > like: mkdumprd /boot/initramfs-`uname -r`.img.tmp; > > > mv /boot/initramfs-`uname -r`.img.tmp /boot/initramfs-`uname -r`.img > > > sync > > > - "echo c >/proc/sysrq-trigger". > > > > > > The result: > > > The dump image will not be saved under /var/crashnew/* as expected, but > > > still saved under /var/crash. > > > > > > The root cause: > > > As Eric pointed out that on xfs, 'sync' ensures the consistency by writing > > > back metadata to xlog, but not necessary to fsblock. This raises issue if > > > grub can not replay the xlog before accessing the xfs files. Since the > > > above dir entry of initramfs should be saved as inline data with xfs_inode, > > > so xfs_fs_sync_fs() does not guarantee it written to fsblock. > > > > > > umount can be used to write metadata fsblock, but the filesystem can not be > > > umounted if still in use. > > > > > > There are two ways to fix this mismatch, either grub or xfs. It may be > > > easier to do this in xfs side by introducing an interface to flush metadata > > > to fsblock explicitly. > > > > > > With this patch, metadata can be written to fsblock by: > > > # update AIL > > > sync > > > # new introduced interface to flush metadata to fsblock > > > mount -o remount,metasync mountpoint > > > > I think this ought to be an ioctl or some sort of generic call since the > > jbd2 filesystems (ext3, ext4, ocfs2) suffer from the same "$BOOTLOADER > > is too dumb to recover logs but still wants to write to the fs" > > checkpointing problem. > Yes, a syscall sounds more reasonable. > > > > (Or maybe we should just put all that stuff in a vfat filesystem, I > > don't know...) > I think it is unavoidable to involve in each fs' implementation. What > about introducing an interface sync_to_fsblock(struct super_block *sb) in > the struct super_operations, then let each fs manage its own case? Well, we already have a way to achieve what you need: fsfreeze. Traditionally, that is guaranteed to put fs into a "clean" state very much equivalent to the fs being unmounted and that seems to be what the bootloader wants so that it can access the filesystem without worrying about some recovery details. So do you see any problem with replacing 'sync' in your example above with 'fsfreeze /boot && fsfreeze -u /boot'? Honza -- Jan Kara SUSE Labs, CR