Just noting that I left things till I put a 4.4 kernel on (4.4.3 as it
turns out) and now convert is going much nicer.
Well it's still got some silly thing where the newly allocated blocks
are mostly empty. It appears that the convert likes to take the 1Gig
RAID1 block and write it to a new RAID5
Yeah having a scrub take 9 hours instead of 24 (+ latency of human
involvement) would be really nice.
On Thu, Dec 3, 2015 at 1:32 AM, Austin S Hemmelgarn
wrote:
> On 2015-12-02 08:45, Duncan wrote:
>>
>> Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
>> excerpted:
>>
>>> On 2015
On 2015-12-02 08:45, Duncan wrote:
Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
excerpted:
On 2015-12-02 05:01, Duncan wrote:
[on unverified errors returned by scrub]
Unverified errors are, I believe[1], errors where a metadata block
holding checksums itself has an error
Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
excerpted:
> On 2015-12-02 05:01, Duncan wrote:
[on unverified errors returned by scrub]
>>
>> Unverified errors are, I believe[1], errors where a metadata block
>> holding checksums itself has an error, so the blocks its checksums
On 2015-12-02 05:01, Duncan wrote:
Gareth Pye posted on Wed, 02 Dec 2015 18:07:48 +1100 as excerpted:
Output from scrub:
sudo btrfs scrub start -Bd /data
[Omitted no-error device reports.]
scrub device /dev/sdh (id 6) done
scrub started at Wed Dec 2 07:04:08 2015 and finished after 06:
Thanks for that info, ram appears to be checking out fine and smartctl
reported that the drives are old but one had some form of elevated
error. Looks like I might be buying a new drive.
On Wed, Dec 2, 2015 at 9:01 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Gareth Pye posted on Wed, 02 Dec 2015 18
Gareth Pye posted on Wed, 02 Dec 2015 18:07:48 +1100 as excerpted:
> Output from scrub:
> sudo btrfs scrub start -Bd /data
[Omitted no-error device reports.]
> scrub device /dev/sdh (id 6) done
>scrub started at Wed Dec 2 07:04:08 2015 and finished after 06:47:22
>total bytes scrubbed:
Output from scrub:
sudo btrfs scrub start -Bd /data
scrub device /dev/sdd (id 2) done
scrub started at Wed Dec 2 07:04:08 2015 and finished after 08:53:53
total bytes scrubbed: 2.47TiB with 0 errors
scrub device /dev/sde (id 3) done
scrub started at Wed Dec 2 07:04:08 2015
Will do that once the scrub finishes/I get home from work.
On Wed, Dec 2, 2015 at 7:30 AM, Austin S Hemmelgarn
wrote:
> On 2015-12-01 15:12, Gareth Pye wrote:
>>
>> On Wed, Dec 2, 2015 at 2:14 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>>>
>>> So if you're running into the same problem gentoo's liv
On 2015-12-01 15:12, Gareth Pye wrote:
On Wed, Dec 2, 2015 at 2:14 AM, Duncan <1i5t5.dun...@cox.net> wrote:
So if you're running into the same problem gentoo's live-git build did,
it's likely because you're building the devel branch cloned from
kernel.org, which is no longer updated.
Woah, ke
On Wed, Dec 2, 2015 at 2:14 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> So if you're running into the same problem gentoo's live-git build did,
> it's likely because you're building the devel branch cloned from
> kernel.org, which is no longer updated.
Woah, kernel.org is making a log that looks l
On 2015-12-01 07:57, Gareth Pye wrote:
Poking around I just noticed that btrfs de stats /data points out that
3 of my drives have some read_io_errors. I'm guessing that is a bad
thing. I assume this would indicate bad hardware and would be a likely
cause of system crashes.
In general, given that
Gareth Pye posted on Tue, 01 Dec 2015 23:38:52 +1100 as excerpted:
> One of the first things I checked was that I was using an up to date
> btrfs util and it keeps reporting that I'm using version 4.0 (btrfs
> --version). This is after confirming that my git clone is up to date,
> the last commit
Gareth Pye posted on Tue, 01 Dec 2015 23:57:28 +1100 as excerpted:
> Poking around I just noticed that btrfs de stats /data points out that 3
> of my drives have some read_io_errors. I'm guessing that is a bad thing.
> I assume this would indicate bad hardware and would be a likely cause of
> syst
Poking around I just noticed that btrfs de stats /data points out that
3 of my drives have some read_io_errors. I'm guessing that is a bad
thing. I assume this would indicate bad hardware and would be a likely
cause of system crashes.
:(
On Tue, Dec 1, 2015 at 11:38 PM, Gareth Pye wrote:
> I'm g
I'm getting some crashes when converting from RAID1 to RAID5, I know
that there was some issues recently but was lead to believe that there
were fixes that should have been in 4.3. (I'm using the ubuntu kernel
ppa teams 4.3 kernel)
One of the first things I checked was that I was using an up to da
16 matches
Mail list logo
