Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 1:50 PM, Linus Torvalds wrote: > > Hmm. I have pulled this, but it is really really broken in one place, > to the degree that I always went "no, I won't pull this garbage". always=almost. I'd blame auto-correct, but I'm not on the phone.

Re: degraded permanent mount option

29.01.2018 14:24, Adam Borowski пишет: ... > > So any event (the user's request) has already happened. A rc system, of > which systemd is one, knows whether we reached the "want root filesystem" or > "want secondary filesystems" stage. Once you're there, you can issue the > mount() call and let

Re: degraded permanent mount option

Austin S. Hemmelgarn wrote: On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened.  A rc system, of which systemd is one, knows whether we reached the "want root filesystem" or "want secondary

Re: [PATCH] btrfs: fix err_cast.cocci warnings

On 01/30/2018 02:40 AM, David Sterba wrote: On Mon, Jan 29, 2018 at 02:50:10AM +0800, kbuild test robot wrote: From: Fengguang Wu fs/btrfs/volumes.c:742:10-17: WARNING: ERR_CAST can be used with fs_devices Use ERR_CAST inlined function instead of

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote: > > This pile of patches is a rework of the inode->i_version field. We have > traditionally incremented that field on every inode data or metadata > change. Typically this increment needs to be logged on disk even when >

[GIT PULL] Btrfs for 4.16

Hi, the btrfs updates for this cycle are mostly cleanups with a few raid56 bugfixes and some feature additions. Please pull, thanks. Features or user visible changes: - fallocate: implement zero range mode - avoid losing data raid profile when deleting a device - tree item checker: more

Re: [PATCH 04/26] libbtrfsutil: add btrfs_util_is_subvolume() and btrfs_util_subvolume_id()

On Mon, Jan 29, 2018 at 12:24:26PM +0200, Nikolay Borisov wrote: > On 26.01.2018 20:40, Omar Sandoval wrote: [snip] > > +/* > > + * This intentionally duplicates btrfs_util_f_is_subvolume() instead of > > opening > > + * a file descriptor and calling it, because fstat() and fstatfs() don't > >

Re: [PATCH] btrfs: fix err_cast.cocci warnings

On Mon, Jan 29, 2018 at 02:50:10AM +0800, kbuild test robot wrote: > From: Fengguang Wu > > fs/btrfs/volumes.c:742:10-17: WARNING: ERR_CAST can be used with fs_devices > > > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)) > > Generated by:

Re: [PATCH] btrfs: btrfs_evict_inode must clear all inodes

On Mon, Jan 29, 2018 at 11:46:28AM -0500, Jeff Mahoney wrote: > btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict(). > > Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction) > Cc: Nikolay Borisov > Cc: # v4.8+ >

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks! Got these # ./btrfs.static inspect dump-super -fFa /dev/sdb3 |grep backup_tree_root: | sort -u backup_tree_root:180410073088gen: 463765level: 1 backup_tree_root:180415758336gen: 463766level: 1 backup_tree_root:180416364544gen:

Re: [PATCH] btrfs: btrfs_evict_inode must clear all inodes

On 1/29/18 2:58 PM, Liu Bo wrote: > On Mon, Jan 29, 2018 at 11:46:28AM -0500, Jeff Mahoney wrote: >> btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict(). >> >> Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction) >> Cc: Nikolay Borisov >> Cc:

Re: degraded permanent mount option

On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened. A rc system, of which systemd is one, knows whether we reached the "want root filesystem" or "want secondary filesystems" stage. Once you're there,

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > systemd can't possibly need to know more information than a person > does in the exact same situation in order to do the right thing. No > human would wait 10 minutes, let alone literally the heat death of the > planet for "all devices

Re: [PATCH v3 06/10] writeback: introduce super_operations->write_metadata

On Wednesday, January 3, 2018 9:59:24 PM IST Josef Bacik wrote: > On Wed, Jan 03, 2018 at 05:26:03PM +0100, Jan Kara wrote: > > Oh ok well if that's the case then I'll fix this up to be a ratio, test > everything, and send it along probably early next week. Thanks, > Hi Josef, Did you get a

Re: [PATCH 04/26] libbtrfsutil: add btrfs_util_is_subvolume() and btrfs_util_subvolume_id()

On 26.01.2018 20:40, Omar Sandoval wrote: > From: Omar Sandoval > > These are the most trivial helpers in the library and will be used to > implement several of the more involved functions. > > Signed-off-by: Omar Sandoval > --- > Makefile

[PATCH v2] btrfs: Gracefully handle errors in btrfs_qgroup_trace_extent_post

Running generic/019 with qgroups on the scratch device enabled is almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's supposed to trigger only on -ENOMEM, in reality, however, it's possible to get -EIO from btrfs_qgroup_trace_extent_post. This function just finds the roots of

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > > > systemd can't possibly need to know more information than a person > > does in the exact same situation in order to do the right thing. No > > human would wait 10

[GIT PULL] inode->i_version rework for v4.16

The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36: Linux 4.15-rc3 (2017-12-10 17:56:26 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git tags/iversion-v4.16-1 for you to fetch changes up to

Re: degraded permanent mount option

On 2018-01-27 17:42, Tomasz Pala wrote: On Sat, Jan 27, 2018 at 14:26:41 +0100, Adam Borowski wrote: It's quite obvious who's the culprit: every single remaining rc system manages to mount degraded btrfs without problems. They just don't try to outsmart the kernel. Yes. They are stupid

[PATCH v3] btrfs: Ignore errors from btrfs_qgroup_trace_extent_post

Running generic/019 with qgroups on the scratch device enabled is almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's supposed to trigger only on -ENOMEM, in reality, however, it's possible to get -EIO from btrfs_qgroup_trace_extent_post. This function just finds the roots of

Re: [PATCH v2] btrfs: Gracefully handle errors in btrfs_qgroup_trace_extent_post

On 2018年01月29日 15:44, Nikolay Borisov wrote: > Running generic/019 with qgroups on the scratch device enabled is > almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's > supposed to trigger only on -ENOMEM, in reality, however, it's possible > to get -EIO from

Re: [PATCH] btrfs: Fix UAF

On 01/29/2018 03:01 PM, Nikolay Borisov wrote: On 29.01.2018 04:38, Anand Jain wrote: On 01/26/2018 09:20 PM, Nikolay Borisov wrote: Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs

Re: degraded permanent mount option

On 2018-01-29 06:24, Adam Borowski wrote: On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote: it is a btrfs drawback that doesn't provice anything else except for this IOCTL with it's logic How can it provide you with something it doesn't yet have? If you want the information, call

Re: [PATCH v2] btrfs: Gracefully handle errors in btrfs_qgroup_trace_extent_post

On 29.01.2018 13:09, Qu Wenruo wrote: > > > On 2018年01月29日 15:44, Nikolay Borisov wrote: >> Running generic/019 with qgroups on the scratch device enabled is >> almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's >> supposed to trigger only on -ENOMEM, in reality, however,

Re: [PATCH v2] btrfs: Gracefully handle errors in btrfs_qgroup_trace_extent_post

On 2018年01月29日 19:21, Nikolay Borisov wrote: > > > On 29.01.2018 13:09, Qu Wenruo wrote: >> >> >> On 2018年01月29日 15:44, Nikolay Borisov wrote: >>> Running generic/019 with qgroups on the scratch device enabled is >>> almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's >>>

Re: [PATCH v2] btrfs: Gracefully handle errors in btrfs_qgroup_trace_extent_post

On 29.01.2018 13:57, Qu Wenruo wrote: > > > On 2018年01月29日 19:21, Nikolay Borisov wrote: >> >> >> On 29.01.2018 13:09, Qu Wenruo wrote: >>> >>> >>> On 2018年01月29日 15:44, Nikolay Borisov wrote: Running generic/019 with qgroups on the scratch device enabled is almost guaranteed to

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks for the advice, Qu! I used the system for a while, did some package upgrades -- writing in the suspect corrupted area. Then tried a btrfs-send to my backup vol, and it failed miserably with a nice kernel oops. So I went for a lowmem repair:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 21:58, ^m'e wrote: > Thanks for the advice, Qu! > > I used the system for a while, did some package upgrades -- writing in > the suspect corrupted area. Then tried a btrfs-send to my backup vol, > and it failed miserably with a nice kernel oops. > > So I went for a lowmem

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月30日 02:16, ^m'e wrote: > Thanks! > > Got these > > # ./btrfs.static inspect dump-super -fFa /dev/sdb3 |grep > backup_tree_root: | sort -u > backup_tree_root:180410073088gen: 463765level: 1 > backup_tree_root:180415758336gen: 463766level: 1 >

Re: [PATCH 02/26] Add libbtrfsutil

On Mon, Jan 29, 2018 at 10:16:40AM +0800, Qu Wenruo wrote: > > > On 2018年01月27日 02:40, Omar Sandoval wrote: > > From: Omar Sandoval > > > > Currently, users wishing to manage Btrfs filesystems programatically > > have to shell out to btrfs-progs and parse the output. This isn't

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 1:54 AM, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > >> systemd can't possibly need to know more information than a person >> does in the exact same situation in order to do the right thing. No >> human would wait 10

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Lowmem check on my backup pool reports dozens of 'backref lost' on extents... Excerpt: -- # ./btrfsck.static check --mode=lowmem /dev/sda1 checking extents ERROR: data extent[33866182656 4096] backref lost ERROR: data extent[37102219264

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 22:49, ^m'e wrote: > On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo wrote: >> >> >> On 2018年01月29日 21:58, ^m'e wrote: >>> Thanks for the advice, Qu! >>> >>> I used the system for a while, did some package upgrades -- writing in >>> the suspect corrupted area.

Re: [PATCH v3] btrfs: Ignore errors from btrfs_qgroup_trace_extent_post

On 2018年01月29日 21:53, Nikolay Borisov wrote: > Running generic/019 with qgroups on the scratch device enabled is > almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's > supposed to trigger only on -ENOMEM, in reality, however, it's possible > to get -EIO from

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo wrote: > > > On 2018年01月29日 21:58, ^m'e wrote: >> Thanks for the advice, Qu! >> >> I used the system for a while, did some package upgrades -- writing in >> the suspect corrupted area. Then tried a btrfs-send to my backup vol, >>

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 23:08, ^m'e wrote: > Lowmem check on my backup pool reports dozens of 'backref lost' on > extents... Excerpt: > -- > # ./btrfsck.static check --mode=lowmem /dev/sda1 > checking extents > ERROR: data extent[33866182656 4096]

[PATCH] btrfs: btrfs_evict_inode must clear all inodes

btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict(). Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction) Cc: Nikolay Borisov Cc: # v4.8+ Signed-off-by: Jeff Mahoney --- fs/btrfs/inode.c |1 + 1

[PATCH 1/2] btrfs: drop num argument from find_live_mirror()

Obtain the stripes info from the map directly and so no need to pass it as an argument. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index

Re: [PATCH 04/26] libbtrfsutil: add btrfs_util_is_subvolume() and btrfs_util_subvolume_id()

On 29.01.2018 23:43, Omar Sandoval wrote: > On Mon, Jan 29, 2018 at 12:24:26PM +0200, Nikolay Borisov wrote: >> On 26.01.2018 20:40, Omar Sandoval wrote: > [snip] >>> +/* >>> + * This intentionally duplicates btrfs_util_f_is_subvolume() instead of >>> opening >>> + * a file descriptor and

[PATCH 0/2] Policy to balance read across mirrored devices

In case of RAID1 and RAID10 devices are mirror-ed, a read IO can pick any device for reading. This choice of picking a device for reading should be configurable. In short not one policy would satisfy all types of workload and configs. So before we add more policies, this patch-set makes existing

[PATCH 2/2] btrfs: add read_mirror_policy parameter devid

Adds the mount option: mount -o read_mirror_policy= To set the devid of the device which should be used for read. That means all the normal reads will go to that particular device only. This also helps testing and gives a better control for the test scripts including mount context reads.

[PATCH 2/2] btrfs: drop optimal argument from find_live_mirror()

Drop optimal argument from the function find_live_mirror() as we can deduce it in the function itself. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c

[PATCH 1/2] btrfs: add mount option read_mirror_policy

In case of RAID1 and RAID10 devices are mirror-ed, a read IO can pick any device for reading. This choice of picking a device for reading should be configurable. In short not one policy would satisfy all types of workload and configs. So before we add more policies, this patch-set makes existing

[PATCH 0/2] Preparatory to add read_mirror mount option

Adds cleanups to find_live_mirror(), so that we can add more policy on how the read mirror device should be found. Anand Jain (2): btrfs: drop num argument from find_live_mirror() btrfs: drop optimal argument from find_live_mirror() fs/btrfs/volumes.c | 20 ++-- 1 file

Re: [PATCH v2 7/7] btrfs-progs: Cleanup use of root in leaf_data_end

On 2018年01月26日 15:26, Gu Jinxiang wrote: > In function leaf_data_end, root is just used to get fs_info, > so change the parameter of this function from btrfs_root to > btrfs_fs_info. > And also make it consistent with kernel. > > Signed-off-by: Gu Jinxiang > --- > ctree.c

[PATCH 1/3] btrfs: Refactor __get_raid_index() to btrfs_bg_flags_to_raid_index()

Function __get_raid_index() is used to convert block group flags into raid index, which can be used to get various info directly from btrfs_raid_array[]. Refactor this function a little: 1) Rename to btrfs_bg_flags_to_raid_index() Double underline prefix is normally for internal functions,

[PATCH 2/3] btrfs: Unexport get_block_group_index()

That function is only used inside extent-tree.c. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 1 - fs/btrfs/extent-tree.c | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 13c260b525a1..27249240fa3e 100644

[PATCH 3/3] btrfs: Refactor parameter of BTRFS_MAX_DEVS() from root to fs_info

Signed-off-by: Qu Wenruo --- fs/btrfs/volumes.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index d818b1f9c625..215e85e22c8e 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4581,7 +4581,7 @@ static