A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
tests/btrfs/023 | 91 +++
tests/btrfs/023.out |2 +
tests/btrfs/group |1 +
3 files
On Sun, Nov 17, 2013 at 11:36:04AM +0200, Gleb Natapov wrote:
On Fri, Nov 15, 2013 at 03:57:23PM +0100, Heiko Carstens wrote:
On Fri, Nov 15, 2013 at 02:42:08PM +0100, Geert Uytterhoeven wrote:
I was just going to comment that
+ const void *zero_page = (const void *)
On Mon, Oct 21, 2013 at 02:30:05PM +0200, David Sterba wrote:
On Thu, Jan 10, 2013 at 11:57:25AM +0300, Dan Carpenter wrote:
The closing parenthesis is in the wrong place. We want to check
sizeof(*arg-clone_sources) * arg-clone_sources_count instead of
sizeof(*arg-clone_sources *
The data type of max_sectors in queue settings is unsigned int. But
this value is stored to the local variable whose type is unsigned short
in bio_size_ok(). This can cause unexpected result when max_sectors
0x.
Cc: Chris Mason chris.ma...@fusionio.com
Cc: linux-btrfs@vger.kernel.org
Added in patch btrfs: add ability to change features via sysfs,
modifications to superblock don't need to reserve metadata blocks when
starting a transaction.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Both patches look good to me, but I haven't actually run the new
testcase yet..
--
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
Quoting Anand Jain (2013-11-17 21:17:19)
There is a fix for this (which David has integrated into the branch
recently). This also needs the kernel side patch which is listed below.
[PATCH v4 1/3] btrfs-progs: mechanism to fetch fsinfo from btrfs-control
[PATCH v4 2/3] btrfs-progs: fs show
If a given filesystem is mounted more than once, btrfs fi show will
print dups. This adds a quick and dirty hash table of fsids it
has already printed and makes sure we don't print any fsid more than
once.
Anand has other patches that solve this by pulling information in from
new kernel
Hello,
My cache adventures (slow boot, btrfs ERRORs in dmesg) continue; I went to the
btrfs IRC and xaba suggested that I run btrfs check with the latest btrfs-progs
from Chris. I was surprised to see such a multitude of errors, most of which
are:
Extent back ref already exists for 951664640
On 11/18/13, 2:26 AM, Anand Jain wrote:
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
tests/btrfs/023 | 91
+++
tests/btrfs/023.out
Hi,
I want to report that I recently implemented a support for
arbitrary number of parities that could be useful also for Linux
RAID and Btrfs, both currently limited to double parity.
In short, to generate the parity I use a Cauchy matrix specifically
built to be compatible with the existing
On 11/18/2013 02:08 PM, Andrea Mazzoleni wrote:
Hi,
I want to report that I recently implemented a support for
arbitrary number of parities that could be useful also for Linux
RAID and Btrfs, both currently limited to double parity.
In short, to generate the parity I use a Cauchy matrix
Hi Peter,
The Cauchy matrix has the mathematical property to always have itself
and all submatrices not singular. So, we are sure that we can always
solve the equations to recover the data disks.
Besides the mathematical proof, I've also inverted all the
377,342,351,231 possible submatrices for
On 11/18/2013 02:35 PM, Andrea Mazzoleni wrote:
Hi Peter,
The Cauchy matrix has the mathematical property to always have itself
and all submatrices not singular. So, we are sure that we can always
solve the equations to recover the data disks.
Besides the mathematical proof, I've also
On 11/19/2013 05:50 AM, Eric Sandeen wrote:
On 11/18/13, 2:26 AM, Anand Jain wrote:
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
tests/btrfs/023 | 91
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v2: a copied comment removed as Eric pointed out
tests/btrfs/023 | 90 +++
Greetings,
This is more of just a report than anything else. I run linux-stable, and
while btrfs in 3.11.7 seemed fine, I've had oopses ever since installating
3.11.8. The server is not under heavy load when it happens, and it happens
fairly shortly after a clean boot.
The oopses all look like
On 11/18/13, 8:29 PM, Anand Jain wrote:
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
Reviewed-by: Eric Sandeen sand...@redhat.com
---
v2: a copied comment removed as Eric pointed out
On Nov 18, 2013, at 8:00 PM, Charles Cazabon charlesc-lists-bt...@pyropus.ca
wrote:
This is on x86_64, server-class hardware (ECC memory, etc). I ran a scrub
overnight that reported no errors, and I'll do it again now that I've reverted
to 3.11.7.
Is there any other info that might be
On Nov 18, 2013, at 8:53 PM, Chris Murphy li...@colorremedies.com wrote:
On Nov 18, 2013, at 8:00 PM, Charles Cazabon
charlesc-lists-bt...@pyropus.ca wrote:
This is on x86_64, server-class hardware (ECC memory, etc). I ran a scrub
overnight that reported no errors, and I'll do it again
On 07/11/13 01:25, Martin wrote:
[...]
And the patching fails due to mismatching code...
I have the Gentoo source for:
Btrfs v0.20-rc1-358-g194aa4a
(On Gentoo 3.11.5, will be on 3.11.6 later today.)
What are the magic incantations to download your version of source code
to try
Continuing:
gdb bt now gives:
#0 0x0042075a in btrfs_search_slot ()
#1 0x00427bb4 in btrfs_read_block_groups ()
#2 0x00423e40 in btrfs_setup_all_roots ()
#3 0x0042406d in __open_ctree_fd ()
#4 0x00424126 in open_ctree_fs_info ()
#5 0x0041812e
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain anand.j...@oracle.com
Reviewed-by: Eric Sandeen sand...@redhat.com
---
v3: need to differentiate between RAID10 and RAID1 in the output,
fixed the grep
v2: a copied
23 matches
Mail list logo
