Debian Bug report logs - #776248
fuseext2: CPU at 100% when mounting ext4 fs with block size > 4K

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jaroslav Mikulík <byczech@malyjarda.cz>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: fuseext2: CPU at 100% when mounting ext4 fs with block size > 4K

Date: Sun, 25 Jan 2015 23:13:22 +0100

Package: fuseext2
Version: 0.4-1.1
Severity: normal

Dear Maintainer,


   * What led up to the situation?

When using fuseext2 for mounting filesystem with block size > 4K, 1 CPU core is
at 100% and directory with mount point is busy (when file image is mounted,
then directory with this file is busy too).

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

i.e.:

$ dd if=/dev/zero of=ext4-bs64k.img bs=1M seek=1M count=0

$ sudo /sbin/mkfs.ext4 -L TestExtFS -b 65536 ext4-bs64k.img

$ fuseext2 ext4-bs64k.img /mount/somewhere/you/want

   * What was the outcome of this action?

Filesystem is mounted without errors, but when any operation (i.e. ls -l) on
mount point cause 100% of 1 CPU core and there is no expected output from
operation.

   * What outcome did you expect instead?

Working with mounted filesystem as usually (ls, cp, mv, mkdir, rm, rmdir, etc.)


Sincerely

Jarda



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fuseext2 depends on:
ii  e2fslibs  1.42.12-1
ii  fuse      2.9.3-15+b1
ii  libc6     2.19-13
ii  libfuse2  2.9.3-15+b1

fuseext2 recommends no packages.

fuseext2 suggests no packages.

-- no debconf information

Message #12 received at 776248@bugs.debian.org (full text, mbox, reply):

From: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>

To: Jaroslav Mikulík <byczech@malyjarda.cz>

Cc: 776248@bugs.debian.org

Subject: Re: fuseext2: CPU at 100% when mounting ext4 fs with block size > 4K

Date: Wed, 25 Nov 2015 17:38:32 +0100

[Message part 1 (text/plain, inline)]

severity 776248 important
thanks

Jaroslav Mikulík wrote...

> Filesystem is mounted without errors, but when any operation (i.e. ls -l) on
> mount point cause 100% of 1 CPU core and there is no expected output from
> operation.

At first, here are two simpler reproducers:

    fallocate --length 1M /tmp/ext4-reprod.img
    mkfs.ext4 -g 256 /tmp/ext4-reprod.img 
    fuseext2 /tmp/ext4-reprod.img /tmp/mountpoint

Or even simpler: Any image as long as it's bigger than 32 Mibyte (take
or give a few):

    fallocate --length 32M /tmp/ext4-reprod.img
    mkfs.ext4 /tmp/ext4-reprod.img 

Running "ls" still works, but midnight commander on the mountpoint
results in the behaviour described before (tested on amd64).

This is not a result of the block size per se but roughly on the "Block
count" to "Blocks per group" ratio (use tune2fs -l to see the actual
values). If it exceeds the value of 2, you're in trouble. In your
example, it is 256.

The bug is in test_root in op_statfs.c as called by ext2_group_spare.
It's called several times with 3, 5, 7 as b, and a for all numbers
from two up to the value mentioned above (s_groups_count, computed in
line 85). Or not at all if that value is just zero or one.

However, test_root is never left if called with (2, 3), or any other
(a, b) where a < b. Integer wraparound might end the loop but that's
undefined behaviour, and gcc optimizes it into an endless loop
instead, on amd64:

  4053a5:       83 ff 02                cmp    $0x2,%edi
  4053a8:       75 06                   jne    4053b0 <ext2_group_spare+0x10>
  4053aa:       eb fe                   jmp    4053aa <ext2_group_spare+0xa>

Note the compiler inlined test_root into ext2_group_spare, thus had
additional information for optimization at hand. You can unbreak the
code by adding a debug print statement into test_root, but this just
hides the underlying problem.

No idea how to fix this since I have no clue what the code is supposed
to do.

Severity raised so a fix might be delivered through a stable point
release. In my personal opinion it should be even higher since today's
ext filesystems are usually ext4 and larger that 32 Mibytes. For all
these, the package is completely unusable.


Aside, the ext2_bg_num_gdb invocation (and other) casts "unsigned long
long" into "int". This gives my quite a bad feeling.

    Christoph

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.