RE: [PATCH 00/17] fs, btrfs refcount conversions

> At 03/06/2017 05:43 PM, Reshetova, Elena wrote: > > > >> At 03/03/2017 04:55 PM, Elena Reshetova wrote: > >>> Now when new refcount_t type and API are finally merged > >>> (see include/linux/refcount.h), the following > >>> patches convert various refcounters in the btrfs filesystem from

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/06/2017 05:43 PM, Reshetova, Elena wrote: At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By

Re: [PATCH v2 4/6] btrfs: Allow barrier_all_devices to do chunk level device check

At 03/07/2017 02:55 PM, Anand Jain wrote: 1) About reentrancy In previous version, the err_* bits are still put into btrfs_devices structure, just timing of resetting these bits are changes. So either way, it's not reentrant in theory. But that doesn't make a problem, as we have other

[PATCH] btrfs: fix a bogus warning when converting only data or metadata

If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs balance -dconvert=raid1", the meta.target field will be uninitialized. That's otherwise ok, as it's unused except for this warning. Thus, let's use the existing set of raid levels for the comparison. As a side effect,

Re: [PATCH] Btrfs: fix regression in lock_delalloc_pages

At 03/07/2017 10:20 AM, Liu Bo wrote: The bug is a regression after commit (da2c7009f6ca "btrfs: teach __process_pages_contig about PAGE_LOCK operation") and commit (76c0021db8fd "Btrfs: use helper to simplify lock/unlock pages"). So if the dirty pages which are under writeback got truncated

Re: [PATCH v2 4/6] btrfs: Allow barrier_all_devices to do chunk level device check

At 03/07/2017 12:48 PM, Anand Jain wrote: On 03/06/2017 04:58 PM, Qu Wenruo wrote: The last user of num_tolerated_disk_barrier_failures is barrier_all_devices(). But it's can be easily changed to new per-chunk degradable check framework. Now btrfs_device will have two extra members,

Re: [PATCH v2 6/6] btrfs: Enhance missing device kernel message

On 03/06/2017 04:58 PM, Qu Wenruo wrote: For missing device, btrfs will just refuse to mount with almost meaningless kernel message like: BTRFS info (device vdb6): disk space caching is enabled BTRFS info (device vdb6): has skinny extents BTRFS error (device vdb6): failed to read the

Re: [PATCH 1/2] Btrfs: fix unexpected file hole after disk errors

