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: Tue, 09 May 2017 16:10:16 +0000	[thread overview]
Message-ID: <bug-195561-13602-vwK2e3spMx@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 #29 from Theodore Tso (tytso@mit.edu) ---
If your firewall is not letting you access git.kernel.org, please complain to
your management.

There is a mirror of the xfstests-bld git tree on github:
https://github.com/tytso/xfstests-bld

However, to access the prebuilt test appliace files, or some of the other git
repositories needed by xfstests-bld if you want to do a build from scratch of
the test appliance, you will need access to either www.kernel.org or
git.kernel.org, so you might as well deal with your firewall configuration
issues sooner rather than later.

I basically don't trust make_ext4fs at all.   There is a reason I have been
pushing the android team to use e2fsprogs.  We do have an updated e2fsprogs in
AOSP, and some of the tools so that make_ext4fs can be replaced by mke2fs plus
some helper programs are mostly in AOSP.  They are not used by default, but
rather the Android team has been cutting devices over one at a time for Android
O, instead of whole sale.  My personal suspicion is that they very paranoid
because they are used to make_ext4fs breaking at random, so they have been
doing a slow migration over because they fear similar breakages as they migrate
away from make_ext4fs, particular as it relates to building a new system.img
file and doing a factory reset from the device.   However, if all you need to
do is format an ext4 file system on an SD card, and not try to set up a system
image or something else complicated where you have to set up SELinux labels,
etc., using mke2fs should be just fine.   It's what the rest of the Linux
ecosystem use, and what we upstream developers use for all of our regression
testing and daily personal use.   

To be clear, we do ****not**** make_ext4fs; that's an Android "special" that
was originally developed when certain management/legal types had a pathological
fear of the GPLv2, and then it grew all out of control and manageability.  
Since it was done as a clean room reimplementation, by someone who was not an
ext4 expert, and then had extra ext4 features as well as SELinux spliced into
it over time, it has caused me no end of headaches over the years....   :-(

If so Linaro folks could help accelerate the move away from make_ext4fs, I
would be most grateful.

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

  parent reply	other threads:[~2017-05-09 16:10 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
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 [this message]
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-vwK2e3spMx@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).