On Mon, Jul 24, 2017 at 8:22 PM, Marat Khalili wrote:
>>> This may be a stupid question , but are your pool of butter (or BTRFS pool)
>>> by any chance hooked up via USB? If this is USB2.0 at 480mitb/s then it is
>>> about 57MB/s / 4 drives = roughly 14.25 or about 11MB/s if you shave off
>>> some
Hello everyone,
I'm migrating to btrfs and i would like to know, in a btrfs filesystem
with 4 disks (multiple sizes) with -d raid0 & -m raid1, how many
drives can i lost without losing the entire array?
Cheers.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
Userspace transactions were introduced in commit
6bf13c0cc833 ("Btrfs: transaction ioctls") to provide semantics that Ceph's
object store required. However, things have changed significantly since then,
to the point where btrfs is no longer suitable as a backend for ceph and in fact
it's actively a
On 2017-07-25 08:55, Hérikz Nawarro wrote:
Hello everyone,
I'm migrating to btrfs and i would like to know, in a btrfs filesystem
with 4 disks (multiple sizes) with -d raid0 & -m raid1, how many
drives can i lost without losing the entire array?
Exactly one, but you will lose data if you lose on
On Tue, Jul 25, 2017 at 09:55:37AM -0300, Hérikz Nawarro wrote:
> Hello everyone,
>
> I'm migrating to btrfs and i would like to know, in a btrfs filesystem
> with 4 disks (multiple sizes) with -d raid0 & -m raid1, how many
> drives can i lost without losing the entire array?
You can lose one
Thanks everyone, I'll stick with raid 1.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 25, 2017 at 01:46:56PM +, Hugo Mills wrote:
> On Tue, Jul 25, 2017 at 09:55:37AM -0300, Hérikz Nawarro wrote:
> > Hello everyone,
> >
> > I'm migrating to btrfs and i would like to know, in a btrfs filesystem
> > with 4 disks (multiple sizes) with -d raid0 & -m raid1, how many
> >
And btw, my current disk conf is a 1x 500GB, 2x3TB and a 5TB.
2017-07-25 10:51 GMT-03:00 Hugo Mills :
> On Tue, Jul 25, 2017 at 01:46:56PM +, Hugo Mills wrote:
>> On Tue, Jul 25, 2017 at 09:55:37AM -0300, Hérikz Nawarro wrote:
>> > Hello everyone,
>> >
>> > I'm migrating to btrfs and i would l
On Tue, Jul 25, 2017 at 10:55:18AM -0300, Hérikz Nawarro wrote:
> And btw, my current disk conf is a 1x 500GB, 2x3TB and a 5TB.
OK, so by my mental arithmetic(*), you'd get:
- 9.5 TB usable in RAID-0
- 11.5 TB usable in single mode
- 5.75 TB usable in RAID-1
Hugo.
(*) Which may be
The return value of flush_space was used to have significance in the early days
when the code was first introduced and before the ticketed enospc rework. Since
the latter got introduced the return value lost any significance whatsoever to
its callers. So let's remove it. While at it also remove the
On Tue, Jul 25, 2017 at 04:12:58PM +0300, Nikolay Borisov wrote:
> Userspace transactions were introduced in commit
> 6bf13c0cc833 ("Btrfs: transaction ioctls") to provide semantics that Ceph's
> object store required. However, things have changed significantly since then,
> to the point where btrf
Am Montag, den 24.07.2017, 23:12 +0200 schrieb waxhead:
>
> Chris Murphy wrote:
>
> This may be a stupid question , but are your pool of butter (or
> BTRFS
> pool) by any chance hooked up via USB? If this is USB2.0 at
No, it is a SATA array with (currently) four 8TB discs.
--
To unsubscribe fr
Am Montag, den 24.07.2017, 20:42 + schrieb Hugo Mills:
> On Mon, Jul 24, 2017 at 02:35:05PM -0600, Chris Murphy wrote:
> > On Mon, Jul 24, 2017 at 5:27 AM, Cloud Admin > r.eu> wrote:
> >
> > > I am a little bit confused because the balance command is running
> > > since
> > > 12 hours and onl
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owni
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and ownin
From: Jeff Mahoney
This patch adds a new -W option to wait for a rescan without starting a
new operation. This is useful for things like xfstests where we want
do to do a "btrfs quota enable" and not continue until the subsequent
rescan has finished.
In addition to documenting the new option in
From: Jeff Mahoney
Rather than iterate over all outstanding backrefs to resolve missing keys,
use a separate list that only contains refs that need missing keys resolved.
Once the missing key is resolved, move the ref to the pending list.
Signed-off-by: Jeff Mahoney
---
backref.c | 28 +++
From: Jeff Mahoney
Rather than iterate over all outstanding backrefs to resolve indirect refs,
use a separate list that only contains indirect refs.
When we process missing keys, the ref moves to the indirect ref list.
Once the indirect ref is resolved, move the ref to the pending list.
Eventua
From: Jeff Mahoney
We have the infrastructure to cache extent buffers but we don't actually
do the caching. As soon as the last reference is dropped, the buffer
is dropped. This patch keeps the extent buffers around until the max
cache size is reached (defaults to 25% of memory) and then it dro
From: Jeff Mahoney
Eventually, we'll have several lists and trees, as well as some statistics.
Signed-off-by: Jeff Mahoney
---
backref.c | 75 ++-
1 file changed, 45 insertions(+), 30 deletions(-)
diff --git a/backref.c b/backref.c
i
From: Jeff Mahoney
We now have two data structures that can be used to iterate the same data
set, and there may be quite a few of them in memory. Eliminating the
list_head member will reduce memory consumption while iterating over
the extent backrefs.
Signed-off-by: Jeff Mahoney
---
cmds-chec
From: Jeff Mahoney
---
backref.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/backref.c b/backref.c
index ac1b506..be3376a 100644
--- a/backref.c
+++ b/backref.c
@@ -130,6 +130,11 @@ struct __prelim_ref {
u64 wanted_disk_byte;
};
+static struct __pre
From: Jeff Mahoney
For the pathlogical case, like xfstests generic/297 that creates a
large file consisting of one, repeating reflinked extent, fsck can
take hours. The root cause is that calling find_data_backref while
iterating the extent records is an O(n^2) algorithm. For my
example test ru
From: Jeff Mahoney
This patch adds support to convert reiserfs file systems in-place to btrfs.
It will convert extended attribute files to btrfs extended attributes,
translate ACLs, coalesce tails that consist of multiple items into one item,
and convert tails that are too big into indirect file
From: Jeff Mahoney
There are two printfs with missing newlines that end up making the
output wonky.
Signed-off-by: Jeff Mahoney
---
convert/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/convert/main.c b/convert/main.c
index c56382e..01657a6 100644
--- a/convert
From: Jeff Mahoney
Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate
the available space) changed how we handle migrating file data so that
we never have btrfs space associated with the reserved ranges. This
works pretty well and when we iterate over the file blocks, the
On 7/25/17 4:54 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> This patch adds support to convert reiserfs file systems in-place to btrfs.
>
> It will convert extended attribute files to btrfs extended attributes,
> translate ACLs, coalesce tails that consist of multiple items into one item,
Hugo Mills wrote:
You can see about the disk usage in different scenarios with the
online tool at:
http://carfax.org.uk/btrfs-usage/
Hugo.
As a side note, have you ever considered making this online tool (that
should never go away just for the record) part of btrfs-progs e.g. a
p
On Tue, Jul 25, 2017 at 11:29:13PM +0200, waxhead wrote:
>
>
> Hugo Mills wrote:
> >
> >>>You can see about the disk usage in different scenarios with the
> >>>online tool at:
> >>>
> >>>http://carfax.org.uk/btrfs-usage/
> >>>
> >>>Hugo.
> >>>
> As a side note, have you ever considered ma
Hi Nick,
On Thu, Jul 20, 2017 at 10:27:42PM +0100, Nick Terrell wrote:
> Add zstd compression and decompression support to BtrFS. zstd at its
> fastest level compresses almost as well as zlib, while offering much
> faster compression and decompression, approaching lzo speeds.
Can we look at integr
30 matches
Mail list logo