From: "Theodore Ts'o" <tytso@mit.edu>
To: Geoffrey Thomas <Geoffrey.Thomas@twosigma.com>
Cc: "'Jan Kara'" <jack@suse.cz>,
Thomas Walker <Thomas.Walker@twosigma.com>,
"'linux-ext4@vger.kernel.org'" <linux-ext4@vger.kernel.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: Phantom full ext4 root filesystems on 4.1 through 4.14 kernels
Date: Thu, 11 Jul 2019 13:10:46 -0400 [thread overview]
Message-ID: <20190711171046.GA13966@mit.edu> (raw)
In-Reply-To: <96c4e04f8d5146c49ee9f4478c161dcb@EXMBDFT10.ad.twosigma.com>
Can you try using "df -i" when the file system looks full, and then
reboot, and look at the results of "df -i" afterwards?
Also interesting would be to grab a metadata-only snapshot of the file
system when it is in its mysteriously full state, writing that
snapshot on some other file system *other* than on /dev/sda3:
e2image -r /dev/sda3 /mnt/sda3.e2i
Then run e2fsck on it:
e2fsck -fy /mnt/sda3.e2i
What I'm curious about is how many "orphaned inodes" are reported, and
how much space they are taking up. That will look like this:
% gunzip < /usr/src/e2fsprogs/tests/f_orphan/image.gz > /tmp/foo.img
% e2fsck -fy /tmp/foo.img
e2fsck 1.45.2 (27-May-2019)
Clearing orphaned inode 15 (uid=0, gid=0, mode=040755, size=1024)
Clearing orphaned inode 17 (uid=0, gid=0, mode=0100644, size=0)
Clearing orphaned inode 16 (uid=0, gid=0, mode=040755, size=1024)
Clearing orphaned inode 14 (uid=0, gid=0, mode=0100644, size=69)
Clearing orphaned inode 13 (uid=0, gid=0, mode=040755, size=1024)
...
It's been theorized the bug is in overlayfs, where it's holding inodes
open so the space isn't released. IIRC somewhat had reported a
similar problem with overlayfs on top of xfs. (BTW, are you using
overlayfs or aufs with your Docker setup?)
- Ted
next prev parent reply other threads:[~2019-07-11 17:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 17:59 Phantom full ext4 root filesystems on 4.1 through 4.14 kernels Elana Hashman
2018-11-08 18:13 ` Reindl Harald
2018-11-08 18:20 ` Elana Hashman
2018-11-08 18:47 ` Darrick J. Wong
2018-12-05 16:26 ` Elana Hashman
2019-01-23 19:59 ` Thomas Walker
2019-06-26 15:17 ` Thomas Walker
2019-07-11 9:23 ` Jan Kara
2019-07-11 14:40 ` Geoffrey Thomas
2019-07-11 15:23 ` Jan Kara
2019-07-11 17:10 ` Theodore Ts'o [this message]
2019-07-12 19:19 ` Thomas Walker
2019-07-12 20:28 ` Theodore Ts'o
2019-07-12 21:47 ` Geoffrey Thomas
2019-07-25 21:22 ` Geoffrey Thomas
2019-07-29 10:09 ` Jan Kara
2019-07-29 11:18 ` ext4 file system is constantly writing to the block device with no activity from the applications, is it a bug? Dmitrij Gusev
2019-07-29 12:55 ` Theodore Y. Ts'o
2019-07-29 21:12 ` Dmitrij Gusev
2019-01-24 1:54 ` Phantom full ext4 root filesystems on 4.1 through 4.14 kernels Liu Bo
2019-01-24 14:40 ` Elana Hashman
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=20190711171046.GA13966@mit.edu \
--to=tytso@mit.edu \
--cc=Geoffrey.Thomas@twosigma.com \
--cc=Thomas.Walker@twosigma.com \
--cc=darrick.wong@oracle.com \
--cc=jack@suse.cz \
--cc=linux-ext4@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.