Linux EXT4 FS development
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: ext4/307 failures?
Date: Thu, 29 Apr 2021 10:38:48 -0700	[thread overview]
Message-ID: <20210429173848.GB3122213@magnolia> (raw)

Hi everyone,

I've been running ext4 through fstets with the default configurations,
and I keep seeing failures in ext4/307:

mke2fs 1.46.3~WIP-2021-03-01 (1-Mar-2021)
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: 922458a1-3a3c-4479-b8bf-33331e9c8583
Superblock backups stored on blocks: 
        32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

fsstress  -p4 -n999 -f setattr=1 -ffsync=0 -fsync=0 -ffdatasync=0 -d /opt/fsstress.244005
# /tmp/fstests/src/e4compact -i -v -f /opt/donor
Init donor /opt/donor off:0 len:64000 bsz:4096
do_defrag_range /opt/fsstress.244005/p2/d2/d20/d81/f91 start:0 len:171 donor [0, 64000]
process /opt/fsstress.244005/p2/d2/d20/d81/f91  it:1 start:0 len:171 donor:0,moved:171 ret:0 errno:0
do_defrag_range /opt/fsstress.244005/p2/d2/d20/d81/fad start:0 len:1257 donor [171, 63829]
process /opt/fsstress.244005/p2/d2/d20/d81/fad  it:1 start:0 len:1257 donor:171,moved:0 ret:-1 errno:61
do_defrag_range EXT4_IOC_MOVE_EXT failed err:61

This continues for quite a while, and then:

do_defrag_range /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/d74/fb7 start:0 len:349 donor [59989, 4011]
process /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/d74/fb7  it:1 start:0 len:349 donor:59989,moved:349 ret:0 errno:0
do_defrag_range /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/d74/fbe start:0 len:648 donor [60338, 3662]
process /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/d74/fbe  it:1 start:0 len:648 donor:60338,moved:648 ret:0 errno:0
do_defrag_range /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/f68 start:0 len:583 donor [60986, 3014]
process /opt/fsstress.244005/p0/d1/d2b/d80/db2/d69/f68  it:1 start:0 len:583 donor:60986,moved:583 ret:0 errno:0
do_defrag_range /opt/fsstresse4compact: e4compact.c:68: do_defrag_range: Assertion `donor->length >= len' failed.
./common/rc: line 3775: 244234 Aborted                 (core dumped) "$@" >> $seqres.full 2>&1
failed: '/tmp/fstests/src/e4compact -i -v -f /opt/donor'
failed: '/tmp/fstests/src/e4compact -i -v -f /opt/donor'
(see /var/tmp/fstests/ext4/307.full for details)

It looks like we failed inside src/e4compact.c at:

Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f9fb92e6859 in __GI_abort () at abort.c:79
#2  0x00007f9fb92e6729 in __assert_fail_base (fmt=0x7f9fb947c588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55dc83526010 "donor->length >= len", 
    file=0x55dc83526004 "e4compact.c", line=68, function=<optimized out>) at assert.c:92
#3  0x00007f9fb92f7f36 in __GI___assert_fail (assertion=0x55dc83526010 "donor->length >= len", file=0x55dc83526004 "e4compact.c", line=68, 
    function=0x55dc835262b0 <__PRETTY_FUNCTION__.1> "do_defrag_range") at assert.c:101
#4  0x000055dc83525b20 in do_defrag_range (fd=<optimized out>, name=0x55dc853462b0 "/opt/fsstress.244005/p0/d1/d7d/fbf", start=<optimized out>, len=<optimized out>, donor=0x7ffd6a2a39c0)
    at e4compact.c:68
#5  0x000055dc83525638 in main (argc=<optimized out>, argv=<optimized out>) at e4compact.c:279

And digging around in gdb, it looks like we have a donor file that's
much shorter than the file being compacted?

(gdb) p donor
$1 = {
  fd = 4,
  offset = 63936,
  length = 64
}
(gdb) p eof_blk
$2 = 3742
(gdb) p st
$3 = {
  st_dev = 2052,
  st_ino = 32,
  st_nlink = 3,
  st_mode = 33206,
  st_uid = 43,
  st_gid = 202,
  __pad0 = 0,
  st_rdev = 0,
  st_size = 15326354,
  st_blksize = 4096,
  st_blocks = 6936,
  st_atim = {
    tv_sec = 1619651668,
    tv_nsec = 652000000
  },
  st_mtim = {
    tv_sec = 1619651668,
    tv_nsec = 80000000
  },
  st_ctim = {
    tv_sec = 1619651668,
    tv_nsec = 80000000
  },
  __glibc_reserved = {0, 0, 0}
}

Not sure what's going on here, but if someone has spare cycles, it might
be worth taking a look.

--D

                 reply	other threads:[~2021-04-29 17:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20210429173848.GB3122213@magnolia \
    --to=djwong@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox