All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann Dupont <Yann.Dupont@univ-nantes.fr>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: Problems with kernel 3.6.x (vm ?) (was : Is kernel 3.6.1 or filestreams option toxic ?)
Date: Mon, 29 Oct 2012 09:07:28 +0100	[thread overview]
Message-ID: <508E3940.4080200@univ-nantes.fr> (raw)
In-Reply-To: <20121028234802.GE4353@dastard>

Le 29/10/2012 00:48, Dave Chinner a écrit :
>
> This is reproductible. Here is how to do it :
>
> - Started a 3.6.2 kernel.
>
> - I created a fresh lvm volume on localdisk of 20 GB.
> Can you reproduce the problem without LVM?

Hello dave. That is THE question. My intent was to test with and without 
LVM. But right now I can't , because all my disks are consumed by lvm.
In fact my test setup hasn't even enough space to locally clone the 
volume where I have errors. I only have 146 sas disks on this machine.

I have to setup another test platform, and as I'm currently traveling, 
it won't be easy before  next week.

What I want to try this week is to recrash a volume, possibly smaller,
download this image on another machine with kvm
see if I have the mounting problems inside this kvm
begin to bisect the kernel .

...
>
> - After some try, I finally had the impossibility to mount the xfs
> volume, with the error reported in previous mails. So far this is
> normal .
> So it doesn't happen every time, and it may be power cycle related.

Yes, during my tests, I had to to power cycle 3 or 4 times before having 
the actual problem

> What is your "local disk"?

Raid 1 array (2 disks) with mptsas on this.
>
>> xfs_logprint don't say much :
>>
>> xfs_logprint:
>>      data device: 0xfe02
>>      log device: 0xfe02 daddr: 10485792 length: 20480
>>
>> Header 0x7c wanted 0xfeedbabe
>> **********************************************************************
>> * ERROR: header cycle=124         block=5414 *
>> **********************************************************************
> You didn't look past the initial error, did you? The file is only
> 482280 lines long, and 482200 lines of that are decoded log data....
> :)
Well I'd tried with -c  but sorry, i didn't had experience with 
xfs_logprint so far.
>
>> I tried xfs_logprint -c , it gaves a 22M file. You can grab it here :
>> http://filex.univ-nantes.fr/get?k=QnBXivz2J3LmzJ18uBV
> I really need the raw log data, not the parsed output. The logprint
> command to do that is "-C <file>", not "-c".

Ok ... I should have read the man page more carefully. Time to restart a 
crash session

>> - Rebooted 3.4.15
>> - xfs_logprint gives the exact same result that with 3.6.2 (diff
>> tells no differences)
> Given that it's generated by the logprint application, I'd expect it
> to be identical.
Me too, but I'd also expect the log replaying to be identical between 
the 2 kernels

>
>> but on 3.4.15, I can mount the volume without problem, log is
>> replayed.
>> for information here is xfs_info of the volume :
>>
>> here is xfs_info output
>>
>> root@label5:/mnt/debug# xfs_info /mnt/tempo
>> meta-data=/dev/mapper/LocalDisk-crashdisk isize=256    agcount=8,
>> agsize=655360 blks
> How did you get a default of 8 AGs? That seems wrong.  What version
> of mkfs.xfs are you using?
root@label5:~# mkfs.xfs -V
mkfs.xfs version 3.1.7

the volume was freshly formatted, with defaults options. Absolutely 
nothing special on my side.
Cheers,

-- 
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2012-10-29  8:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 14:14 Is kernel 3.6.1 or filestreams option toxic ? Yann Dupont
2012-10-23  8:24 ` Problems with kernel 3.6.x (vm ?) (was : Is kernel 3.6.1 or filestreams option toxic ?) Yann Dupont
2012-10-23  8:24   ` Yann Dupont
2012-10-25 15:21   ` Yann Dupont
2012-10-25 20:55     ` Yann Dupont
2012-10-25 21:10     ` Dave Chinner
2012-10-26 10:03       ` Yann Dupont
2012-10-26 22:05         ` Yann Dupont
2012-10-28 23:48           ` Dave Chinner
2012-10-29  1:25             ` Dave Chinner
2012-10-29  8:11               ` Yann Dupont
2012-10-29 12:21                 ` Dave Chinner
2012-10-29 12:18               ` Dave Chinner
2012-10-29 12:43                 ` Yann Dupont
2012-10-30  1:33                   ` Dave Chinner
2012-10-31 11:45                     ` Gaudenz Steinlin
2012-11-05 13:57                     ` Yann Dupont
2012-10-29  8:07             ` Yann Dupont [this message]
2012-10-29  8:17               ` Yann Dupont
  -- strict thread matches above, loose matches on Subject: below --
2012-11-28  9:39 reste donewell
2012-11-28 20:37 ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=508E3940.4080200@univ-nantes.fr \
    --to=yann.dupont@univ-nantes.fr \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.