Re: [dm-devel] [PATCH 08/15] dm mpath: merge do_end_io_bio into multipath_end_io_bio

On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote: > This simplifies the code and especially the error passing a bit and > will help with the next patch. > > Signed-off-by: Christoph Hellwig > --- >  drivers/md/dm-mpath.c | 42 - > - >

Re: QGroups Semantics

On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo wrote: > > > At 05/19/2017 05:07 PM, Sargun Dhillon wrote: >> >> I have some questions about the *intended* qgroups semantics, and why >> we allow certain operations: >> >> 1) Why can you create a level 0 qgroup for a

Re: btrfs metadata reclaim behavior/performance characteristics

On Sun, May 21, 2017 at 03:45:02PM +0300, Nikolay Borisov wrote: > > > On 19.05.2017 21:32, Liu Bo wrote: > > On Fri, May 19, 2017 at 12:54:59PM +0300, Nikolay Borisov wrote: > >>> From: Liu Bo > >>> > >>> Subject: [PATCH] Btrfs: skip commit transaction if we don't have

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: > > I already have 24GB of RAM in that machine, adding more for the real > fsck repair to run, is going to be difficult and ndb would take days I > guess (then again I don't have a machine with 32 or 48 or 64GB of RAM >

Re: [PATCH 7/8] btrfs: Add code to prevent qgroup creation for a non-existent subvol

Hi Sargun, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc2 next-20170522] [cannot apply to btrfs/next] [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/commits/Sargun-Dhillon

Re: help!!! error when mount a btrfs file system

At 03/16/2017 08:23 PM, 李云甫 wrote: hi, buddy I have a file server with btrfs file system, it's work well for several months. but after last system reboot, the /dev/sdb become not mountable. below is the details. is there any advise? ##Version info Fedora 25 Server Kernel

WARNING: CPU: 5 PID: 19734 at fs/btrfs/send.c:6290 btrfs_ioctl_send+0xad/0xde2

This is probably not a bug I should report and simply an issue with the filesystem I'm trying to get data out of, but reporting it just in case it's useful somehow. /* * This is done when we lookup the root, it should already be complete * by the time we get here. */

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: > On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: > > > > > I already have 24GB of RAM in that machine, adding more for the real > > fsck repair to run, is going to be difficult and ndb would take days I > >

[PATCH v14.3 00/16] Btrfs In-band De-duplication

This patchset can be fetched from github: https://github.com/adam900710/linux.git wang_dedupe_latest This is just a normal rebase update. Now the new base is v4.12-rc1. Normal test cases from auto group exposes no regression, and ib-dedupe group can pass without problem. Changelog: v2:

[PATCH v11 0/5] In-band de-duplication for btrfs-progs

Patchset can be fetched from github: https://github.com/adam900710/btrfs-progs.git dedupe_20170523 Inband dedupe(in-memory backend only) ioctl support for btrfs-progs. Existing tester/reviewer can just rebase v10 patches to btrfs-progs v4.11 tags. All conflicts can be resolved by git without any

Re: QGroups Semantics

Just some user's point of view: I propose the following changes: 1) We always cleanup level-0 qgroups by default, with no opt-out. I see absolutely no reason to keep these around. It WILL break scripts that try to do this cleanup themselves. OTOH it will simplify writing new ones. Since

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

When I ran the script, it produces below output. From the output it looks like, it detected the error and corrected. But parity-block corruption fix patch not yet merged or I missed something? Run: (with scrub_offline repo) btrfs scrub start /home/laks/centos/laks/BTRFS/scrub_offline/tests/mnt

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

Yes. It detects the injected corruption. #btrfs scrub start --offline /dev/loop6 ERROR: data at bytenr 145293312 mirror 0 csum mismatch, have 0x790f1fe1 expect 0xa30cb5c5 ERROR: full stripe 145227776 RECOVERABLE: Data stripes corrupted, but P/Q is good Scrub result: Tree bytes scrubbed: 131072

Re: Fwd: confusing "no space left" -- how to troubleshoot and "be prepared"?

On Thu, 18 May 2017, Peter Becker wrote: > I'm not sure if this would be helpfull but can you post the output > from this script? > cd /tmp > wget https://raw.githubusercontent.com/kdave/btrfs-progs/master/btrfs-debugfs > chmod +x btrfs-debugfs > stats=$(sudo ./btrfs-debugfs -b /) > ... Thank

[PATCH v4 2/2] btrfs: Refactor update_space_info

Following the factoring out of the creation code udpate_space_info can only be called for already-existing space_info structs. As such it cannot fail. Remove superfulous error handling and make the function return void. Signed-off-by: Nikolay Borisov Reviewed-by: Jeff Mahoney

[PATCH v4 1/2] btrfs: Separate space_info create/update

Currently the struct space_info creation code is intermixed in the udpate_space_info function. There are well-defined points at which the we actually want to create brand-new space_info structs (e.g. during mount of the filesystem as well as sometimes when adding/initialising new chunks). In such

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

> > As the title said, it's *offline* scrub, while you're still using the > *online* scrub. > > To use offline scrub, you should exec "btrfs scrub start --offline > " > > And then it should detect the same error. > Output is nothing like kernel. > > Thanks, > Qu > Ah,my bad. I thought the entire

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

Okay sure, When I find free-time, will run few more combinations and let you know the details along with any other suggestions/thoughts on the interface. thanks. On 5/22/17, Qu Wenruo wrote: > Good to hear that. > > And you could try more combination (although I have

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

Marc MERLIN posted on Sun, 21 May 2017 18:35:53 -0700 as excerpted: > On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote: >> On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: >> > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 enabling repair >> > mode Checking

Re: [PATCH v2 2/2] Btrfs: compression must free at least PAGE_SIZE

Timofey Titovets posted on Mon, 22 May 2017 01:32:21 +0300 as excerpted: > 2017-05-21 20:30 GMT+03:00 Roman Mamedov : >> On Sun, 21 May 2017 19:54:05 +0300 Timofey Titovets >> wrote: >> >>> Sorry, but i know about subpagesize-blocksize patch set, but i

[PATCH 1/2] btrfs: rename btrfs_leaf_data to BTRFS_LEAF_DATA_OFFSET

Commit 5f39d397dfbe ("Btrfs: Create extent_buffer interface for large blocksizes") refactored btrfs_leaf_data function to take extent_buffer rather than struct btrfs_leaf. However, as it turns out the parameter being passed is never used. Furthermore this function no longer returns the leaf data

[PATCH 2/2] btrfs: remove __BTRFS_LEAF_DATA_SIZE

__BTRFS_LAF_DATA_SIZE is used only by BTRFS_LEAF_DATA_SIZE. Make the latter subsume the former. Signed-off-by: Nikolay Borisov --- fs/btrfs/ctree.h | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote: > On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: >> On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: >> >> > >> > I already have 24GB of RAM in that machine, adding more for the real >> >

Re: [PATCH 4/8] btrfs: autoremove qgroup by default, and add a mount flag to override

At 05/23/2017 01:31 AM, Sargun Dhillon wrote: On Sun, May 21, 2017 at 7:03 PM, Qu Wenruo wrote: At 05/22/2017 09:58 AM, Sargun Dhillon wrote: On Sun, May 21, 2017 at 6:20 PM, Qu Wenruo wrote: At 05/20/2017 04:39 PM, Sargun Dhillon

Re: QGroups Semantics

At 05/23/2017 04:54 AM, Sargun Dhillon wrote: On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo wrote: At 05/19/2017 05:07 PM, Sargun Dhillon wrote: I have some questions about the *intended* qgroups semantics, and why we allow certain operations: 1) Why can you create

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Sun, May 21, 2017 at 06:35:53PM -0700, Marc MERLIN wrote: > On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote: > > On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote: > > > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 > > > enabling repair mode > > > Checking

Re: [PATCH 4/8] btrfs: autoremove qgroup by default, and add a mount flag to override

On Sun, May 21, 2017 at 7:03 PM, Qu Wenruo wrote: > > > At 05/22/2017 09:58 AM, Sargun Dhillon wrote: >> >> On Sun, May 21, 2017 at 6:20 PM, Qu Wenruo >> wrote: >>> >>> >>> >>> At 05/20/2017 04:39 PM, Sargun Dhillon wrote: This