Re: [PATCH] duperemove: test presence of dedupe ioctl

On Thu, Dec 15, 2016 at 05:20:14PM -0800, Darrick J. Wong wrote: > Fair enough, no need to pollute the namespace. Or confuse poor readers with the 'fake' name :) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v2] duperemove: test presence of dedupe ioctl

Looks fine, Reviewed-by: Christoph Hellwig -- 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 http://vger.kernel.org/majordomo-info.html

Re: OOM: Better, but still there on 4.9

[CC linux-mm and btrfs guys] On Thu 15-12-16 23:57:04, Nils Holland wrote: [...] > Of course, none of this are workloads that are new / special in any > way - prior to 4.8, I never experienced any issues doing the exact > same things. > > Dec 15 19:02:16 teela kernel: kworker/u4:5 invoked

[PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

This is actually inspired by Filipe's patch(55e3bd2e0c2e1). When submit_extent_page() in __extent_writepage_io() fails, Btrfs misses clearing a writeback bit of the failed page. This causes the false under-writeback page. Then, another sync task hangs in filemap_fdatawait_range(), because it

Re: [PATCH v2 2/3] btrfs-progs: convert: Rework rollback to handle new convert image

On Thursday, December 15, 2016 05:03:30 PM Qu Wenruo wrote: > Although commit 9c4b820412746b3 tried to make the rollback condition > less restrict, to co-operate with new rollback behavior, it's still too > restrict. > > If btrfs allocates a new data chunk, it's highly possible that the new >

[PATCH v2] duperemove: test presence of dedupe ioctl

Since a zero-length dedupe operation is guaranteed to succeed, use that to test whether or not this filesystem supports dedupe. Signed-off-by: Darrick J. Wong --- v2: Don't declare a new type; just declare the struct on the stack. --- file_scan.c | 45

Re: [PATCH] duperemove: test presence of dedupe ioctl

On Wed, Dec 14, 2016 at 11:26:07AM -0800, Christoph Hellwig wrote: > On Wed, Dec 14, 2016 at 10:38:45AM -0800, Darrick J. Wong wrote: > > > > +struct fake_btrfs_ioctl_same_args { > > > > + struct btrfs_ioctl_same_args args; > > > > + struct btrfs_ioctl_same_extent_info info; > > > >

Re: [PATCH v2] btrfs-progs: Fix NULL pointer when receive clone operation

On 2016/12/15 17:37, Qu Wenruo wrote: > Regression introduced by: > commit a2f7af94abe4a3491ca1280a2ae1d63edc0d62ab > Author: Prasanth K S R > Date: Sat Dec 10 19:17:43 2016 +0530 > > btrfs-progs: subvol_uuid_search: return error encoded pointer > > IS_ERR() will

Re: Server hangs when mount BTRFS filesystem.

Hi Кравцов, >From the log message, it seems dm-22 has been running out space, probably some >checksum did not get committed to disk. And when trying to repair, it reports checksum missing. merge_reloc_roots:2426: errno=-28 No space left Dec 15 00:05:47 OraCI2 kernel: BTRFS warning (device

[PATCH 7/9] 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 3/9] 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 genric name PF_MEMALLOC_NOFS which is in line

[PATCH 1/9] 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 9/9] 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 2/9] xfs: introduce and use KM_NOLOCKDEP to silence reclaim lockdep false positives

From: Michal Hocko Now that the page allocator offers __GFP_NOLOCKDEP let's introduce KM_NOLOCKDEP alias for the xfs allocation APIs. While we are at it also change KM_NOFS users introduced by b17cb364dbbb ("xfs: fix missing KM_NOFS tags to keep lockdep happy") and use the new

[PATCH 8/9] 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 4/9] 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/9] 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 0/9 v2] scope GFP_NOFS api

Hi, I have posted the previous version here [1]. Since then I have added a support to suppress reclaim lockdep warnings (__GFP_NOLOCKDEP) to allow removing GFP_NOFS usage motivated by the lockdep false positives. On top of that I've tried to convert few KM_NOFS usages to use the new flag in the

[PATCH 6/9] 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 4/4] Btrfs: code cleanup min/max -> min_t/max_t

This cleans up the cases where the min/max macros were used with a cast rather than using directly min_t/max_t. Signed-off-by: Seraphime Kirkovski --- fs/btrfs/file-item.c | 4 ++-- fs/btrfs/ioctl.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/4] Btrfs: coding style fixes

