linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nathaniel W Filardo <nwf@cs.jhu.edu>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, admins@acm.jhu.edu
Subject: Re: ext4 metadata corruption bug?
Date: Tue, 29 Apr 2014 11:22:13 -0400	[thread overview]
Message-ID: <20140429152213.GF5136@gradx.cs.jhu.edu> (raw)
In-Reply-To: <20140423143642.GA29925@thunk.org>

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Wed, Apr 23, 2014 at 10:36:42AM -0400, Theodore Ts'o wrote:
> OK, with the two of you reporting this problem, can you do me the
> following so we can try to seriously dig into this:
>[snip]

Just got another instance of corruption; this time on the allocation side:
[715863.874936] EXT4-fs error (device vdb): ext4_mb_generate_buddy:756: group 50737, 485 clusters in bitmap, 484 in gd; block bitmap corrupt.

This time from a different, though still > 8TB filesystem, whose dump
information sayeth:

Filesystem volume name:   <none>
Last mounted on:          /viceps
Filesystem UUID:          5bd1df60-53df-43f9-9785-5a35da485c81
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              335544320
Block count:              2684354560
Reserved block count:     134217728
Free blocks:              1767616367
Free inodes:              328163234
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      384
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
RAID stride:              1024
RAID stripe width:        1024
Flex block group size:    16
Filesystem created:       Fri Jan 24 18:01:34 2014
Last mount time:          Sun Apr 20 14:08:10 2014
Last write time:          Tue Apr 29 11:16:22 2014
Mount count:              5
Maximum mount count:      -1
Last checked:             Wed Apr  9 17:39:32 2014
Check interval:           0 (<none>)
Lifetime writes:          3574 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      d51561e1-73f7-40c6-bfac-61d8e46a4da4
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000ab65b
Journal start:            0

Cheers,
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2014-04-29 15:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140409223820.GU10985@gradx.cs.jhu.edu>
     [not found] ` <CAGagf4eEzY4+3cfNWSEENTo1PKe40nq1Ne6ZzOLGm-O78W7RcA@mail.gmail.com>
2014-04-10  5:04   ` ext4 metadata corruption bug? Nathaniel W Filardo
2014-04-10 14:03     ` Theodore Ts'o
2014-04-10 16:33       ` Nathaniel W Filardo
2014-04-10 22:17         ` Theodore Ts'o
2014-04-20 16:32           ` Nathaniel W Filardo
2014-04-20 17:57             ` Theodore Ts'o
2014-04-23  7:23             ` Sander Smeenk
2014-04-23 14:36               ` Theodore Ts'o
2014-04-23 15:30                 ` Nathaniel W Filardo
2014-04-23 18:05                 ` Sander Smeenk
2014-04-29 15:22                 ` Nathaniel W Filardo [this message]
2014-05-01 16:25                 ` Nathaniel W Filardo
2014-05-06 15:42                   ` Theodore Ts'o
2014-05-06 15:51                     ` Nathaniel W Filardo
2014-07-31  2:37                       ` Theodore Ts'o
2014-08-06  8:53                         ` Sander Smeenk
2014-05-01 17:02                 ` Sander Smeenk
2014-05-06 14:22                   ` Sander Smeenk
2014-05-26 14:59                     ` Sander Smeenk

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=20140429152213.GF5136@gradx.cs.jhu.edu \
    --to=nwf@cs.jhu.edu \
    --cc=admins@acm.jhu.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).