On Tue, Apr 7, 2015 at 11:40 PM, Dan Merillat dan.meril...@gmail.com wrote:
Bcache failures are nasty, because they leave a mix of old and new
data on the disk. In this case, there was very little dirty data, but
of course the tree roots were dirty and out-of-sync.
It's a known bug with bcache and enabling discard, it was discarding
sections containing data it wanted. After a reboot bcache refused to
accept the cache data, and of course it was dirty because I'm frankly
too stupid to breathe sometimes.
So yes, it's a bcache issue, but that's unresolvable.
Sorry I pressed send before I finished my thoughts.
btrfs restore gets nowhere with any options. btrfs-recover says the
superblocks are fine, and chunk recover does nothing after a few hours
of reading.
Everything else bails out with the errors I listed above.
On Wed, Apr 8, 2015 at 2:36 PM,
time, this is all you can try now. If your data is
valuable - well, you have to wait for the experts here. But general opinion
here is: If you don't have backups, your data is not valuable by definition,
especially if using an unmature fs, or an even more experimental setup like
bcache. ;-)
PS
Any ideas on where to start with this? I did flush the cache out to
disk before I made changes to the bcache configuration, so there
shouldn't be anything completely missing, just some bits of stale
metadata. If I can get the tools to take the closest match and run
with it it would probably
Bcache failures are nasty, because they leave a mix of old and new
data on the disk. In this case, there was very little dirty data, but
of course the tree roots were dirty and out-of-sync.
fileserver:/usr/src/btrfs-progs# ./btrfs --version
Btrfs v3.18.2
kernel version 3.18
[ 572.573566]
I have a server which runs zoneminder (video recording which is CPU and
disk IO intensive) while also doing a bunch of I/O over serial ports.
I have a a dual core
Intel(R) Core(TM) i3-2100T CPU @ 2.50GHz
(4 virtual CPUs in /proc/cpuinfo)
It's pretty clear that when zoneminder is doing more work,
Hi,
has this issue been resolved?
I would like to use the bcache + btrfs combo.
Thanks
--
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
,
Fábio Pfeifer
2014-07-30 20:01 GMT-03:00 Larkin Lowrey llow...@nuclearwinter.com:
I've been running two backup servers, with 25T and 20T of data, using
btrfs on bcache (writeback) for about 7 months. I periodically run btrfs
scrubs and backup verifies (SHA1 hashes) and have never had a corruption
Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018, does
this bug still exists?
Kernel 3.14
B: 2x HDD 1 TB
C: 1x SSD 256 GB
# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc --cache_replacement_policy=lru
# mkfs.btrfs -d raid1 -m raid1 -L BTRFS_RAID /dev/bcache0 /dev/bcache1
I
dptrash posted on Thu, 31 Jul 2014 17:35:44 +0200 as excerpted:
Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018,
does this bug still exists?
Kernel 3.14 B: 2x HDD 1 TB C: 1x SSD 256 GB
# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
--cache_replacement_policy=lru
#
Concerning http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018, does
this bug still exists?
Kernel 3.14
B: 2x HDD 1 TB
C: 1x SSD 256 GB
# make-bcache -B /dev/sda /dev/sdb -C /dev/sdc --cache_replacement_policy=lru
# mkfs.btrfs -d raid1 -m raid1 -L BTRFS_RAID /dev/bcache0 /dev/bcache1
I
I've been running two backup servers, with 25T and 20T of data, using
btrfs on bcache (writeback) for about 7 months. I periodically run btrfs
scrubs and backup verifies (SHA1 hashes) and have never had a corruption
issue.
My use of btrfs is simple, though, with no subvolumes and no btrfs level
On 2014-04-30 14:16, Felix Homann wrote:
Hi,
a couple of months ago there has been some discussion about issues
when using btrfs on bcache:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018
From looking at the mailing list archives I cannot tell whether or not
this issue has
Hi,
a couple of months ago there has been some discussion about issues
when using btrfs on bcache:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018
From looking at the mailing list archives I cannot tell whether or not
this issue has been resolved in current kernels from either
On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote:
On Fri, Dec 20, 2013 at 03:46:30PM +, Chris Mason wrote:
On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote:
Hello,
I put the WARN_ON(1); after the printk lines (incomplete page read
and incomplete page write) in
On Wed, Jan 08, 2014 at 07:35:32PM +, Chris Mason wrote:
On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote:
Ok, I looked again at the relevant btrfs code, I guess I can see how this
printk
isn't normally triggered. But Chris, _what on earth_ is btrfs trying to
check
for
On Fri, Dec 20, 2013 at 03:46:30PM +, Chris Mason wrote:
On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote:
Hello,
I put the WARN_ON(1); after the printk lines (incomplete page read
and incomplete page write) in extent_io.c.
here some call traces:
[ 19.509497]
). I didn't have time to test with kernel 3.11 again.
But lately the errors increased, and it started to make my system
unstable, and then unusable.
I had to reformat everything and recover my backups.
I don't have my / and /home in btrfs over bcache anymore, but I can
make some tests in a spare HD
on hacking on the kernel is
exactly 0 - I'll try to see if I can compile a custom kernel and get
it running.
Could you please cc the bcache and btrfs list together?
Done.
I did some more testing - I copied an image of a 128GB drive over the
network (via netcat) onto the bcache/btrfs system
. Are you able to add
a WARN_ON to the message that prints this so we can see the stack trace?
Could you please cc the bcache and btrfs list together?
-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote:
Hello,
I put the WARN_ON(1); after the printk lines (incomplete page read
and incomplete page write) in extent_io.c.
here some call traces:
[ 19.509497] incomplete page read in btrfs with offset 2560 and length 1536
[
On Thu, Dec 19, 2013 at 2:04 PM, Fábio Pfeifer fmpfei...@gmail.com wrote:
Any update on this?
I have here exactly the same issue. Kernel 3.12.5-1-ARCH, backing
device 500 GB IDE, cache 24 GB SSD = /dev/bcache0
On /dev/bcache I also have 2 subvolumes, / and /home. I get lots of
messages in
to disappear. As
soon as I re-attached /dev/sdb3 they started again, so I am fairly
sure it's an unfavorable interaction between bcache and btrfs.
Is this something I should be worried about (they're only emitted with
KERN_INFO?) or just an alignment problem? The underlying HDD is using
4K-Sectors
a desktop).
Trying to fix this, I unattached the cache (still using /dev/bcache0,
but without /dev/sdb3 attached), causing these errors to disappear. As
soon as I re-attached /dev/sdb3 they started again, so I am fairly
sure it's an unfavorable interaction between bcache and btrfs
to the message that prints this so we can see the stack trace?
Could you please cc the bcache and btrfs list together?
-chris
--
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
-attached /dev/sdb3 they started again, so I am fairly
sure it's an unfavorable interaction between bcache and btrfs.
Is this something I should be worried about (they're only emitted with
KERN_INFO?) or just an alignment problem? The underlying HDD is using
4K-Sectors, while the block_size of bcache
27 matches
Mail list logo
