public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Jesper Juhl <jj@chaosbits.net>,
	linux-kernel@vger.kernel.org, ap@solarrain.com,
	linux-ext4@vger.kernel.org
Subject: Re: Upgraded from 3.4 to 3.5.1 kernel: machine does not boot
Date: Sun, 12 Aug 2012 08:10:34 -0500	[thread overview]
Message-ID: <5027AB4A.6010200@sandeen.net> (raw)
In-Reply-To: <CAO9zADzxste_Zs0CGtNoTL0SARV41-q4X-8i8fXBPVNQ4ADDcA@mail.gmail.com>

On 8/10/12 11:14 PM, Justin Piszcz wrote:
> On Fri, Aug 10, 2012 at 7:07 PM, Justin Piszcz
>>
>> Hi,
>>
>> Found the root cause, the 3.5.1 kernel cannot mount my ext4 filesystem
>> (60TB).

You are a brave man running ext4 at 60T, but thank you for testing :)

Backing out 8aeb00ff85ad25453765dd339b408c0087db1527 from 3.5.1
(952fc18ef9ec707ebdc16c0786ec360295e5ff15 upstream) probably helps?

>From a quick look, I think that essentially has a :

for (i = 0; i < ngroups; i++) {

	for (j = 0; j < ngroups; j++) {

	}
}

type nested loop going on; for a filesystem this big it's going to take almost
literally forever, if I read it right.

-Eric

>> The 3.4 kernel works fine.
>>
>> This is proven by commenting out the filesystem in /etc/fstab with
>> 3.5.1, and all is OK.
>>
>> --
>>
>> Hi again,
>>
>> I tested with linux-3.6-rc1:
>>
>> The same problem, here is what I get from the strace:
>>
>> irectory)
>> 4434  readlink("/dev", 0x7fff3b05c670, 4096) = -1 EINVAL (Invalid argument)
>> 4434  readlink("/dev/sda1", 0x7fff3b05c670, 4096) = -1 EINVAL (Invalid
>> argument)
>> 4434  readlink("/r1", 0x7fff3b05c670, 4096) = -1 EINVAL (Invalid argument)
>> 4434  getuid()                          = 0
>> 4434  geteuid()                         = 0
>> 4434  getgid()                          = 0
>> 4434  getegid()                         = 0
>> 4434  prctl(PR_GET_DUMPABLE)            = 1
>> 4434  lstat("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=12, ...}) = 0
>> 4434  getuid()                          = 0
>> 4434  geteuid()                         = 0
>> 4434  getgid()                          = 0
>> 4434  getegid()                         = 0
>> 4434  prctl(PR_GET_DUMPABLE)            = 1
>> 4434  stat("/run", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
>> 4434  lstat("/run/mount/utab", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>> 4434  open("/run/mount/utab", O_RDWR|O_CREAT, 0644) = 3
>> 4434  close(3)                          = 0
>> 4434  mount("/dev/sda1", "/r1", "ext4", MS_MGC_VAL|MS_NOATIME, NULL
>>
>> --
>>
>> (w/ 3.6-rc1)
>>
>> [   89.868843] mount           R  running task        0  4434   4433
>> 0x00000009
>> [   89.868847]  ffff880c246b7b68 ffffffff816c9279 ffff880c246b7aa8
>> ffff880c246b7fd8
>> [   89.868851]  ffff880c246b7fd8 0000000000004000 ffff88062720cdb0
>> ffff880c246862d0
>> [   89.868855]  00000000000116c0 ffff880623a863c0 ffff880623a863c0
>> 00000000ffffffff
>> [   89.868855] Call Trace:
>> [   89.868858]  [<ffffffff816c9279>] ? __schedule+0x299/0x770
>> [   89.868860]  [<ffffffff816c9279>] ? __schedule+0x299/0x770
>> [   89.868864]  [<ffffffff8114a729>] ? ext4_get_group_desc+0x49/0xb0
>> [   89.868868]  [<ffffffff81161d41>] ? ext4_calculate_overhead+0x131/0x3e0
>> [   89.868871]  [<ffffffff81163a3b>] ? ext4_fill_super+0x1a4b/0x28d0
>> [   89.868875]  [<ffffffff810cc301>] ? mount_bdev+0x1a1/0x1e0
>> [   89.868877]  [<ffffffff81161ff0>] ? ext4_calculate_overhead+0x3e0/0x3e0
>> [   89.868880]  [<ffffffff8115dd00>] ? ext4_mount+0x10/0x20
>> [   89.868882]  [<ffffffff810cc55b>] ? mount_fs+0x1b/0xd0
>> [   89.868885]  [<ffffffff810e57af>] ? vfs_kern_mount+0x6f/0x110
>> [   89.868888]  [<ffffffff810e58cf>] ? do_kern_mount+0x4f/0x100
>> [   89.868890]  [<ffffffff810e6dae>] ? do_mount+0x2fe/0x8a0
>> [   89.868894]  [<ffffffff8109c0a3>] ? strndup_user+0x53/0x70
>> [   89.868896]  [<ffffffff810e73e0>] ? sys_mount+0x90/0xe0
>> [   89.868899]  [<ffffffff816cafa1>] ? tracesys+0xd4/0xd9
>>
>> Justin.
>>
>>
>>
> 
> CC: linux-ext4
> 
> Any ideas here (kernel 3.4 and below can mount 60TB ext4 no issues)
> but > 3.5.1 (did not try 3.5) cannot mount the filesystem.
> 
> Justin.
> 
> Justin.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2012-08-12 13:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10 16:45 Upgraded from 3.4 to 3.5.1 kernel: machine does not boot Justin Piszcz
2012-08-10 17:53 ` Jesper Juhl
2012-08-10 21:45   ` Justin Piszcz
2012-08-10 23:07     ` Justin Piszcz
2012-08-11  4:14       ` Justin Piszcz
2012-08-12 13:10         ` Eric Sandeen [this message]
2012-08-12 13:51           ` Justin Piszcz
2012-08-12 14:13             ` Paul Gortmaker
2012-08-12 14:36               ` Justin Piszcz

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=5027AB4A.6010200@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=ap@solarrain.com \
    --cc=jj@chaosbits.net \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox