All of lore.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:10 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 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.