Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

On 2018年05月14日 12:41, james harvey wrote: > On Sun, May 13, 2018 at 10:08 PM, Qu Wenruo wrote: >> On 2018年05月12日 13:08, james harvey wrote: >>> Hardware is fine. Passes memtest86+ in SMP mode. Works fine on all >>> other files. >>> >>> >>> >>> [ 381.869940] BUG:

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

On Sun, May 13, 2018 at 10:08 PM, Qu Wenruo wrote: > On 2018年05月12日 13:08, james harvey wrote: >> Hardware is fine. Passes memtest86+ in SMP mode. Works fine on all >> other files. >> >> >> >> [ 381.869940] BUG: unable to handle kernel paging request at >>

[PATCH v3] btrfs: incremental send, fix BUG when invalid memory access

From: Robbie Ko [BUG] btrfs incremental send BUG happens when creating a snapshot of snapshot that is being used by send. [REASON] The problem can happen if while we are doing a send one of the snapshots used (parent or send) is snapshotted, because snapshoting implies

Re: [PATCH v2] btrfs: incremental send, fix BUG when invalid memory access

Filipe Manana 於 2018-05-11 17:59 寫到: On Fri, May 11, 2018 at 7:34 AM, robbieko wrote: From: Robbie Ko [BUG] btrfs incremental send BUG happens when creating a snapshot of snapshot that is being used by send. [REASON] The problem can happen if

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

On 2018年05月12日 13:08, james harvey wrote: > 100% reproducible, booting from disk, or even Arch installation ISO. > Kernel 4.16.7. btrfs-progs v4.16. > > Reading one of two journalctl files causes a kernel oops. Initially > ran into it from "journalctl --list-boots", but cat'ing the file does

[PATCH v2 0/2] btrfs: qgroup rescan fixes part 1

This patchset is mainly focused on fixing qgroup rescan corruption. Since the whole btrfs qgroup is based on the modification between 2 transactions, it only has correct qgroup delta. While if the rescan can't provide a correct result from the very beginning, qgroup numbers are corrupted. The

[PATCH v2 2/2] btrfs: qgroup: Finish rescan when hit the last leaf of extent tree

Under the following case, qgroup rescan can double account cowed tree blocks: In this case, extent tree only has one tree block. - | transid=5 last committed=4 | btrfs_qgroup_rescan_worker() | |- btrfs_start_transaction() | | transid = 5 | |- qgroup_rescan_leaf() ||-

[PATCH v2 1/2] btrfs: qgroup: Search commit root for rescan to avoid missing extent

When doing qgroup rescan using the following script (modified from btrfs/017 test case), we can sometimes hit qgroup corruption. -- umount $dev &> /dev/null umount $mnt &> /dev/null mkfs.btrfs -f -n 64k $dev mount $dev $mnt extent_size=8192 xfs_io -f -d -c "pwrite 0 $extent_size" $mnt/foo

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

On Sat, May 12, 2018 at 8:09 PM, Chris Murphy wrote: > On Sat, May 12, 2018 at 6:10 PM, james harvey > wrote: >> On Sat, May 12, 2018 at 3:51 AM, Martin Steigerwald >> wrote: >>> Hey James. >>> >>> james harvey -

Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags

On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote: > On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote: > > The Linux VFS does not allow a way to set append/immuttable > > attributes to symlinks, this is just not possible. If this is > > detected inform the user as the filesystem must be

Re: [PATCH 1/2] vfs: allow dedupe of user owned read-only files

On Sun, May 13, 2018 at 06:16:53PM +, Mark Fasheh wrote: > On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote: > > On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote: > > > The permission check in vfs_dedupe_file_range() is too coarse - We > > > only allow dedupe of the

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

On Sun, May 13, 2018 at 06:21:52PM +, Mark Fasheh wrote: > On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote: > > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: > > > Right now we return EINVAL if a process does not have permission to > > > dedupe a > > > file.

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: > > Right now we return EINVAL if a process does not have permission to dedupe a > > file. This was an oversight on my part. EPERM gives a true description of > > the

Re: [PATCH 1/2] vfs: allow dedupe of user owned read-only files

Hey Adam, On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote: > On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote: > > The permission check in vfs_dedupe_file_range() is too coarse - We > > only allow dedupe of the destination file if the user is root, or > > they have the

[RFC][PATCH] btrfs: take the last remnants of ->d_fsdata use out

[spotted while going through ->d_fsdata handling around d_splice_alias(); don't really care which tree that goes through] The only thing even looking at ->d_fsdata in there (since 2012) had been kfree(dentry->d_fsdata) in btrfs_dentry_delete(). Which, incidentally, is all btrfs_dentry_delete()

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: > > Right now we return EINVAL if a process does not have permission to dedupe a > > file. This was an oversight on my part. EPERM gives a true description of > > the

Re: Btrfs installation advices

On martedì 8 maggio 2018 09:50:23 CEST, Rolf Wald wrote: You need to build three partitions, e.g. named boot, swap, root. You don't need to use an unencrypted boot if you use grub: https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29 A

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

Reported at: https://bugzilla.kernel.org/show_bug.cgi?id=199707 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

*** Disregard previous post. I read btrfs-map-logical.c, and the reply below is more sensical than my last. I now understand since I wasn't specifying a byte size to btrfs-map-logical, it was defaulting to the nodesize which is 16k. Filefrag shows the first fragment is 128k, but below I discuss