Re: [PATCH 00/10] Simplify function interfaces

On 27.03.2018 10:19, Nikolay Borisov wrote: > A bunch of functions in lowmem mode take an 'ext_ref' parameter only to pass > it > down the call chain where it eventually is consumed. Turns out the functions > which actually check the parameter are find_inode_ref and check_inode_item, > the >

Re: [PATCH 1/2] btrfs-progs: Fix DIR_ITEM checking in lowmem

On 23.03.2018 16:48, Nikolay Borisov wrote: > When checking the validity of a DIR_ITEM item the index variable > is explicitly set to -1 so that the index check in find_inode_ref() > is ignored. This is necessary due to possible name collisions in DIR_ITEMS > (i.e multiple files with the same

Re: BTRFS RAID filesystem unmountable

Thanks Qu, I actually aborted the run with the old btrfs tools once I saw its output. The new btrfs tools is still running and has produced a log file of ~85mb filled with that content so far. Kind regards Michael On 2 May 2018 at 02:31, Qu Wenruo wrote: > > > On

[PATCH] btrfs: qgroup: More meaningful qgroup_rescan_init error message

Error message from qgroup_rescan_init() mostly looks like: -- BTRFS info (device nvme0n1p1): qgroup_rescan_init failed with -115 -- Which is far from meaningful, and sometimes confusing as for above -EINPROGRESS it's mostly (despite the init race) harmless, but sometimes it can also

[PATCH V3 3/3] Btrfs: btrfs_extent_same() reuse cmp workspace

We support big dedup requests by split range to several smaller, and call dedup logic over each of them. Instead of alloc/dealloc on each, let's reuse allocated memory. Changes: v3: - Splited from one to 3 patches Signed-off-by: Timofey Titovets ---

[PATCH V3 2/3] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction

At now btrfs_dedupe_file_range() restricted to 16MiB range for limit locking time and memory requirement for dedup ioctl() For too big input range code silently set range to 16MiB Let's remove that restriction by do iterating over dedup range. That's backward compatible and will not change

[PATCH V3 1/3] Btrfs: split btrfs_extent_same() for simplification

Split btrfs_extent_same() for simplification and preparation for call several times over target files Move most logic to __btrfs_extent_same() And leave in btrfs_extent_same() things which must happens only once Changes: v3: - Splited from one to 3 patches Signed-off-by: Timofey Titovets

[PATCH V3 0/3] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction

At now btrfs_dedupe_file_range() restricted to 16MiB range for limit locking time and memory requirement for dedup ioctl() For too big input range code silently set range to 16MiB Let's remove that restriction by do iterating over dedup range. That's backward compatible and will not change

[PATCH] btrfs: Take trans lock before access running trans in check_delayed_ref

In preivous patch: Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist We avoid starting btrfs transaction and get transaction from fs_info->running_transaction directly. When accessing running_transaction in check_delayed_ref, there's a chance that current transaction will be freed

Re: [PATCH] btrfs: rename btrfs_balance_control::flags to b_flags

On 05/01/2018 01:08 AM, David Sterba wrote: On Mon, Apr 30, 2018 at 05:49:13PM +0800, Anand Jain wrote: As flags is a generic name, its often difficult to search, rename btrfs_balance_control::flags to btrfs_balance_control::b_flags. I don't think this one is necessary as it's always tied

Re: RAID56 - 6 parity raid

Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 + as excerpted: > Hi to all I've found some patches from Andrea Mazzoleni that adds > support up to 6 parity raid. > Why these are wasn't merged ? > With modern disk size, having something greater than 2 parity, would be > great. 1)

Re: BTRFS RAID filesystem unmountable

On 2018年05月01日 23:50, Michael Wade wrote: > Hi Qu, > > Oh dear that is not good news! > > I have been running the find root command since yesterday but it only > seems to be only be outputting the following message: > > ERROR: tree block bytenr 0 is not aligned to sectorsize 4096 It's mostly

RAID56 - 6 parity raid

Hi to all I've found some patches from Andrea Mazzoleni that adds support up to 6 parity raid. Why these are wasn't merged ? With modern disk size, having something greater than 2 parity, would be great. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: BTRFS RAID filesystem unmountable

