Re: btrfs subvolume delete --commit-after doesn't wait for deletions

On Thu, Jan 05, 2017 at 10:03:17AM +0800, Qu Wenruo wrote: > To wait the deletion finish, please use "btrfs filesystem sync". That doesn't entirely work either. It does appear to wait for something, but disk space available continues to increase after it exits. -- Bruce Guenter

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

On 01/06/2017 12:22 PM, Joseph Salisbury wrote: Hi Luke, 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 08:22:21 2015 +

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

On Friday, January 06, 2017 5:22:34 PM Joseph Salisbury wrote: > btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in > btrfs_ioctl > > However, this commit introduced a new regression. With this commit > applied, "btrfs fi show" no longer works and the btrfs snapshot >

Re: kernel crash after upgrading to 4.9

On Fri, Jan 6, 2017 at 8:15 AM, Imran Geriskovan wrote: >>> I seem to have a similar issue to a subject in December: >>> Subject: page allocation stall in kernel 4.9 when copying files from one >>> btrfs hdd to another >>> In my case, this is caused when rsync'ing

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

Hi Luke, 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 08:22:21 2015 + btrfs: bugfix: handle

Re: kernel crash after upgrading to 4.9

>> I seem to have a similar issue to a subject in December: >> Subject: page allocation stall in kernel 4.9 when copying files from one >> btrfs hdd to another >> In my case, this is caused when rsync'ing large amounts of data over NFS >> to the server with the BTRFS file system. This was not

[PATCH] btrfs: make tracepoint format strings more compact

We've recently added the fsid to trace events, this makes the line quite long. To reduce the it again, remove extra spaces around = and remove ",". Signed-off-by: David Sterba --- Applies on top of integration plus two recent tracepoint patches: * Btrfs: add 'inode' for extent

[DEBUG PATCH 2/2] silent warnings which we cannot do anything about

From: Michal Hocko THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE There are some code paths used by all the filesystems which we cannot change to drop the GFP_NOFS, yet they generate a lot of warnings. Provide {disable,enable}_scope_gfp_check to silence those.

[DEBUG PATCH 1/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

From: Michal Hocko THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE It is desirable to reduce the direct GFP_NO{FS,IO} usage at minimum and prefer scope usage defined by memalloc_no{fs,io}_{save,restore} API. Let's help this process and add a debugging tool to

[DEBUG PATCH 0/2] debug explicit GFP_NO{FS,IO} usage from the scope context

These two patches should help to identify explicit GFP_NO{FS,IO} usage from withing a scope context and reduce such a usage as a result. Such a usage can be changed to the full GFP_KERNEL because all the calls from within the NO{FS,IO} scope will drop the __GFP_FS resp. __GFP_IO automatically and

[PATCH 1/8] 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/8] Revert "ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp"

From: Michal Hocko This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because sb_getblk_gfp is not really needed as sb_getblk __getblk_gfp __getblk_slow grow_buffers grow_dev_page gfp_mask = mapping_gfp_constraint(inode->i_mapping,

[PATCH 3/8] 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 0/8 v3] scope GFP_NOFS api

can get further with the xfs as well. I haven't heard anything from btrfs or other filesystems guys which is a bit unfortunate but I do not want to wait for them to much longer, they can join the effort later on. The patchset is based on next-20170106 Diffstat says fs/ext4/acl.c | 6

[PATCH 6/8] 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 2/8] 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 4/8] 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

[PATCH 5/8] 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 8/8] Revert "ext4: fix wrong gfp type under transaction"

From: Michal Hocko This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that the transaction context uses memalloc_nofs_save and all allocations within the this context inherit GFP_NOFS automatically, there is no reason to mark specific allocations explicitly. This

[PATCH] btrfs: fix crash when tracepoint arguments are freed by wq callbacks

Enabling btrfs tracepoints leads to instant crash, as reported. The wq callbacks could free the memory and the tracepoints started to dereference the members to get to fs_info. The proposed fix https://marc.info/?l=linux-btrfs=148172436722606=2 removed the tracepoints but we could preserve them

[PATCH] btrfs: remove unused logic of limiting async delalloc pages

A proposed patch in https://marc.info/?l=linux-btrfs=147859791003837 pointed out bad limit threshold in cow_file_range_async, but it turned out that the whole logic is not necessary and is done by writeback. We agreed to remove it. Signed-off-by: David Sterba ---

Re: [PATCH] Fix spelling/typos in user-facing strings.

On Thu, Jan 05, 2017 at 10:40:47PM -0500, Nicholas D Steeves wrote: > Signed-off-by: Nicholas D Steeves Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] Btrfs: Fix deadlock between direct IO and fast fsync

On Fri, Jan 06, 2017 at 11:45:46AM +, Filipe Manana wrote: > >From my point of view, it's ok and you can have: > > Reviewed-by: Filipe Manana Added to next and queued for 4.10, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

Re: [PATCH] Btrfs: Fix deadlock between direct IO and fast fsync

On Fri, Dec 23, 2016 at 9:30 AM, Chandan Rajendra wrote: > The following deadlock is seen when executing generic/113 test, > > > -+ > Direct I/O task

Question about nano second timestamps on files in btrfs

It seems like the nano seconds that are stored in for example mtime are snapshots of a nano second counter, taken at certain intervals, much more seldom than one would expect. For example, a bash script with: echo HELLO > a.txt do some bashy loops and echos echo HELLO > b.txt at least on my

Re: [PATCH] Btrfs: adjust outstanding_extents counter properly when dio write is split

On Fri, Dec 23, 2016 at 1:13 AM, Liu Bo wrote: > Currently how btrfs dio deals with split dio write is not good > enough if dio write is split into several segments due to the > lack of contiguous space, a large dio write like 'dd bs=1G count=1' > can end up with incorrect

Re: BUG at mount time on v4.8.10

Petr Janecek posted on Fri, 06 Jan 2017 05:36:01 +0100 as excerpted: > I just got a BUG on mount of a raid10 fs. /dev/sde was added to > the fs recently and balance has been started. After reboot (balance > still running), the fs can not be mounted any more. Try the skip_balance mount option (as