Re: [PATCH v2] btrfs-progs: ctree: Add extra level check for read_node_slot()

2018-02-09 Thread Nikolay Borisov
On 9.02.2018 09:44, Qu Wenruo wrote: > Strangely, we have level check in btrfs_print_tree() while we don't have > the same check in read_node_slot(). > > That's to say, for the following corruption, btrfs_search_slot() or > btrfs_next_leaf() can return invalid leaf: > > Parent eb: > node XXX

Re: [PATCH v2 10/10] btrfs-progs: Refactor btrfs_alloc_chunk to mimic kernel structure and behavior

2018-02-09 Thread Nikolay Borisov
On 9.02.2018 09:44, Qu Wenruo wrote: > Kernel uses a delayed chunk allocation behavior for metadata chunks > > KERNEL: > btrfs_alloc_chunk() > |- __btrfs_alloc_chunk(): Only allocate chunk mapping >|- btrfs_make_block_group(): Add corresponding bg to fs_info->new_bgs > > Then at

Re: [PATCH 0/4] Btrfs: just bunch of patches to ioctl.c

2018-02-09 Thread Timofey Titovets
Gentle ping 2018-01-09 13:53 GMT+03:00 Timofey Titovets : > Gentle ping > > 2017-12-19 13:02 GMT+03:00 Timofey Titovets : >> 1st patch, remove 16MiB restriction from extent_same ioctl(), >> by doing iterations over passed range. >> >> I did not see much difference in performance, so it's just remo

[PATCH] btrfs: Move error handling of btrfs_start_dirty_block_groups closer to call site

2018-02-09 Thread Nikolay Borisov
Even though btrfs_start_dirty_block_groups fairly in the beginning of btrfs_commit_transaction outside of the critical section defined by the transaction states it can only be run by a single comitter. In other words it defines its own critical section thanks to the BTRFS_TRANS_DIRTY_BG run flag an

Re: [PATCH v2 10/10] btrfs-progs: Refactor btrfs_alloc_chunk to mimic kernel structure and behavior

2018-02-09 Thread Qu Wenruo
On 2018年02月09日 16:17, Nikolay Borisov wrote: > > > On 9.02.2018 09:44, Qu Wenruo wrote: >> Kernel uses a delayed chunk allocation behavior for metadata chunks >> >> KERNEL: >> btrfs_alloc_chunk() >> |- __btrfs_alloc_chunk():Only allocate chunk mapping >>|- btrfs_make_block_group():

Re: [PATCH v2] btrfs-progs: ctree: Add extra level check for read_node_slot()

2018-02-09 Thread Qu Wenruo
On 2018年02月09日 16:09, Nikolay Borisov wrote: > > > On 9.02.2018 09:44, Qu Wenruo wrote: >> Strangely, we have level check in btrfs_print_tree() while we don't have >> the same check in read_node_slot(). >> >> That's to say, for the following corruption, btrfs_search_slot() or >> btrfs_next_lea

btrfs-cleaner / snapshot performance analysis

2018-02-09 Thread Ellis H. Wilson III
Hi all, I am trying to better understand how the cleaner kthread (btrfs-cleaner) impacts foreground performance, specifically during snapshot deletion. My experience so far has been that it can be dramatically disruptive to foreground I/O. Looking through the wiki at kernel.org I have not ye

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

2018-02-09 Thread Goffredo Baroncelli
On 02/08/2018 08:07 PM, Liu Bo wrote: > On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote: >> On 02/06/2018 12:15 AM, Liu Bo wrote: >> [...] >>> One way to mitigate the data loss pain is to expose 'bad chunks', >>> i.e. degraded chunks, to users, so that they can use 'btrfs balanc

Re: btrfs-cleaner / snapshot performance analysis

2018-02-09 Thread Peter Grandi
> I am trying to better understand how the cleaner kthread > (btrfs-cleaner) impacts foreground performance, specifically > during snapshot deletion. My experience so far has been that > it can be dramatically disruptive to foreground I/O. That's such a warmly innocent and optimistic question! Th

Re: btrfs-cleaner / snapshot performance analysis

2018-02-09 Thread Hans van Kranenburg
On 02/09/2018 05:45 PM, Ellis H. Wilson III wrote: > > I am trying to better understand how the cleaner kthread (btrfs-cleaner) > impacts foreground performance, specifically during snapshot deletion. > My experience so far has been that it can be dramatically disruptive to > foreground I/O. > >