Hi Qu, Oh dear that is not good news! I have been running the find root command since yesterday but it only seems to be only be outputting the following message: ERROR: tree block bytenr 0 is not aligned to sectorsize 4096 ERROR: tree block bytenr 0 is not aligned to sectorsize 4096 ERROR: tree

Re: [PATCH 4/4] [RESEND] Btrfs: reduce size of struct btrfs_inode

On Sat, Apr 28, 2018 at 10:01:57AM +, Timofey Titovets wrote: > May be i misunderstood something, but i was think that slab combine > several pages in continuous range, so object in slab can cross page > boundary. So, all calculation will be very depends on scale of slab > size. > > i.e. on

Re: [PATCH] Btrfs: send, fix missing truncate for inode with prealloc extent past eof

On Mon, Apr 30, 2018 at 07:05:07PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > An incremental send operation can miss a truncate operation when an inode > has an increased size in the send snapshot and a prealloc extent beyond > its size. > > Consider the

Re: [PATCH] btrfs: trace: Allow trace_qgroup_update_counters() to record old rfer/excl value

On Mon, Apr 30, 2018 at 03:04:44PM +0800, Qu Wenruo wrote: > Origin trace_qgroup_update_counters() only records qgroup id and its > reference count change. > > It's good enough to debug qgroup accounting change, but when rescan race > is involved, it's pretty hard to distinguish which

Re: [PATCH 0/5] Fix delalloc inodes leaking on btrfs unmount

On Fri, Apr 27, 2018 at 12:21:49PM +0300, Nikolay Borisov wrote: > After investigating crashes on generic/176 it turned that the culprit in fact > is the random failure induced by generic/019. As it happens, if on unmount > the > filesystem is in BTRFS_FS_STATE_ERROR then

Re: [PATCH] btrfs: modify path->reada in btrfs_shrink_device to READA_BACK

On Fri, Apr 27, 2018 at 04:22:07PM +0800, Gu Jinxiang wrote: > In btrfs_shrink_device, before btrfs_search_slot, path->reada is > set to READA_FORWARD. But I think READA_BACK is correct. > Since, > 1.key.offset is set to (u64)-1 > 2.After btrfs_search_slot, btrfs_previous_item is called. > So,

Re: [PATCH v2] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Fri, Apr 27, 2018 at 01:36:35PM +0800, Liu Bo wrote: > > What does btrfs_search_forward do as the first statement: > > > > 5115 int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key > > *min_key, > > 5116 struct btrfs_path *path, > > 5117

Re: [PATCH v2] btrfs: Take trans lock before access running trans in check_delayed_ref

On Sun, Apr 29, 2018 at 03:59:42PM +0800, ethanwu wrote: > In preivous patch: > Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist If you know which patch introduced the bug, please add it with the commit id and as Fixes: e4c3b2dcd144 ("Btrfs: kill trans in run_delalloc_nocow and

Re: [PATCH] btrfs: trace: Remove unnecessary fs_info parameter for btrfs__reserve_extent event class

On Sun, Apr 29, 2018 at 08:33:49AM +0800, Qu Wenruo wrote: > > > On 2018年04月29日 01:45, David Sterba wrote: > > On Sat, Apr 28, 2018 at 06:42:06PM +0200, David Sterba wrote: > >> On Thu, Apr 26, 2018 at 02:24:25PM +0800, Qu Wenruo wrote: > >>> fs_info can be extracted from

Re: stack trace during scrub

On 2018年05月01日 16:47, Jan Fajerski wrote: > The system has multiple btrfs filesystems (RAID1 and single device). > During last nights scrub the kernel logged the following stack trace > about 1.5h into the scrub: > > May 01 03:29:27 apollo kernel: [ cut here ] > May 01

stack trace during scrub

The system has multiple btrfs filesystems (RAID1 and single device). During last nights scrub the kernel logged the following stack trace about 1.5h into the scrub: May 01 03:29:27 apollo kernel: [ cut here ] May 01 03:29:27 apollo kernel: WARNING: CPU: 1 PID: 24395 at