Re: Btrfs broken in massive transfar

On 2018年03月13日 12:19, MASAKI haruka wrote: > *Now* I tried with Linux 4.14 and 4.15. > I experienced same probrem and reported in 2014 with Linux 3.9 and 3.10. > (Perchance, actually the kernel was newer than 3.10, anyway I experienced > same probrem with old 3.x kernel.) Then kernel message

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds wrote: > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton > wrote: >> >> Replacing the __builtin_choose_expr() with ?: works of course. > > Hmm. That sounds like the right thing to do. We were

Re: Btrfs broken in massive transfar

*Now* I tried with Linux 4.14 and 4.15. I experienced same probrem and reported in 2014 with Linux 3.9 and 3.10. (Perchance, actually the kernel was newer than 3.10, anyway I experienced same probrem with old 3.x kernel.) > > > On 2018年03月13日 05:57, MASAKI haruka wrote: > > I'm trying to

Re: Btrfs broken in massive transfar

On 2018年03月13日 05:57, MASAKI haruka wrote: > I'm trying to clone 18TiB data between btrfs, > but it will crash anyway. > > This probrem is occured even how to clone (btrfs send/receive, rsync or cp.) > I experienced same probrem in Linux 3.9 and Linux 3.10. Did you really mean *3*.9 and

[PATCH v2 1/7] btrfs-progs: convert/ext2: Fix inline extent creation check

Signed-off-by: Qu Wenruo --- convert/source-ext2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/convert/source-ext2.c b/convert/source-ext2.c index b1492c78693d..e13fbe00415a 100644 --- a/convert/source-ext2.c +++ b/convert/source-ext2.c @@ -310,7 +310,7 @@

[PATCH v2 2/7] btrfs-progs: convert/reiserfs: Fix inline file extent creation check

Signed-off-by: Qu Wenruo --- convert/source-reiserfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/convert/source-reiserfs.c b/convert/source-reiserfs.c index 39d6f0728bd3..eeb68d962c5d 100644 --- a/convert/source-reiserfs.c +++

[PATCH v2 7/7] btrfs-progs: test/mkfs: Add test case for rootdir inline extent size

Add a test case for mkfs --rootdir, using files with different file sizes to check if invalid large inline extent could exist. Signed-off-by: Qu Wenruo --- tests/mkfs-tests/014-rootdir-inline-extent/test.sh | 81 ++ 1 file changed, 81 insertions(+) create

[PATCH v2 5/7] btrfs-progs: check/lowmem mode: Check inline extent size

Signed-off-by: Qu Wenruo --- check/mode-lowmem.c | 28 1 file changed, 28 insertions(+) diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c index 62bcf3d2e126..0d19b373c7af 100644 --- a/check/mode-lowmem.c +++ b/check/mode-lowmem.c @@ -1417,6

[PATCH v2 6/7] btrfs-progs: test/convert: Add test case for invalid large inline data extent

Signed-off-by: Qu Wenruo --- .../016-invalid-large-inline-extent/test.sh| 22 ++ 1 file changed, 22 insertions(+) create mode 100755 tests/convert-tests/016-invalid-large-inline-extent/test.sh diff --git

[PATCH v2 3/7] btrfs-progs: mkfs/rootdir: Fix inline extent creation check

Just like convert, we need extra check against sector size for creating inline extent. Signed-off-by: Qu Wenruo --- mkfs/rootdir.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mkfs/rootdir.c b/mkfs/rootdir.c index e06b65ac13e4..a1d223a2408a 100644 ---

[PATCH v2 4/7] btrfs-progs: check/original mode: Check inline extent size

For inline compressed file extent, kernel doesn't allow inline extent ram size larger than sector size and on-disk inline extent size should not exceed BTRFS_MAX_INLINE_DATA_SIZE(). For inline uncompressed file extent, kernel doesn't allow inline extent ram and on-disk size larger than either

[PATCH v2 0/7] Fix long standing -EOPNOTSUPP problem caused by large inline extent

The patch is based on v4.15.1, and is designed to replace the old patch in devel branch. Kernel doesn't support dropping range inside inline extent, and prevents such thing happening by limiting max inline extent size to min(max_inline, sectorsize - 1) in cow_file_range_inline(). However

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton wrote: > > Replacing the __builtin_choose_expr() with ?: works of course. Hmm. That sounds like the right thing to do. We were so myopically staring at the __builtin_choose_expr() problem that we overlooked the obvious

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, 9 Mar 2018 17:30:15 -0800 Kees Cook wrote: > > It's one reason why I wondered if simplifying the expression to have > > just that single __builtin_constant_p() might not end up working.. > > Yeah, it seems like it doesn't bail out as "false" for complex >

