s/contaning/containing
s/clearning/clearing/
Signed-off-by: Bhaskar Chowdhury
---
fs/btrfs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 7cdf65be3707..e0c08176bc18 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@
In order to reply in plain text, I send the mail from Gmail.
Filipe Manana 於 2021年3月24日 週三 下午8:16寫道：
>
> On Wed, Mar 24, 2021 at 11:15 AM bingjingc wrote:
> >
> > From: BingJing Chang
> >
> > In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole in
> > a already existed hole."),
From: BingJing Chang
In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole
in a already existed hole."), existed holes can be skipped by calling
find_first_non_hole() to adjust *start and *len. However, if the given
len is invalid and large, when an EXTENT_MAP_HOLE extent is found
On 2021/3/25 上午2:09, Jim Geo wrote:
Hello,
Could you please elaborate on the relation between thread_pool and
physical devices?
By default thread_pool is scaling with the number of CPUs. Does the
default value make sense in cases where the physical devices are fewer
than the CPUs? For HDD? F
Hi,
btrfs-progs version 5.11.1 have been released. This is a bugfix release.
Changelog:
* properly format checksums when a mismatch is reported
* check: fix false alert on tree block crossing 64K page boundary
* convert:
* refuse to convert filesystem with 'needs_recovery'
* update
Hello,
Could you please elaborate on the relation between thread_pool and
physical devices?
By default thread_pool is scaling with the number of CPUs. Does the
default value make sense in cases where the physical devices are fewer
than the CPUs? For HDD? For SSD?
What is the relation between use
On Wed, Mar 24, 2021 at 2:26 PM Naohiro Aota wrote:
>
> Commit 6e37d2459941 ("btrfs: zoned: fix deadlock on log sync") pointed out
> a deadlock warning and removed
> mutex_{lock,unlock}(&fs_info->tree_root->log_mutex). While it looks like it
> always cause a deadlock, we didn't see actual deadlock
Commit 6e37d2459941 ("btrfs: zoned: fix deadlock on log sync") pointed out
a deadlock warning and removed
mutex_{lock,unlock}(&fs_info->tree_root->log_mutex). While it looks like it
always cause a deadlock, we didn't see actual deadlock in fstests runs. The
reason is log_root_tree->log_mutex != fs_
Vennligst jeg vil vite om du har mine tidligere meldinger.
Looking at perf data for a fio workload I noticed that we were spending
a pretty large chunk of time (around 5%) doing percpu_counter_sum() in
need_preemptive_reclaim. This is silly, as we only want to know if we
have more ordered than delalloc to see if we should be counting the
delayed items in
On Wed, Mar 24, 2021 at 11:15 AM bingjingc wrote:
>
> From: BingJing Chang
>
> In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole in
> a already existed hole."), existed holes can be skipped by calling
> find_first_non_hole() to adjust *start and *len. However, if the given
> l
From: BingJing Chang
In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole in
a already existed hole."), existed holes can be skipped by calling
find_first_non_hole() to adjust *start and *len. However, if the given
len is invalid and large, when an EXTENT_MAP_HOLE extent is found
On 2021/03/15 14:55, Naohiro Aota wrote:
> This commit moves the location of superblock logging zones. The location of
> the logging zones are determined based on fixed block addresses instead of
> on fixed zone numbers.
David,
Any comment on this ? It would be nice to get this settled in this cy
13 matches
Mail list logo
