Hi Jaegeuk,
> I cut off the patches for this merge window. Please consider next release.
Alright, thanks for your reminder.
> BTW, could you please send a patch set instead of random posts?
Most of the patches were noticed when I looked at the code, and they were
scattered.
On the one hand, th
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #116 from Thomas (v10la...@myway.de) ---
(In reply to Jaegeuk Kim from comment #112)
> this requires lots of effort between 5.15 vs. 5.18 tho, is it doable?
Really good question. I think it is doable but with a lot of time and passion
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #115 from Guido (guido.iod...@gmail.com) ---
(In reply to Thomas from comment #114)
> (In reply to Guido from comment #113)
>
> Why not test the "f2fs_io_schedule_timeout" kernel patch in combination with
> running the manual GC scrip
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #114 from Thomas (v10la...@myway.de) ---
(In reply to Guido from comment #113)
Why not test the "f2fs_io_schedule_timeout" kernel patch in combination with
running the manual GC script one time (doesn't seem to matter if you run this
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #113 from Guido (guido.iod...@gmail.com) ---
(In reply to Jaegeuk Kim from comment #112)
Now I'm trying another solution: I used fstransform to format the partition and
upgrade the filesystem to f2fs 1.15. So now I'm testing kernel 6.
Currently, fsverity development is reusing the same mailing list, git repo
(though a different branch), and patchwork project as fscrypt --- mainly just
because I was a little lazy and didn't bother to ask for new ones:
FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
[...]
L: linux-fscr...@vger
On 12/13, Yangtao Li wrote:
> Hi Jaegeuk,
>
> >>> Again, w'd better to consider this functionality only when DEBUG_FS
> >>> is enabled.
> >>
> >> BTW, why can't we use iostat to get the discard latencies?
> >
> > Agreed.
>
> Let me spend some time on this. So, I guess this patch can't catch up
On 12/13, Yangtao Li wrote:
> > What do you think of extending this function to support io_counts?
> >
> > void f2fs_update_iostat(struct f2fs_sb_info *sbi, struct inode *inode,
> > enum iostat_type type, unsigned long long io_bytes,
> > unsigned long long i
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #112 from Jaegeuk Kim (jaeg...@kernel.org) ---
I feel that this may be a subtle page cache issue, which is really hard to find
the root cause. That being said, we might have two options: 1) bisecting the
kernel version, 2) trying 5.15
https://bugzilla.kernel.org/show_bug.cgi?id=216050
--- Comment #111 from Guido (guido.iod...@gmail.com) ---
Even worse, although I reactivated the script to force gc, I had the problem of
the cpu at 100 per cent again, even though I had done the 'cleaning' with the
5.15 kernel earlier.
So at the m
There is a problem with the html converted from the previous
commit 6047de5482c3 ("f2fs: add barrier mount option")
code submission. Probably something like this:
barrier If this option is set, cache_flush commands are
allowed to be
Let's fix it.
Signed-off-by: Yangtao L
Hi Jaegeuk,
>>> Again, w'd better to consider this functionality only when DEBUG_FS
>>> is enabled.
>>
>> BTW, why can't we use iostat to get the discard latencies?
>
> Agreed.
Let me spend some time on this. So, I guess this patch can't catch up with the
merge window.
And I still have some p
> I don't think this needs cleanup, other part looks good to me.
What is the point here comparing to the below? fyi; I picked this change.
>>>
>>> IIUC, the question is for Yangtao? :P
>>
>> Heh, to you. :) I think either looks fine. Hence,
>
> Ah... alright.
> I comment on this cl
> What do you think of extending this function to support io_counts?
>
> void f2fs_update_iostat(struct f2fs_sb_info *sbi, struct inode *inode,
> enum iostat_type type, unsigned long long io_bytes,
> unsigned long long io_counts)
Support to have extra i
Any of the following scenarios will send more than the number of
max_requests at a time, which will not meet the design of the
max_requests limit.
- Set max_ordered_discard larger than discard_granularity from userspace.
- It is a small size device, discard_granularity can be tuned to 1 in
f2fs_
Bagas Sanjaya 于2022年12月11日周日 21:20写道：
>
> On Sun, Dec 11, 2022 at 08:18:52PM +0800, Yuwei Guan wrote:
> > As the 'dcc->discard_granularity' and 'dcc->max_ordered_discard' can be set
> > at the user space, and if the 'dcc->max_ordered_discard' is set larger than
> > 'dcc->discard_granularity' in DP
16 matches
Mail list logo
