public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yong <shengyong2021@gmail.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>,
	xiang@kernel.org, chao@kernel.org, zbestahu@gmail.com,
	jefflexu@linux.alibaba.com, dhavale@google.com, kzak@redhat.com
Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	wangshuai12@xiaomi.com, Sheng Yong <shengyong1@xiaomi.com>
Subject: Re: [PATCH v4 2/2] erofs: add 'fsoffset' mount option for file-backed & bdev-based mounts
Date: Thu, 8 May 2025 20:53:14 +0800	[thread overview]
Message-ID: <93df9b24-3a37-48ff-aa21-5f27a76ecf90@gmail.com> (raw)
In-Reply-To: <6389156c-c6df-4e02-ab46-3aaf6230ef76@linux.alibaba.com>

On 5/8/25 12:09, Gao Xiang wrote:
> Hi Yong,
> 
[...]
>> diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
>> index 4ac188d5d894..10656bd986bd 100644
>> --- a/fs/erofs/internal.h
>> +++ b/fs/erofs/internal.h
>> @@ -43,6 +43,7 @@ struct erofs_device_info {
>>       char *path;
>>       struct erofs_fscache *fscache;
>>       struct file *file;
>> +    loff_t off;
>>       struct dax_device *dax_dev;
>>       u64 dax_part_off;
> 
> I wonder if it's possible to combine off as dax_part_off since
> they are the same functionality...

Hi, Xiang,

Thanks for the review. Yes, they almost have the same functionality.
Will combine them.
> 
>> @@ -199,6 +200,7 @@ enum {
>>   struct erofs_buf {
>>       struct address_space *mapping;
>>       struct file *file;
>> +    loff_t off;
> 
> I wonder if there is some other way to check
> if it's a metabuf, so that we could just use sbi->dif0.off..
> 
> But not sure.

It seems no specific fields could tell directly whether a buf is a
metabuf. But I'll have a try.
> 
>>       struct page *page;
>>       void *base;
>>   };
> 
> ..
> 
>> +        if (sb->s_bdev)
>> +            devsz = bdev_nr_bytes(sb->s_bdev);
>> +        else if (erofs_is_fileio_mode(sbi))
>> +            devsz = i_size_read(file_inode(sbi->dif0.file));
>> +        else
>> +            return invalfc(fc, "fsoffset only supports file or bdev 
>> backing");
>> +        if (sbi->dif0.off + (1 << sbi->blkszbits) > devsz)
>> +            return invalfc(fc, "fsoffset exceeds device size");
> 
> I wonder if those checks are really necessary? even it exceeds
> the device size, it won't find the valid on-disk superblock then.

Will remove this check.
> 
>> +    }
>> +
[...]
>> diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
>> index 0671184d9cf1..671527b63c6d 100644
>> --- a/fs/erofs/zdata.c
>> +++ b/fs/erofs/zdata.c
>> @@ -1624,7 +1624,8 @@ static void z_erofs_submit_queue(struct 
>> z_erofs_frontend *f,
>>                    bool *force_fg, bool readahead)
>>   {
>>       struct super_block *sb = f->inode->i_sb;
>> -    struct address_space *mc = MNGD_MAPPING(EROFS_SB(sb));
>> +    struct erofs_sb_info *sbi = EROFS_SB(sb);
>> +    struct address_space *mc = MNGD_MAPPING(sbi);
>>       struct z_erofs_pcluster **qtail[NR_JOBQUEUES];
>>       struct z_erofs_decompressqueue *q[NR_JOBQUEUES];
>>       struct z_erofs_pcluster *pcl, *next;
>> @@ -1673,12 +1674,15 @@ static void z_erofs_submit_queue(struct 
>> z_erofs_frontend *f,
>>               if (bio && (cur != last_pa ||
>>                       bio->bi_bdev != mdev.m_bdev)) {
>>   drain_io:
>> -                if (erofs_is_fileio_mode(EROFS_SB(sb)))
>> +                if (erofs_is_fileio_mode(sbi)) {
>>                       erofs_fileio_submit_bio(bio);
>> -                else if (erofs_is_fscache_mode(sb))
>> +                } else if (erofs_is_fscache_mode(sb)) {
>>                       erofs_fscache_submit_bio(bio);
>> -                else
>> +                } else {
>> +                    bio->bi_iter.bi_sector +=
>> +                        sbi->dif0.off >> SECTOR_SHIFT;
> 
> How about multi-device? I guess we should modify
> erofs_map_dev() directly rather than callers.
Will fix fsoffset on multi device in the next version.

thanks,
shengyong
> 
> Thanks,
> Gao Xiang


  reply	other threads:[~2025-05-08 12:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 12:23 [PATCH v4 1/2] erofs: set error to bio if file-backed IO fails Sheng Yong
2025-04-08 12:23 ` [PATCH v4 2/2] erofs: add 'fsoffset' mount option for file-backed & bdev-based mounts Sheng Yong
2025-05-08  4:09   ` Gao Xiang
2025-05-08 12:53     ` Sheng Yong [this message]
2025-04-08 12:32 ` [PATCH v4 1/2] erofs: set error to bio if file-backed IO fails Gao Xiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=93df9b24-3a37-48ff-aa21-5f27a76ecf90@gmail.com \
    --to=shengyong2021@gmail.com \
    --cc=chao@kernel.org \
    --cc=dhavale@google.com \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=kzak@redhat.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shengyong1@xiaomi.com \
    --cc=wangshuai12@xiaomi.com \
    --cc=xiang@kernel.org \
    --cc=zbestahu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox