[PATCH] test online label ioctl

This tests the online label ioctl that btrfs has, which has been recently proposed for XFS. To run, it requires an updated xfs_io with the label command and a filesystem that supports it A slight change here to _require_xfs_io_command as well, so that tests which simply fail with "Inappropriate

[PATCH] Btrfs: send, fix missing truncate for inode with prealloc extent past eof

From: Filipe Manana An incremental send operation can miss a truncate operation when an inode has an increased size in the send snapshot and a prealloc extent beyond its size. Consider the following scenario where a necessary truncate operation is missing in the incremental

Re: [PATCH] btrfs: rename btrfs_balance_control::flags to b_flags

On Mon, Apr 30, 2018 at 05:49:13PM +0800, Anand Jain wrote: > As flags is a generic name, its often difficult to search, rename > btrfs_balance_control::flags to btrfs_balance_control::b_flags. I don't think this one is necessary as it's always tied to bctl. -- To unsubscribe from this list: send

Re: Strange behavior (possible bugs) in btrfs

Hi Jeff, On Mon, Apr 30, 2018 at 11:51 AM, Jeff Mahoney wrote: > On 4/30/18 12:04 PM, Vijay Chidambaram wrote: >> Hi, >> >> We found two more cases where the btrfs behavior is a little strange. >> In one case, an fsync-ed file goes missing after a crash. In the >> other, a

Re: Strange behavior (possible bugs) in btrfs

On 4/30/18 12:04 PM, Vijay Chidambaram wrote: > Hi, > > We found two more cases where the btrfs behavior is a little strange. > In one case, an fsync-ed file goes missing after a crash. In the > other, a renamed file shows up in both directories after a crash. Hi Vijay - What kernel version did

Strange behavior (possible bugs) in btrfs

Hi, We found two more cases where the btrfs behavior is a little strange. In one case, an fsync-ed file goes missing after a crash. In the other, a renamed file shows up in both directories after a crash. Workload 1: mkdir A mkdir B mkdir A/C creat B/foo fsync B/foo link B/foo A/C/foo fsync A

[PATCH 2/3] btrfs-progs: build: autoconf 2.63 compatibility

From: Jeff Mahoney Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking) started m4_chomp to strip the newlines from the version file. m4_chomp was introduced in autoconf 2.64 but SLE11 ships with autoconf 2.63. For purposes of just stripping the newline, m4_flatten

[PATCH 1/3] btrfs-progs: convert: fix support for e2fsprogs < 1.42

From: Jeff Mahoney Commit 324d4c1857a (btrfs-progs: convert: Add larger device support) introduced new dependencies on the 64-bit API provided by e2fsprogs. That API was introduced in v1.42 (along with bigalloc). This patch maps the following to their equivalents in e2fsprogs <

[PATCH 3/3 v2] btrfs-progs: build: detect whether -std=gnu90 is supported

From: Jeff Mahoney GCC releases prior to 4.5.0 don't support -std=gnu90 so btrfs-progs won't build at all on older distros. We can detect whether the compiler supports -std=gnu90 and fall back to -std=gnu89 if it doesn't. AX_CHECK_COMPILE_FLAG is the right way to do this, but

Re: Inconsistent behavior of fsync in btrfs

On 29 Apr 2018, at 18:16, Theodore Y. Ts'o wrote: On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: In the spirit of clarifying fsync behavior, we have one more case where we'd like to find out what should be expected. Consider this: Mkdir A Creat A/bar Fsync A/bar Rename

Re: [PATCH v2] btrfs: fix BUG trying to resume balance without resume flag

Hi Anand, Thank you for the patch! Yet something to improve: [auto build test ERROR on btrfs/next] [also build test ERROR on v4.17-rc3 next-20180430] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2] btrfs: fix BUG trying to resume balance without resume flag

Hi Anand, Thank you for the patch! Yet something to improve: [auto build test ERROR on btrfs/next] [also build test ERROR on v4.17-rc3 next-20180430] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH 1/3] btrfs: qgroups, fix rescan worker running races

On 4/30/18 2:20 AM, Qu Wenruo wrote: > > > On 2018年04月27日 03:23, je...@suse.com wrote: >> From: Jeff Mahoney >> >> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) >> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but >> ended up reintroducing

[PATCH] btrfs: rename btrfs_balance_control::flags to b_flags

As flags is a generic name, its often difficult to search, rename btrfs_balance_control::flags to btrfs_balance_control::b_flags. Signed-off-by: Anand Jain --- fs/btrfs/ioctl.c | 10 +- fs/btrfs/volumes.c | 30 +++--- fs/btrfs/volumes.h |

[PATCH v2] btrfs: fix BUG trying to resume balance without resume flag

We set the BTRFS_BALANCE_RESUME flag in the btrfs_recover_balance(), which is not called during the remount. So when resuming from the paused balance we hit BUG. kernel: kernel BUG at fs/btrfs/volumes.c:3890! :: kernel: balance_kthread+0x51/0x60 [btrfs] kernel: kthread+0x111/0x130 ::

[PATCH] btrfs: trace: Allow trace_qgroup_update_counters() to record old rfer/excl value

Origin trace_qgroup_update_counters() only records qgroup id and its reference count change. It's good enough to debug qgroup accounting change, but when rescan race is involved, it's pretty hard to distinguish which modification belongs to which rescan. So add old_rfer and old_excl trace output

[PATCH 1/2] btrfs-progs: check: Make btrfs check return error for qgroup mismatch

Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0. Fix it by allowing report_qgroups() to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful. Without this patch,

[PATCH 1/2] btrfs-progs: check: Make btrfs check return error for qgroup mismatch

Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0. Fix it by allowing report_qgroups() to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful. Without this patch,

[PATCH 2/2] btrfs-progs: fsck-tests: Add test case to ensure btrfs check return error for corrupted qgroups

Since the test case uses run_mustfail(), which is pretty easy pass due to other unexpected problems, so here an extra run_check() is added to ensure we don't only report qgroup error, but also fix it without problem. Signed-off-by: Qu Wenruo ---

Re: [PATCH 1/3] btrfs: qgroups, fix rescan worker running races

On 2018年04月27日 03:23, je...@suse.com wrote: > From: Jeff Mahoney > > Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) > fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but > ended up reintroducing the hang-on-unmount bug that the commit it >

[PATCH 2/2] btrfs-progs: fsck-tests: Add test case to ensure btrfs check return error for corrupted qgroups

Since the test case uses run_mustfail(), which is pretty easy pass due to other unexpected problems, so here an extra run_check() is added to ensure we don't only report qgroup error, but also fix it without problem. Signed-off-by: Qu Wenruo ---