Note that this FS still be unmountable with last for-linus branch.
Aug 27 10:47:33 backup2 kernel: [987464.600465] device fsid
a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110425
/dev/mapper/vg--backupplug-backup
Aug 27 10:47:33 backup2 kernel: [987464.601701] btrfs: force zlib
Hi Robert,
do you think you can make the root_snap_send file of yours available
anywhere (not sure how big it is)?
Also, I am not sure I understand how you btrfs tree looks like WRT to
where all subvolumes are mounted (but all others seem to understand
well).
You mentioned:
/dev/loop0 on
On Sun, 26 Aug 2012 16:07:33 -0400 (EDT), tubalcane wrote:
I'm primarily interested in the block level checksums of files and the
scrubbing
feature to detect corrupt files. Currently I use ext4 and create and keep
md5sums of everything which is tedious but I care about my data (quadruple
Hi Chris,
I am looking at your fix in find_extent_clone(), and the code now
looks like this:
if (compressed == BTRFS_COMPRESS_NONE)
extent_item_pos = logical - found_key.objectid;
else
extent_item_pos = 0;
extent_item_pos = logical - found_key.objectid;
So the compressed flag
Commit 442a4f6308e694e0fa6025708bd5e4e424bbf51c added btrfs device
statistic counters for detected IO and checksum errors to Linux 3.5.
The statistic part that counts checksum errors in
end_bio_extent_readpage() can cause a BUG() in a subfunction:
kernel BUG at fs/btrfs/volumes.c:3762!
That part
Just following up on this... does anyone know if any of this is
technically feasible even if not implemented/supported today?
Also, do any hardware RAID1 implementations offer something like the
full btrfs checksum functionality?
I've seen HP promoting their `Advanced Data Mirroring' in new
On 08/27/2012 07:12 PM, Stefan Behrens wrote:
On Sun, 26 Aug 2012 16:07:33 -0400 (EDT), tubalcane wrote:
I'm primarily interested in the block level checksums of files and the
scrubbing
feature to detect corrupt files. Currently I use ext4 and create and keep
md5sums of everything which is
On Mon, 27 Aug 2012 23:31:41 +0800, Liu Bo wrote:
On 08/27/2012 07:12 PM, Stefan Behrens wrote:
On Sun, 26 Aug 2012 16:07:33 -0400 (EDT), tubalcane wrote:
I'm primarily interested in the block level checksums of files and the
scrubbing
feature to detect corrupt files. Currently I use ext4
This is based on Josef's Btrfs: turbo charge fsync.
We should cleanup those extents after we've finished logging inode,
otherwise we may do redundant work on them.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/tree-log.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
This is based on Josef's Btrfs: turbo charge fsync.
The above Josef's patch performs very good in random sync write test,
because we won't have too much extents to merge.
However, it does not performs good on the test:
dd if=/dev/zero of=foobar bs=4k count=12500 oflag=sync
The reason is when we
On Mon, Aug 27, 2012 at 10:52:19AM -0600, Liu Bo wrote:
This is based on Josef's Btrfs: turbo charge fsync.
We should cleanup those extents after we've finished logging inode,
otherwise we may do redundant work on them.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/tree-log.c
On Mon, Aug 27, 2012 at 10:52:20AM -0600, Liu Bo wrote:
This is based on Josef's Btrfs: turbo charge fsync.
The above Josef's patch performs very good in random sync write test,
because we won't have too much extents to merge.
However, it does not performs good on the test:
dd
Hi Alex,
i've made a list of all commands i executed for this test. You can find
it here:
http://pastebin.com/y8PBgmMZ
Hi Robert,
do you think you can make the root_snap_send file of yours available
anywhere (not sure how big it is)?
I'm afraid i've already delete it :/ sry. But in the
On Tue, Jul 31, 2012 at 2:37 PM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
I've been working on running down intermittent ENOSPC issues.
I can only seem to replicate ENOSPC errors when running zlib
compression. However, I have been seeing similar ENOSPC errors to a
lesser extent when
On Mon, Aug 27, 2012 at 04:05:37PM -0600, Sage Weil wrote:
On Sun, 26 Aug 2012, Josef Bacik wrote:
On Fri, Aug 24, 2012 at 04:47:56PM -0600, Sage Weil wrote:
Sadly, now I hit another one:
Oh haha you need to set current-journal_info to the trans you have before
you
call
On 08/28/2012 01:12 AM, Josef Bacik wrote:
On Mon, Aug 27, 2012 at 10:52:20AM -0600, Liu Bo wrote:
This is based on Josef's Btrfs: turbo charge fsync.
The above Josef's patch performs very good in random sync write test,
because we won't have too much extents to merge.
However, it does not
16 matches
Mail list logo
