http://www.cs.wisc.edu/adsl/Publications/corruption-fast08.html
Page 13 of the above paper says:
# Figure 12 presents for each block number, the number of disk drives of disk
# model ‘E-1’ that developed a checksum mismatch at that block number. We see
# in the figure that many disks develop
Russell Coker posted on Thu, 15 May 2014 19:00:10 +1000 as excerpted:
http://www.cs.wisc.edu/adsl/Publications/corruption-fast08.html
Page 13 of the above paper says:
# Figure 12 [...] We see in the figure that many disks develop
# corruption for a specific set of block numbers.
On Thu, May 15, 2014 at 07:00:10PM +1000, Russell Coker wrote:
http://www.cs.wisc.edu/adsl/Publications/corruption-fast08.html
Page 13 of the above paper says:
# Figure 12 presents for each block number, the number of disk drives of disk
# model ‘E-1’ that developed a checksum mismatch at
On Thu, 15 May 2014 09:31:42 Duncan wrote:
Does the BTRFS RAID functionality do such staggered stripes? If not
could it be added?
AFAIK nothing like that yet, but it's reasonably likely to be implemented
later. N-way-mirroring is roadmapped for next up after raid56
completion, however.
On 2014/05/15 04:38 PM, Russell Coker wrote:
On Thu, 15 May 2014 09:31:42 Duncan wrote:
Does the BTRFS RAID functionality do such staggered stripes? If not
could it be added?
AFAIK nothing like that yet, but it's reasonably likely to be implemented
later. N-way-mirroring is roadmapped for
On Fri, May 16, 2014 at 12:38:04AM +1000, Russell Coker wrote:
On Thu, 15 May 2014 09:31:42 Duncan wrote:
Does the BTRFS RAID functionality do such staggered stripes? If not
could it be added?
AFAIK nothing like that yet, but it's reasonably likely to be implemented
later.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/inode-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c
index 86935f5ae291..888fbe19079f 100644
--- a/fs/btrfs/inode-map.c
+++ b/fs/btrfs/inode-map.c
@@ -174,7 +174,7 @@
On Thu, May 08, 2014 at 11:03:57AM +0800, Gui Hecheng wrote:
Add sys chunk array and backup roots info if the new option '-f'
if specified.
This may be useful for debugging sys_chunk related issues.
Sounds useful. One comment below.
+static void print_sys_chunk_array(struct btrfs_super_block
Obviously I can't put that patch into progs integration as it's changing
the default behaviour. You can add #ifdefs if you want.
--
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
On Tue, May 13, 2014 at 05:05:05PM +0800, Wang Shilong wrote:
Btrfs device id start from 1, not 0.
--- a/utils.c
+++ b/utils.c
@@ -1765,7 +1765,7 @@ int get_fs_info(char *path, struct
btrfs_ioctl_fs_info_args *fi_args,
goto out;
}
- for (; i = fi_args-max_id;
On Wed, May 14, 2014 at 05:07:04PM -0500, Eric Sandeen wrote:
@@ -125,7 +154,20 @@ int make_btrfs(int fd, const char *device, const char
*label,
memset(super, 0, sizeof(super));
num_bytes = (num_bytes / sectorsize) * sectorsize;
- uuid_generate(super.fsid);
+ if (fs_uuid)
On Mon, May 12, 2014 at 07:10:17PM +0200, David Sterba wrote:
One thing that looks as a show stopper is the fact that the fake data
blocks that would become the metadata blocks would lie out of any
metadata group. I'm not familiar with the chunk rebuilder, but this
seems as a simple check to
On 5/15/14, 12:39 PM, David Sterba wrote:
On Wed, May 14, 2014 at 05:07:04PM -0500, Eric Sandeen wrote:
@@ -125,7 +154,20 @@ int make_btrfs(int fd, const char *device, const char
*label,
memset(super, 0, sizeof(super));
num_bytes = (num_bytes / sectorsize) * sectorsize;
-
Summary: Two device btrfs raid1, as data device not boot/rootfs, mounted and
filled with some data. Power off and remove one device. Reboot and mount the
single device available with -o degraded. Create new subvolume and fill with
some data. Poweroff and reattach previously removed device.
On 05/15/2014 04:40 PM, Chris Murphy wrote:
Summary: Two device btrfs raid1, as data device not boot/rootfs, mounted and
filled with some data. Power off and remove one device. Reboot and mount the
single device available with -o degraded. Create new subvolume and fill with
some data.
On May 15, 2014, at 2:45 PM, Chris Mason c...@fb.com wrote:
On 05/15/2014 04:40 PM, Chris Murphy wrote:
Summary: Two device btrfs raid1, as data device not boot/rootfs, mounted and
filled with some data. Power off and remove one device. Reboot and mount the
single device available with
On Thu, 2014-05-15 at 18:35 +0200, David Sterba wrote:
On Thu, May 08, 2014 at 11:03:57AM +0800, Gui Hecheng wrote:
Add sys chunk array and backup roots info if the new option '-f'
if specified.
This may be useful for debugging sys_chunk related issues.
Sounds useful. One comment below.
Add sys chunk array and backup roots info if the new option '-f'
if specified.
This may be useful for debugging sys_chunk related issues.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
Changelog:
v1-v2: add malloc failure check
---
btrfs-show-super.c | 142
https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape
Probably most of you already know about this, but for those of you who haven't
the above describes ZFS ditto blocks which is a good feature we need on
BTRFS. The briefest summary is that on top of the RAID redundancy there is
On Fri, 16 May 2014 00:38:04 +1000
Russell Coker russ...@coker.com.au wrote:
You do mention the partition alternative, but not as I'd do it for
such a case. Instead of doing a different sized buffer partition
(or using the mkfs.btrfs option to start at some offset into the
device) on
David,
As mentioned, this patch will back-out the earlier patch
50275bacab0f62b91453fbfa29e75c2bb77bf9b6
I am confused on what I am missing ? Any comment?
Thanks, Anand
On 16/05/14 01:06, David Sterba wrote:
On Tue, May 13, 2014 at 05:05:05PM +0800, Wang Shilong wrote:
Btrfs device id
Hi folks,
As requested I've created a new mailing list for xfstests
development and discussion. Reflecting the fact that the test
harness is not really XFS specific anymore, the list is:
fste...@vger.kernel.org
I have not confirmed an archiving location yet (in the process of
doing so
Hi Anand,
On 05/16/2014 12:32 PM, Anand Jain wrote:
David,
As mentioned, this patch will back-out the earlier patch
50275bacab0f62b91453fbfa29e75c2bb77bf9b6
I am confused on what I am missing ? Any comment?
You are right, i guess dave just missed your previous thread.:-)
dave, please
On Fri, May 16, 2014 at 02:46:11PM +1000, Dave Chinner wrote:
Hi folks,
As requested I've created a new mailing list for xfstests
development and discussion. Reflecting the fact that the test
harness is not really XFS specific anymore, the list is:
fste...@vger.kernel.org
Isn't
24 matches
Mail list logo
