Re: [f2fs-dev] [PATCH] f2fs: change fiemap way in printing compression chunk

From: Eric Biggers <ebiggers@kernel.org>
To: Daeho Jeong <daeho43@gmail.com>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: change fiemap way in printing compression chunk
Date: Thu, 22 Jul 2021 09:26:26 -0700	[thread overview]
Message-ID: <YPmcMpbv3kxSZOs8@gmail.com> (raw)
In-Reply-To: <YPmaMFlR6/tJTmpQ@gmail.com>

On Thu, Jul 22, 2021 at 09:17:54AM -0700, Eric Biggers wrote:
> > I think it matches with FIEMAP_EXTENT_UNWRITTEN. Otherwise, we should
> > shorten the last extent like below.
> > 
> >         fe_logical=0    fe_physical=16384  length=4096
> >         fe_logical=4096 fe_physical=81920  length=4096
> >         fe_logical=8192 fe_physical=147456 length=4096
> > 
> > 
> >   Unwritten extent - the extent is allocated but its data has not been
> >   initialized.  This indicates the extent's data will be all zero if read
> >   through the filesystem but the contents are undefined if read directly from
> >   the device.
> 
> Well, as I said before, using UNWRITTEN isn't appropriate because it indicates
> that the data is all zeroes, which in this case it is not.  Similarly, reporting
> a hole isn't appropriate because it also indicates that the data is all zeroes
> and also that it has no space allocated on-disk at all.
> 
> I think we should just over-report the physical length of the last extent in the
> cluster, which is what btrfs does...
> 

Also keep in mind that as far as fiemap is concerned, when FIEMAP_EXTENT_ENCODED
is set (indicating that the data is compressed or encrypted), then reading the
data from disk will have "undefined results"; see
Documentation/filesystems/fiemap.rst.  As such, when someone decides to do so
anyway (which is necessary for encryption testing), they really need to know
*exactly* what they're doing.  So I think it's less bad to bend the rules on
extents where FIEMAP_EXTENT_ENCODED is already set.

In contrast, your suggestion would incorreectly report some parts of the file as
standard extents (or holes) without FIEMAP_EXTENT_ENCODED, so it would be
expected that the standard meaning would apply to those parts.

- Eric

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel