On Tuesday 18 February 2014 15:02:51 Chris Murphy wrote:
On Feb 18, 2014, at 2:33 PM, Wolfgang Mader wolfgang_ma...@brain-frog.de
wrote:
Feb 18 13:14:09 deck kernel: ata2.00: failed command: READ DMA
Feb 18 13:14:09 deck kernel: ata2.00: cmd
c8/00:08:60:f2:30/00:00:00:00:00/e0 tag 0 dma
Hi all,
well, I hit the first incidence where I really have to work with my btrfs
setup. To get things straight I want to double-check here to not screw things
up right from the start. We are talking about a home server. There is no time
or user pressure involved, and there are backups, too.
On Feb 18, 2014, at 6:19 AM, Wolfgang Mader wolfgang_ma...@brain-frog.de
wrote:
Hi all,
well, I hit the first incidence where I really have to work with my btrfs
setup. To get things straight I want to double-check here to not screw things
up right from the start. We are talking about a
On Tuesday 18 February 2014 11:48:49 Chris Murphy wrote:
On Feb 18, 2014, at 6:19 AM, Wolfgang Mader wolfgang_ma...@brain-frog.de
wrote:
Hi all,
well, I hit the first incidence where I really have to work with my btrfs
setup. To get things straight I want to double-check here to not
On Feb 18, 2014, at 2:33 PM, Wolfgang Mader wolfgang_ma...@brain-frog.de
wrote:
Feb 18 13:14:09 deck kernel: ata2.00: failed command: READ DMA
Feb 18 13:14:09 deck kernel: ata2.00: cmd c8/00:08:60:f2:30/00:00:00:00:00/e0
tag 0 dma 4096 in
res
Chris Murphy posted on Tue, 18 Feb 2014 15:02:51 -0700 as excerpted:
Also, what model drives are being used? If they are
consumer drives, they almost certainly have long error recoveries over
30 minutes.
FWIW, that should be 30 seconds, not 30 minutes (OUCH!). The below
context sort of
Chris Murphy posted on Tue, 18 Feb 2014 11:48:49 -0700 as excerpted:
This is not btrfs' fault but due to an hd error. I saw in the system
logs
btrfs: bdev /dev/sdb errs: wr 0, rd 2, flush 0, corrupt 0, gen 0
and a subsequent check on btrfs showed
[/dev/sdb].write_io_errs 0
