On Wed, Oct 21, 2015 at 2:07 PM, Austin S Hemmelgarn
wrote:
> And I realize of course right after sending this that my other reply didn't
> get through because GMail refuses to send mail in plain text, no matter how
> hard I beat it over the head...
In the web browser
On 2015-10-21 12:01, Chris Murphy wrote:
On Wed, Oct 21, 2015 at 2:07 PM, Austin S Hemmelgarn
wrote:
And I realize of course right after sending this that my other reply didn't
get through because GMail refuses to send mail in plain text, no matter how
hard I beat it over
On 2015-10-20 15:59, Austin S Hemmelgarn wrote:
On 2015-10-20 15:20, Duncan wrote:
Yes, there's some small but not infinitesimal chance the checksum may be
wrong, but if there's two copies of the data and the checksum on one is
wrong while the checksum on the other verifies... yes, there's
On 2015-10-21 07:51, Austin S Hemmelgarn wrote:
On 2015-10-20 15:59, Austin S Hemmelgarn wrote:
On 2015-10-20 15:20, Duncan wrote:
Yes, there's some small but not infinitesimal chance the checksum may be
wrong, but if there's two copies of the data and the checksum on one is
wrong while the
On 2015-10-20 09:15, Russell Coker wrote:
On Wed, 21 Oct 2015 12:00:59 AM Austin S Hemmelgarn wrote:
https://www.gnu.org/software/ddrescue/
At this stage I would use ddrescue or something similar to copy data from
the failing disk to a fresh disk, then do a BTRFS scrub to regenerate
the
Austin S Hemmelgarn posted on Tue, 20 Oct 2015 09:59:17 -0400 as
excerpted:
>>> It is worth clarifying also that:
>>> a. While BTRFS will not return bad data in this case, it also won't
>>> automatically repair the corruption.
>>
>> Really? If so I think that's a bug in BTRFS. When mounted rw
james harvey posted on Tue, 20 Oct 2015 00:16:15 -0400 as excerpted:
> Background -
>
> My fileserver had a "bad event" last week. Shut it down normally to add
> a new hard drive, and it would no longer post. Tried about 50 times,
> doing the typical everything non-essential unplugged,
On 2015-10-20 14:54, Duncan wrote:
But tho I'm a user not a dev and thus haven't actually checked the source
code itself, my believe here is with Russ and disagrees with Austin, as
based on what I've read both on the wiki and seen here previously, btrfs
runtime (that is, not during scrub)
On 2015-10-20 15:20, Duncan wrote:
Austin S Hemmelgarn posted on Tue, 20 Oct 2015 09:59:17 -0400 as
excerpted:
It is worth clarifying also that:
a. While BTRFS will not return bad data in this case, it also won't
automatically repair the corruption.
Really? If so I think that's a bug in
On 10/20/2015 15:59 -0400, Austin S Hemmelgarn wrote:
>> .
>> With a 32-bit checksum and a 4k block (the math is easier with
>> smaller numbers), that's 4128 bits, which means that a random
>> single bit error will have a approximately 0.24% chance of
>> occurring
Austin S Hemmelgarn posted on Tue, 20 Oct 2015 15:48:07 -0400 as
excerpted:
> FWIW, my assessment is based on some testing I did a while back (kernel
> 3.14 IIRC) using a VM. The (significantly summarized of course)
> procedure I used was:
> 1. Create a basic minimalistic Linux system in a VM
On 2015-10-20 00:45, Russell Coker wrote:
On Tue, 20 Oct 2015 03:16:15 PM james harvey wrote:
sda appears to be going bad, with my low threshold of "going bad", and
will be replaced ASAP. It just developed 16 reallocated sectors, and
has 40 current pending sectors.
I'm currently running a
On Wed, 21 Oct 2015 12:00:59 AM Austin S Hemmelgarn wrote:
> > https://www.gnu.org/software/ddrescue/
> >
> > At this stage I would use ddrescue or something similar to copy data from
> > the failing disk to a fresh disk, then do a BTRFS scrub to regenerate
> > the missing data.
> >
> > I
Background -
My fileserver had a "bad event" last week. Shut it down normally to
add a new hard drive, and it would no longer post. Tried about 50
times, doing the typical everything non-essential unplugged, trying 1
of 4 memory modules at a time, and 1 of 2 processors at a time. Got
no
On Tue, 20 Oct 2015 03:16:15 PM james harvey wrote:
> sda appears to be going bad, with my low threshold of "going bad", and
> will be replaced ASAP. It just developed 16 reallocated sectors, and
> has 40 current pending sectors.
>
> I'm currently running a "btrfs scrub start -B -d -r /terra",
15 matches
Mail list logo