On Wed, Mar 01, 2017 at 10:44:53AM +0800, Qu Wenruo wrote: > > > At 03/01/2017 09:04 AM, Liu Bo wrote: > > Btrfs creates hole extents to cover any unwritten section right before > > doing buffer writes after commit 3ac0d7b96a26 ("btrfs: Change the expanding > > write sequence to fix snapshot

[PATCH] Btrfs: fix regression in lock_delalloc_pages

The bug is a regression after commit (da2c7009f6ca "btrfs: teach __process_pages_contig about PAGE_LOCK operation") and commit (76c0021db8fd "Btrfs: use helper to simplify lock/unlock pages"). So if the dirty pages which are under writeback got truncated partially before we lock the dirty pages,

Re: [PATCH v2 0/6] Chunk level degradable check

On Tue, Mar 07, 2017 at 09:35:56AM +0800, Qu Wenruo wrote: > At 03/07/2017 08:36 AM, Adam Borowski wrote: > > Not so for -draid5 -mraid1, unfortunately: > > Unfortunately, for raid5 there are still unfixed bugs. > In fact, some raid5/6 bugs are already fixed, but still not merged yet. > > >

Re: [PATCH 0/5] raid56: variant bug fixes

So raid56 bug fixes are the same case as qgroup fixes now? No reviewer so no merge? I understand we need enough reviewer, however there is never enough reviewer for *minor* functions, like qgroup or raid56. Such situation will just make such functions starve, bugs makes fewer tester and

Re: Btrfs progs pre-release 4.10-rc1

Hi David, On 2017/03/02 23:59, David Sterba wrote: > Hi, > > a pre-release has been tagged. There are patches that have queued so far, but > I haven't gone through everything that's in the mailinglist. The 4.10 release > ETA is next week so I'll try to process the backlog and merge what would

Re: assertion failed: page_ops & PAGE_LOCK

On Sun, Mar 05, 2017 at 11:59:17AM -0500, Dave Jones wrote: > After commenting out the assertion that Liu bo pointed out was bogus, > my trinity runs last a little longer.. This is a new one I think.. > Could you please try this patch? Thanks, -liubo diff --git a/fs/btrfs/extent_io.c

Re: [PATCH v2 0/6] Chunk level degradable check

At 03/07/2017 08:36 AM, Adam Borowski wrote: On Mon, Mar 06, 2017 at 04:58:49PM +0800, Qu Wenruo wrote: Btrfs currently uses num_tolerated_disk_barrier_failures to do global check for tolerated missing device. Although the one-size-fit-all solution is quite safe, it's too strict if data and

Re: [PATCH v2 0/6] Chunk level degradable check

On Mon, Mar 06, 2017 at 04:58:49PM +0800, Qu Wenruo wrote: > Btrfs currently uses num_tolerated_disk_barrier_failures to do global > check for tolerated missing device. > > Although the one-size-fit-all solution is quite safe, it's too strict if > data and metadata has different duplication

Re: [PATCH v2] Btrfs: fix unexpected file hole after disk errors

At 03/07/2017 04:23 AM, Liu Bo wrote: Btrfs creates hole extents to cover any unwritten section right before doing buffer writes after commit 3ac0d7b96a26 ("btrfs: Change the expanding write sequence to fix snapshot related bug."). However, that takes the start position of the buffered write

[PATCH 2/2] Btrfs: fix invalid attempt to free reserved space on failure to cow range

From: Filipe Manana When attempting to COW a file range (we are starting writeback and doing COW), if we manage to reserve an extent for the range we will write into but fail after reserving it and before creating the respective ordered extent, we end up in an error path where

[PATCH 1/2] Btrfs: remove unused delalloc_end parameter

From: Filipe Manana The delalloc_end parameter for extent_clear_unlock_delalloc() is never used, and only making the code for all callers longer and more complex. Just remove it. Signed-off-by: Filipe Manana --- fs/btrfs/extent_io.c | 2 +-

Re: [PATCH] Btrfs: fix file corruption after cloning inline extents

On Fri, Mar 3, 2017 at 6:48 PM, Liu Bo wrote: > On Fri, Mar 03, 2017 at 03:36:36PM +, Filipe Manana wrote: >> On Fri, Mar 3, 2017 at 12:36 AM, Liu Bo wrote: >> > On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wrote: >> >> On Tue, Jul 14, 2015 at

Re: [PATCH v6 2/2] btrfs: Handle delalloc error correctly to avoid ordered extent hang

On Mon, Mar 6, 2017 at 2:55 AM, Qu Wenruo wrote: > [BUG] > If run_delalloc_range() returns error and there is already some ordered > extents created, btrfs will be hanged with the following backtrace: > > Call Trace: > __schedule+0x2d4/0xae0 > schedule+0x3d/0x90 >

Re: [PATCH v6 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

On Mon, Mar 6, 2017 at 2:55 AM, Qu Wenruo wrote: > [BUG] > When btrfs_reloc_clone_csum() reports error, it can underflow metadata > and leads to kernel assertion on outstanding extents in > run_delalloc_nocow() and cow_file_range(). > > BTRFS info (device vdb5):

Re: [PATCH 4/7] mm: introduce memalloc_nofs_{save,restore} API

On Mon, 6 Mar 2017 14:14:05 +0100 Michal Hocko wrote: > From: Michal Hocko > > GFP_NOFS context is used for the following 5 reasons currently > - to prevent from deadlocks when the lock held by the allocation > context would be needed during

Re: [PATCH 2/2] Btrfs: remove start_pos

On Wed, Mar 01, 2017 at 04:48:20PM +0800, Qu Wenruo wrote: > > > At 03/01/2017 09:04 AM, Liu Bo wrote: > > @pos, not aligned @start_pos, should be used to check whether the eof page > > needs to be marked as readonly, thus @start_pos can be removed. > > > > Signed-off-by: Liu Bo

[PATCH v2] Btrfs: fix unexpected file hole after disk errors

Btrfs creates hole extents to cover any unwritten section right before doing buffer writes after commit 3ac0d7b96a26 ("btrfs: Change the expanding write sequence to fix snapshot related bug."). However, that takes the start position of the buffered write to compare against the current EOF, hole

[PATCH] Btrfs: update comments in cache_save_setup

We also don't bother to flush free space cache while with free space tree. Cc: David Sterba Signed-off-by: Liu Bo --- fs/btrfs/extent-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/extent-tree.c

Re: assertion failed: page_ops & PAGE_LOCK

On Sun, Mar 05, 2017 at 11:59:17AM -0500, Dave Jones wrote: > After commenting out the assertion that Liu bo pointed out was bogus, > my trinity runs last a little longer.. This is a new one I think.. I hit this once, haven't got enough info. to check what went wrong, but I'm working on it.

Re: [PATCH 2/7] Btrfs: separate DISCARD from __btrfs_map_block

On Mon, Feb 20, 2017 at 11:54:31AM +0800, Qu Wenruo wrote: > > > At 02/18/2017 09:28 AM, Liu Bo wrote: > > Since DISCARD is not as important as an operation like write, we don't > > copy it to target device during replace, and it makes __btrfs_map_block > > less complex. > > Makes sense to me.

Re: [PATCH] btrfs: Change s_flags instead of returning -EBUSY

On Sat, Mar 04, 2017 at 12:33:22PM -0600, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > The problem is with parallel mounting multiple subvolumes rw when the > root filesystem is marked as read-only such as a boot sequence > using systemd. Not all subvolumes will be

Re: [PATCH] btrfs: Change s_flags instead of returning -EBUSY

On Sat, Mar 04, 2017 at 12:33:22PM -0600, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > The problem is with parallel mounting multiple subvolumes rw when the > root filesystem is marked as read-only such as a boot sequence > using systemd. Not all subvolumes will be

Re: [PATCH v2 0/6] Chunk level degradable check

On Mon, 6 Mar 2017 16:58:49 +0800 Qu Wenruo wrote: > Btrfs currently uses num_tolerated_disk_barrier_failures to do global > check for tolerated missing device. > > Although the one-size-fit-all solution is quite safe, it's too strict > if data and metadata has

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 11:17 AM, Avi Kivity wrote: > > > On 03/06/2017 07:06 PM, Jens Axboe wrote: >> On 03/06/2017 09:59 AM, Avi Kivity wrote: >>> >>> On 03/06/2017 06:08 PM, Jens Axboe wrote: On 03/06/2017 08:59 AM, Avi Kivity wrote: > On 03/06/2017 05:38 PM, Jens Axboe wrote: >> On

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 08:27 PM, Jens Axboe wrote: On 03/06/2017 11:17 AM, Avi Kivity wrote: On 03/06/2017 07:06 PM, Jens Axboe wrote: On 03/06/2017 09:59 AM, Avi Kivity wrote: On 03/06/2017 06:08 PM, Jens Axboe wrote: On 03/06/2017 08:59 AM, Avi Kivity wrote: On 03/06/2017 05:38 PM, Jens Axboe

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 07:06 PM, Jens Axboe wrote: On 03/06/2017 09:59 AM, Avi Kivity wrote: On 03/06/2017 06:08 PM, Jens Axboe wrote: On 03/06/2017 08:59 AM, Avi Kivity wrote: On 03/06/2017 05:38 PM, Jens Axboe wrote: On 03/06/2017 08:29 AM, Avi Kivity wrote: On 03/06/2017 05:19 PM, Jens Axboe

Re: [PATCH 0/9 PULL REQUEST] Qgroup fixes for 4.11

On 03/06/2017 11:44 AM, David Sterba wrote: On Mon, Mar 06, 2017 at 04:08:41PM +0800, Qu Wenruo wrote: Any response? These patches are already here for at least 2 kernel releases. And are all bug fixes, and fix bugs that are already reported. I didn't see any reason why it should be delayed

Re: [PATCH] btrfs: No need to check !(flags & MS_RDONLY) twice

On Sat, Mar 04, 2017 at 12:32:50PM -0600, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > Code cleanup. > The code block is for !(*flags & MS_RDONLY). We don't need > to check it again. Reviewed-by: Omar Sandoval > Signed-off-by: Goldwyn Rodrigues

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 06:08 PM, Jens Axboe wrote: On 03/06/2017 08:59 AM, Avi Kivity wrote: On 03/06/2017 05:38 PM, Jens Axboe wrote: On 03/06/2017 08:29 AM, Avi Kivity wrote: On 03/06/2017 05:19 PM, Jens Axboe wrote: On 03/06/2017 01:25 AM, Jan Kara wrote: On Sun 05-03-17 16:56:21, Avi Kivity

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 09:59 AM, Avi Kivity wrote: > > > On 03/06/2017 06:08 PM, Jens Axboe wrote: >> On 03/06/2017 08:59 AM, Avi Kivity wrote: >>> On 03/06/2017 05:38 PM, Jens Axboe wrote: On 03/06/2017 08:29 AM, Avi Kivity wrote: > On 03/06/2017 05:19 PM, Jens Axboe wrote: >> On 03/06/2017

Re: [PATCH 0/9 PULL REQUEST] Qgroup fixes for 4.11

On Mon, Mar 06, 2017 at 04:08:41PM +0800, Qu Wenruo wrote: > Any response? > > These patches are already here for at least 2 kernel releases. > And are all bug fixes, and fix bugs that are already reported. > > I didn't see any reason why it should be delayed for so long time. The reason is not

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 08:59 AM, Avi Kivity wrote: > On 03/06/2017 05:38 PM, Jens Axboe wrote: >> On 03/06/2017 08:29 AM, Avi Kivity wrote: >>> >>> On 03/06/2017 05:19 PM, Jens Axboe wrote: On 03/06/2017 01:25 AM, Jan Kara wrote: > On Sun 05-03-17 16:56:21, Avi Kivity wrote: >>> The goal of

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 05:38 PM, Jens Axboe wrote: On 03/06/2017 08:29 AM, Avi Kivity wrote: On 03/06/2017 05:19 PM, Jens Axboe wrote: On 03/06/2017 01:25 AM, Jan Kara wrote: On Sun 05-03-17 16:56:21, Avi Kivity wrote: The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if any of these

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 08:29 AM, Avi Kivity wrote: > > > On 03/06/2017 05:19 PM, Jens Axboe wrote: >> On 03/06/2017 01:25 AM, Jan Kara wrote: >>> On Sun 05-03-17 16:56:21, Avi Kivity wrote: > The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if > any of these conditions are met. This

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 05:19 PM, Jens Axboe wrote: On 03/06/2017 01:25 AM, Jan Kara wrote: On Sun 05-03-17 16:56:21, Avi Kivity wrote: The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if any of these conditions are met. This way userspace can push most of the write()s to the kernel to

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 01:25 AM, Jan Kara wrote: > On Sun 05-03-17 16:56:21, Avi Kivity wrote: >>> The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if >>> any of these conditions are met. This way userspace can push most >>> of the write()s to the kernel to the best of its ability to complete

[PATCH 2/7] lockdep: allow to disable reclaim lockup detection

From: Michal Hocko The current implementation of the reclaim lockup detection can lead to false positives and those even happen and usually lead to tweak the code to silence the lockdep by using GFP_NOFS even though the context can use __GFP_FS just fine. See

[PATCH 7/7] jbd2: make the whole kjournald2 kthread NOFS safe

From: Michal Hocko kjournald2 is central to the transaction commit processing. As such any potential allocation from this kernel thread has to be GFP_NOFS. Make sure to mark the whole kernel thread GFP_NOFS by the memalloc_nofs_save. Suggested-by: Jan Kara

[PATCH 6/7] jbd2: mark the transaction context with the scope GFP_NOFS context

From: Michal Hocko now that we have memalloc_nofs_{save,restore} api we can mark the whole transaction context as implicitly GFP_NOFS. All allocations will automatically inherit GFP_NOFS this way. This means that we do not have to mark any of those requests with GFP_NOFS and

[PATCH 3/7] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

From: Michal Hocko xfs has defined PF_FSTRANS to declare a scope GFP_NOFS semantic quite some time ago. We would like to make this concept more generic and use it for other filesystems as well. Let's start by giving the flag a more generic name PF_MEMALLOC_NOFS which is in line

[PATCH 1/7] lockdep: teach lockdep about memalloc_noio_save

From: Nikolay Borisov Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O during memory allocation") added the memalloc_noio_(save|restore) functions to enable people to modify the MM behavior by disabling I/O during memory allocation. This was further

[PATCH 0/7 v5] scope GFP_NOFS api

Hi, I have posted the previous version here [1]. There are no real changes in the implementation since then. I've just added "lockdep: teach lockdep about memalloc_noio_save" from Nikolay which is a lockdep bugfix developed independently but "mm: introduce memalloc_nofs_{save,restore} API" depends

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On 2017-03-05 14:13, Peter Grandi wrote: What makes me think that "unmirrored" 'raid1' profile chunks are "not a thing" is that it is impossible to remove explicitly a member device from a 'raid1' profile volume: first one has to 'convert' to 'single', and then the 'remove' copies back to the

[PATCH 4/7] mm: introduce memalloc_nofs_{save,restore} API

From: Michal Hocko GFP_NOFS context is used for the following 5 reasons currently - to prevent from deadlocks when the lock held by the allocation context would be needed during the memory reclaim - to prevent from stack overflows during the reclaim

[PATCH 5/7] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

From: Michal Hocko kmem_zalloc_large and _xfs_buf_map_pages use memalloc_noio_{save,restore} API to prevent from reclaim recursion into the fs because vmalloc can invoke unconditional GFP_KERNEL allocations and these functions might be called from the NOFS contexts. The

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On 2017-03-03 15:10, Kai Krakow wrote: Am Fri, 3 Mar 2017 07:19:06 -0500 schrieb "Austin S. Hemmelgarn" : On 2017-03-03 00:56, Kai Krakow wrote: Am Thu, 2 Mar 2017 11:37:53 +0100 schrieb Adam Borowski : On Wed, Mar 01, 2017 at 05:30:37PM -0700,

lockdep splat on latest master

Hello, Running generic/208 on latest linux master I got the following splat: [ 3540.719007] == [ 3540.719007] [ INFO: possible circular locking dependency detected ] [ 3540.719007] 4.11.0-rc1-nbor #147 Tainted: GW [ 3540.719007]

Re: [PATCH 7/8] Revert "ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp"

On Tue 17-01-17 08:54:50, Michal Hocko wrote: > On Mon 16-01-17 22:01:18, Theodore Ts'o wrote: > > On Fri, Jan 06, 2017 at 03:11:06PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because > > >

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

On Montag, 6. März 2017 00:53:40 CET Marc Joliet wrote: > On Mittwoch, 1. März 2017 19:14:07 CET you wrote: > > In any > > > > case, I started btrfs-check on the device itself. > > *Sigh*, I had to restart it, because I forgot to redirect to a file and > quite frankly wasn't expecting this

[PATCH v2 4/6] btrfs: Allow barrier_all_devices to do chunk level device check

The last user of num_tolerated_disk_barrier_failures is barrier_all_devices(). But it's can be easily changed to new per-chunk degradable check framework. Now btrfs_device will have two extra members, representing send/wait error, set at write_dev_flush() time. With these 2 new members,

[PATCH v2 3/6] btrfs: Do chunk level degradation check for remount

Just the same for mount time check, use btrfs_check_rw_degradable() to check if we are OK to be remounted rw. Signed-off-by: Qu Wenruo --- fs/btrfs/super.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index

[PATCH v2 2/6] btrfs: Do chunk level rw degrade check at mount time

Now use the btrfs_check_rw_degradable() to do mount time degration check. With this patch, now we can mount with the following case: # mkfs.btrfs -f -m raid1 -d single /dev/sdb /dev/sdc # wipefs -a /dev/sdc # mount /dev/sdb /mnt/btrfs -o degraded As the single data chunk is only in sdb, so

[PATCH v2 1/6] btrfs: Introduce a function to check if all chunks a OK for degraded rw mount

Introduce a new function, btrfs_check_rw_degradable(), to check if all chunks in btrfs is OK for degraded rw mount. It provides the new basis for accurate btrfs mount/remount and even runtime degraded mount check other than old one-size-fit-all method. Signed-off-by: Qu Wenruo

[PATCH v2 5/6] btrfs: Cleanup num_tolerated_disk_barrier_failures

As we use per-chunk degradable check, now the global num_tolerated_disk_barrier_failures is of no use. So cleanup it. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 2 -- fs/btrfs/disk-io.c | 54 --

[PATCH v2 6/6] btrfs: Enhance missing device kernel message

For missing device, btrfs will just refuse to mount with almost meaningless kernel message like: BTRFS info (device vdb6): disk space caching is enabled BTRFS info (device vdb6): has skinny extents BTRFS error (device vdb6): failed to read the system array: -5 BTRFS error (device vdb6):

[PATCH v2 0/6] Chunk level degradable check

Btrfs currently uses num_tolerated_disk_barrier_failures to do global check for tolerated missing device. Although the one-size-fit-all solution is quite safe, it's too strict if data and metadata has different duplication level. For example, if one use Single data and RAID1 metadata for 2

Re: [PATCH 0/8 v2] Non-blocking AIO

On Sun 05-03-17 16:56:21, Avi Kivity wrote: > >The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if > >any of these conditions are met. This way userspace can push most > >of the write()s to the kernel to the best of its ability to complete > >and if it returns -EAGAIN, can defer it

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/06/2017 10:25 AM, Jan Kara wrote: On Sun 05-03-17 16:56:21, Avi Kivity wrote: The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if any of these conditions are met. This way userspace can push most of the write()s to the kernel to the best of its ability to complete and if it

Re: [PATCH 0/9 PULL REQUEST] Qgroup fixes for 4.11

Any response? These patches are already here for at least 2 kernel releases. And are all bug fixes, and fix bugs that are already reported. I didn't see any reason why it should be delayed for so long time. Thanks, Qu At 02/27/2017 03:10 PM, Qu Wenruo wrote: Pull request can be fetched from