This eliminates the rare uses of `unsigned` instead of `unsigned int`. Signed-off-by: Seraphime Kirkovski --- fs/btrfs/dir-item.c | 6 ++--- fs/btrfs/extent-tree.c | 20 - fs/btrfs/extent_io.c| 55

[PATCH 3/4] Btrfs: ACCESS_ONCE cleanup

This replaces ACCESS_ONCE macro with the corresponding READ|WRITE macros Signed-off-by: Seraphime Kirkovski --- fs/btrfs/delayed-inode.c | 4 ++-- fs/btrfs/super.c | 2 +- fs/btrfs/transaction.c | 10 +- fs/btrfs/tree-log.h | 4 ++-- 4 files

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

Hi, The source is a software raid 5 (md) of 4x 4TB Western Digital RE4 disks. The destinations is a hardware raid 5 enclosure containing 4x 8TB Seagate Archival disks connected using e-sata. I am currently trying Duncans suggestions. With them, the page allocation stall doesn't seem to

[PATCH v2 3/3] btrfs-progs: convert-test: trigger chunk allocation after convert

Populate fs after convert so we can trigger data chunk allocation. This can expose too restrict old rollback condition Reported-by: Chandan Rajendra Signed-off-by: Qu Wenruo --- tests/common | 4 tests/common.convert | 3 +++ 2

[PATCH v2 1/3] btrfs-progs: file-item: Fix wrong file extents inserted

If we specify NO_HOLES incompat feature when converting, the result image still uses hole file extents. And further more, the hole is incorrect as its disk_num_bytes is not zero. The problem is at btrfs_insert_file_extent() which doesn't check if we are going to insert hole file extent. Modify

[PATCH v2 2/3] btrfs-progs: convert: Rework rollback to handle new convert image

Although commit 9c4b820412746b3 tried to make the rollback condition less restrict, to co-operate with new rollback behavior, it's still too restrict. If btrfs allocates a new data chunk, it's highly possible that the new chunk will not be 1:1 mapped anymore. And this makes old rollback check

[PATCH v2 0/3] Convert rollback rework for v4.9

Can be fetched from github: https://github.com/adam900710/btrfs-progs.git convert_rework_for_4.9 This is mainly to fix problems exposed by Chandan's fix for 64K nodesize. The problem is, although we're still using old rollback functions, it has quite a lot of problems to support the new

Server hangs when mount BTRFS filesystem.

Hello. First, server is hangs when btrfs balance working (see logs below). After server reset can't mount filesystem. When trying to execute command # mount -t btrfs /dev/OraCI2/pes.isuse_bp.stands /var/lib/docker/db/pes.isuse_bp.stands/pes.isuse_bp.standby.base/ server hangs without any

Re: Btrfs progs pre-release 4.9-rc1

At 12/15/2016 04:41 PM, Tsutomu Itoh wrote: On 2016/12/15 15:45, Tsutomu Itoh wrote: On 2016/12/14 23:42, David Sterba wrote: Hi, a pre-release has been tagged. Contains almost the entire devel branch from today. There are small fixes, the lowmem mode of check gets more updates but still

Re: Btrfs progs pre-release 4.9-rc1

On 2016/12/15 15:45, Tsutomu Itoh wrote: > On 2016/12/14 23:42, David Sterba wrote: >> Hi, >> >> a pre-release has been tagged. Contains almost the entire devel branch from >> today. There are small fixes, the lowmem mode of check gets more updates but >> still does not work in the --repair mode

[PATCH v2] btrfs-progs: Fix NULL pointer when receive clone operation

Regression introduced by: commit a2f7af94abe4a3491ca1280a2ae1d63edc0d62ab Author: Prasanth K S R Date: Sat Dec 10 19:17:43 2016 +0530 btrfs-progs: subvol_uuid_search: return error encoded pointer IS_ERR() will only check if it's an error code, won't check if it's

Re: [PATCH] btrfs-progs: Fix NULL pointer when receive clone operation

At 12/15/2016 04:07 PM, Tsutomu Itoh wrote: On 2016/12/15 16:28, Qu Wenruo wrote: The subvol_info returned from subvol_uuid_search() can be NULL. So the branch checking IS_ERR(si) should also check if it's NULL. Reported-by: Tsutomu Itoh Signed-off-by: Qu Wenruo

Re: [PATCH] btrfs-progs: Fix NULL pointer when receive clone operation

On 2016/12/15 16:28, Qu Wenruo wrote: > The subvol_info returned from subvol_uuid_search() can be NULL. > So the branch checking IS_ERR(si) should also check if it's NULL. > > Reported-by: Tsutomu Itoh > Signed-off-by: Qu Wenruo > --- >