Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 19.01.2018 12:39, Qu Wenruo wrote: > > > On 2018年01月19日 18:21, Nikolay Borisov wrote: >> >> >> On 19.01.2018 12:03, Qu Wenruo wrote: >>> >>> >>> On 2018年01月19日 17:40, Nikolay Borisov wrote: On 19.01.2018 09:25, Qu Wenruo wrote: > btrfs_match_dir_item_name() will check if

Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

On Fri, Jan 19, 2018 at 09:36:34AM -0500, Jeff Layton wrote: > Shrug...we have that problem with the spinlock in place too. The bottom > line is that reads of this value are not serialized with the increment > at all. OK, so this wouldn't even be a new bug. > I'm not 100% thrilled with this

Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

On Thu, 2018-01-18 at 16:45 -0500, J. Bruce Fields wrote: > On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > The rationale for taking the i_lock when incrementing this value is > > lost in antiquity. The readers of the field don't

Re: [PATCH v2 09/10] Btrfs: add tracepoint for em's EEXIST case

On 19.01.2018 20:15, David Sterba wrote: > On Fri, Jan 05, 2018 at 12:51:16PM -0700, Liu Bo wrote: >> This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the >> subtle bugs around merge_extent_mapping. >> >> Signed-off-by: Liu Bo > > Nikolay has some

Re: [PATCH v2 09/10] Btrfs: add tracepoint for em's EEXIST case

On Fri, Jan 05, 2018 at 12:51:16PM -0700, Liu Bo wrote: > This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the > subtle bugs around merge_extent_mapping. > > Signed-off-by: Liu Bo Nikolay has some concernas about adding the tracepoint, so I'll leave this

btrfs volume corrupt. btrfs-progs bug or need to rebuild volume?

v2: Add proper subject I've been playing around with a specific kernel on a specific device trying to figure out why btrfs keeps throwing csum errors after ~15 hours. I've almost nailed it down to some specific CONFIG option in the kernel, possibly related to IRQs. Anyway, I managed to get my

Re: [PATCH RESEND v4 0/4] device_list_add() peparation to add reappearing missing device

On Thu, Jan 18, 2018 at 06:47:17PM +0100, David Sterba wrote: > On Thu, Jan 18, 2018 at 10:02:32PM +0800, Anand Jain wrote: > > (Apply on top of my patchset > >[PATCH v4 0/6] preparatory work to add device forget > > for conflict free apply. They don't actually depend on > > each other

Re: [PATCH] btrfs: Use IS_ALIGNED in btrfs_truncate_block instead of opencoding it

On Fri, Jan 19, 2018 at 08:45:40AM +0800, Qu Wenruo wrote: > > > On 2018年01月18日 20:47, Nikolay Borisov wrote: > > No functional changes, just makes the code more readable > > > > Signed-off-by: Nikolay Borisov > > Reviewed-by: Qu Wenruo Thanks, added to

Re: [PATCH v2 09/10] Btrfs: add tracepoint for em's EEXIST case

On Fri, Jan 19, 2018 at 08:22:36PM +0200, Nikolay Borisov wrote: > > > On 19.01.2018 20:15, David Sterba wrote: > > On Fri, Jan 05, 2018 at 12:51:16PM -0700, Liu Bo wrote: > >> This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the > >> subtle bugs around merge_extent_mapping. >

Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 01/19/2018 03:38 PM, Qu Wenruo wrote: On 2018年01月19日 15:39, Su Yue wrote: On 01/19/2018 03:25 PM, Qu Wenruo wrote: btrfs_match_dir_item_name() will check if its filetype is valid before doing search, this makes btrfs-progs unable to locate and remove invalid dir_index for

Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 19.01.2018 12:03, Qu Wenruo wrote: > > > On 2018年01月19日 17:40, Nikolay Borisov wrote: >> >> >> On 19.01.2018 09:25, Qu Wenruo wrote: >>> btrfs_match_dir_item_name() will check if its filetype is valid before >>> doing search, this makes btrfs-progs unable to locate and remove invalid >>>

Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 2018年01月19日 18:21, Nikolay Borisov wrote: > > > On 19.01.2018 12:03, Qu Wenruo wrote: >> >> >> On 2018年01月19日 17:40, Nikolay Borisov wrote: >>> >>> >>> On 19.01.2018 09:25, Qu Wenruo wrote: btrfs_match_dir_item_name() will check if its filetype is valid before doing search, this

Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 2018年01月19日 17:40, Nikolay Borisov wrote: > > > On 19.01.2018 09:25, Qu Wenruo wrote: >> btrfs_match_dir_item_name() will check if its filetype is valid before >> doing search, this makes btrfs-progs unable to locate and remove invalid >> dir_index for btrfs_unlink().> >> This function only

Re: [PATCH v2 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 19.01.2018 09:25, Qu Wenruo wrote: > btrfs_match_dir_item_name() will check if its filetype is valid before > doing search, this makes btrfs-progs unable to locate and remove invalid > dir_index for btrfs_unlink().> > This function only affects btrfs_link() and btrfs_unlink() in upper >

Re: [PATCH v2 3/3] btrfs-progs: dir-item: Make btrfs_delete_one_dir_name more robust to handle corrupted name len

On 19.01.2018 09:25, Qu Wenruo wrote: > Function btrfs_delete_one_dir_name() will check if the dir_item is the > last content of the item, and delete the whole item if needed. > > However if @name_len of one dir_item/dir_index is corrupted and larger > than the item size, the function will

Re: btrfs volume corrupt. btrfs-progs bug or need to rebuild volume?

Rosen Penev posted on Fri, 19 Jan 2018 13:45:35 -0800 as excerpted: > v2: Add proper subject =:^) > I've been playing around with a specific kernel on a specific device > trying to figure out why btrfs keeps throwing csum errors after ~15 > hours. I've almost nailed it down to some specific