On May 23, 2023 / 20:35, Chao Yu wrote:
> Use sbi->log_sectors_per_block to clean up below calculated one:
>
> unsigned int log_sectors_per_block = sbi->log_blocksize - SECTOR_SHIFT;
Hello Chao,
When I ran workloads on f2fs using v6.5-rcX with fixes [1][2] and a zoned block
devices with 4kb logi
On Feb 19, 2024 / 00:58, Yi Zhang wrote:
> Hello
> I reproduced this issue on the latest linux-block/for-next, please
> help check it and let me know if you need more info/test, thanks.
[...]
> [ 4381.278858] [ cut here ]
> [ 4381.283484] WARNING: CPU: 22 PID: 44011 at fs/
On Mar 01, 2024 / 15:49, Yi Zhang wrote:
> On Wed, Feb 28, 2024 at 8:08 PM Yi Zhang wrote:
> >
> > On Wed, Feb 28, 2024 at 7:09 PM Shinichiro Kawasaki
> > wrote:
> > >
> > > On Feb 19, 2024 / 00:58, Yi Zhang wrote:
> > > > Hello
> > > > I reproduced this issue on the latest linux-block/for-next,
On Mar 12, 2024 / 12:57, Yi Zhang wrote:
...
> Sorry, please use this one.
Thanks. I have succeeded to recreate the issue. Will take a look tomorrow.
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net
I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
look in the commit, but it looks fine to me. So I thought the cause is not
in the commit diff.
I found the WARN is printed when the f2fs is set up with multiple devices,
and read requests are mapped to the very first bloc
On Mar 18, 2024 / 14:12, Daeho Jeong wrote:
> On Sun, Mar 17, 2024 at 10:49 PM Shinichiro Kawasaki via
> Linux-f2fs-devel wrote:
> >
> > I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
> > look in the commit, but it looks fine to me. So I
On Mar 19, 2024 / 10:22, Chao Yu wrote:
> On 2024/3/18 13:47, Shinichiro Kawasaki via Linux-f2fs-devel wrote:
> > I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
> > look in the commit, but it looks fine to me. So I thought the cause is not
> &g
On Mar 24, 2024 / 20:13, Chao Yu wrote:
...
> Hi Shinichiro,
>
> Can you please check below diff? IIUC, for the case: f2fs_map_blocks()
> returns zero blkaddr in non-primary device, which is a verified valid
> block address, we'd better to check m_flags & F2FS_MAP_MAPPED instead
> of map.m_pblk !=
On Mar 25, 2024 / 11:06, Chao Yu wrote:
> On 2024/3/25 10:14, Shinichiro Kawasaki wrote:
> > On Mar 24, 2024 / 20:13, Chao Yu wrote:
> > ...
> > > Hi Shinichiro,
> > >
> > > Can you please check below diff? IIUC, for the case: f2fs_map_blocks()
> > > returns zero blkaddr in non-primary device, whi
Thank you for the comments. Will reflect them and post v2.
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On Oct 10, 2022 / 15:15, Jaegeuk Kim wrote:
> As f2fs becomes more resilient for GCs, let's give the marginal overprovision
> space back to user.
>
> Signed-off-by: Jaegeuk Kim
Hello Jaegeuk,
Using the dev branch of f2fs-tools repo, I observed mkfs.f2fs failure with zoned
block devices:
On Oct 20, 2022 / 16:18, Jaegeuk Kim wrote:
...
> Thanks, I think that fix looks good to me. I applied into the original patch.
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?h=dev&id=281d3e72370f6c39c0d57acaf37a7f0e003ddd28
Oh, happy to know that the fix is goo
On Nov 01, 2022 / 00:09, Sijie Lan wrote:
...
> Info: Host-managed zoned block device:
> 20 zones, 2147483648 zone size(bytes), 10 randomly writeable zones
When zone size is large comparing to device size, reserved area size tend to be
large and results in the failure. Can you try with sma
With kernel v6.5-rc1, I observed failure of a blktests test case zbd/010, which
mounts f2fs on zoned null_blk and scsi_debug devices. This mount failure can be
recreated just executing "mkfs.f2fs -m" and "mount" commands on various zoned
block devices. The mount failure is not observed with non-zon
On Jul 13, 2023 / 13:19, Christoph Hellwig wrote:
> Take a look at the "f2fs: don't reopen the main block device in
> f2fs_scan_devices" thread on the block list. The first version of patch
> still had issues, but there is an updated on deeper in the thread.
Thanks! I found the second patch in th
15 matches
Mail list logo
