On Fri, Nov 9, 2018 at 1:21 AM robbieko wrote:
>
> robbieko 於 2018-11-06 20:23 寫到:
> > Hi,
> >
> > I can reproduce the infinite loop, the following will describe the
> > reason and example.
> >
> > Example:
> > tree --inodes parent/ send/
> > parent/
> > `-- [261] 261
> > `-- [271] 2
On Fri, Nov 9, 2018 at 12:27 AM Qu Wenruo wrote:
>
>
>
> On 2018/11/8 下午10:48, Filipe Manana wrote:
> > On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote:
> >>
> >> On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote:
> >>>
> >>>
> >>>
> >>> On 2018/11/8 下午9:17, fdman...@kernel.org wrote:
> Fro
From: Filipe Manana
We currently are in a loop finding each range (corresponding to a btree
node/leaf) in a log root's extent io tree and then clean it up. This is a
waste of time since we are traversing the extent io tree's rb_tree more
times then needed (one for a range lookup and another for c
On 9.11.18 г. 12:43 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We currently are in a loop finding each range (corresponding to a btree
> node/leaf) in a log root's extent io tree and then clean it up. This is a
> waste of time since we are traversing the extent io tree's rb_tree
On 2018/11/9 下午6:21, Filipe Manana wrote:
> On Fri, Nov 9, 2018 at 12:27 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/11/8 下午10:48, Filipe Manana wrote:
>>> On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote:
On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote:
>
>
>
> On 2018/
This will be used in future patches that remove the optional
extent_io_ops callbacks.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/btrfs_inode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 97d91e55b70a..213a6a63dac5 100644
--- a/f
Here is the 2nd revision of the extent_io_ops optinal callbacks removal. What
prompted this version was that I identified a flaw in the initial version -
while
it did check for the presence of an inode in extent_io_tree::private_data, i
forgot to explicitly check the ino to be different than the
This is the counterpart to ex-set_bit_hook (now btrfs_set_delalloc_extent),
similar to what was done before remove clear_bit_hook and rename the
function. No functional changes.
Reviewed-by: Josef Bacik
Signed-off-by: Nikolay Borisov
Reviewed-by: David Sterba
Signed-off-by: David Sterba
---
f
This hook is called only from __extent_writepage_io which is already
called only from the data page writeout path. So there is no need to
make an indirect call via extent_io_ops. This patch just removes the
callback definition, exports the callback function and calls it directly
at the only call si
This callback is called only from writepage_delalloc which in turn is
guaranteed to be called from the data page writeout path. In the end
there is no reason to have the call to this function to be indrected via
the extent_io_ops structure. This patch removes the callback definition,
exports the fu
This callback is ony ever called for data page writeout so there is no
need to actually abstract it via extent_io_ops. Lets just export it,
remove the definition of the callback and call it directly in the
functions that invoke the callback. Also rename the function to
btrfs_writepage_endio_finish_
This callback is used only for data and free space inodes. Such inodes
are guaranteed to have their extent_io_tree::private_data set to the
inode struct. Exploit this fact to directly call the function. Also give
it a more descriptive name. No functional changes.
Reviewed-by: Josef Bacik
Signed-o
This callback is used to properly account delalloc extents for data
inodes (ordinary file inodes and freespace v1 inodes). Those can be
easily identified since they have their extent_io trees ->private_data
member point to the inode. Let's exploit this fact to remove the
needless indirection throug
This is the counterpart to merge_extent_hook, similarly, it's used only
for data/freespace inodes so let's remove it, rename it and call it
directly where necessary. No functional changes.
Reviewed-by: Josef Bacik
Signed-off-by: Nikolay Borisov
Reviewed-by: David Sterba
Signed-off-by: David Ste
This callback was only used in debug builds by btrfs_leak_debug_check.
A better approach is to move its implementation in
btrfs_leak_debug_check and ensure the latter is only executed for extent
tree which have ->private_data set i.e. relate to a data node and not
the btree one. No functional chang
On 9.11.18 г. 16:08 ч., Nikolay Borisov wrote:
> Here is the 2nd revision of the extent_io_ops optinal callbacks removal. What
> prompted this version was that I identified a flaw in the initial version -
> while
> it did check for the presence of an inode in extent_io_tree::private_data, i
>
Op 09-11-18 om 02:21 schreef Qu Wenruo:
>
> On 2018/11/9 上午6:40, Pieter Maes wrote:
>> Hello,
>>
[Snip]
> Btrfs-progs could do it with some extra dirty work.
> (I purposed offline device resize idea, but didn't implement it yet)
>
> You could use this branch:
> https://github.com/adam900710/btrfs-p
btrfs sits on md RAID-5:
/dev/md2 /data btrfs noatime,compress-force=zstd,space_cache=v2,noauto 0
0
After upgrading from kernel 4.16.1 to 4.19.1 and a clean restart, the fs
no longer mounts:
# mount /data
mount: wrong fs type, bad option, bad superblock on /dev/md2,
missing codepag
On Sat, 10 Nov 2018 03:08:01 +0900
Tomasz Chmielewski wrote:
> After upgrading from kernel 4.16.1 to 4.19.1 and a clean restart, the fs
> no longer mounts:
Did you try rebooting back to 4.16.1 to see if it still mounts there?
--
With respect,
Roman
On 2018-11-10 03:20, Roman Mamedov wrote:
On Sat, 10 Nov 2018 03:08:01 +0900
Tomasz Chmielewski wrote:
After upgrading from kernel 4.16.1 to 4.19.1 and a clean restart, the
fs
no longer mounts:
Did you try rebooting back to 4.16.1 to see if it still mounts there?
Yes, just did.
Interesti
On 2018-11-10 04:15, Tomasz Chmielewski wrote:
On 2018-11-10 03:20, Roman Mamedov wrote:
On Sat, 10 Nov 2018 03:08:01 +0900
Tomasz Chmielewski wrote:
After upgrading from kernel 4.16.1 to 4.19.1 and a clean restart, the
fs
no longer mounts:
Did you try rebooting back to 4.16.1 to see if it
On 2018-11-10 04:20, Tomasz Chmielewski wrote:
On 2018-11-10 04:15, Tomasz Chmielewski wrote:
On 2018-11-10 03:20, Roman Mamedov wrote:
On Sat, 10 Nov 2018 03:08:01 +0900
Tomasz Chmielewski wrote:
After upgrading from kernel 4.16.1 to 4.19.1 and a clean restart,
the fs
no longer mounts:
D
On Fri, Nov 09, 2018 at 10:43:08AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We currently are in a loop finding each range (corresponding to a btree
> node/leaf) in a log root's extent io tree and then clean it up. This is a
> waste of time since we are traversing the extent io
On Thu, Nov 08, 2018 at 04:16:38PM +0200, Nikolay Borisov wrote:
> Before btrfs_map_bio submits all stripe bio it does a number of checks
> to ensure the device for every stripe is present. However, it doesn't
> do a DEV_STATE_MISSING check, instead this is relegated to the lower
> level btrfs_sche
On Tue, Nov 06, 2018 at 02:41:10PM +0800, Lu Fengqi wrote:
> From: Wang Xiaoguang
>
> Introduce the header for btrfs in-band(write time) de-duplication
> framework and needed header.
>
> The new de-duplication framework is going to support 2 different dedupe
> methods and 1 dedupe hash.
>
> Sig
On Tue, Nov 06, 2018 at 02:41:13PM +0800, Lu Fengqi wrote:
> From: Wang Xiaoguang
>
> Introduce static function inmem_del() to remove hash from in-memory
> dedupe tree.
> And implement btrfs_dedupe_del() and btrfs_dedup_disable() interfaces.
>
> Also for btrfs_dedupe_disable(), add new functions
Hi Josef (and review/signed-off path),
I noticed a particularly large regression when reviewing results from
v4.18 to v4.18 (33.81% regression with 5 reaim clients). An automatic
bisection resolved to commit b5e6c3e170b7 ("btrfs: always wait on ordered
extents at fsync time"). I won't pretend to u
--
Groet, groet aan jou,
GELD BESCHIKBAAR VOOR LENING. Krijg het geld / de lening die u nodig
hebt bij Funding Trusts Finance. Wij zijn particuliere
kredietverstrekkers / investeerders en bieden zowel persoonlijke
leningen, startleningen, educatieve / agrarische leningen, onroerend
goed /
On Fri, Nov 09, 2018 at 09:51:48PM +, Mel Gorman wrote:
> Unfortunately, as
> I'm about to travel, I didn't attempt a revert and a test comparing 4.18,
> 4.19 and 4.20-rc1 is a few hours away so this could potentially be fixed
> already but I didn't spot any obvious Fixes commit.
>
Still here
On Wed, Nov 07, 2018 at 05:01:19PM +0100, David Sterba wrote:
> On Wed, Oct 31, 2018 at 10:06:08AM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > There's a race between close_ctree() and cleaner_kthread().
> > close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it
> > s
On Wed, Nov 07, 2018 at 04:28:10PM +0100, David Sterba wrote:
> On Wed, Nov 07, 2018 at 05:07:00PM +0200, Nikolay Borisov wrote:
> >
> >
> > On 7.11.18 г. 16:49 ч., David Sterba wrote:
> > > On Tue, Nov 06, 2018 at 10:54:51AM +0100, David Sterba wrote:
> > >> On Thu, Sep 27, 2018 at 11:17:32AM -0
De-duplication must also let use cases to enable de-duplication on per
subvolume level, using the subvolume properties. Similar to compression
and future-encryption.
Thanks, Anand
On Wed, Oct 31, 2018 at 07:48:08PM +0100, Goffredo Baroncelli wrote:
> On 31/10/2018 13.06, Daniel Kiper wrote:
> [...]
> >
> > v11 pushed.
> >
> > Goffredo, thank you for doing the work.
>
> Great ! Many thanks for your support !!
You are welcome!
Daniel
This patch introduces one extra iterator variable to bio_for_each_segment_all(),
then we can allow bio_for_each_segment_all() to iterate over multi-page bvec.
Given it is just one mechannical & simple change on all
bio_for_each_segment_all()
users, this patch does tree-wide change in one single p
BTRFS is the only user of this helper, so move this helper into
BTRFS, and implement it via bio_for_each_segment_all(), since
bio->bi_vcnt may not equal to number of pages after multipage bvec
is enabled.
Cc: Christoph Hellwig
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming
Preparing for supporting multi-page bvec.
Cc: Christoph Hellwig
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming Lei
---
fs/btrfs/compression.c | 5 -
fs/btrfs/extent_io.c | 5 +++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/compression.c
This started as an experiment to see how hard it would be to change
the four pointers in struct _ddebug into relative offsets, a la
CONFIG_GENERIC_BUG_RELATIVE_POINTERS, thus saving 16 bytes per
pr_debug site (and thus exactly making up for the extra space used by
the introduction of jump labels in
First, the btrfs_debug macros open-code (one possible definition of)
DYNAMIC_DEBUG_BRANCH, so they don't benefit from the HAVE_JUMP_LABEL
optimization.
Second, changes on x86-64 later in this series require that all struct
_ddebug descriptors in a translation unit use distinct identifiers.
Using
38 matches
Mail list logo