Signed-off-by: Brian Foster
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8754ac2c259d..128bf05e981c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3672,7 +3672,6 @@ F:drivers/md/bcache/
BCACHEFS
M: Kent Overstreet
-R
the structure.
Fixes: cde738a61e65 ("bcachefs: Convert bch2_ioctl_fs_usage() to new
accounting")
Reported-by: Dan Carpenter
Signed-off-by: Brian Foster
---
fs/bcachefs/chardev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/bcachefs/chardev.c b/fs/bcachefs/chard
On Mon, May 27, 2024 at 01:18:23AM +0100, Al Viro wrote:
> On Mon, May 27, 2024 at 07:51:39AM +0800, Ian Kent wrote:
>
> > Indeed, that's what I found when I had a quick look.
> >
> >
> > Maybe a dentry (since that's part of the subject of the path walk and inode
> > is readily
> >
> >
On Mon, May 13, 2024 at 11:42:42PM +, Reed Riley wrote:
> On Monday, May 13th, 2024 at 5:34 AM, Brian Foster wrote:
>
> > On Sat, May 11, 2024 at 12:20:12AM +, Reed Riley wrote:
> >
> > > By removing the early-exit when REMAP_FILE_DEDUP is set, we shou
efs. Extent comparison logic already exists inside of
> `__generic_remap_file_range_prep`.
>
> Signed-off-by: Reed Riley
> ---
Seems reasonable:
Reviewed-by: Brian Foster
Have you run any tests just to make sure there are no surprises? If not,
it looks like xfs_io has a 'dedupe'
ethod to indicate support for direct I/O.
> Do that for bcachefs so that noop_direct_IO can eventually be removed.
>
> Similar to commit b29434999371 ("xfs: set FMODE_CAN_ODIRECT instead of
> a dummy direct_IO method").
>
> Signed-off-by: Youling Tang
> ---
Seems stra
gned-off-by: Petr Vorel
> ---
I was thinking you'd just rename the STATFS_MAGIC def locally as well,
but whatever.. LGTM, thanks for the tweaks!
Acked-by: Brian Foster
> Changes v2->v3:
> * Align tab with other entries.
>
> Changes v1->v2 (all suggested by Brian Foster -
On Tue, May 07, 2024 at 01:11:24PM +0200, Petr Vorel wrote:
> There are other bcachefs magic definitions: BCACHE_MAGIC, BCHFS_MAGIC,
> which use UUID_INIT() and are used only in libbcachefs. Therefore move
> to only BCACHEFS_STATFS_MAGIC, which can be used outside
> of libbcachefs for f_type
into a
bch2_fiemap_extent() helper that takes the current key and formats
the bch_fiemap_extent appropriately for the fill function.
No functional changes intended by this patch.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 90 +---
1 file changed, 55
with btrfs
and it is recommended to use the sync flag for the most up to date
extent state from fiemap.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 119 ---
1 file changed, 112 insertions(+), 7 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index f6cd14c9b38c..8b806e33c6c9 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -1011,6 +1011,7 @@ static int bch2_fiemap(struct
FIEMAP_FLAG_SYNC handling was deliberately moved into core code in
commit 45dd052e67ad ("fs: handle FIEMAP_FLAG_SYNC in fiemap_prep"),
released in kernel v5.8. Update bcachefs accordingly.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 2 +-
1 file changed, 1 insertion(+),
/20231219140215.300753-1-bfos...@redhat.com/
Brian Foster (4):
bcachefs: drop duplicate fiemap sync flag
bcachefs: track current fiemap offset in start variable
bcachefs: refactor fiemap processing into extent helper and struct
bcachefs: add fiemap delalloc extent detection
fs/bcachefs/fs.c | 207
On Mon, Apr 08, 2024 at 10:48:46AM -0400, Brian Foster wrote:
> bcachefs currently populates fiemap data from the extents btree.
> This works correctly when the fiemap sync flag is provided, but if
> not, it skips all delalloc extents that have not yet been flushed.
> This is beca
metadata performance testing
without the overhead of actual data I/O.
Signed-off-by: Brian Foster
---
fs/iomap/buffered-io.c | 21 +
include/linux/iomap.h | 1 +
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
without blowing up.
Signed-off-by: Brian Foster
---
fs/xfs/xfs_iomap.c | 3 +++
fs/xfs/xfs_mount.h | 2 ++
fs/xfs/xfs_super.c | 6 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 4087af7f3c9f..9b71a649e106 100644
--- a/fs/xfs
This is a small cleanup to facilitate a nosubmit iomap flag. No
functional changes intended.
Signed-off-by: Brian Foster
---
fs/iomap/buffered-io.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered
is simple enough as it is and not really
worth the additional polishing for the latter, but I offered to at least
rebase and post for discussion. Thoughts, reviews, flames appreciated.
Brian
Brian Foster (3):
iomap: factor out a bio submission helper
iomap: add nosubmit flag to skip data I/O
On Mon, Apr 08, 2024 at 11:33:05PM -0400, Kent Overstreet wrote:
> On Mon, Apr 08, 2024 at 10:48:42AM -0400, Brian Foster wrote:
> > Hi all,
> >
> > Here's v3 of the fiemap delalloc support patches for bcachefs. The main
> > difference from v2 is that the pagecac
On Wed, Apr 03, 2024 at 03:22:52AM -0400, Sweet Tea Dorminy wrote:
> Signed-off-by: Sweet Tea Dorminy
> ---
> fs/bcachefs/fs.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
> index f830578a9cd1..d2793bae842d
On Wed, Apr 03, 2024 at 03:22:52AM -0400, Sweet Tea Dorminy wrote:
> Signed-off-by: Sweet Tea Dorminy
> ---
> fs/bcachefs/fs.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
> index f830578a9cd1..d2793bae842d
On Wed, Apr 03, 2024 at 03:22:43AM -0400, Sweet Tea Dorminy wrote:
> Update the signature of fiemap_fill_next_extent() to allow passing a
> physical length. Update all callers to pass a 0 physical length -- since
> none set the EXTENT_HAS_PHYS_LEN flag, this value doesn't matter.
>
>
On Wed, Apr 03, 2024 at 03:22:43AM -0400, Sweet Tea Dorminy wrote:
> Update the signature of fiemap_fill_next_extent() to allow passing a
> physical length. Update all callers to pass a 0 physical length -- since
> none set the EXTENT_HAS_PHYS_LEN flag, this value doesn't matter.
>
>
On Wed, Apr 03, 2024 at 03:22:42AM -0400, Sweet Tea Dorminy wrote:
> Some filesystems support compressed extents which have a larger logical
> size than physical, and for those filesystems, it can be useful for
> userspace to know how much space those extents actually use. For
> instance, the
On Wed, Apr 03, 2024 at 03:22:42AM -0400, Sweet Tea Dorminy wrote:
> Some filesystems support compressed extents which have a larger logical
> size than physical, and for those filesystems, it can be useful for
> userspace to know how much space those extents actually use. For
> instance, the
On Wed, Mar 20, 2024 at 02:29:23PM +0800, Hongbo Li wrote:
> UPTODATE means btree_path is useable, so here use
> btree_path_is_uptodate to check this status. And the old
> function btree_path_set_dirty cannot represent what it really
> does (such as if UPTODATE is passed into it, btree_path
On Wed, Mar 20, 2024 at 02:29:22PM +0800, Hongbo Li wrote:
> First, the old structure cannot clearly represent the state changes
> of btree_path (such as BTREE_ITER_xxx). Secondly, the member (
> btree_path->uptodate) cannot express its purpose intuitively. It's
> essentially a state value if I
On Sat, Mar 09, 2024 at 12:14:23PM +0800, Hou Tao wrote:
> Hi,
>
> On 2/29/2024 11:01 PM, Brian Foster wrote:
> > On Wed, Feb 28, 2024 at 10:41:24PM +0800, Hou Tao wrote:
> >> From: Hou Tao
> >>
> >> When reading a file kept in virtiofs from
On Thu, Feb 29, 2024 at 04:16:00PM -0500, Kent Overstreet wrote:
> On Thu, Feb 29, 2024 at 01:44:27PM -0500, Brian Foster wrote:
> > On Wed, Feb 28, 2024 at 11:10:12PM -0500, Kent Overstreet wrote:
> > > I think it ended up not needing to be moved, and I just forgot to drop
>
On Thu, Feb 29, 2024 at 04:24:37PM -0500, Kent Overstreet wrote:
> On Thu, Feb 29, 2024 at 01:43:15PM -0500, Brian Foster wrote:
> > Hmm.. I think the connection I missed on first look is basically
> > disk_accounting_key_to_bpos(). I think what is confusing is that calling
> >
On Wed, Feb 28, 2024 at 11:10:12PM -0500, Kent Overstreet wrote:
> On Tue, Feb 27, 2024 at 10:55:02AM -0500, Brian Foster wrote:
> > On Sat, Feb 24, 2024 at 09:38:06PM -0500, Kent Overstreet wrote:
> > > Main part of the disk accounting rewrite.
> > >
> &
On Wed, Feb 28, 2024 at 05:42:39PM -0500, Kent Overstreet wrote:
> On Tue, Feb 27, 2024 at 10:50:23AM -0500, Brian Foster wrote:
> > On Sat, Feb 24, 2024 at 09:38:05PM -0500, Kent Overstreet wrote:
> > > + if (!*accounting_accumulated && wb->k.
On Wed, Feb 28, 2024 at 02:39:38PM -0500, Kent Overstreet wrote:
> On Tue, Feb 27, 2024 at 10:49:19AM -0500, Brian Foster wrote:
> > On Sat, Feb 24, 2024 at 09:38:03PM -0500, Kent Overstreet wrote:
> > > New key type for the disk space accounting rewrite.
> > >
>
On Wed, Feb 28, 2024 at 09:59:12PM -0500, Kent Overstreet wrote:
> On Wed, Feb 28, 2024 at 07:02:39PM -0500, Kent Overstreet wrote:
> > On Wed, Feb 28, 2024 at 03:13:04PM -0500, Brian Foster wrote:
> > > On Wed, Feb 28, 2024 at 03:03:06PM -0500, Kent Overstreet wrote:
> >
On Wed, Feb 28, 2024 at 10:41:24PM +0800, Hou Tao wrote:
> From: Hou Tao
>
> When reading a file kept in virtiofs from kernel (e.g., insmod a kernel
> module), if the cache of virtiofs is disabled, the read buffer will be
> passed to virtiofs through out_args[0].value instead of pages. Because
>
On Wed, Feb 28, 2024 at 03:03:06PM -0500, Kent Overstreet wrote:
> On Wed, Feb 28, 2024 at 02:47:26PM -0500, Brian Foster wrote:
> > Hi Kent,
> >
> > Firstly, I confirmed that today's master seems to avoid the splat I sent
> > previously (re: your comment about a r
Hi Kent,
Firstly, I confirmed that today's master seems to avoid the splat I sent
previously (re: your comment about a reverse journal replay patch or
some such).
I still reproduce the stall issue on this system. After peeling away at
it, I was eventually able to reproduce without the drop
On Sat, Feb 24, 2024 at 09:38:03PM -0500, Kent Overstreet wrote:
> New key type for the disk space accounting rewrite.
>
> - Holds a variable sized array of u64s (may be more than one for
>accounting e.g. compressed and uncompressed size, or buckets and
>sectors for a given data type)
>
On Sat, Feb 24, 2024 at 09:38:06PM -0500, Kent Overstreet wrote:
> Main part of the disk accounting rewrite.
>
> This is a wholesale rewrite of the existing disk space accounting, which
> relies on percepu counters that are sharded by journal buffer, and
> rolled up and added to each journal
On Sat, Feb 24, 2024 at 09:38:05PM -0500, Kent Overstreet wrote:
> Teach the btree write buffer how to accumulate accounting keys - instead
> of having the newer key overwrite the older key as we do with other
> updates, we need to add them together.
>
> Also, add a flag so that write buffer
On Sat, Feb 24, 2024 at 09:38:04PM -0500, Kent Overstreet wrote:
> Until accounting keys hit the btree, they are deltas, not new versions
> of the existing key; this means we have to teach journal replay to
> accumulate them.
>
> Additionally, the journal doesn't track precisely which entries
On Wed, Feb 21, 2024 at 07:07:37PM -0500, Kent Overstreet wrote:
> On Wed, Feb 21, 2024 at 07:39:49AM -0500, Brian Foster wrote:
> > On Fri, Feb 16, 2024 at 10:57:24AM -0500, Kent Overstreet wrote:
> > > On Fri, Feb 16, 2024 at 07:40:34AM -0500, Brian Foster wrote:
> >
fs/bcachefs/super-io.c:806:2: warning: Value stored to 'ret' is
> never read [deadcode.DeadStores]
>
> Signed-off-by: Colin Ian King
> ---
Reviewed-by: Brian Foster
> fs/bcachefs/super-io.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/bcachefs/super-io.c b/f
return ret;
> + return ret < 0 ?: -EINVAL;
It might be nice for that error message to be more specific in that the
bool value must be 0 or 1, but LGTM regardless:
Reviewed-by: Brian Foster
> }
> break;
> case BCH_OPT_UINT:
> --
> 2.34.1
>
On Fri, Feb 16, 2024 at 10:57:24AM -0500, Kent Overstreet wrote:
> On Fri, Feb 16, 2024 at 07:40:34AM -0500, Brian Foster wrote:
> > On Fri, Feb 16, 2024 at 09:00:17AM +0100, Christoph Hellwig wrote:
> > > On Thu, Feb 15, 2024 at 07:24:23PM -0500, Kent Overstreet wrote:
>
On Fri, Feb 16, 2024 at 09:00:17AM +0100, Christoph Hellwig wrote:
> On Thu, Feb 15, 2024 at 07:24:23PM -0500, Kent Overstreet wrote:
> > > It looks like the warning could be avoided in bcachefs by checking for
> > > whether the parent dir/node still exists at cleanup time, but I'm not
> > >
On Thu, Feb 15, 2024 at 09:19:57AM -0700, Thomas Bertschinger wrote:
> This is needed for building Rust bindings on big endian architectures
> like s390x. Currently this is only done in userspace, but it might
> happen in-kernel in the future. When creating a Rust binding for struct
> bkey, the
unt if the block size happens to be large
enough. This is triggered by fstest generic/361 with a 4k block
size, which subsequently leads to a crash. To avoid this crash,
check that the shorten length doesn't exceed the overall length of
the iter.
Signed-off-by: Brian Foster
---
Ok, I think
cc linux-block
On Thu, Feb 01, 2024 at 03:52:56PM -0600, Tony Asleson wrote:
> Fedora 39 with 6.7 kernel with bcachefs support
>
> Steps
> 1. I created the bcachefs (using locally compiled git repo
> f15633cce1b79e708e9debc21c7b8772df7c7a29)
> # bcachefs format --replicas=2 /dev/sd[bcdej]
> 2.
On Fri, Feb 09, 2024 at 10:39:43AM +0800, Su Yue wrote:
>
> On Mon 05 Feb 2024 at 14:38, Brian Foster wrote:
>
> > On Mon, Feb 05, 2024 at 02:15:36PM -0500, Kent Overstreet wrote:
> > > On Mon, Feb 05, 2024 at 10:48:14AM -0500, Brian Foster wrote:
> > &g
On Mon, Feb 05, 2024 at 02:15:36PM -0500, Kent Overstreet wrote:
> On Mon, Feb 05, 2024 at 10:48:14AM -0500, Brian Foster wrote:
> > bch2_direct_IO_read() checks the request offset and size for sector
> > alignment and then falls through to a couple calculations to shri
ted value, so simplify things and avoid the underflow problem by
removing it.
Signed-off-by: Brian Foster
---
Note that I left the ret variable name alone because it seemed to
bother me less after we realized it is actually the dio return
value.
Brian
fs/bcachefs/fs-io-direct.c | 6 --
1 f
given in
> local.config or _scratch_mkfs_sized parameter.
> v2:
> Born.
> ---
This LGTM, appreciate the tweaks and discussion:
Reviewed-by: Brian Foster
> common/rc | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/common/rc b/co
On Mon, Jan 29, 2024 at 10:01:01PM +0800, Su Yue wrote:
> From: Su Yue
>
> mkfs.bcachefs now supports option '--block_size' to allow
> custom block_size.
>
> Add the pattern to set def_blksz if MKFS_OPTIONS contains the
> option in _scratch_mkfs_sized.
> Also let mkfs.bcachefs decide blocksize
On Thu, Jan 25, 2024 at 10:10:48AM +0800, Su Yue wrote:
>
> On Mon 22 Jan 2024 at 10:20, Brian Foster wrote:
>
> > On Sun, Jan 21, 2024 at 12:00:47PM +0800, Su Yue wrote:
> > >
> > > On Fri 19 Jan 2024 at 11:09, Brian Foster
> > > wrote:
> > >
On Sun, Jan 21, 2024 at 12:00:47PM +0800, Su Yue wrote:
>
> On Fri 19 Jan 2024 at 11:09, Brian Foster wrote:
>
> > On Thu, Jan 18, 2024 at 10:59:14AM +0800, Su Yue wrote:
> > >
> > > On Wed 17 Jan 2024 at 12:55, Brian Foster
> > > wrote:
> > >
On Thu, Jan 18, 2024 at 10:59:14AM +0800, Su Yue wrote:
>
> On Wed 17 Jan 2024 at 12:55, Brian Foster wrote:
>
> > On Wed, Jan 17, 2024 at 05:23:09PM +0800, Su Yue wrote:
> > > For bcachefs, def_blksz is never assigned even MKFS_OPTIONS contains
> > > option
&g
On Wed, Jan 17, 2024 at 05:23:09PM +0800, Su Yue wrote:
> For bcachefs, def_blksz is never assigned even MKFS_OPTIONS contains option
> '--block_size'. So block size of bcachefs on scratch dev is always 4096
> if _scratch_mkfs_sized is called without second parameter.
>
> Add the pattern to set
iff --git a/common/rc b/common/rc
> index 524ffa02aa6a..31c21d2a8360 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -611,6 +611,9 @@ _test_mkfs()
> xfs)
> $MKFS_PROG -t $FSTYP -- -f $MKFS_OPTIONS $* $TEST_DEV
> ;;
> +bcachefs)
> +$MKFS_BCACHEFS_PR
FIEMAP_FLAG_SYNC handling was deliberately moved into core code in
commit 45dd052e67ad ("fs: handle FIEMAP_FLAG_SYNC in fiemap_prep"),
released in kernel v5.8. Update bcachefs accordingly.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 2 +-
1 file changed, 1 insertion(+),
into a
bch2_fiemap_extent() helper that takes the current key and formats
the bch_fiemap_extent appropriately for the fill function.
No functional changes intended by this patch.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 90 +---
1 file changed, 55
://lore.kernel.org/linux-bcachefs/20231219140215.300753-1-bfos...@redhat.com/
Brian Foster (4):
bcachefs: drop duplicate fiemap sync flag
bcachefs: track current fiemap offset in start variable
bcachefs: refactor fiemap processing into extent helper and struct
bcachefs: add fiemap delalloc
with btrfs
and it is recommended to use the sync flag for the most up to date
extent state from fiemap.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 64 ++--
1 file changed, 57 insertions(+), 7 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index 696f266febfe..c9f426905ef9 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -945,6 +945,7 @@ static int bch2_fiemap(struct
On Wed, Jan 17, 2024 at 12:20:55PM +0800, Su Yue wrote:
>
> On Tue 16 Jan 2024 at 12:33, Kent Overstreet
> wrote:
>
> > On Tue, Jan 16, 2024 at 12:24:48PM -0500, Brian Foster wrote:
> > > On Tue, Jan 16, 2024 at 12:03:09PM -0500, Kent Overstreet wrote:
> > >
On Tue, Jan 16, 2024 at 12:03:09PM -0500, Kent Overstreet wrote:
> On Tue, Jan 16, 2024 at 10:33:08AM -0500, Brian Foster wrote:
> > Hi Kent,
> >
> > JFYI, I'm seeing the following splat pretty reliably via generic/361 on
> > an 80xcpu test box. The CI doesn't s
On Tue, Jan 16, 2024 at 10:10:53PM +0800, Su Yue wrote:
>
> On Tue 16 Jan 2024 at 08:47, Brian Foster wrote:
>
> > On Mon, Jan 15, 2024 at 10:21:25AM +0800, Su Yue wrote:
> > > When I was testing mongodb over bcachefs with compression,
> > > there is a lockdep
Hi Kent,
JFYI, I'm seeing the following splat pretty reliably via generic/361 on
an 80xcpu test box. The CI doesn't seem to produce this failure for
whatever reason. This bisects down to commit 023f9ac9f70f ("bcachefs:
Delete dio read alignment check"), before which the test still fails but
the
to bubble back through kthread_stop(). That said, we don't check for
error there either (i.e. bch2_rebalance_stop()), so this seems
reasonable enough to me to address the warning:
Reviewed-by: Brian Foster
> ;
>
> bch2_moving_ctxt_exit();
> --
> 2.39.2
>
843552 ] deactivate_locked_super+0x2f/0xa0
> [ 406.843756 ] cleanup_mnt+0xba/0x150
> [ 406.843917 ] task_work_run+0x59/0xa0
> [ 406.844083 ] exit_to_user_mode_prepare+0x197/0x1a0
> [ 406.844302 ] syscall_exit_to_user_mode+0x16/0x40
> [ 406.844510 ] do_syscall_64+0x4e/0xf0
>
On Mon, Jan 15, 2024 at 10:21:25AM +0800, Su Yue wrote:
> When I was testing mongodb over bcachefs with compression,
> there is a lockdep warning when snapshotting mongodb data volume.
>
> $ cat test.sh
> prog=bcachefs
>
> $prog subvolume create /mnt/data
> $prog subvolume create
On Sun, Jan 14, 2024 at 12:41:20PM +0800, Su Yue wrote:
> mkfs.bcachefs supports force overwrite when option '-f' is given:
> $ mkfs.bcachefs --help | grep force
> -f, --force
> After this commit, MKFS_BCACHEFS_PROG will contains ' -f' so
> we don't have to add '-f' to $MKFS_OPTIONS manually.
>
On Mon, Jan 08, 2024 at 02:34:43PM -0800, Carl E. Thompson wrote:
> I'm not a kernel developer so feel free to ignore this.
>
> > On 2024-01-08 7:33 AM PST Brian Foster wrote:
>
> > ...
>
> > 3. Logistically, this is likely to be a bit awkward for pretty much
&
On Thu, Jan 04, 2024 at 06:41:26PM -0500, Kent Overstreet wrote:
> +cc btrfs folks
>
-cc btrfs folks ;) (for unrelated discussion mostly around the variable
declaration thing...)
> On Thu, Jan 04, 2024 at 07:12:47AM -0500, Brian Foster wrote:
> > On Tue, Dec 19, 2023 at 06:57:4
ter_hwframe+0x6e/0x76
>
> Fix it by copy pointer dev_name at beginning and free the copied
> pointer at end.
>
> Signed-off-by: Su Yue
> ---
> changelog:
> v3:
> Add the missing the memleak report.
> v2:
> Remove the unnecessary assignment.
> ---
LG
On Sun, Jan 07, 2024 at 03:05:59PM +0800, Su Yue wrote:
> The pointer dev_name can be modified by strseq(),
> then causes the memleak:
>
> unreferenced object 0x9d08a2916c80 (size 32):
> comm "mount.bcachefs", pid 9090, jiffies 4295856224 (age 17.564s)
> hex dump (first 32 bytes):
>
On Tue, Dec 19, 2023 at 06:57:42PM -0500, Kent Overstreet wrote:
> On Tue, Dec 19, 2023 at 09:02:14AM -0500, Brian Foster wrote:
> > bcachefs currently populates fiemap data from the extents btree.
> > This works correctly when the fiemap sync flag is provided, but if
> &
On Tue, Dec 19, 2023 at 03:55:38PM -0500, Kent Overstreet wrote:
> On Tue, Dec 19, 2023 at 08:01:59AM -0500, Brian Foster wrote:
> > On Sat, Dec 16, 2023 at 09:51:40AM +0800, Kevin Hao wrote:
> > > In the macro kthread_wait_freezable(), there is already a check for
> > >
-by: Brian Foster
---
fs/bcachefs/fs.c | 60
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index bc280a0a957d..0b3b35092818 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -868,6 +868,41
to be addressed
with these patches, I'll pick it back up after the New Year.
Brian Foster (2):
bcachefs: add fiemap delalloc extent detection
bcachefs: clean up some dead fallocate code
fs/bcachefs/fs.c | 60 ---
fs/bcachefs/io_misc.c | 35
some of the unnecessary logic and
code.
Signed-off-by: Brian Foster
---
fs/bcachefs/io_misc.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/fs/bcachefs/io_misc.c b/fs/bcachefs/io_misc.c
index eab0c8c57785..521c32554dd0 100644
--- a/fs
o
> ---
Looks right to me:
Reviewed-by: Brian Foster
> fs/bcachefs/movinggc.c | 3 +--
> fs/bcachefs/rebalance.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/bcachefs/movinggc.c b/fs/bcachefs/movinggc.c
> index fd239a261aca..bc1ec877a66b 1
Hi all,
So we've been seeing an occasional failure of generic/243 that seems to
be caused by a userspace fsck crash. This is not the most reproducible
failure as it seems to require hundreds of iterations. The test failure
generally looks like this:
_check_generic_filesystem: filesystem on
On Wed, Dec 06, 2023 at 03:33:09PM -0500, Kent Overstreet wrote:
> This adds a new ioctl for running fsck on a list of devices.
>
> Normally, if we wish to use the kernel's implementation of fsck we'd run
> it at mount time with -o fsck. This ioctl lets us run fsck without
> mounting, so that
On Wed, Dec 06, 2023 at 03:33:08PM -0500, Kent Overstreet wrote:
> Add a new helper for running online recovery passes - i.e. online fsck.
> This is a subset of our normal recovery passes, and does not - for now -
> use or follow c->curr_recovery_pass.
>
> Signed-off-by: Kent Overstreet
> ---
>
On Wed, Dec 06, 2023 at 03:33:06PM -0500, Kent Overstreet wrote:
> Upcoming patches are going to add two new ioctls for running fsck in the
> kernel, but pretending that we're running our normal userspace fsck.
>
> This patch adds some plumbing for redirecting our normal log messages
> away from
On Wed, Dec 06, 2023 at 05:42:09PM -0500, Kent Overstreet wrote:
> On Wed, Dec 06, 2023 at 02:01:02PM -0500, Brian Foster wrote:
> > On Wed, Dec 06, 2023 at 10:26:14AM +1100, Steve Smith wrote:
> > > Hi Brian,
> > >
> > > Thanks for the suggestion. Y
extents that would be
> contiguous on some other FSs, but that's fine here.
>
> Thanks,
> Steve
>
>
>
> On Wed, 6 Dec 2023 at 01:53, Brian Foster wrote:
> >
> > On Tue, Dec 05, 2023 at 04:26:40PM +1100, Steve Smith wrote:
> > > Hi,
> > >
>
On Tue, Dec 05, 2023 at 04:26:40PM +1100, Steve Smith wrote:
> Hi,
>
> I'm doing some testing of xcp[1] against bcachefs, and having issues
> with fiemap. Using fiemap on both sparse and non-sparse files always
> returns `mapped_extents` of 0. The same tests on other extent-based
> FSs return
Skip the read write transition if the fs is shutdown. This allows
the fs to unfreeze at the vfs level so writes will no longer block,
but will still fail due to the emergency read-only state of the fs.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs.c | 3 +++
1 file changed, 3 insertions(+)
data I/O errors
on single disk errors without triggering high level metadata errors.
This might be another option worth considering for bcachefs if we can do
something similar...
Thoughts, reviews, flames appreciated.
Brian
[1] https://lore.kernel.org/linux-bcachefs/Y+EduoshRHXec+XU@bfoster/
Brian
the unnecessary shutdowns and allows the test to pass reliably on
bcachefs.
Signed-off-by: Brian Foster
---
fs/bcachefs/fs-io.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/bcachefs/fs-io.c b/fs/bcachefs/fs-io.c
index 31f40e587a4f..98bd5babab19 100644
On Thu, Nov 30, 2023 at 09:00:06PM -0500, Kent Overstreet wrote:
> On Thu, Nov 30, 2023 at 02:17:11PM -0500, Brian Foster wrote:
> > bcachefs grabs s_umount and sets SB_RDONLY when the fs is shutdown
> > via the ioctl() interface. This has a couple issues related to
> >
in reconfigure_super(). Drop the unnecessary sb
lock and flags update bch2_ioc_goingdown() to address both of these
issues.
Signed-off-by: Brian Foster
---
This is currently churning through CI here (though I had already pushed
an early version that ran clean):
https://evilpiepirate.org
Even though the blkid wipe has been fixed to detect and wipe old
superblocks, we still incorrectly skip the wipe when in force mode.
Update the force logic in open_for_format() to bypass the user
request and otherwise proceed with the wipe.
Signed-off-by: Brian Foster
---
tools-util.c | 11
On Fri, Nov 17, 2023 at 02:14:34PM -0800, Darrick J. Wong wrote:
> On Fri, Nov 17, 2023 at 09:43:17AM -0500, Brian Foster wrote:
> > generic/459 occasionally fails on bcachefs because the deliberately
> > induced I/O errors caused by exhausting the overprovisioned thin
&g
ext4
error handling sequence, this can be tweaked to serve double duty
and also more accurately detect read-only status on bcachefs.
Refactor into a small helper, check for an EROFS return to the touch
command, and consider the fs read-only if either that or the mount
entry check indicates it.
Signed-off
ted reason.
Signed-off-by: Brian Foster
---
tools-util.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools-util.c b/tools-util.c
index 923a666..7d4a3c1 100644
--- a/tools-util.c
+++ b/tools-util.c
@@ -232,7 +232,10 @@ int open_for_format(struct dev_opts *dev,
devices might be lvm or
device-mapper based.
The default behavior for show_vfsmnt() appers to be to use the
string passed to alloc_vfsmnt(), so tweak bcachefs to copy the path
at device superblock read time and to display it via
->show_devname().
Signed-off-by: Brian Foster
---
I was look
On Fri, Nov 10, 2023 at 11:31:44AM -0500, Kent Overstreet wrote:
> Journal replay now first attempts to replay keys in sorted order,
> similar to how the btree write buffer flush path works.
>
> Any keys that can not be replayed due to journal deadlock are then left
> for later and replayed in
1 - 100 of 1153 matches
Mail list logo
