Marc MERLIN posted on Fri, 22 Aug 2014 20:10:55 -0700 as excerpted:
> On Sat, Aug 23, 2014 at 02:52:16AM +, Duncan wrote:
>> > For mysql, I got:
>> > InnoDB: Page directory corruption:
>> > infimum not pointed to 140708 11:53:58 InnoDB: Page dump in ascii and
>> > hex (16384 bytes):
>> > len 1
On Sat, Aug 23, 2014 at 12:10 PM, Marc MERLIN wrote:
> On Sat, Aug 23, 2014 at 02:52:16AM +, Duncan wrote:
>> > For mysql, I got:
>> > InnoDB: Page directory corruption:
>> > infimum not pointed to 140708 11:53:58
>> > InnoDB: Page dump in ascii and hex (16384 bytes):
>> > len 16384; hex 0
Florian Gamböck posted on Sat, 23 Aug 2014 00:00:46 +0200 as excerpted:
> I think i just crashed my btrfs partition, is someone willing to guide
> me through the recovery steps?
A month or so ago I had a similar problem, and got some experience with
real recovery, that I hadn't had previous desp
Um. Derp. Yeah, it's actually sd[defh].
Thanks for the continuing education.
On Fri, Aug 22, 2014 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> G. Richard Bellamy posted on Fri, 22 Aug 2014 14:36:22 -0700 as excerpted:
>
>> An interesting exercise saw me reading data from my RAID10 to a USB
The crash is
[ cut here ]
kernel BUG at fs/btrfs/extent_io.c:2124!
invalid opcode: [#1] SMP
...
CPU: 3 PID: 88 Comm: kworker/u8:7 Not tainted 3.17.0-0.rc1.git0.1.fc22.x86_64 #1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Workqueue: btr
The crash is
[ cut here ]
kernel BUG at fs/btrfs/extent_io.c:2124!
invalid opcode: [#1] SMP
...
CPU: 3 PID: 88 Comm: kworker/u8:7 Not tainted 3.17.0-0.rc1.git0.1.fc22.x86_64 #1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Workqueue: btr
On Fri, Aug 22, 2014 at 10:32:13AM -0500, Eric Sandeen wrote:
> On 8/20/14, 3:51 AM, Liu Bo wrote:
> > The crash is
> >
> > [ cut here ]
> > kernel BUG at fs/btrfs/extent_io.c:2124!
> > invalid opcode: [#1] SMP
>
> ...
>
> > ---
> > v2:
> >- Improve the commit lo
G. Richard Bellamy posted on Fri, 22 Aug 2014 14:36:22 -0700 as excerpted:
> An interesting exercise saw me reading data from my RAID10 to a USB
> device, which produced the following representative iostat:
>
> Linux 3.14.17-1-lts (eanna) 08/22/2014 _x86_64_ (24 CPU)
>
> avg-cpu: %user %nice
On Sat, Aug 23, 2014 at 02:52:16AM +, Duncan wrote:
> > For mysql, I got:
> > InnoDB: Page directory corruption:
> > infimum not pointed to 140708 11:53:58
> > InnoDB: Page dump in ascii and hex (16384 bytes):
> > len 16384; hex (16KB of 0's).
>
> Is that on ssd or spinning rust, and
Marc MERLIN posted on Fri, 22 Aug 2014 11:49:19 -0700 as excerpted:
> On Fri, Aug 22, 2014 at 06:17:38PM +, Duncan wrote:
>> Marc MERLIN posted on Fri, 22 Aug 2014 08:50:40 -0700 as excerpted:
>>
>> > Fairly often (over 20 times for me so far with various kernel
>> > versions), when I reboot
I am sorry, I totally forgot to post information about my systems. I use
Btrfs v3.14.2 on all systems. My Raspberry Pi, on which the crash occured,
runs on Linux Kernel 3.16.1, my other computer on which I try to recover the
file system, runs on 3.14.14.
--
To unsubscribe from this list: send the
Hi there,
I think i just crashed my btrfs partition, is someone willing to guide
me through the recovery steps?
The "crash" went like so: I was testing the watchdog ability of my
Raspberry Pi, whose root filesystem is btrfs. To test if the watchdog
works I started a fork bomb. Normally, the
An interesting exercise saw me reading data from my RAID10 to a USB
device, which produced the following representative iostat:
Linux 3.14.17-1-lts (eanna) 08/22/2014 _x86_64_ (24 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.530.000.502.830.00 93.14
Josef Bacik writes:
> On 06/20/2014 12:51 PM, Rasmus Villemoes wrote:
>> Maybe "else if" was meant, but because of the goto out_unlock, it
>> doesn't make a difference. Anyway, I chose the "only whitespace" fix.
>>
>> Signed-off-by: Rasmus Villemoes
>> ---
>> fs/btrfs/tree-log.c | 3 ++-
>> 1
On 2014-08-22 14:22, Rich Freeman wrote:
> On Fri, Aug 22, 2014 at 8:04 AM, Austin S Hemmelgarn
> wrote:
>>>
>> I personally use Gentoo Unstable on all my systems, so I build all my
>> kernels locally anyway, and stay pretty much in-line with the current
>> stable Mainline kernel.
>
> "Gentoo Uns
On Fri, Aug 22, 2014 at 06:17:38PM +, Duncan wrote:
> Marc MERLIN posted on Fri, 22 Aug 2014 08:50:40 -0700 as excerpted:
>
> > Fairly often (over 20 times for me so far with various kernel versions),
> > when I reboot after a crash, my google-chrome profile is damaged in one
> > of 2 ways:
>
On Fri, Aug 22, 2014 at 12:32:27PM -0500, Eric Sandeen wrote:
> On 8/22/14, 10:50 AM, Marc MERLIN wrote:
>
> > But if my kernel hangs due to a bug that isn't btrfs' fault and I need
> > to power off and back on, after reboot my google-chrome profile is
> > almost always broken in some way.
>
> Gi
On Fri, Aug 22, 2014 at 3:35 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> No claim to be a dev, btrfs or otherwise, here, but I believe in this
> case you /are/ "being too paranoid."
>
> Both btrfs send and receive only deal with data/metadata they know how to
> deal with. If it's corrupt in some
On Fri, Aug 22, 2014 at 8:04 AM, Austin S Hemmelgarn
wrote:
>>
> I personally use Gentoo Unstable on all my systems, so I build all my
> kernels locally anyway, and stay pretty much in-line with the current
> stable Mainline kernel.
"Gentoo Unstable" probably means gentoo-sources, testing version
Marc MERLIN posted on Fri, 22 Aug 2014 08:50:40 -0700 as excerpted:
> Fairly often (over 20 times for me so far with various kernel versions),
> when I reboot after a crash, my google-chrome profile is damaged in one
> of 2 ways:
> 1) open tabs don't reopen 2) google-chrome says that my profile is
Austin S Hemmelgarn posted on Fri, 22 Aug 2014 08:04:12 -0400 as
excerpted:
> On 2014-08-22 07:59, Shriramana Sharma wrote:
>> Hello. I've seen repeated advices to use the latest kernel. While
>> hearing of the recent compression bug affecting recent kernels does
>> somewhat warn one off the previ
Am Freitag, 22. August 2014, 17:29:29 schrieb Shriramana Sharma:
> Hello. I've seen repeated advices to use the latest kernel. While
> hearing of the recent compression bug affecting recent kernels does
> somewhat warn one off the previous advice, I would like to know what
> people who are running
Filipe David Manana posted on Fri, 22 Aug 2014 10:58:33 +0100 as
excerpted:
> On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
>> excerpted:
>>
>>> I would stay with rsync for a while, because there is alwa
On 8/22/14, 10:50 AM, Marc MERLIN wrote:
> But if my kernel hangs due to a bug that isn't btrfs' fault and I need
> to power off and back on, after reboot my google-chrome profile is
> almost always broken in some way.
Given my experiences with userspace in general, I'd lay money on
google-chrome
On Aug 22, 2014, at 5:59 AM, Shriramana Sharma wrote:
> Hello. I've seen repeated advices to use the latest kernel. While
> hearing of the recent compression bug affecting recent kernels does
> somewhat warn one off the previous advice, I would like to know what
> people who are running regular
Someone just told me yesterday they had the same problem, so I filed a
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=83041
Fairly often (over 20 times for me so far with various kernel versions),
when I reboot after a crash, my google-chrome profile is damaged in one
of 2 ways:
1) open tabs don
On 8/20/14, 3:51 AM, Liu Bo wrote:
> The crash is
>
> [ cut here ]
> kernel BUG at fs/btrfs/extent_io.c:2124!
> invalid opcode: [#1] SMP
...
> ---
> v2:
>- Improve the commit log to be clear, suggested by Eric.
Well, I had specifically asked for it to include de
On 8/20/14, 10:35 PM, Gui Hecheng wrote:
> A memory problem reported by valgrind as follows:
> === Syscall param pwrite64(buf) points to uninitialised byte(s)
> When running:
> # valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup
>
> Because the output buf size is alloced wi
On 8/22/14, 2:35 AM, Marc Dietrich wrote:
> Hi Eric,
>
> Am Donnerstag, 21. August 2014, 13:56:49 schrieb Eric Sandeen:
>> On 8/21/14, 1:42 PM, Eric Sandeen wrote:
>>> On 8/20/14, 10:35 PM, Gui Hecheng wrote:
A memory problem reported by valgrind as follows:
=== Syscall param pwrite64
On Fri, Aug 22, 2014 at 05:29:29PM +0530, Shriramana Sharma wrote:
> Hello. I've seen repeated advices to use the latest kernel. While
> hearing of the recent compression bug affecting recent kernels does
> somewhat warn one off the previous advice, I would like to know what
> people who are runnin
Hello Zach!
Am 2014-08-21 um 23:25 schrieb Zach Brown:
> On Thu, Aug 21, 2014 at 09:03:16PM +0200, Klaus Holler wrote:
>> Hello Hugo and Zach!
>>
>> a big thanks to both of you!
>>
>> Both Hugo's userspace workaround and
>> Zach's patch work fine for me - the /boot snapshot can be restored
>> comp
On Fri, Aug 22, 2014 at 09:56:55AM +0300, Konstantinos Skarlatos wrote:
> I would stay with rsync for a while, because there is always the
> possibility of a bug that corrupts both your primary filesystem and
> your backup one, or send propagating corruption from one filesystem
> to another (Or may
On 22/8/2014 12:58 μμ, Filipe David Manana wrote:
On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.dun...@cox.net> wrote:
Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
excerpted:
I would stay with rsync for a while, because there is always the
possibility of a bug that corr
> "Chris" == Chris Murphy writes:
Chris> Since the SD Card spec references a completely different command
Chris> than the ATA spec (TRIM), I don't think either one of these are
Chris> TRIM, even if functionally equivalent. Instead the SD Card
Chris> ERASE_* commands are probably being used,
On 2014-08-22 07:59, Shriramana Sharma wrote:
> Hello. I've seen repeated advices to use the latest kernel. While
> hearing of the recent compression bug affecting recent kernels does
> somewhat warn one off the previous advice, I would like to know what
> people who are running regular distros do
Hello. I've seen repeated advices to use the latest kernel. While
hearing of the recent compression bug affecting recent kernels does
somewhat warn one off the previous advice, I would like to know what
people who are running regular distros do to get the latest kernel.
Personally I'm on Kubuntu,
On 2014-08-20 23:22, Shriramana Sharma wrote:
> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the
> development itself:
>
> Is this just an indication
On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
> excerpted:
>
>> I would stay with rsync for a while, because there is always the
>> possibility of a bug that corrupts both your primary filesystem and your
On Fri, 2014-08-22 at 10:42 +0200, Marc Dietrich wrote:
> Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng:
> > On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
> > > Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng:
> > > > On Mon, 2014-08-18 at 11:25 +0200, Marc Dietri
Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng:
> On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote:
> > Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng:
> > > On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote:
> > > > Hi,
> > > >
> > > > I did a checkout of the l
Marc MERLIN merlins.org> writes:
>
> On Thu, Aug 21, 2014 at 05:52:01AM +, Mihail Zaporozhets wrote:
> > # btrfs-zero-log /dev/sda1
> > warning devid 5 not found already
> > Check tree block failed, want=16845270495232, have=0
> > read block failed check_tree_block
>
Hi Eric,
Am Donnerstag, 21. August 2014, 13:56:49 schrieb Eric Sandeen:
> On 8/21/14, 1:42 PM, Eric Sandeen wrote:
> > On 8/20/14, 10:35 PM, Gui Hecheng wrote:
> >> A memory problem reported by valgrind as follows:
> >>=== Syscall param pwrite64(buf) points to uninitialised byte(s)
> >>
> >>
Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
excerpted:
> I would stay with rsync for a while, because there is always the
> possibility of a bug that corrupts both your primary filesystem and your
> backup one, or send propagating corruption from one filesystem to
> another
43 matches
Mail list logo
