From: Brian Rogers <brian@xyzw.org>
To: linux-ext4@vger.kernel.org
Subject: e4defrag and chattr +e warnings
Date: Mon, 24 Aug 2009 15:39:24 -0700 [thread overview]
Message-ID: <4A93169C.7070106@xyzw.org> (raw)
Hi all.
The first time since boot that I run e4defrag on a directory of
significant size, I get this warning in dmesg:
[ 199.076871]
[ 199.076876] =============================================
[ 199.076884] [ INFO: possible recursive locking detected ]
[ 199.076891] 2.6.31-rc7-red-debug #4
[ 199.076896] ---------------------------------------------
[ 199.076902] e4defrag/4399 is trying to acquire lock:
[ 199.076908] (&ei->i_data_sem){++++..}, at: [<ffffffffa0043839>]
ext4_move_extents+0x10e/0xa19 [ext4]
[ 199.076957]
[ 199.076958] but task is already holding lock:
[ 199.076964] (&ei->i_data_sem){++++..}, at: [<ffffffffa0043830>]
ext4_move_extents+0x105/0xa19 [ext4]
[ 199.077006]
[ 199.077007] other info that might help us debug this:
[ 199.077015] 3 locks held by e4defrag/4399:
[ 199.077019] #0: (&sb->s_type->i_mutex_key#7/1){+.+.+.}, at:
[<ffffffffa00437f3>] ext4_move_extents+0xc8/0xa19 [ext4]
[ 199.077069] #1: (&sb->s_type->i_mutex_key#7/2){+.+...}, at:
[<ffffffffa0043800>] ext4_move_extents+0xd5/0xa19 [ext4]
[ 199.077117] #2: (&ei->i_data_sem){++++..}, at: [<ffffffffa0043830>]
ext4_move_extents+0x105/0xa19 [ext4]
[ 199.077161]
[ 199.077162] stack backtrace:
[ 199.077170] Pid: 4399, comm: e4defrag Not tainted 2.6.31-rc7-red-debug #4
[ 199.077176] Call Trace:
[ 199.077188] [<ffffffff8105bcc4>] __lock_acquire+0x1467/0x14f5
[ 199.077200] [<ffffffff81059990>] ? mark_held_locks+0x52/0x70
[ 199.077212] [<ffffffff812a699a>] ? _spin_unlock_irq+0x2b/0x57
[ 199.077223] [<ffffffff8105bda7>] lock_acquire+0x55/0x71
[ 199.077261] [<ffffffffa0043839>] ? ext4_move_extents+0x10e/0xa19 [ext4]
[ 199.077275] [<ffffffff812a5b10>] down_read+0x40/0x4f
[ 199.077313] [<ffffffffa0043839>] ? ext4_move_extents+0x10e/0xa19 [ext4]
[ 199.077341] [<ffffffffa0043839>] ext4_move_extents+0x10e/0xa19 [ext4]
[ 199.077341] [<ffffffff8105af3b>] ? __lock_acquire+0x6de/0x14f5
[ 199.077341] [<ffffffffa002b44d>] ext4_ioctl+0x595/0x756 [ext4]
[ 199.077341] [<ffffffff810b1a91>] vfs_ioctl+0x1d/0x82
[ 199.077341] [<ffffffff812a6a00>] ? _spin_unlock_irqrestore+0x3a/0x67
[ 199.077341] [<ffffffff810b1ff0>] do_vfs_ioctl+0x483/0x4c9
[ 199.077341] [<ffffffff81059c30>] ? trace_hardirqs_on+0xd/0xf
[ 199.077341] [<ffffffff8113fa6f>] ? __up_write+0x115/0x124
[ 199.077341] [<ffffffff8100ba9c>] ? sysret_check+0x27/0x62
[ 199.077341] [<ffffffff810b2087>] sys_ioctl+0x51/0x74
[ 199.077341] [<ffffffff8113f97a>] ? __up_write+0x20/0x124
[ 199.077341] [<ffffffff8113f97a>] ? __up_write+0x20/0x124
[ 199.077341] [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
This might be happening when it hits files that don't use extents, but I
haven't tried e4defrag on a single non-extents file to verify that
theory. I've just so far only seen this happen when I defrag a directory
where I get the "operation not supported" message.
If I use chattr +e to migrate a file to use extents, I get this:
[ 470.400044] ------------[ cut here ]------------
[ 470.400065] WARNING: at fs/inode.c:1210 generic_delete_inode+0x65/0x16a()
[ 470.400072] Hardware name: N/A
[ 470.400078] Modules linked in: hidp hid ecryptfs cpufreq_ondemand
binfmt_misc af_packet ipt_MASQUERADE iptable_nat nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_tcpudp iptable_filter ip_tables x_tables rfcomm bridge stp llc bnep
sco l2cap kvm_intel kvm ipv6 container sbs sbshc microcode acpi_cpufreq
freq_table uinput sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek
snd_hda_intel arc4 snd_hda_codec ecb snd_hwdep iwl3945 snd_pcm iwlcore
snd_seq_midi snd_rawmidi snd_seq_midi_event mac80211 snd_seq led_class
btusb joydev snd_timer sr_mod bluetooth snd_seq_device cdrom cfg80211
snd ata_generic tg3 soundcore pata_acpi ohci1394 uhci_hcd ehci_hcd
psmouse libphy snd_page_alloc ata_piix processor rfkill ieee1394 button
usbcore battery evdev serio_raw wmi ac sg sd_mod thermal fan fuse
dm_mirror dm_region_hash dm_log dm_mod ahci libata scsi_mod ext4 mbcache
jbd2 crc16
[ 470.400353] Pid: 4451, comm: chattr Not tainted 2.6.31-rc7-red-debug #4
[ 470.400359] Call Trace:
[ 470.400372] [<ffffffff81037771>] warn_slowpath_common+0x77/0x8f
[ 470.400385] [<ffffffff81037798>] warn_slowpath_null+0xf/0x11
[ 470.400395] [<ffffffff810b7f28>] generic_delete_inode+0x65/0x16a
[ 470.400405] [<ffffffff810b8044>] generic_drop_inode+0x17/0x1bd
[ 470.400413] [<ffffffff810b7083>] iput+0x61/0x65
[ 470.400455] [<ffffffffa003b229>] ext4_ext_migrate+0x5eb/0x66a [ext4]
[ 470.400492] [<ffffffffa002b1f8>] ext4_ioctl+0x340/0x756 [ext4]
[ 470.400507] [<ffffffff810b1a91>] vfs_ioctl+0x1d/0x82
[ 470.400517] [<ffffffff810b1ff0>] do_vfs_ioctl+0x483/0x4c9
[ 470.400527] [<ffffffff81059c30>] ? trace_hardirqs_on+0xd/0xf
[ 470.400537] [<ffffffff810b2087>] sys_ioctl+0x51/0x74
[ 470.400549] [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[ 470.400557] ---[ end trace ab85723542352dac ]---
Aside from these messages, the system continues normally and I haven't
seen any data loss. After the chattr +e, I am able to defrag with
e4defrag just fine. This is with the latest kernel code today and with
the current ext4 next tree merged in. Same result also in both ordered
and writeback modes. I hope this info helps.
Brian
next reply other threads:[~2009-08-24 22:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 22:39 Brian Rogers [this message]
2009-08-25 9:48 ` e4defrag and chattr +e warnings Aneesh Kumar K.V
2009-08-26 6:06 ` Brian Rogers
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=4A93169C.7070106@xyzw.org \
--to=brian@xyzw.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;
as well as URLs for NNTP newsgroup(s).