Hi Anna,
On 09/11/2015 10:30 PM, Anna Schumaker wrote:
> copy_file_range() is a new system call for copying ranges of data
> completely in the kernel. This gives filesystems an opportunity to
> implement some kind of "copy acceleration", such as reflinks or
> server-side-copy (in the case of NFS)
This patch completes the 2-patches patch series which modifies
btrfs_start_transaction() to receive an u64 as its "num_items"
parameter thus avoiding to pass an int to start_transaction()
which actually takes an u64.
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/file
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/transaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 8f259b3..8a83acd 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -
Recent commits to kernel/git/torvalds/linux.git have made the following
functions able to tolerate NULL arguments:
kmem_cache_destroy (commit 3942d29918522)
mempool_destroy (commit 4e3ca3e033d1)
dma_pool_destroy (commit 44d7175da6ea)
These patches remove the associated NULL tests for the files th
Remove unneeded NULL test.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@@ expression x; @@
-if (x != NULL)
\(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
//
Signed-off-by: Julia Lawall
---
fs/btrfs/backref.c |3 +--
fs/
On Sun, Sep 13, 2015 at 02:53:14PM +, Holger Hoffstätte wrote:
> On Sun, 13 Sep 2015 14:29:41 +, Alexandru Moise wrote:
>
> > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> > ---
> > fs/btrfs/transaction.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
v2: Forgot to add transaction.h when I made the commit, many thanks
Holger for pointing it out.
fs/btrfs/transaction.c | 2 +-
fs/btrfs/transaction.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/
On Sun, Sep 13, 2015 at 02:53:14PM +, Holger Hoffstätte wrote:
> On Sun, 13 Sep 2015 14:29:41 +, Alexandru Moise wrote:
>
> > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> > ---
> > fs/btrfs/transaction.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
> Can we have a clean way to figure out whether two file ranges are the
> same in a way that allows false negatives? I.e. return 1 if the
> ranges are reflinks of each other and 0 if not? Pretty please? I've
> implemented that in t
Hi, everyone,
I went back and fixed the issues that came up since v2. Changes below. I
removed Josef's Reviewed-by on patch 9 because it was completely
rewritten to change the mount options like Dave suggested. These are
still based on 4.2
Thanks!
Changes from v2->v3:
- Fixed a warning in the f
From: Omar Sandoval
The on-disk format for the free space tree is straightforward. Each
block group is represented in the free space tree by a free space info
item that stores accounting information: whether the free space for this
block group is stored as bitmaps or extents and how many extents
From: Omar Sandoval
Sanity test the extent buffer bitmap operations (test, set, and clear)
against the equivalent standard kernel operations.
Signed-off-by: Omar Sandoval
---
fs/btrfs/extent_io.c | 34 ++
fs/btrfs/extent_io.h | 4 +-
fs/btrfs/tests/extent-io-
From: Omar Sandoval
The free space tree is updated in tandem with the extent tree. There are
only a handful of places where we need to hook in:
1. Block group creation
2. Block group deletion
3. Delayed refs (extent creation and deletion)
4. Block group caching
Signed-off-by: Omar Sandoval
---
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 this
happens in the critical section, things are especially bad because w
From: Omar Sandoval
These are going to be used for the free space tree bitmap items.
Signed-off-by: Omar Sandoval
---
fs/btrfs/extent_io.c | 149 +++
fs/btrfs/extent_io.h | 6 +++
2 files changed, 155 insertions(+)
diff --git a/fs/btrfs/extent
From: Omar Sandoval
We're also going to load the free space tree from caching_thread(), so
we should refactor some of the common code.
Signed-off-by: Omar Sandoval
---
fs/btrfs/ctree.h | 3 +++
fs/btrfs/extent-tree.c | 59 --
2 files chang
From: Omar Sandoval
We're finally going to add one of these for the free space tree, so
let's add the same nice helpers that we have for the incompat bits.
While we're add it, also add helpers to clear the bits.
Reviewed-by: Josef Bacik
Signed-off-by: Omar Sandoval
---
fs/btrfs/ctree.h | 82 +
From: Omar Sandoval
Now we can finally hook up everything so we can actually use free space
tree. The free space tree is enabled by passing the space_cache=v2 mount
option. On the first mount with the this option set, the free space tree
will be created and the FREE_SPACE_TREE read-only compat bi
From: Omar Sandoval
This tests the operations on the free space tree trying to excercise all
of the main cases for both formats. Between this and xfstests, the free
space tree should have pretty good coverage.
Signed-off-by: Omar Sandoval
---
fs/btrfs/Makefile | 3 +-
fs
From: Omar Sandoval
To start, let's tell btrfs-progs to read the free space root and how to
print the on-disk format of the free space tree. However, we're not
adding the FREE_SPACE_TREE read-only compat bit to the set of supported
bits because progs doesn't know how to keep the free space tree
c
From: Omar Sandoval
Signed-off-by: Omar Sandoval
---
disk-io.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 1d4889322411..8496aded31c4 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -833,13 +833,13 @@ struct btrfs_fs_info *bt
From: Omar Sandoval
This reuses the existing code for checking the free space cache, we just
need to load the free space tree. While we do that, we check a couple of
invariants on the free space tree itself. This requires pulling in some
code from the kernel to exclude the super stripes.
Signed-
Hi Ivan,
Ivan Petrovic wrote on 2015/09/04 22:45 +0200:
Hello,
I had 3 HDDs in single mode and one died.
Unfortunately, single mode means no duplication.
And degrade mount only works for RAID level with
duplication(DUP,RAID1/5/6/10).
So you lost all your data.
Thanks,
Qu
I have put a re
23 matches
Mail list logo
