kernel: RSP
kernel: CR2: 035c
kernel: ---[ end trace c49186b736aa143c ]---
Has anyone seen this recently or have any ideas on how to fix this problem?
Please CC me as well as the list as I don't believe I'm currently
subscribed to this specific list.
--
Steven Haigh
Emai
wiki
page.
It may seem trivial to people who live, eat, and breathe BTRFS, but for
others, it saves stress, headaches and data loss.
I can't emphasise enough how important getting this part right is until
some future date where *everything* just works.
--
Steven Haigh
Email: net...@crc.id.au
On 2016-09-12 05:48, Martin Steigerwald wrote:
Am Sonntag, 26. Juni 2016, 13:13:04 CEST schrieb Steven Haigh:
On 26/06/16 12:30, Duncan wrote:
> Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
>> In every case, it was a flurry of csum error messages, then instant
hings bit easier
> and perhaps a bit less scary too. Remember if you get bitten badly once
> you tend to stay away from from it all just in case, if you on the other
> hand know what bites you can safely pet the fluffy end instead :)
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
with 3 devices
> only");
> + }
> + if (dev_cnt == 2 && profile & BTRFS_BLOCK_GROUP_RAID5) {
> + warning("RAID5 is not recommended on filesystem with 2 devices
> only");
> + }
> warning_on(!mixed && (data_profile & BTRFS_BLOCK_GROUP_DUP) && ssd,
> "DUP may not actually lead to 2 copies on the device, see
> manual page");
>
>
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
58323
> sdh 325,2522,52 0,149132715 58355
>
>
> So I have a really poor performance in rebuilding a raid5 mostly when the
> replaced device is missing.
> Is there a parameter to tweak of something I can do to improve the replace ?
>
> Re
he system never hung.
Every crash ended with the last line along the lines of "Stopped
recurring error. Your system needs rebooting". I wonder if this error
reporting was altered, that the system wouldn't go down.
Of course I have no way of testing this.
--
Steven Haigh
Em
On 28/06/16 22:25, Austin S. Hemmelgarn wrote:
> On 2016-06-28 08:14, Steven Haigh wrote:
>> On 28/06/16 22:05, Austin S. Hemmelgarn wrote:
>>> On 2016-06-27 17:57, Zygo Blaxell wrote:
>>>> On Mon, Jun 27, 2016 at 10:17:04AM -0600, Chris Murphy wrote:
>>>>
e for parity). You could probably do one pass computing both
> values, but that would need to be done carefully; and, without
> significant optimization, would likely not get you much benefit other
> than cutting the number of loads in half.
And it all means jack shit because you don't get the data to disk that
quick. Who cares if its 500% faster - if it still saturates the
throughput of the actual drives, what difference does it make?
I'm all for actual solutions, but the nirvana fallacy seems to apply here...
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
g the guts out of the array
with mdadm RAID6 doing a reshape of that - and no read errors, system
crashes or other problems in over 48 hours.
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
don't think these go anywhere near far enough.
It needs to be completely obvious that its a good chance you'll lose
everything. IMHO that's the only way that will stop BTRFS from getting
the 'data eater' reputation. It can be revisited and reworded when the
implementation is more tested and st
rch something, are
more likely to go to fora and wiki
than search out an upstream fora.
Another good idea.
I'd also recommend updates to the ArchLinux wiki - as for some reason I
always seem to end up there when searching for a certain topic...
--
Steven Haigh
Email: net...@crc.id.au
Web: https:/
On 26/06/16 12:30, Duncan wrote:
> Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
>
>> In every case, it was a flurry of csum error messages, then instant
>> death.
>
> This is very possibly a known bug in btrfs, that occurs even in raid1
> wher
On 26/06/16 02:25, Chris Murphy wrote:
> On Fri, Jun 24, 2016 at 10:19 PM, Steven Haigh <net...@crc.id.au> wrote:
>
>>
>> Interesting though that EVERY crash references:
>> kernel BUG at fs/btrfs/extent_io.c:2401!
>
> Yeah because you're mounted ro, an
On 25/06/2016 3:50 AM, Austin S. Hemmelgarn wrote:
> On 2016-06-24 13:43, Steven Haigh wrote:
>> On 25/06/16 03:40, Austin S. Hemmelgarn wrote:
>>> On 2016-06-24 13:05, Steven Haigh wrote:
>>>> On 25/06/16 02:59, ronnie sahlberg wrote:
>>>> What I hav
On 25/06/16 03:40, Austin S. Hemmelgarn wrote:
> On 2016-06-24 13:05, Steven Haigh wrote:
>> On 25/06/16 02:59, ronnie sahlberg wrote:
>> What I have in mind here is that a file seems to get CREATED when I copy
>> the file that crashes the system in the target directory. I'm
s worked
perfectly for years) and using maybe a vanilla BTRFS on top of that
block device.
Anything else seems like too much work for too little reward - and lack
of confidence.
> On Fri, Jun 24, 2016 at 9:26 AM, Steven Haigh <net...@crc.id.au> wrote:
>> On 25/06/16 00:52, Steven H
On 25/06/16 00:52, Steven Haigh wrote:
> Ok, so I figured that despite what the BTRFS wiki seems to imply, the
> 'multi parity' support just isn't stable enough to be used. So, I'm
> trying to revert to what I had before.
>
> My setup consist of:
> * 2 x 3Tb drives +
in my future,
but not sure how to minimise this :\
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
On 2016-06-24 13:22, Eric Sandeen wrote:
On 6/23/16 8:49 PM, Steven Haigh wrote:
I've tried to build the new tools for CentOS 6 / Scientific Linux 6 /
RHEL 6 etc.
During the build process, I see:
cmds-fi-du.c: In function 'du_calc_file_space':
cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED
identifier is reported only
once
cmds-fi-du.c:330: error: for each function it appears in.)
make: *** [cmds-fi-du.o] Error 1
I'm guessing this is probably due to a different GCC version used? I'm
guessing this is a simple fix for someone with knowhow... :)
--
Steven Haigh
Email: net
On 2016-06-24 05:13, Scott Talbert wrote:
On Thu, 23 Jun 2016, Steven Haigh wrote:
On 24/06/16 04:35, Austin S. Hemmelgarn wrote:
On 2016-06-23 13:44, Steven Haigh wrote:
Hi all,
Relative newbie to BTRFS, but long time linux user. I pass the full
disks from a Xen Dom0 -> guest DomU and
On 24/06/16 04:35, Austin S. Hemmelgarn wrote:
> On 2016-06-23 13:44, Steven Haigh wrote:
>> Hi all,
>>
>> Relative newbie to BTRFS, but long time linux user. I pass the full
>> disks from a Xen Dom0 -> guest DomU and run BTRFS within the DomU.
>>
>
h a btrfs replace cancel
/mnt/fileshare - so at least the system doesn't crash completely in the
meantime - and mounted it with -o degraded until I can see what the deal
is here.
Any suggestions?
--
Steven Haigh
Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 041
24 matches
Mail list logo
