Re: Btrfs broken in massive transfar

> On Tue, Mar 13, 2018 at 1:25 PM, MASAKI haruka wrote: > > journal(Kernel log), 7th try (to be readonly): > > > > --- > > 3月 12 16:25:51 lily kernel: BTRFS info (device dm-6): creating UUID tree > > 3月 12 16:25:53 lily iscsid[1406]: Connection-1:0 to [target: > >

Re: btrfs errors

If you search the list for 'corrupt leaf bad key ordering' the top two causes are bad RAM and flaky power supply. These can be hard to narrow down. But yes pretty good chance it can be fixed with 'btrfs check --repair' but two things before you do that: a. Make sure backups are up to date.

Re: Btrfs broken in massive transfar

On Tue, Mar 13, 2018 at 1:25 PM, MASAKI haruka wrote: > journal(Kernel log), 7th try (to be readonly): > > --- > 3月 12 16:25:51 lily kernel: BTRFS info (device dm-6): creating UUID tree > 3月 12 16:25:53 lily iscsid[1406]: Connection-1:0 to [target: >

WARN when unmounting a subvolume that is being synced

Hi all, I'm getting the WARN below. I think (?) what I'm doing when I get it is that I'm unmounting a subvolume while it's being synced (concurrent uses of the subvolume, at least, happy to look into it further if the stack trace is not so useful). Anyway, I can fairly reliably reproduce this on

btrfs errors

Hi When recompiling the kernel a few weeks ago i got some error and after some research notices some checksum errors in the dmesg in my root filesystem, with btrfs Doing a btrfs check i got many errors in the linux source tree *.o and several other files in /usr/*. So i umounted, rebooted from a

Re: [PATCH 1/2] Btrfs-progs: check, fix false error reports for shared prealloc extents

On Wed, Mar 14, 2018 at 09:32:50AM +0800, Qu Wenruo wrote: > > >On 2018年03月14日 02:47, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> Under some cases the filesystem checker reports an error when it finds >> checksum items for an extent that is referenced by an inode

Re: [PATCH 1/2] Btrfs-progs: check, fix false error reports for shared prealloc extents

On 2018年03月14日 09:32, Qu Wenruo wrote: > > > On 2018年03月14日 02:47, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> Under some cases the filesystem checker reports an error when it finds >> checksum items for an extent that is referenced by an inode as a prealloc >>

Re: [PATCH 2/2] Btrfs-progs: add fsck test for filesystem with shared prealloc extents

On 2018年03月14日 02:47, fdman...@kernel.org wrote: > From: Filipe Manana > > Verify that a filesystem check operation (fsck) does not report the > following scenario as an error: > > An extent is shared between two inodes, as a result of clone/reflink > operation, and for one

Re: [PATCH 1/2] Btrfs-progs: check, fix false error reports for shared prealloc extents

On 2018年03月14日 02:47, fdman...@kernel.org wrote: > From: Filipe Manana > > Under some cases the filesystem checker reports an error when it finds > checksum items for an extent that is referenced by an inode as a prealloc > extent. Such cases are not an error when the extent

[PATCH] btrfs-progs: inspect-dump-tree: add '-f|--follow' options to print all children tree blocks for '-b'

When debuging with "btrfs inspect dump-tree", it's not that handy if we want to iterate all child tree blocks starting from a specified block. -b can only print a single block, while without -b "btrfs inspect dump-tree" will need extra tree roots fulfilled to continue, which is not possible for

[PATCH] btrfs-progs: convert/ext2: Remove check for ext2_ext_attr_entry->e_value_block

In latest e2fsprogs (1.44.0) definition of ext2_ext_attr_entry has removed member e_value_block, as currently ext* doesn't support it set anyway. So remove such check so that we can pass compile. Signed-off-by: Qu Wenruo --- Fast rolling distribution (Arch) catches this much

Re: FS unmountable after RAID/LVM problems

On 2018年03月13日 22:49, Dirk Gouders wrote: [snip] >> >> # btrfs inspect dump-tree -b 848986112 /dev/loop0p1 >> # btrfs inspect dump-tree -b 72089600 /dev/loop0p1 > > OK. > > (This mail gets a bit long but I don't want to snip probably important > information above.) > Feel free to snip. As

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

On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton wrote: > On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > >> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds >> wrote: >> > On Mon, Mar 12, 2018 at 3:55 PM,

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

On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > 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

Re: Ongoing Btrfs stability issues

On Tue, 2018-03-13 at 20:36 +0100, Goffredo Baroncelli wrote: > A checksum mismatch, is returned as -EIO by a read() syscall. This is > an event handled badly by most part of the programs. Then these programs must simply be fixed... otherwise they'll also fail under normal circumstances with

[PATCH] Btrfs: drop a VLA in btrfs_check_super_csum()

Avoid a VLA[1] by using a real constant expression instead of a variable. The compiler should be able to optimize the original code and avoid using an actual VLA. Anyway this change is useful because it will avoid a false positive with -Wvla, it might also help the compiler generating better code.

Re: Ongoing Btrfs stability issues

On 03/12/2018 10:48 PM, Christoph Anton Mitterer wrote: > 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

Re: Btrfs broken in massive transfar

journal(Kernel log), 7th try (to be readonly): --- 3月 12 16:25:51 lily kernel: BTRFS info (device dm-6): creating UUID tree 3月 12 16:25:53 lily iscsid[1406]: Connection-1:0 to [target: iqn.1994-11.com.netgear:eggplant-01:edc9adcf:btr1group, portal: 192.168.1.166,3260] through [iface: default]

[PATCH 1/2] Btrfs-progs: check, fix false error reports for shared prealloc extents

From: Filipe Manana Under some cases the filesystem checker reports an error when it finds checksum items for an extent that is referenced by an inode as a prealloc extent. Such cases are not an error when the extent is actually shared (was cloned/reflinked) with other inodes

[PATCH 2/2] Btrfs-progs: add fsck test for filesystem with shared prealloc extents

From: Filipe Manana Verify that a filesystem check operation (fsck) does not report the following scenario as an error: An extent is shared between two inodes, as a result of clone/reflink operation, and for one of the inodes, lets call it inode A, the extent is referenced

Re: [PATCH 02/22] btrfs: assume that prev_em_start is always valid in __do_readpage

On 03/08/2018 10:33 PM, David Sterba wrote: All callers pass a valid pointer, we can remove the redundant checks. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent_io.c

[RFC PATCH] btrfs: check for SB checksum when scanned

We aren't checking the SB csum when the device scanned, instead we do that when mounting the device, and if the csum fails we fail the mount. How if we check the csum when the device is scanned, I can't see any reason for why not? any idea? Signed-off-by: Anand Jain ---

Re: Fwd: Used space discrepancy

2018-03-13 14:31 GMT+01:00 Austin S. Hemmelgarn : > In your case, start by just calling `du` on the _whole_ volume. There's > probably some space you're missing that isn't in snapshots and isn't used > under the folder/folders you told it to look at. du -sh /mnt/dati/ 1,8T

Re: FS unmountable after RAID/LVM problems

Qu Wenruo writes: > On 2018年03月13日 22:21, Dirk Gouders wrote: >> Qu Wenruo writes: >> >>> On 2018年03月13日 21:29, Dirk Gouders wrote: Qu Wenruo writes: > On 2018年03月13日 21:01, Dirk Gouders wrote: >> Qu

Re: FS unmountable after RAID/LVM problems

On 2018年03月13日 22:21, Dirk Gouders wrote: > Qu Wenruo writes: > >> On 2018年03月13日 21:29, Dirk Gouders wrote: >>> Qu Wenruo writes: >>> On 2018年03月13日 21:01, Dirk Gouders wrote: > Qu Wenruo writes: > >>

Re: FS unmountable after RAID/LVM problems

Qu Wenruo writes: > On 2018年03月13日 21:29, Dirk Gouders wrote: >> Qu Wenruo writes: >> >>> On 2018年03月13日 21:01, Dirk Gouders wrote: Qu Wenruo writes: > On 2018年03月13日 16:53, Dirk Gouders wrote:

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

The amount of replicated defined could also be reduced by passing > or < to a min_max() macro. So you start off with something like: #define min(x, y) __min_max(x, <, y) #define max(x, y) __min_max(x, >, y) then have: #define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y)) in all its associated

Re: [PATCH] btrfs: Document parameters of btrfs_reserve_extent

On 03/13/2018 06:22 PM, Nikolay Borisov wrote: This function is the entry to the extent allocator and as such has quite a number of parameters. Some of those have subtle effects on the allocation algorithm. Document the parameters. Signed-off-by: Nikolay Borisov

Re: Ongoing Btrfs stability issues

On 9 March 2018 at 20:05, Alex Adriaanse wrote: > > Yes, we have PostgreSQL databases running these VMs that put a heavy I/O load > on these machines. Dump the databases and recreate them with --data-checksums and Btrfs No_COW attribute. You can add this to

Re: FS unmountable after RAID/LVM problems

On 2018年03月13日 21:29, Dirk Gouders wrote: > Qu Wenruo writes: > >> On 2018年03月13日 21:01, Dirk Gouders wrote: >>> Qu Wenruo writes: >>> On 2018年03月13日 16:53, Dirk Gouders wrote: >>> >>> >>> > find-root: > > # btrfs-find-root

Re: Fwd: Used space discrepancy

On 2018-03-13 09:07, Valerio Pachera wrote: Short version: 656G used (df -h) 450G used (du -sh) 10G used by snapshots 196G discrepancy <- I don't undertand what is using 196G. df -h /mnt/dati/ File systemDim. Usati Dispon. Uso% Montato su /dev/mapper/vg00-dati 919G 656G

Re: FS unmountable after RAID/LVM problems

Qu Wenruo writes: > On 2018年03月13日 21:01, Dirk Gouders wrote: >> Qu Wenruo writes: >> >>> On 2018年03月13日 16:53, Dirk Gouders wrote: >> >> >> find-root: # btrfs-find-root /dev/loop0p1 Superblock thinks the generation is

Re: Used space discrepancy

Today I've been updating the kernel and btrfs-progs to jessie backports and rebooted the server. There seems to not be usefull info in dmesg dmesg | grep -i btrfs [4.702295] Btrfs loaded, crc32c=crc32c-generic [8.371792] BTRFS: device fsid f0a8ff89-608e-4ca2-bde9-8dc09b91accf devid 1

Re: FS unmountable after RAID/LVM problems

On 2018年03月13日 21:01, Dirk Gouders wrote: > Qu Wenruo writes: > >> On 2018年03月13日 16:53, Dirk Gouders wrote: > > > >>> find-root: >>> >>> # btrfs-find-root /dev/loop0p1 >>> Superblock thinks the generation is 9858294 >>> Superblock thinks the level is 1 >>> Found

Fwd: Used space discrepancy

Short version: 656G used (df -h) 450G used (du -sh) 10G used by snapshots 196G discrepancy <- I don't undertand what is using 196G. df -h /mnt/dati/ File systemDim. Usati Dispon. Uso% Montato su /dev/mapper/vg00-dati 919G 656G262G 72% /mnt/dati du -sh

Re: FS unmountable after RAID/LVM problems

Qu Wenruo writes: > On 2018年03月13日 16:53, Dirk Gouders wrote: >> find-root: >> >> # btrfs-find-root /dev/loop0p1 >> Superblock thinks the generation is 9858294 >> Superblock thinks the level is 1 >> Found tree root at 848773120 gen 9858294 level 1 > > Tree root is

Re: FS unmountable after RAID/LVM problems

On 2018年03月13日 16:53, Dirk Gouders wrote: > Hello all, > > a somewhat aged RAID array (16 Disks) got into trouble after it has > been powered off because of facility management maintenance tasks. > > It then went through some rebuilds loosing three disks on the way and > the whole procedure

Re: Btrfs remounted read-only due to ENOSPC in btrfs_run_delayed_refs

Dne 10.3.2018 v 15:51 Martin Svec napsal(a): > Dne 10.3.2018 v 13:13 Nikolay Borisov napsal(a): >> >> > And then report back on the output of the extra debug > statements. > > Your global rsv is essentially unused, this means > in the worst case the code should fallback to

FS unmountable after RAID/LVM problems

Hello all, a somewhat aged RAID array (16 Disks) got into trouble after it has been powered off because of facility management maintenance tasks. It then went through some rebuilds loosing three disks on the way and the whole procedure ended with corrupted volumes. Volumes with ext{2,4}

[PATCH] btrfs: Document parameters of btrfs_reserve_extent

This function is the entry to the extent allocator and as such has quite a number of parameters. Some of those have subtle effects on the allocation algorithm. Document the parameters. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 45

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

On 2018年03月13日 16:40, Nikolay Borisov wrote: > > > On 13.03.2018 03:56, Qu Wenruo wrote: >> 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

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

On 2018年03月13日 16:39, Nikolay Borisov wrote: > > > On 13.03.2018 03:56, Qu Wenruo wrote: >> Signed-off-by: Qu Wenruo >> --- >> check/mode-lowmem.c | 28 >> 1 file changed, 28 insertions(+) >> >> diff --git a/check/mode-lowmem.c

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

On 13.03.2018 03:56, Qu Wenruo wrote: > 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

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

On 13.03.2018 03:56, Qu Wenruo wrote: > 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 > ---

[PATCH v2] 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: Raid1 volume stuck as read-only: How to dump, recreate and restore its content?

Hello, > Put differently, 4.7 is missing a year and a half worth of bugfixes that you > won't have when you run it to try to check or recover that btrfs that won't > mount! Do you *really* want to risk your data on bugs that were after all > discovered and fixed over a year ago? It is also