Re: OFF-By-One Trouble? [BTRFS in Debian Stretch Kernel 4.9.0-4-amd64]

On 2017年12月12日 18:22, Juergen Sauer wrote: > Hi collegues, > this morning we've got a problm with btrfs in Debian Stable. > > Yesterday we had our fs filled below 30% space usage. > No further usage came in the usage is nearly the same, but ... > > # df -h . > DateisystemGröße Benutzt

Re: OFF-By-One Trouble? [BTRFS in Debian Stretch Kernel 4.9.0-4-amd64]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/12/2017 11:22 AM, Juergen Sauer wrote: > Hi collegues, Hello. > > this morning we've got a problm with btrfs in Debian Stable. > > Yesterday we had our fs filled below 30% space usage. No further > usage came in the usage is nearly the

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Wed, 13 Dec 2017 13:57:45 -0500 Josef Bacik wrote: > On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote: > > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote: > > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > > > > On Mon,

Re: [PATCH] fs/*/Kconfig: drop links to 404-compliant http://acl.bestbits.at

> On 13 Dec 2017, at 13:38, Adam Borowski wrote: > > This link is replicated in most filesystems' config stanzas. Referring > to an archived version of that site is pointless as it mostly deals with > patches; user documentation is available elsewhere. > > Signed-off-by:

Re: [BUG?] Defrag on compressed FS do massive data rewrites

Timofey Titovets posted on Thu, 14 Dec 2017 02:05:35 +0300 as excerpted: > Also, same problem exist for autodefrag case i.e.: > write 4KiB at start of compressed file autodefrag code add that file to > autodefrag queue, call btrfs_defrag_file, set range from start to u64-1. > That will trigger to

Re: [BUG?] Defrag on compressed FS do massive data rewrites

Timofey Titovets posted on Thu, 14 Dec 2017 01:09:52 +0300 as excerpted: > Hi, i see massive data rewrites of defragmented files when work with > btrfs fi def . > Before, i just thought it's a design problem - i.e. defrag always > rewrite data to new place. > > At now, i read the code and see 2

Re: [PATCH] fs/*/Kconfig: drop links to 404-compliant http://acl.bestbits.at

On Wed, Dec 13, 2017 at 06:38:25AM +0100, Adam Borowski wrote: > This link is replicated in most filesystems' config stanzas. Referring > to an archived version of that site is pointless as it mostly deals with > patches; user documentation is available elsewhere. > > Signed-off-by: Adam

[RFC PATCH] Btrfs: btrfs_defrag_file() force use target extent size SZ_128KiB for compressed data

Defrag heuristic use extent lengh as threshold, kernel autodefrag use SZ_256KiB and btrfs-progs use SZ_32MiB as target extent lengh. Problem: Compressed extents always have lengh at < 128KiB (BTRFS_MAX_COMPRESSED) So btrfs_defrag_file() always rewrite all extents in defrag range. Hot fix that by

Re: [BUG?] Defrag on compressed FS do massive data rewrites

2017-12-14 1:09 GMT+03:00 Timofey Titovets : > Hi, i see massive data rewrites of defragmented files when work with > btrfs fi def . > Before, i just thought it's a design problem - i.e. defrag always > rewrite data to new place. > > At now, i read the code and see 2 bad

[BUG?] Defrag on compressed FS do massive data rewrites

Hi, i see massive data rewrites of defragmented files when work with btrfs fi def . Before, i just thought it's a design problem - i.e. defrag always rewrite data to new place. At now, i read the code and see 2 bad cases: 1. With -c all extents of data will be rewriten, always. 2. btrfs use "bad"

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote: > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote: > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > > > On Mon, Dec 11, 2017 at 11:36:45AM -0500, Josef Bacik wrote: > > > > This is the same as v8,

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote: > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > > On Mon, Dec 11, 2017 at 11:36:45AM -0500, Josef Bacik wrote: > > > This is the same as v8, just rebased onto the bpf tree. > > > > > > v8->v9: > > > - rebased onto

Re: [PATCH v3 0/5] define BTRFS_DEV_STATE

