From: Nikhilesh Reddy <reddyn@codeaurora.org>
To: Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Emergency remount readonly and EFBIG errors when unlinking files on 3.18 android kernel
Date: Tue, 26 Apr 2016 15:08:27 -0700 [thread overview]
Message-ID: <571FE6DB.8030604@codeaurora.org> (raw)
Hi
As you know Android uses emergency remount instead of doing something
like "umount -a" in its shutdown/reboot path.
https://android.googlesource.com/platform/system/core/+/master/libcutils/android_reboot.c#132
I have seen a strange issue that sometimes occurs when there are a large
number of writes to an ext4 file system and an adb reboot is issued (
triggering an emergency remount readonly and a reboot)
Teh issue doesnt happen all the writer processes are killed before the
emergency remount
And on disk we see that one of the files being written to has incorrect
ext4_inode->i_blocks_lo ( which is less than the the size of the file by
something like 2k)
When unlinking this file the vfs inode->iblocks underflows and we end up
with EFBIG if EXT4_FEATURE_RO_COMPAT_HUGE_FILE is not enabled in the
superblock.
Is this a known issue?
I am still trying to figure out why we have a incorrect i_blocks_lo on
the disk.
Running fsck on the partition does fix the issue but i am trying to
figure out why this would happen and how to fix it.
I would appreciate if you could point me in the right direction and any
help you can give me.
--
Thanks
Nikhilesh Reddy
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
next reply other threads:[~2016-04-26 22:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 22:08 Nikhilesh Reddy [this message]
2016-04-27 3:07 ` Emergency remount readonly and EFBIG errors when unlinking files on 3.18 android kernel Theodore Ts'o
2016-04-27 3:25 ` Dave Chinner
2016-04-27 17:56 ` Nikhilesh Reddy
-- strict thread matches above, loose matches on Subject: below --
2016-05-02 0:59 Daeho Jeong
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=571FE6DB.8030604@codeaurora.org \
--to=reddyn@codeaurora.org \
--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 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.