From: Wang Xiaoguang
Introduce static function inmem_add() to add hash into in-memory tree.
And now we can implement the btrfs_dedup_add() interface.
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/dedup.c | 116 +++
1 file changed, 116 insertions
From: Wang Xiaoguang
Introduce the header for btrfs online(write time) de-duplication
framework and needed header.
The new de-duplication framework is going to support 2 different dedup
method and 1 dedup hash.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/ctree.h | 3
Add basic ioctl header and command group framework for later use.
Alone with basic man page doc.
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-dedup.asciidoc | 37 +
Makefile.in| 2 +-
btrfs.c| 1 +
cmds-dedup.c
Now btrfs-show-super can handle DEDUP ro compat flag.
Signed-off-by: Qu Wenruo
---
btrfs-show-super.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/btrfs-show-super.c b/btrfs-show-super.c
index d8ad69e..7c0dfa9 100644
--- a/btrfs-show-super.c
+++ b/btrfs-show-super.c
@@
Add enable subcommand for dedup commmand group.
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-dedup.asciidoc | 62 ++-
cmds-dedup.c | 120 +
ioctl.h| 2 +
kerncompat.h
Preparation patchset for in-coming (aimed for 4.6) kernel in-band
de-duplication patchset.
New kernel dedup will has 2 different dedup backends and a ioctl
interface to enable/disable dedup.
The ioctl interface and on-disk format (mostly) is determined, so submit
this patchset first before de-dup
This updated version of inband de-duplication has the following features:
1) ONE unified dedup framework.
Most of its code is hidden quietly in dedup.c and export the minimal
interfaces for its caller.
Reviewer and further developer would benefit from the unified
framework.
2) TWO diff
Now on-disk backend should be able to search hash now.
Signed-off-by: Wang Xiaoguang
Signed-off-by: Qu Wenruo
---
fs/btrfs/dedup.c | 169 ++-
fs/btrfs/dedup.h | 3 +
2 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/de
From: Wang Xiaoguang
Unlike in-memory or on-disk dedup method, only SHA256 hash method is
supported yet, so implement btrfs_dedup_calc_hash() interface using
SHA256.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/dedup.c | 57 ++
From: Wang Xiaoguang
Introduce static function inmem_search() to handle the job for in-memory
hash tree.
The trick is, we must ensure the delayed ref head is not being run at
the time we search the for the hash.
With inmem_search(), we can implement the btrfs_dedup_search()
interface.
Signed-o
Add status subcommand for dedup command group.
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-dedup.asciidoc | 3 ++
cmds-dedup.c | 72 ++
2 files changed, 75 insertions(+)
diff --git a/Documentation/btrfs-dedup.asciidoc
b/Documentat
From: Wang Xiaoguang
Add generic function to initialize dedup info.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/dedup.c | 96 +++
fs/btrfs/dedup.h | 14 ++--
3 files changed, 109 inser
From: Wang Xiaoguang
Add ordered-extent support for dedup.
Note, current ordered-extent support only supports non-compressed source
extent.
Support for compressed source extent will be added later.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/ordered-data.c | 33 ++
Add dedup tree support for btrfs-debug-tree.
Signed-off-by: Qu Wenruo
---
btrfs-debug-tree.c | 4
ctree.h| 7 +++
print-tree.c | 52
3 files changed, 63 insertions(+)
diff --git a/btrfs-debug-tree.c b/btrfs-debug-
Add new DEDUP ro compat flag and corresponding mkfs/convert flag
'dedup'.
Since dedup tree is completely isolated from fs tree, so even old kernel
could do read mount.
So add it to RO compat flag instead of common incompat flags
Signed-off-by: Qu Wenruo
---
Documentation/mkfs.btrfs.asciidoc |
Now on-disk backend can delete hash now.
Signed-off-by: Wang Xiaoguang
Signed-off-by: Qu Wenruo
---
fs/btrfs/dedup.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/fs/btrfs/dedup.c b/fs/btrfs/dedup.c
index 82e21a6..704c3c7 100644
---
Since we will introduce a new on-disk based dedup method, introduce new
interfaces to resume previous dedup setup.
And since we introduce a new tree for status, also add disable handler
for it.
Signed-off-by: Wang Xiaoguang
Signed-off-by: Qu Wenruo
---
fs/btrfs/dedup.c | 193
From: Wang Xiaoguang
Add ioctl interface for inband deduplication, which includes:
1) enable
2) disable
3) status
We will later add ioctl to disable inband dedup for given file/dir.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/disk-io
Now on-disk backend can add hash now.
Signed-off-by: Wang Xiaoguang
Signed-off-by: Qu Wenruo
---
fs/btrfs/dedup.c | 69
1 file changed, 69 insertions(+)
diff --git a/fs/btrfs/dedup.c b/fs/btrfs/dedup.c
index bebf180..82e21a6 100644
--- a
Introduce a new tree, dedup tree to record on-disk dedup hash.
As a persist hash storage instead of in-memeory only implement.
Unlike Liu Bo's implement, in this version we won't do hack for
bytenr -> hash search, but add a new type, DEDUP_BYTENR_ITEM for such
search case, just like in-memory back
From: Wang Xiaoguang
Core implement for inband de-duplication.
It reuse the async_cow_start() facility to do the calculate dedup hash.
And use dedup hash to do inband de-duplication at extent level.
The work flow is as below:
1) Run delalloc range for an inode
2) Calculate hash for the delalloc
From: Wang Xiaoguang
Introduce static function inmem_del() to remove hash from in-memory
dedup tree.
And implement btrfs_dedup_del() and btrfs_dedup_destroy() interfaces.
Signed-off-by: Qu Wenruo
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/dedup.c | 77 +
Add disable subcommand for dedup command group.
Signed-off-by: Qu Wenruo
---
Documentation/btrfs-dedup.asciidoc | 5 +
cmds-dedup.c | 42 ++
2 files changed, 47 insertions(+)
diff --git a/Documentation/btrfs-dedup.asciidoc
b/Docume
Hello, I've hit this bug when removing the device
/dev/mapper/vg_hd04-lv_btrfs_hd04 from this filesystem. The only
peculiarity is that it mixes partitions and a lvm logical volume.
The device was removed successfully and no further errors have been seen.
# btrfs fi show
Label: 'btrfs_raid1' uuid
On Tuesday 08 Dec 2015 16:40:42 Qu Wenruo wrote:
> Enhance chunk validation:
> 1) Num_stripes
>We already have such check but it's only in super block sys chunk
>array.
>Now check all on-disk chunks.
>
> 2) Chunk logical
>It should be aligned to sector size.
>This behavior shou
On Fri, Dec 25, 2015 at 11:34 PM, Chris Murphy wrote:
> I would then also try to reproduce with 4.2.8 or 4.3.3 because those
> have ~ 25% backports than made it to 4.1.15, so there's an off chance
> it's fixed there.
I take it that those backports are in the queue though? I was
actually thinking
On Mon, Dec 28, 2015 at 07:24:11AM -0500, Sanidhya Solanki wrote:
> An option to select the RAID Stripe size is made
> available in the BTRFS Filesystem, via an option
> in the BTRFS Config setup, with minimal change
> to the existing code base.
The stripe size depends on how the filesystem was ma
On Tue, 29 Dec 2015 14:39:07 +0100
David Sterba wrote:
> The stripe size depends on how the filesystem was made, at the moment
> the stripesize parameter is missing from mkfs. The kernel module
> should support all sizes at runtime, so it's not a compile-time
> option.
No good? I will try and re
On Mon, 2015-12-28 at 21:23 -0500, Sanidhya Solanki wrote:
> From Documentation/filesystems/BTRFS.txt:
> Btrfs is under heavy development, and is not suitable for
> any uses other than benchmarking and review.
Well I guess now it's time for Duncan's usual "stable or not" talk
(@Duncan, I think by n
Christoph Anton Mitterer posted on Tue, 29 Dec 2015 16:32:59 +0100 as
excerpted:
>> From Documentation/filesystems/BTRFS.txt:
>> Btrfs is under heavy development, and is not suitable for any uses
>> other than benchmarking and review.
> Well I guess now it's time for Duncan's usual "stable or not
On Tue, Dec 29, 2015 at 06:15:12AM -0500, Sanidhya Solanki wrote:
> On Tue, 29 Dec 2015 14:39:07 +0100
> David Sterba wrote:
>
> > The stripe size depends on how the filesystem was made, at the moment
> > the stripesize parameter is missing from mkfs. The kernel module
> > should support all size
On Tue, Dec 29, 2015 at 02:28:19AM +, Duncan wrote:
> Btrfs check's -s option simply lets you use a different superblock. I
> don't believe check is designed to actually fix superblocks, tho I guess
> with --repair it fixes certain bad fields in them.
The superblock is a special type of met
On Tue, Dec 29, 2015 at 05:26:28AM +0100, Christoph Anton Mitterer wrote:
> On Mon, 2015-12-28 at 19:03 -0500, Sanidhya Solanki wrote:
> > That sounds like an absolutely ghastly idea.
> *G* and it probably is ;)
>
>
> > Lots of potential for
> > mistakes and potential data loss. I take up the of
On Tue, Sep 29, 2015 at 08:50:35PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> The free space cache has turned out to be a scalability bottleneck on
> large, busy filesystems. When the cache for a lot of block groups needs
> to be written out, we can get extremely long commit times; if
Chris Murphy wrote:
On Mon, Dec 28, 2015 at 3:55 PM, Waxhead wrote:
I tried the following
btrfs-image -t4 -c9 /dev/sdb1 /btrfs_raid6.img
checksum verify failed on 28734324736 found C3E98F3B wanted EB2392C6
checksum verify failed on 28734324736 found C3E98F3B wanted EB2392C6
checksum ver
On Tue, Dec 29, 2015 at 7:16 AM, Christian wrote:
> I found out, that i can also show more Information about Files and Diretories
> contained in the Filesystem.
>
> btrfs-debug-tree show me the following Infos:
>
> parent transid verify failed on 2234958286848 wanted 35674 found 35675
> parent tr
Latest update on this thread. btrfs check (4.3.1) reports no problems.
Volume mounts with kernel 4.2.8 with no errors. And I just did a scrub
and there were no errors, not even any fix up messages. And dev stats
are all zero.
So... it appears it was a minor enough problem, and still consistent
eno
On Tue, 29 Dec 2015 18:06:11 +0100
David Sterba wrote:
> I don't know about all implications from changing the define to
> sb->stripesize, also we want to define the allowed range etc. It would
> be better to add more description to the patch.
So, is the patch atleast somewhat usable and you jus
On Tue, 2015-12-29 at 16:44 +, Duncan wrote:
> As I normally put it, btrfs is "definitely stabilizING, but not yetÂ
> entirely stable and mature."
[snip snap]
And now... as a song please :D
I'd also take a medieval rhyme ;-)
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signat
Well all the generations on all devices are now the same, and so are
the chunk trees. I haven't looked at them in detail to see if there
are any discrepancies among them.
If you don't care much for this file system, then you could try btrfs
check --repair, using btrfs-progs 4.3.1 or integration br
40 matches
Mail list logo
