[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181219071149.GB2628@infradead.org>
Date: Tue, 18 Dec 2018 23:11:49 -0800
From: Christoph Hellwig <hch@...radead.org>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Eric Biggers <ebiggers@...nel.org>,
Christoph Hellwig <hch@...radead.org>,
linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
"Theodore Y . Ts'o" <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>,
Victor Hsieh <victorhsieh@...gle.com>,
Chandan Rajendra <chandan@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file
On Mon, Dec 17, 2018 at 12:00:39PM -0800, Darrick J. Wong wrote:
> FWIW, if I were (hypothetically) working on an xfs implementation, I
> likely would have settled on passing a reference to a merkle tree
> through a (fd, length) pair, because that allows us plenty of options
> on the back end:
>
> b) we could remap the tree into a new inode fork for merkle trees, or
> a) remap it as posteof blocks like ext4/f2fs does, or
> c) remap the blocks into the attribute fork as an (unusually large)
> extended attribute value.
>
> If the merkle_fd isn't on the same filesystem as the fd we could at
> least use generic_copy_file_range (i.e. page cache copying) to land the
> merkle tree wherever we want.
I think the fd would have to be on the same fs for this interface to
make sense. But it could be an O_TMPFILE one. And given that ext4
already supports a variant of swapext this interface should also work
with the existing ext4 on disk format.
Powered by blists - more mailing lists