Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <06F8DFC9-26F5-475F-9428-06FED2CA01AA@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_91D2A469-7A61-4CB1-93C3-4B807A11CBBD";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH v5 0/3] ext4, jbd2: journal cycled record transactions
 between each mount
Date:   Wed, 22 Mar 2023 15:34:49 -0600
In-Reply-To: <20230322013353.1843306-1-yi.zhang@huaweicloud.com>
Cc:     Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
        Zhang Yi <yi.zhang@huawei.com>, yukuai3@huawei.com
To:     Zhang Yi <yi.zhang@huaweicloud.com>
References: <20230322013353.1843306-1-yi.zhang@huaweicloud.com>
Precedence: bulk


--Apple-Mail=_91D2A469-7A61-4CB1-93C3-4B807A11CBBD
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Mar 21, 2023, at 7:33 PM, Zhang Yi <yi.zhang@huaweicloud.com> wrote:
> This patch set add a new journal option 'JBD2_CYCLE_RECORD' and always
> enable on ext4. It saves journal head for a clean unmounted file system
> in the journal super block, which could let us record journal
> transactions between each mount continuously. It could help us to do
> journal backtrack and find root cause from a corrupted filesystem.
> Current filesystem's corruption analysis is difficult and less useful
> information, especially on the real products. It is useful to some
> extent, especially for the cases of doing fuzzy tests and deploy in some
> shout-runing products.

Another interesting side benefit of this change is that it gets a step
closer to the "lazy ext4" (log-structured optimization) that had been
described some time ago at FAST:

https://lwn.net/Articles/720226/
https://www.usenix.org/system/files/conference/fast17/fast17-aghayev.pdf
https://lists.openwall.net/linux-ext4/2017/04/11/1

Essentially, free space in the filesystem (or a large external device)
could be used as a continuous journal, and metadata would only rarely
be checkpointed to the actual filesystem.  If the "journal" is close to
wrapping to the start, either the meta/data is checkpointed (if it is
no longer actively used or can make a large write), or re-journaled to
the end of the journal.  At remount time, the full journal is read into
memory (discarding old copies of blocks) and this is used to identify
the current metadata rather than reading from the filesystem itself.

This would allow e.g. very efficient flash caching of metadata (and also
journaled data for small writes) for an HDD (or QLC) device.

Cheers, Andreas


--Apple-Mail=_91D2A469-7A61-4CB1-93C3-4B807A11CBBD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmQbdHoACgkQcqXauRfM
H+CvOxAAs8h7UWeM/XFNozgG2NrYa4eEnPHUxApEP5jcmij0B72Zg48cFi5Nivjg
DXPkslM1kDIA7Dn0a94cnwfJT6BXQrpgmhLggZtFnVVILb7+WHUuLx+1hYbILtWa
wndRZwnaV3nVWdaEL6HiZlHgmyw9fS+gWXUOSP07Me48Ox8pQVrKJ5ht0uXQszgg
ff9DaUCVmTX1OY9JvslqFh84BHCSV3/Q1fMcy8JGile1MBduRLZg2IEi+DvS+FTe
Xrwm7BSfD7MdfSSWnt5EbiZibAYNH69cCDIAHPPdDHbLVDRw/HmUcD31+OiOlriz
eme991yqCKE4BGxUl01m8WJ4uqCFEvRszAxrOFpLjtuO28xUeTkOgoqTfCwuFVDF
ifywPCKZDX9rX06t7D2DSiyupK/vFS88/7cKDraULD7vB6gXJg+sjKzSNRryKUlA
o5koFfpl8cVXAyAvARA/lIf1OyVh/jlvFcwhshMPSBh5NuP+OUvxmTdlhN44VRnH
e0enPVD+ZSZ4pDAlNYvDzo2FgQ43aCwEBxdL7H3MQ4KPwl4CZT0qwR5u9EehNJHK
BX7x/O0d8tG3dMVbfm8juQU9zSvMwgAqBEtQbGRIuKlacXs0rwUHciZyMPkohfQJ
8D5JAJ5cj/yg+WqDno1IivFvYnsxpjgSKx4JC62bEQ7w0q87qcI=
=c7GG
-----END PGP SIGNATURE-----

--Apple-Mail=_91D2A469-7A61-4CB1-93C3-4B807A11CBBD--