From: Zhao Lei <zhaolei@cn.fujitsu.com>
To: "'Sasà Vita'" <totore9876@gmail.com>, linux-btrfs@vger.kernel.org
Subject: RE: stack trace (free_fs_root) with either fallocate + mv-across-subvolumes, or mount-wth-compress + dd
Date: Wed, 22 Jul 2015 17:28:13 +0800 [thread overview]
Message-ID: <047201d0c460$bc02f7c0$3408e740$@cn.fujitsu.com> (raw)
In-Reply-To: <CAL_C0_VTsfp7BbsRionsJ2SNJNqdNQ0Dyd4xrfsTm3wKzvnB_w@mail.gmail.com>
Hi, Sasà Vita
Thanks for reporting!
> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Sasà Vita
> Sent: Wednesday, July 22, 2015 1:52 PM
> To: linux-btrfs@vger.kernel.org
> Subject: stack trace (free_fs_root) with either fallocate +
> mv-across-subvolumes, or mount-wth-compress + dd
>
> The script below generates a stack trace, and some of the "mv dir/f dir/a"
> commands that it spawns fail with the message: "Device or resource busy".
>
> The stack trace is not generated on every iteration. The "for" loop ensures that
> it is generated at least once.
>
> Reproduced on Arch Linux, with various kernels from 3.11.2-1-ARCH up to
> 4.0.4-2-ARCH.
>
>
> mkdir dir
> truncate -s 3G loop
>
> fun1() {
> mount loop dir
> btrfs subvolume create dir/a
> fallocate -l 46M dir/f
> mv dir/f dir/a
> }
>
> for i in {1..30} ; do
> mkfs.btrfs loop
> fun1
> umount dir
> done
>
>
I tested this script in following platforms,
but can't reproduce this bug:
1: physical machine, RHEL7.1, linux 4.2-rc1
2: physical machine, RHEL7.1, linux 4.0
3: physical machine, RHEL7.1, linux 3.11
4: kvm, RHEL6, linux 4.2-rc2
on both physical and loop device,
and 3 times(90 loops) tests.
Who can test it in other platform?
Thanks
Zhaolei
> [ 112.060072] BTRFS: device fsid 88f9e1b0-d018-4f21-9598-22987aa2b893
> devid 1 transid 4 /dev/loop3
> [ 112.067593] BTRFS info (device loop3): disk space caching is enabled
> [ 112.067597] BTRFS: has skinny extents [ 112.067599] BTRFS: flagging fs
> with big metadata feature [ 112.068900] BTRFS: creating UUID tree
> [ 112.316740] ------------[ cut here ]------------ [ 112.316740] WARNING: CPU: 0
> PID: 1094 at fs/btrfs/disk-io.c:3549
> free_fs_root+0xe1/0xf0 [btrfs]()
> [ 112.316740] Modules linked in: crc32c_generic btrfs xor raid6_pq
> cfg80211 rfkill ppdev psmouse snd_intel8x0 iosf_mbi joydev mousedev pcspkr
> snd_ac97_codec ac97_bus snd_pcm serio_raw i2c_piix4 i2c_core snd_timer
> snd soundcore parport_pc parport battery ac evdev mac_hid acpi_cpufreq
> processor sch_fq_codel nfs lockd grace sunrpc fscache
> ext4 crc16 mbcache jbd2 dm_snapshot dm_bufio dm_mod squashfs loop isofs
> sr_mod cdrom hid_generic usbhid hid atkbd libps2 ahci libahci ohci_pci ohci_hcd
> ehci_pci ehci_hcd libata scsi_mod usbcore usb_common
> e1000 intel_agp intel_gtt i8042 serio video button [ 112.316740] CPU: 0 PID:
> 1094 Comm: umount Not tainted 4.0.4-2-ARCH #1 [ 112.316740] Hardware
> name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> [ 112.316740] 0000000000000000 000000001675626b ffff88004925bc88
> ffffffff81574b23
> [ 112.316740] 0000000000000000 0000000000000000 ffff88004925bcc8
> ffffffff81074dda [ 112.316740] ffff88004925bcd8 ffff880000082000
> ffff880053082000
> ffff880053082068
> [ 112.316740] Call Trace:
> [ 112.316740] [<ffffffff81574b23>] dump_stack+0x4c/0x6e [ 112.316740]
> [<ffffffff81074dda>] warn_slowpath_common+0x8a/0xc0 [ 112.316740]
> [<ffffffff81074f0a>] warn_slowpath_null+0x1a/0x20 [ 112.316740]
> [<ffffffffa04f2bc1>] free_fs_root+0xe1/0xf0 [btrfs] [ 112.316740]
> [<ffffffffa04f55bd>]
> btrfs_drop_and_free_fs_root+0x7d/0xc0 [btrfs] [ 112.316740]
> [<ffffffffa04f56df>] btrfs_free_fs_roots+0xdf/0x180 [btrfs] [ 112.316740]
> [<ffffffffa04f7471>] close_ctree+0x151/0x360 [btrfs] [ 112.316740]
> [<ffffffff811f535d>] ? evict_inodes+0x13d/0x160 [ 112.316740]
> [<ffffffffa04ca739>] btrfs_put_super+0x19/0x20 [btrfs] [ 112.316740]
> [<ffffffff811da836>] generic_shutdown_super+0x76/0x100 [ 112.316740]
> [<ffffffff811dab76>] kill_anon_super+0x16/0x30 [ 112.316740]
> [<ffffffffa04ca398>] btrfs_kill_super+0x18/0x120 [btrfs] [ 112.316740]
> [<ffffffff811daf69>] deactivate_locked_super+0x49/0x80 [ 112.316740]
> [<ffffffff811db3dc>] deactivate_super+0x6c/0x80 [ 112.316740]
> [<ffffffff811f8df3>] cleanup_mnt+0x43/0xa0 [ 112.316740]
> [<ffffffff811f8ea2>] __cleanup_mnt+0x12/0x20 [ 112.316740]
> [<ffffffff810917b4>] task_work_run+0xd4/0xf0 [ 112.316740]
> [<ffffffff81015d35>] do_notify_resume+0x75/0x80 [ 112.316740]
> [<ffffffff8157a6a3>] int_signal+0x12/0x17 [ 112.316740] ---[ end trace
> 1cd8909b794df110 ]--- [ 112.351293] VFS: Busy inodes after unmount of loop3.
> Self-destruct in 5 seconds. Have a nice day...
>
>
> I tested a variant of the script, where only the fallocate line is changed, and
> replaced with:
> dd if=/dev/zero of=dir/f bs=512 count=1
> I was unable to reproduce the problem, in this case.
>
>
> A related issue: in the following script, some of the 'mv dir/a/f dir' commands
> enter the state D and hang, even if no external storage is involved and the
> loop-mounted file is on a tmpfs.
>
> for i in {1..30} ; do
> mkfs.btrfs loop
> fun1
> umount dir
> mount loop dir
> mv dir/a/f dir # this may hang
> umount dir
> done
>
>
> Furthermore, the following script also generates the same stack trace, as
> above.
>
> mkdir dir
> truncate -s 3G loop
>
> fun2() {
> mount -ocompress=zlib loop dir # or compress=lzo
> dd if=/usr/bin/js of=dir/a bs=1024 count=2000 }
>
> for i in {1..30} ; do
> mkfs.btrfs loop
> fun2
> umount dir
> done
>
>
> Hope this helps.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2015-07-22 9:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 5:52 stack trace (free_fs_root) with either fallocate + mv-across-subvolumes, or mount-wth-compress + dd Sasà Vita
2015-07-22 9:28 ` Zhao Lei [this message]
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='047201d0c460$bc02f7c0$3408e740$@cn.fujitsu.com' \
--to=zhaolei@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=totore9876@gmail.com \
/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).