Re: mkfs.btrfs/balance small-btrfs chunk size RFC

At 01/10/2017 11:55 AM, Duncan wrote: This post is triggered by a balance problem due to oversized chunks that I have currently. Proposal 1: Ensure maximum chunk sizes are less than 1/8 the size of the filesystem (down to where they can't be any smaller, at least). In fact, kernel created

mkfs.btrfs/balance small-btrfs chunk size RFC

This post is triggered by a balance problem due to oversized chunks that I have currently. Proposal 1: Ensure maximum chunk sizes are less than 1/8 the size of the filesystem (down to where they can't be any smaller, at least). Proposal 2: Drastically reduce default system chunk size on small

Re: [RFC] Converging userspace and kernel code

Goldwyn, Could you add a list what functionality in btrfs-progs will be using the 'core'. ? Thanks, Anand On 01/08/17 21:16, Goldwyn Rodrigues wrote: 1. Motivation While fixing user space tools for btrfs-progs, I found a couple of bugs which are already solved in kernel space but were

Re: [RFC] Converging userspace and kernel code

At 01/10/2017 09:46 AM, Darrick J. Wong wrote: On Mon, Jan 09, 2017 at 04:38:22PM -0500, Jeff Mahoney wrote: On 1/9/17 4:34 PM, Omar Sandoval wrote: On Mon, Jan 09, 2017 at 09:31:39AM -0600, Eric Sandeen wrote: On 1/8/17 8:11 PM, Qu Wenruo wrote: At 01/08/2017 09:16 PM, Goldwyn Rodrigues

Re: [RFC] Converging userspace and kernel code

On Mon, Jan 09, 2017 at 04:38:22PM -0500, Jeff Mahoney wrote: > On 1/9/17 4:34 PM, Omar Sandoval wrote: > > On Mon, Jan 09, 2017 at 09:31:39AM -0600, Eric Sandeen wrote: > >> On 1/8/17 8:11 PM, Qu Wenruo wrote: > >>> > >>> > >>> At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: > > 1.

Re: [RFC] Converging userspace and kernel code

On Tue, Jan 10, 2017 at 08:35:26AM +0800, Qu Wenruo wrote: > That depends on how independent the "core" btrfs part is. > > If completely independent,(Don't ever has any page/VFS/race code) I'm > completely fine with that. > > But the problem is, at least from current code base, even btrfs_path >

Re: [RFC] Converging userspace and kernel code

At 01/09/2017 08:06 PM, Goldwyn Rodrigues wrote: On 01/08/2017 08:11 PM, Qu Wenruo wrote: At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: 1. Motivation While fixing user space tools for btrfs-progs, I found a couple of bugs which are already solved in kernel space but were not ported

Re: [RFC] Converging userspace and kernel code

On 1/9/17 4:34 PM, Omar Sandoval wrote: > On Mon, Jan 09, 2017 at 09:31:39AM -0600, Eric Sandeen wrote: >> On 1/8/17 8:11 PM, Qu Wenruo wrote: >>> >>> >>> At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: 1. Motivation While fixing user space tools for btrfs-progs, I found a couple

Re: [RFC] Converging userspace and kernel code

On Mon, Jan 09, 2017 at 09:31:39AM -0600, Eric Sandeen wrote: > On 1/8/17 8:11 PM, Qu Wenruo wrote: > > > > > > At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: > >> > >> 1. Motivation > >> While fixing user space tools for btrfs-progs, I found a couple of bugs > >> which are already solved in

Re: [PATCH 2/8] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

On Fri, Jan 06, 2017 at 03:11:01PM +0100, Michal Hocko wrote: > 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

Re: [PATCH 4/8] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

On Fri, Jan 06, 2017 at 03:11:03PM +0100, Michal Hocko wrote: > 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

Re: [PATCH 4/8] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

On Fri, Jan 06, 2017 at 03:11:03PM +0100, Michal Hocko wrote: > 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

Re: [RFC] Converging userspace and kernel code

On 1/8/17 8:11 PM, Qu Wenruo wrote: > > > At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: >> >> 1. Motivation >> While fixing user space tools for btrfs-progs, I found a couple of bugs >> which are already solved in kernel space but were not ported to user >> space. User space is a little

[PATCH 1/2] etrfs: fix up misleading GFP_NOFS usage in btrfs_releasepage

From: Michal Hocko b335b0034e25 ("Btrfs: Avoid using __GFP_HIGHMEM with slab allocator") has reduced the allocation mask in btrfs_releasepage to GFP_NOFS just to prevent from giving an unappropriate gfp mask to the slab allocator deeper down the callchain (in

[PATCH 2/2] btrfs: drop gfp mask tweaking in try_release_extent_state

From: Michal Hocko try_release_extent_state reduces the gfp mask to GFP_NOFS if it is compatible. This is true for GFP_KERNEL as well. There is no real reason to do that though. There is no new lock taken down the the only consumer of the gfp mask which is

Re: [PATCH 2/8] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

On Mon 09-01-17 13:59:05, Vlastimil Babka wrote: > On 01/06/2017 03:11 PM, Michal Hocko wrote: > > 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

Re: [PATCH 4/8] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

On Mon 09-01-17 15:08:27, Vlastimil Babka wrote: > On 01/06/2017 03:11 PM, Michal Hocko wrote: > > 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 > >

Re: [PATCH 4/8] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

On 01/06/2017 03:11 PM, Michal Hocko wrote: > 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

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On 01/09/2017 02:42 PM, Michal Hocko wrote: > On Mon 09-01-17 14:04:21, Vlastimil Babka wrote: > [...] >>> +static inline unsigned int memalloc_nofs_save(void) >>> +{ >>> + unsigned int flags = current->flags & PF_MEMALLOC_NOFS; >>> + current->flags |= PF_MEMALLOC_NOFS; >> >> So this is not

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On Mon 09-01-17 14:42:10, Michal Hocko wrote: > On Mon 09-01-17 14:04:21, Vlastimil Babka wrote: [...] > Now that you have opened this I have noticed that the code is wrong > here because GFP_HIGHUSER_MOVABLE & ~GFP_RECLAIM_MASK would overwrite > the removed GFP_FS. Blee, it wouldn't because

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On Mon 09-01-17 14:04:21, Vlastimil Babka wrote: [...] > > +static inline unsigned int memalloc_nofs_save(void) > > +{ > > + unsigned int flags = current->flags & PF_MEMALLOC_NOFS; > > + current->flags |= PF_MEMALLOC_NOFS; > > So this is not new, as same goes for memalloc_noio_save, but I've

LSF/MM 2017: Call for Proposals closes January 15th

We initially sent this pretty early this year, so this is a resend in case anyone missed the first posting. The call for topics and attendance requests is open until January 15th, 2017. The original message follows: --8< The annual

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On 01/06/2017 03:11 PM, 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 the memory reclaim > - to

Re: [PATCH 1/8] lockdep: allow to disable reclaim lockup detection

On 01/06/2017 03:11 PM, Michal Hocko wrote: > 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

Re: [PATCH 2/8] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

On 01/06/2017 03:11 PM, Michal Hocko wrote: > 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

[PULL] Btrfs tracepoint updates for 4.10

Hi, I've selected a handful of tracepoint fixes and updates. The fixes a crash when tracepoints are enabled so this can be considered urgent, the others are minor harmless improvements. The qgroup tracepoint update is not included as it depends on other patches so it'll possibly go later or with

Re: [RFC] Converging userspace and kernel code

On 01/08/2017 08:11 PM, Qu Wenruo wrote: > > > At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: >> >> 1. Motivation >> While fixing user space tools for btrfs-progs, I found a couple of bugs >> which are already solved in kernel space but were not ported to user >> space. User space is a

Re: [Regression 4.7-rc1] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

On Fri, Jan 06, 2017 at 12:22:34PM -0500, Joseph Salisbury wrote: > A kernel bug report was opened against Ubuntu [0]. This bug was fixed > by the following commit in v4.7-rc1: > > commit 4c63c2454eff996c5e27991221106eb511f7db38 > > Author: Luke Dashjr > Date: Thu Oct 29

Re: [RFC] Converging userspace and kernel code

On Mon, Jan 09, 2017 at 10:11:29AM +0800, Qu Wenruo wrote: > (I'm already trying to re-implement btrfs_map_block() in btrfs-progs with a > better interface in out-of-tree offline scrub patchset) How about doing the right thing in the kernel as well? While looking at the btrfs abuse of the block

Re: [markfasheh/duperemove] Why blocksize is limit to 1MB?

2017-01-09 2:09 GMT+01:00 Zygo Blaxell : > On Wed, Jan 04, 2017 at 07:58:55AM -0500, Austin S. Hemmelgarn wrote: >> On 2017-01-03 16:35, Peter Becker wrote: >> >As i understand the duperemove source-code right (i work on/ try to >> >improve this code since 5 or 6