On Thu, Oct 11, 2018 at 11:20:43AM +0500, Mikhail Gavrilov wrote: > On Thu, 11 Oct 2018 at 11:00, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Thu, Oct 11, 2018 at 10:47:31AM +0500, Mikhail Gavrilov wrote: > > > When I researched the most fragmented files, I found that xfs_bmap > > > stuck at the file /home/mikhail/.steam/steam.pipe. > > > > Stuck, or just taking a long time? > > I was waiting for seven hours when process ended. I think it's enough > for think than this process stuck. *nod* > $ ps aux | grep xfs_bmap > mikhail 16226 0.0 0.0 213216 840 pts/21 S+ 11:07 0:00 grep > --color=auto xfs_bmap > mikhail 21021 0.0 0.0 213804 1224 pts/12 S+ 04:32 0:00 > /usr/bin/sh -f /usr/sbin/xfs_bmap /home/mikhail/.steam/steam.pipe > mikhail 21024 0.0 0.0 217424 8 pts/12 S+ 04:32 0:00 > /usr/sbin/xfs_io -r -p xfs_bmap -c bmap > /home/mikhail/.steam/steam.pipe > [mikhail@localhost ~]$ date > Thu Oct 11 11:07:55 +05 2018 > > > > > It's in the kernel open() syscall opening the file. userspace > > tracing won't tell you what is going on at this point. Is there > > anything in dmesg? > > Nothing since the time when process xfs_io was started. > > $ dmesg -e > ... > [Oct10 23:37] perf: interrupt took too long (2512 > 2500), lowering > kernel.perf_event_max_sample_rate to 79000 > [Oct11 09:53] tun: Universal TUN/TAP device driver, 1.6 > [Oct11 10:21] usb 3-2.4: USB disconnect, device number 6 > [ +0.953248] usb 3-2.4: new high-speed USB device number 10 using xhci_hcd > [ +0.090606] usb 3-2.4: New USB device found, idVendor=2109, > idProduct=2813, bcdDevice=90.11 > [ +0.000003] usb 3-2.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ +0.000002] usb 3-2.4: Product: USB2.0 Hub > [ +0.000002] usb 3-2.4: Manufacturer: VIA Labs, Inc. > [ +0.043404] hub 3-2.4:1.0: USB hub found > [ +0.000869] hub 3-2.4:1.0: 4 ports detected > > > > what is the output of `cat /proc/<pid>/stack` for the xfs_io process > > that is running the bmap command? > > # cat /proc/21024/stack > [<0>] pipe_wait+0x6c/0xb0 > [<0>] wait_for_partner+0x19/0x50 > [<0>] fifo_open+0x266/0x2c0 > [<0>] do_dentry_open+0x132/0x340 > [<0>] path_openat+0x334/0x1610 > [<0>] do_filp_open+0x93/0x100 > [<0>] do_sys_open+0x186/0x210 > [<0>] do_syscall_64+0x5b/0x160 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [<0>] 0xffffffffffffffff Hmmm. That's waiting for pipe to connect, not waiting for an XFS file to open. *ding* You ran xfs_bmap on a *named pipe*, not a regular file. Yeah, xfs_bmap is waiting for the other end of the pipe to be connected to something, which never happens. Only regular files and directories have extents, so running xfs_bmap on a pipe is not a useful thing to do. Ok, so there's an element of user error here, but xfs_io doesn't check that it's getting anything other than regular files, directories or block devices so I'm guessing we'll have to add a check to error this case out before opening the pipe. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
