linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@kernel.org
Subject: [Bug 195561] Suspicious persistent EXT4-fs error: ext4_validate_block_bitmap:395: [Proc] bg 17: block 557056: invalid block bitmap
Date: Sun, 30 Apr 2017 02:59:10 +0000	[thread overview]
Message-ID: <bug-195561-13602-E2sxYqMRyd@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-195561-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=195561

--- Comment #23 from Theodore Tso (tytso@mit.edu) ---
What version of AOSP are you using, and how recently have you refreshed with
latest AOSP master (if you are using AOSP master)?

The reason why I ask is because there have been a number of changes that have
recently landed in AOSP over the last couple of months changing how ext4 file
systems are created.   They used to use make_ext4fs, and they are now using
mke2fs plus a collection of Android-specific utilities in
e2fsprogs/contrib/android.    (Note there are a lot of patches in AOSP's
e2fsprogs that haven't been integrated into mainline e2fsprogs yet.)

No one else is complaining about problems in the Linux kernel, and given that
you are seeing this problem across a huge spread of kernels, I'm wondering if
the problem is in the verison of AOSP you are using and whether it is creating
file systems which are sane.   I know that version being used internally at
Google is working, but it's possible (a) that what has been pushed out to AOSP
doesn't have all of the bug fixes that they are using, or (b) you haven't doing
a repo sync, and the bug has since been fixed in AOSP master, or (c) they have
been doing mostly ARM-based testing and the problem hasn't been noticed in
android-x86 yet.   (I have no idea which branches various Android development
efforts are using; it's not my main area of focus and I've been way to busy
recently to pay enough attention here.   So there is a bit of guessing here.)

Something you might want to try is try installing the file system where you've
been having trouble --- and then checking it with e2fsck before the kernel has
a chance to mount it read/write.   If e2fsck is reporting problems before the
kernel has mounted it, or mounted it read/write, then it's almost certainly a
userspace bug in AOSP somewhere.

One other thought.   I'm pretty sure there are some device kernels using 4.4
under development, but I'm *certain* there are device kernels using 3.18
(including, as it happens, my Pixel XL running Android 7.1.2).   So if you
haven't tried 3.18, give it a quick spin.   If you are seeing the problem on
3.18, then it's almost certainly not a kernel bug, but Something Else.  The
thing I come back to is that I'm not seeing any other complaints similar to
yours from Desktop distributions using Linux, or from people with shipped
devices, or people internally at Google doing development on Android O.  
(Which is out as a developer preview.  :-)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2017-04-30  2:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  2:40 [Bug 195561] New: Suspicious persistent EXT4-fs error (device sda1): ext4_validate_block_bitmap:395: [Proc] bg 17: block 557056: invalid block bitmap bugzilla-daemon
2017-04-24  2:41 ` [Bug 195561] " bugzilla-daemon
2017-04-24  2:42 ` bugzilla-daemon
2017-04-24  2:44 ` bugzilla-daemon
2017-04-24  2:52 ` bugzilla-daemon
2017-04-24  3:00 ` bugzilla-daemon
2017-04-24  3:01 ` [Bug 195561] Suspicious persistent EXT4-fs error: " bugzilla-daemon
2017-04-24  4:51 ` bugzilla-daemon
2017-04-24 16:50 ` bugzilla-daemon
2017-04-24 16:53 ` bugzilla-daemon
2017-04-25 15:22 ` bugzilla-daemon
2017-04-25 15:23 ` bugzilla-daemon
2017-04-25 15:24 ` bugzilla-daemon
2017-04-25 15:27 ` bugzilla-daemon
2017-04-25 15:29 ` bugzilla-daemon
2017-04-25 15:29 ` bugzilla-daemon
2017-04-25 15:31 ` bugzilla-daemon
2017-04-25 15:32 ` bugzilla-daemon
2017-04-25 23:13 ` bugzilla-daemon
2017-04-25 23:14 ` bugzilla-daemon
2017-04-25 23:16 ` bugzilla-daemon
2017-04-25 23:18 ` bugzilla-daemon
2017-04-25 23:19 ` bugzilla-daemon
2017-04-25 23:20 ` bugzilla-daemon
2017-04-26 15:11 ` bugzilla-daemon
2017-04-29 21:59 ` bugzilla-daemon
2017-04-30  2:59 ` bugzilla-daemon [this message]
2017-04-30  3:20 ` bugzilla-daemon
2017-05-03  8:17 ` bugzilla-daemon
2017-05-03 17:48 ` bugzilla-daemon
2017-05-09  3:20 ` bugzilla-daemon
2017-05-09  5:01 ` bugzilla-daemon
2017-05-09 16:10 ` bugzilla-daemon
2017-05-13 12:00 ` bugzilla-daemon
2017-05-14  4:14 ` bugzilla-daemon
2017-05-14 11:41 ` bugzilla-daemon
2017-05-14 14:56 ` bugzilla-daemon
2017-05-14 18:20 ` bugzilla-daemon

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=bug-195561-13602-E2sxYqMRyd@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).