Btrfs broken in massive transfar

I'm trying to clone 18TiB data between btrfs, but it will crash anyway. This probrem is occured even how to clone (btrfs send/receive, rsync or cp.) I experienced same probrem in Linux 3.9 and Linux 3.10. What happen: 1. Failed to write because I/O error (read only filesystem) 2. writing to the

Re: Ongoing Btrfs stability issues

On Mon, 2018-03-12 at 22:22 +0100, Goffredo Baroncelli wrote: > Unfortunately no, the likelihood might be 100%: there are some > patterns which trigger this problem quite easily. See The link which > I posted in my previous email. There was a program which creates a > bad checksum (in COW+DATASUM

Re: Ongoing Btrfs stability issues

On 03/11/2018 11:37 PM, Christoph Anton Mitterer wrote: > On Sun, 2018-03-11 at 18:51 +0100, Goffredo Baroncelli wrote: >> >> COW is needed to properly checksum the data. Otherwise is not >> possible to ensure the coherency between data and checksum (however I >> have to point out that BTRFS fails

Re: [btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks

On Sun, Feb 11, 2018 at 08:04:39PM +0100, Axel Burri wrote: > > > On 2018-02-10 12:24, Tomasz Pala wrote: > > There is a serious flaw in btrfs subcommands handling. Since all of them > > are handled by single 'btrfs' binary, there is no way to create any > > protection against accidental data

Re: [btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks

On Sat, Feb 10, 2018 at 12:24:41PM +0100, Tomasz Pala wrote: > There is a serious flaw in btrfs subcommands handling. Since all of them > are handled by single 'btrfs' binary, there is no way to create any > protection against accidental data loss for (the only one I've found, > but still

Re: [PATCH] Fix NULL pointer exception in find_bio_stripe()

On Sat, Feb 24, 2018 at 12:09:32AM +0100, David Sterba wrote: > On Fri, Feb 16, 2018 at 07:51:38PM +, Dmitriy Gorokh wrote: > > On detaching of a disk which is a part of a RAID6 filesystem, the following > > kernel OOPS may happen: > > > > [63122.680461] BTRFS error (device sdo): bdev

Re: [PATCH 1/4] btrfs-progs: mode-lowmem: Fix false alert about orphan inode

On Mon, Feb 05, 2018 at 02:47:11PM +0800, Qu Wenruo wrote: > Btrfs can delay inode deletion and in that case btrfs will unlink the > victim inode from its parent dir, and insert a marker to info btrfs to > delete it later. > > In that case, such victim inode will have nlinks == 0, but is still >

Re: [PATCH 1/4] btrfs-progs: mode-lowmem: Fix false alert about orphan inode

On Mon, Feb 05, 2018 at 03:00:39PM +0800, Su Yue wrote: > > > On 02/05/2018 02:47 PM, Qu Wenruo wrote: > > Btrfs can delay inode deletion and in that case btrfs will unlink the > > victim inode from its parent dir, and insert a marker to info btrfs to > > delete it later. > > > > In that case,

Re: [PATCH] btrfs: Use sizeof directly instead of a constant variable

On Mon, Mar 12, 2018 at 06:52:28PM +0200, Nikolay Borisov wrote: > The kernel would like to have all stack VLA usage removed[1]. > Unfortunately using an integer constant variable as the size of an > array is still considered a VLA. Instead let's use directly sizeof(var) > which removes the VLA

[PATCH] btrfs: Use sizeof directly instead of a constant variable

The kernel would like to have all stack VLA usage removed[1]. Unfortunately using an integer constant variable as the size of an array is still considered a VLA. Instead let's use directly sizeof(var) which removes the VLA usage. Use the occasion to remove csum_size altogether and use sizeof()

Re: [PATCH v2] fstests: test regression of -EEXIST on creating new file after log replay

On Mon, Mar 12, 2018 at 07:28:26PM +0800, Eryu Guan wrote: > On Sat, Mar 10, 2018 at 04:56:04PM -0700, Liu Bo wrote: > > The regression is introduced to btrfs in linux v4.4 and it refuses to create > > new files after log replay by returning -EEXIST. > > > > Although the problem is on btrfs only,

Re: [BUGFIX PATCH bpf-next] error-injection: Fix to prohibit jump optimization

On 03/12/2018 03:06 PM, Masami Hiramatsu wrote: > On Mon, 12 Mar 2018 11:44:21 +0100 > Daniel Borkmann wrote: >> On 03/12/2018 11:27 AM, Masami Hiramatsu wrote: >>> On Mon, 12 Mar 2018 19:00:49 +0900 >>> Masami Hiramatsu wrote: >>> Since the kprobe

Re: [BUGFIX PATCH bpf-next] error-injection: Fix to prohibit jump optimization

On Mon, 12 Mar 2018 11:44:21 +0100 Daniel Borkmann wrote: > Hi Masami, > > On 03/12/2018 11:27 AM, Masami Hiramatsu wrote: > > On Mon, 12 Mar 2018 19:00:49 +0900 > > Masami Hiramatsu wrote: > > > >> Since the kprobe which was optimized by jump can

[PATCH] btrfs: Handle error from btrfs_uuid_tree_rem call in _btrfs_ioctl_set_received_subvol

As with every function which deals with modifying the btree btrfs_uuid_tree_rem can fail for any number of reasons (ie. EIO/ENOMEM). Handle return error value from this function gracefully by aborting the transaction. Fixes: dd5f9615fc5c ("Btrfs: maintain subvolume items in the UUID tree")

Re: [PATCH v2] fstests: test regression of -EEXIST on creating new file after log replay

On Sat, Mar 10, 2018 at 04:56:04PM -0700, Liu Bo wrote: > The regression is introduced to btrfs in linux v4.4 and it refuses to create > new files after log replay by returning -EEXIST. > > Although the problem is on btrfs only, there is no btrfs stuff in terms of > test, so this makes it

Re: [BUGFIX PATCH bpf-next] error-injection: Fix to prohibit jump optimization

Hi Masami, On 03/12/2018 11:27 AM, Masami Hiramatsu wrote: > On Mon, 12 Mar 2018 19:00:49 +0900 > Masami Hiramatsu wrote: > >> Since the kprobe which was optimized by jump can not change >> the execution path, the kprobe for error-injection must not >> be optimized. To

Re: [BUGFIX PATCH bpf-next] error-injection: Fix to prohibit jump optimization

On Mon, 12 Mar 2018 19:00:49 +0900 Masami Hiramatsu wrote: > Since the kprobe which was optimized by jump can not change > the execution path, the kprobe for error-injection must not > be optimized. To prohibit it, set a dummy post-handler as > officially stated in

[BUGFIX PATCH bpf-next] error-injection: Fix to prohibit jump optimization

Since the kprobe which was optimized by jump can not change the execution path, the kprobe for error-injection must not be optimized. To prohibit it, set a dummy post-handler as officially stated in Documentation/kprobes.txt. Fixes: 4b1a29a7f542 ("error-injection: Support fault injection

[PATCH] btrfs: Remove received information from snapshot on ro->rw switch

Currently when a read-only snapshot is received and subsequently its ro property is set to false i.e. switched to rw-mode the received_uuid/stime/rtime/stransid/rtransid of that subvol remains intact. However, once the received volume is switched to RW mode we cannot guaranteee that it contains

[PATCH 3/3] btrfs-progs: Move check/main.c to cmds-check.c to maintain the subcommand hierarchy

cmds-check.c is back now, with include files cleaned up. Signed-off-by: Qu Wenruo --- Makefile | 8 check/main.c => cmds-check.c | 17 - 2 files changed, 4 insertions(+), 21 deletions(-) rename check/main.c => cmds-check.c (97%)

[PATCH 0/3] btrfs-progs: Split mode-original code

This patchset can be fetched from github: https://github.com/adam900710/btrfs-progs/tree/split_check_for_david This is the remaining part of the check code split. After the code split, the old cmds-check.c will return to make every subcommand have its own cmds-*.c. And there will be

Re: Raid1 volume stuck as read-only: How to dump, recreate and restore its content?

Adam Borowski posted on Sun, 11 Mar 2018 18:47:13 +0100 as excerpted: > On Sun, Mar 11, 2018 at 11:28:08PM +0700, Andreas Hild wrote: >> Following a physical disk failure of a RAID1 array, I tried to mount >> the remaining volume of a root partition with "-o degraded". For some >> reason it ended

[PATCH] btrfs-progs: check: Fix false alerts on sector sized compressed inline file extent

Commit 9d015c984006 ("btrfs-progs: Limit inline extent below page size") tries to fix the convert problem which we could create large inline file extent but kernel can't hanle. This leads the false alert about fsck test case 020. And after discussion about the problem in the mail list, we still