Messages in this thread |  | | Date | Mon, 3 Dec 2012 21:35:00 +0200 (EET) | From | Dimitrios Apostolou <> | Subject | Re: backing up ext4 fs, system unresponsive, thrashing like crazy even though swap is unused |
| |
On Mon, 3 Dec 2012, Eric Paris wrote:
> On Mon, Dec 3, 2012 at 12:43 PM, Theodore Ts'o <tytso@mit.edu> wrote: > >> If you are seeing a large number of inodes still in the ext4 inode >> cache after using drop_caches, then I'd look to see whether you have >> something like SELinux or auditing enabled which is pinning a bunch of >> dentries or inodes > > You can safely ignore this suggestion as it does make sense. SELinux > only grabs a references to dentries during its call to > fs_ops->getxattr, which can't last a meaningful length of time (unless > the filesystem is busted). It only grabs references to inodes during > system initialization, when you couldn't have many in core. > > Audit, likewise, only grabs a reference to a dentry during execve() > and only long enough to run getxattr and does not grab any reference > directly to an inode at all. >
AFAICT I use neither SELinux nor audit.
>> or whether your backup program (or some other >> program running on your system) is keeping lots of directories or >> inodes open for some reason. > > Certainly could be this suggestion though.. >
I've managed to reproduce the scenario with concurrent "du" commands running on the filesystems. I'll try doing it once more, but it may take a while to get the dmesg/slabinfo etc output, since even a realtime root shell is non-responsive for many minutes.
What other debug output do you suggest to get, to find out why ext4 inodes are pinned?
Thanks, Dimitris
|  |