On Wed, Dec 13, 2017 at 12:57:21PM +0300, Timofey Titovets wrote: > > The kernel.org repository only gets the latest for-next, that is > > assembled from the pending branches, and also after some testing. You > > could still find 'misc-next' inside the for-next branch, but it's not > > obvious. >

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > On Mon, Dec 11, 2017 at 11:36:45AM -0500, Josef Bacik wrote: > > This is the same as v8, just rebased onto the bpf tree. > > > > v8->v9: > > - rebased onto the bpf tree. > > > > v7->v8: > > - removed the _ASM_KPROBE_ERROR_INJECT

Re: [PATCH] btrfs: Fix bio leak

On Wed, Dec 13, 2017 at 01:50:07PM +0200, Nikolay Borisov wrote: > Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked > the way the flush bio is allocated and used. Concretely it allocates > the bio in __alloc_device and then re-uses it multiple times with a > very simple endio

Re: [PATCH v2] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction

Compile tested && battle tested by btrfs-extent-same from duperemove. At performance, i see a negligible difference. Thanks 2017-12-13 3:45 GMT+03:00 Timofey Titovets : > At now btrfs_dedupe_file_range() restricted to 16MiB range for > limit locking time and memory

[PATCH] btrfs: Fix bio leak

Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked the way the flush bio is allocated and used. Concretely it allocates the bio in __alloc_device and then re-uses it multiple times with a very simple endio routine that just calls complete() without consuming a reference.

Re: [PATCH] fs/*/Kconfig: drop links to 404-compliant http://acl.bestbits.at

On Wed 13-12-17 06:38:25, Adam Borowski wrote: > This link is replicated in most filesystems' config stanzas. Referring > to an archived version of that site is pointless as it mostly deals with > patches; user documentation is available elsewhere. > > Signed-off-by: Adam Borowski

Re: [PATCH v3 0/5] define BTRFS_DEV_STATE

2017-12-13 5:26 GMT+03:00 David Sterba : > On Wed, Dec 13, 2017 at 06:38:12AM +0800, Anand Jain wrote: >> >> >> On 12/13/2017 01:42 AM, David Sterba wrote: >> > On Sun, Dec 10, 2017 at 05:15:17PM +0800, Anand Jain wrote: >> >> As of now device properties and states are being

Re: [PATCH 7/8] btrfs: don't call btrfs_start_delalloc_roots in flushoncommit

Hi all, I'm sorry if duplicate emails bother you. (Today I always cannot successfully send mail to the mailing list.) I get the following warning about s_umount isn't locked when running xfstests btrfs/001(kernel: v4.15-rc3, mount_option: flushoncommit). [ 400.276381] WARNING: CPU: 0 PID: 3371

[PATCH 3/4] btrfs: Remove redundan bio_get/bio_set pair from submit_one_bio

The bio is never referenced after it has been submitted so there is no point in getting an extra reference. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent_io.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index

[PATCH 1/4] btrfs: Remove redundant bio_get/set calls in compressed read/write paths

bio_get/set is necessary only if the bio is going to be referenced following submissions. In the code paths where such calls are made we don't really need them since the bio is referenced only if btrfs_map_bio returns an error. And this function can return an error prior to submission only. So

[PATCH 2/4] btrfs: Remove redundant bio_get/set from submit_dio_repair_bio

The bio that is passsed is the newly created repair bio which already has a reference count of 1, which is going to be consumed by the endio routine on successful submission. On error the handler also calls bio_put. Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 7

[PATCH 4/4] btrfs: Remove redundant pair of bio_get/set in __btrfs_submit_dio_bio

The bio is not referenced after it has been submitted and the endio is going to consume the sole reference on successful submission. On error, the callers of __btrfs_submit_dio_bio do invoke bio_put so we don't leak it either. Signed-off-by: Nikolay Borisov ---

[PATCH 0/4] Cleanup of bio_get/set

Hello, Here is a series which cleans the btrfs source code of all the redundant bio_get/set calls. After it's applied there is only a single bio_get inovcation left in __alloc_device for the flush_bio (and that is wrong since it leaks the bio, but this will be fixed in a follow up fix).