> On Apr 5, 2024, at 1:17 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote:
>
> On Apr 3, 2024, at 1:22 AM, Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx> wrote:
>>
>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx>
>> ---
>> fs/bcachefs/fs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
>> index d2793bae842d..54f613f977b4 100644
>> --- a/fs/bcachefs/fs.c
>> +++ b/fs/bcachefs/fs.c
>> @@ -921,7 +921,7 @@ static int bch2_fill_extent(struct bch_fs *c,
>> flags2 |= FIEMAP_EXTENT_UNWRITTEN;
>>
>> if (p.crc.compression_type) {
>> - flags2 |= FIEMAP_EXTENT_ENCODED;
>> + flags2 |= FIEMAP_EXTENT_DATA_COMPRESSED;
>
> (defect) This should *also* set FIEMAP_EXTENT_ENCODED in this case,
> along with FIEMAP_EXTENT_DATA_COMPRESSED. Both for compatibility with
> older code that doesn't understand FIEMAP_EXTENT_DATA_COMPRESSED, and
> because the data still cannot be read directly from the volume when it
> is not mounted.
>
> Probably Kent should chime in here with what needs to be done to set
> the phys_len properly for bcachefs, or leave this patch out of your
> series and let him submit it directly. With proposed wrapper in the
> first patch of the series there isn't a hard requirement to change
> all of the filesystems in one shot.
Ah, I missed the 11/13 patch that is handling up most of the bcachefs
phys_len changes. I think this should be folded into that patch so
it is clear to the callers that the data is compressed when they see
fe_physical_length is not the same as fe_logical_length.
Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
