Re: [PATCH 19/26] xfs: don't bother storing merkle tree blocks for zeroed data blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 30, 2024 at 11:47:23PM -0700, Christoph Hellwig wrote:
> On Mon, Apr 29, 2024 at 08:29:03PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> > 
> > Now that fsverity tells our merkle tree io functions about what a hash
> > of a data block full of zeroes looks like, we can use this information
> > to avoid writing out merkle tree blocks for sparse regions of the file.
> > For verified gold master images this can save quite a bit of overhead.
> 
> Is this something that fsverity should be doing in a generic way?

I don't think it's all that useful for ext4/f2fs because they always
write out full merkle tree blocks even if it's the zerohash over and
over again.  Old kernels aren't going to know how to deal with that.

> It feels odd to have XFS behave different from everyone else here,
> even if this does feel useful.  Do we also need any hash validation
> that no one tampered with the metadata and added a new extent, or
> is this out of scope for fsverity?

If they wrote a new extent with nonzero contents, then the validation
will fail, right?

If they added a new unwritten extent (or a written one full of zeroes),
then the file data hasn't changed and validation would still pass,
correct?

--D




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux