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, 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
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
> >
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
--
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 /
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
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
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.
>
>
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
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 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:
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
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.
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
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
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:
>
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
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
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
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
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
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
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
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
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
---
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
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
---
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
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
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
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:
>
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]
32 matches
Mail list logo
