CPU stuck when getdents gets run on some directories #4583

Marlinc · 2016-05-02T12:15:34Z

May  2 09:40:52 marlinc-laptop kernel: [  564.151271] INFO: rcu_sched self-detected stall on CPU
May  2 09:40:52 marlinc-laptop kernel: [  564.151284]   6-...: (60003 ticks this GP) idle=edf/140000000000001/0 softirq=25054/25055 fqs=54725 
May  2 09:40:52 marlinc-laptop kernel: [  564.151286]    (t=60004 jiffies g=12919 c=12918 q=290208)
May  2 09:40:52 marlinc-laptop kernel: [  564.151289] Task dump for CPU 6:
May  2 09:40:52 marlinc-laptop kernel: [  564.151291] updatedb.mlocat R  running task        0 10110  10109 0x00000008
May  2 09:40:52 marlinc-laptop kernel: [  564.151294]  ffff88023ee6c4c0 00000000374cf737 ffff88042fb83da8 ffffffff810ae4c9
May  2 09:40:52 marlinc-laptop kernel: [  564.151297]  0000000000000006 ffffffff81e52500 ffff88042fb83dc0 ffffffff810b0cf7
May  2 09:40:52 marlinc-laptop kernel: [  564.151299]  0000000000000007 ffff88042fb83df0 ffffffff810e45ae ffff88042fb97a80
May  2 09:40:52 marlinc-laptop kernel: [  564.151302] Call Trace:
May  2 09:40:52 marlinc-laptop kernel: [  564.151303]  <IRQ>  [<ffffffff810ae4c9>] sched_show_task+0xa9/0x110
May  2 09:40:52 marlinc-laptop kernel: [  564.151315]  [<ffffffff810b0cf7>] dump_cpu_task+0x37/0x40
May  2 09:40:52 marlinc-laptop kernel: [  564.151319]  [<ffffffff810e45ae>] rcu_dump_cpu_stacks+0x8e/0xe0
May  2 09:40:52 marlinc-laptop kernel: [  564.151322]  [<ffffffff810e834a>] rcu_check_callbacks+0x4fa/0x7f0
May  2 09:40:52 marlinc-laptop kernel: [  564.151328]  [<ffffffff8113f3cc>] ? acct_account_cputime+0x1c/0x20
May  2 09:40:52 marlinc-laptop kernel: [  564.151330]  [<ffffffff810b17df>] ? account_system_time+0x7f/0x110
May  2 09:40:52 marlinc-laptop kernel: [  564.151334]  [<ffffffff810fe4f0>] ? tick_sched_handle.isra.14+0x60/0x60
May  2 09:40:52 marlinc-laptop kernel: [  564.151336]  [<ffffffff810ee8d9>] update_process_times+0x39/0x60
May  2 09:40:52 marlinc-laptop kernel: [  564.151338]  [<ffffffff810fe4b5>] tick_sched_handle.isra.14+0x25/0x60
May  2 09:40:52 marlinc-laptop kernel: [  564.151341]  [<ffffffff810fe52d>] tick_sched_timer+0x3d/0x70
May  2 09:40:52 marlinc-laptop kernel: [  564.151343]  [<ffffffff810ef212>] __hrtimer_run_queues+0x102/0x290
May  2 09:40:52 marlinc-laptop kernel: [  564.151345]  [<ffffffff810ef9d8>] hrtimer_interrupt+0xa8/0x1a0
May  2 09:40:52 marlinc-laptop kernel: [  564.151349]  [<ffffffff81052f88>] local_apic_timer_interrupt+0x38/0x60
May  2 09:40:52 marlinc-laptop kernel: [  564.151353]  [<ffffffff81826f9d>] smp_apic_timer_interrupt+0x3d/0x50
May  2 09:40:52 marlinc-laptop kernel: [  564.151357]  [<ffffffff81825262>] apic_timer_interrupt+0x82/0x90
May  2 09:40:52 marlinc-laptop kernel: [  564.151358]  <EOI>  [<ffffffffc03f0119>] ? zap_leaf_lookup_closest+0xb9/0x180 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151460]  [<ffffffffc03eecf2>] fzap_cursor_retrieve+0xc2/0x2c0 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151493]  [<ffffffffc03f24d9>] zap_cursor_retrieve+0x69/0x300 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151515]  [<ffffffffc038a2a4>] ? dmu_prefetch+0x134/0x250 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151547]  [<ffffffffc04126b6>] zfs_readdir+0x146/0x490 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151580]  [<ffffffffc0413423>] ? zfs_getattr_fast+0x133/0x1d0 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151612]  [<ffffffffc042d522>] zpl_iterate+0x52/0x80 [zfs]
May  2 09:40:52 marlinc-laptop kernel: [  564.151615]  [<ffffffff81220412>] iterate_dir+0x92/0x120
May  2 09:40:52 marlinc-laptop kernel: [  564.151617]  [<ffffffff812208b9>] SyS_getdents+0x99/0x110
May  2 09:40:52 marlinc-laptop kernel: [  564.151619]  [<ffffffff812204a0>] ? iterate_dir+0x120/0x120
May  2 09:40:52 marlinc-laptop kernel: [  564.151622]  [<ffffffff818244f2>] entry_SYSCALL_64_fastpath+0x16/0x71

This is an example strace of rm on one of these directories:

execve("/bin/rm", ["rm", "-rf", "upstart/"], [/* 34 vars */]) = 0
brk(NULL)                               = 0x1daa000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce4dfa6000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=148364, ...}) = 0
mmap(NULL, 148364, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce4df81000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce4d9ba000
mprotect(0x7fce4db7a000, 2093056, PROT_NONE) = 0
mmap(0x7fce4dd79000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fce4dd79000
mmap(0x7fce4dd7f000, 14848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce4dd7f000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce4df80000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce4df7f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce4df7e000
arch_prctl(ARCH_SET_FS, 0x7fce4df7f700) = 0
mprotect(0x7fce4dd79000, 16384, PROT_READ) = 0
mprotect(0x60d000, 4096, PROT_READ)     = 0
mprotect(0x7fce4dfa8000, 4096, PROT_READ) = 0
munmap(0x7fce4df81000, 148364)          = 0
brk(NULL)                               = 0x1daa000
brk(0x1dcb000)                          = 0x1dcb000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10223024, ...}) = 0
mmap(NULL, 10223024, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce4cffa000
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=33, ...}) = 0
newfstatat(AT_FDCWD, "upstart/", {st_mode=S_IFDIR|0700, st_size=496, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "upstart/", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFDIR|0700, st_size=496, ...}) = 0
fcntl(3, F_GETFL)                       = 0x38800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents(3,

From there it just gets stuck and the CPU executing that system call just keeps hanging.

The text was updated successfully, but these errors were encountered:

dweeezil · 2016-05-02T12:51:51Z

@Marlinc It would appear you've got a corrupted fat zap but the question is how it happened and whether the zap iterator code could handle the situation better. It would appear you've got a directory named "upstart" which is corrupted. If you could find its inode number (with ls -di upstart), it might be interesting to run zdb -dddd <pool>/<dataset> <inum>.

Marlinc · 2016-05-02T12:58:27Z

@dweeezil this is on my laptop so something might have happened with shutting down or something? Not sure actually. The command is still running but this is the result in the meantime.

Dataset ssd-boot/home/marlinc [ZPL], ID 60, cr_txg 19, 43.0G, 196133 objects, rootbp DVA[0]=<0:1eb9e6f800:200> DVA[1]=<0:7e4d52e00:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=1117954L/1117954P fill=196133 cksum=10ace24890:5e1c871238b:118ca58d3f3ee:249ef04e3d46d9

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
        29    2    16K    16K  71.0K   112K  100.00  ZFS directory
                                        168   bonus  System attributes
    dnode flags: USED_BYTES USERUSED_ACCOUNTED 
    dnode maxblkid: 6
    path    /.cache/upstart
    uid     0
    gid     0
    atime   Sun Apr 10 22:08:20 2016
    mtime   Mon Apr 25 09:37:08 2016
    ctime   Mon Apr 25 09:57:01 2016
    crtime  Fri Feb  5 15:45:23 2016
    gen 955
    mode    40700
    size    496
    parent  7
    links   2
    pflags  40800000044

I'll update it when its done.

I changed the owner of the directory to root so that no automated tools running as my user can access the directory and cause my laptop to hang.

dweeezil · 2016-05-02T13:05:49Z

@Marlinc It sounds like zdb is spinning the same way.

Marlinc · 2016-05-02T13:06:22Z

@dweeezil looks like it, it hasn't stopped yet. Are you on IRC by any chance?

dweeezil · 2016-05-02T13:19:01Z

@Marlinc I think in the mean time, you're going to have to settle for renaming the directory and living with potential space leakage for the time being. You should be able to send/receive the dataset and then destroy the original one if you wanted to eliminate the corruption. That said, however, it would be interesting to get a better handle on the type of corruption which occurred here. Since it appears to be a normal directory, there shouldn't be a way for a crash to leave it in a corrupted state, unless the SSD lies about its flushes. If you wanted to pursue this further, the next easy thing to try would be to compile a debugging build of ZoL without even installing it and then run the zdb with asserts enable and see if any of them are tripped.

Marlinc · 2016-05-02T13:49:50Z

@dweeezil I'm currently compiling ZFS in a container. Should I enable any extra options while compiling?

Marlinc · 2016-05-03T08:46:49Z

Is there a way to run the user land ZFS commands from within the container? That way I don't have to install them on the host.

dweeezil · 2016-05-03T11:42:08Z

@Marlinc The userland utilities can be run on the host directly from the build area. You can, for example, run zdb as cmd/zdb/zdb <args> and it'll do the Right Thing. In other words, you don't really need a container since you can build them in an isolated area on the host and run the userland utilities from there without installing anything at all.

Marlinc · 2016-05-03T11:55:28Z

@dweeezil I guess I'll have to compile on the host then. I didn't want to install all of the required tools on my host OS. I'll make a clone and do it in that instead.

Marlinc · 2016-05-03T12:12:53Z

@dweeezil okay, I compiled it. What now?

dweeezil · 2016-05-03T12:21:13Z

@Marlinc I was interested as to whether a debug build would help isolate the corruption by tripping an ASSERT. You need to configure with --enable-debug, build and then run cmd/zdb/zdb -dddd <pool>/<dataset> <inum>. If it just hangs as before, then none of the ASSERTs have been tripped. I'm hoping one of them does get hit.

Marlinc · 2016-05-03T12:47:42Z

@dweeezil its unfortunately still hanging.

dweeezil · 2016-05-03T13:01:43Z

@Marlinc Try cherry-picking behlendorf/zfs/@faf8d5162154c51223146080aa4bae461f59eaa8 from #1263. Apply the patch to your debug build and run zdb again. You've clearly got some zap corruption.

Marlinc · 2016-05-03T13:13:52Z

@dweeezil that didn't do anything either. Don't I have to reload the kernel module for that? Or is it purely user space tools? Anyway, same result as before. I cleaned the build and applied the patch.

dweeezil · 2016-05-07T12:48:29Z

@Marlinc I wasn't able to look into this any more during the week. A couple of patches in the "zdb" branch of my repo might be handy. First would be e2482cd which with a single "-z" option suppresses the full decode of a zap and with "-zz" suppresses any interpretation of the zap. If you tried with simply a "-z", we might be able to get some interesting stats about the zap. Next is 0959207 which add "-a" to dump a megabyte of raw data from a zap. This allows to grab a copy of the zap in a file for off-line analysis. I'm not suggesting this yet.

Does your system have ECC memory? I have a feeling there was a bit-flip in either a zap leaf header (probably lh_prefix or lh_prefix_len) or in a leaf entry (probably le_cd). Something is causing the iteration to loop infinitely. We could work up a patch to break the loop if necessary but since your goal is to remove the directory, you'd wind up with leaked space. If you do have ECC memory, then there's potentially a bug here which merits further investigation.

Have you tried to zfs send dataset containing the directory? Your best bet to correct things without space leakage is likely to copy the dataset with send/receive and then destroy the old copy.

Marlinc · 2016-05-26T21:15:53Z

My server at home just run into the exact same issue.

johnramsden · 2016-09-17T07:17:35Z

I just hit this problem on Arch Linux running the zfsonlinux stable release.

Here is the output from strace where I tried rm -rf:

~ » strace rm -rf /home/john/.cache/google-chrome/Default/Cache                        john@Archon
execve("/usr/sbin/rm", ["rm", "-rf", "/home/john/.cache/google-chrome/"...], [/* 34 vars */]) = 0
brk(NULL)                               = 0x259a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=177065, ...}) = 0
mmap(NULL, 177065, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc18f0a4000
close(3)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\3\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1951744, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc18f0a2000
mmap(NULL, 3791152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc18eb10000
mprotect(0x7fc18eca5000, 2093056, PROT_NONE) = 0
mmap(0x7fc18eea4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7fc18eea4000
mmap(0x7fc18eeaa000, 14640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc18eeaa000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7fc18f0a3480) = 0
mprotect(0x7fc18eea4000, 16384, PROT_READ) = 0
mprotect(0x60d000, 4096, PROT_READ)     = 0
mprotect(0x7fc18f0d0000, 4096, PROT_READ) = 0
munmap(0x7fc18f0a4000, 177065)          = 0
brk(NULL)                               = 0x259a000
brk(0x25bb000)                          = 0x25bb000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1669168, ...}) = 0
mmap(NULL, 1669168, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc18ef0a000
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=20, ...}) = 0
newfstatat(AT_FDCWD, "/home/john/.cache/google-chrome/Default/Cache", {st_mode=S_IFDIR|0700, st_size=9600, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/home/john/.cache/google-chrome/Default/Cache", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFDIR|0700, st_size=9600, ...}) = 0
fcntl(3, F_GETFL)                       = 0x38800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents(3,

If I have snapshots should I be able to fix this with a rollback? or do I need to zfs send/recieve a backup off my server?

I was able to rename the folder from /home/john/.cache/google-chrome to ~/.cashe/trash/Default/Cache/ but I was hoping i'd be able to create a new dataset, move it there, and delete the new dataset, unfortunately it didn't work. Attempting to move it gave me this:

# strace mv /home/john/.cache/trash/Default/Cache/ /home/john/trashbin
execve("/usr/sbin/mv", ["mv", "/home/john/.cache/trash/Default/"..., "/home/john/trashbin"], [/* 36 vars */]) = 0
brk(NULL)                               = 0x1b9c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=177065, ...}) = 0
mmap(NULL, 177065, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd424f23000
close(3)                                = 0
open("/usr/lib/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300 \0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=35384, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd424f21000
mmap(NULL, 2130592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd424b24000
mprotect(0x7fd424b2c000, 2093056, PROT_NONE) = 0
mmap(0x7fd424d2b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fd424d2b000
close(3)                                = 0
open("/usr/lib/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\24\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18736, ...}) = 0
mmap(NULL, 2113912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd42491f000
mprotect(0x7fd424923000, 2093056, PROT_NONE) = 0
mmap(0x7fd424b22000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fd424b22000
close(3)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\3\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1951744, ...}) = 0
mmap(NULL, 3791152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fd424581000
mprotect(0x7fd424716000, 2093056, PROT_NONE) = 0
mmap(0x7fd424915000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7fd424915000
mmap(0x7fd42491b000, 14640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd42491b000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd424f1f000
arch_prctl(ARCH_SET_FS, 0x7fd424f1f700) = 0
mprotect(0x7fd424915000, 16384, PROT_READ) = 0
mprotect(0x7fd424b22000, 4096, PROT_READ) = 0
mprotect(0x7fd424d2b000, 4096, PROT_READ) = 0
mprotect(0x61c000, 4096, PROT_READ)     = 0
mprotect(0x7fd424f4f000, 4096, PROT_READ) = 0
munmap(0x7fd424f23000, 177065)          = 0
brk(NULL)                               = 0x1b9c000
brk(0x1bbd000)                          = 0x1bbd000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1669168, ...}) = 0
mmap(NULL, 1669168, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd424d87000
close(3)                                = 0
geteuid()                               = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("/home/john/trashbin", {st_mode=S_IFDIR|0755, st_size=4, ...}) = 0
lstat("/home/john/.cache/trash/Default/Cache/", {st_mode=S_IFDIR|0700, st_size=9600, ...}) = 0
lstat("/home/john/trashbin/Cache", {st_mode=S_IFDIR|0700, st_size=2, ...}) = 0
geteuid()                               = 0
rename("/home/john/.cache/trash/Default/Cache/", "/home/john/trashbin/Cache") = -1 EXDEV (Invalid cross-device link)
rmdir("/home/john/trashbin/Cache")      = 0
mkdir("/home/john/trashbin/Cache", 0700) = 0
lstat("/home/john/trashbin/Cache", {st_mode=S_IFDIR|0700, st_size=2, ...}) = 0
open("/home/john/.cache/trash/Default/Cache/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0700, st_size=9600, ...}) = 0

baukus mentioned this issue Feb 8, 2017

Directories corrupted, commands hanging indefineltly #5346

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CPU stuck when getdents gets run on some directories #4583

CPU stuck when getdents gets run on some directories #4583

Marlinc commented May 2, 2016

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016 •

edited

Loading

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016 •

edited

Loading

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 7, 2016

Marlinc commented May 26, 2016

johnramsden commented Sep 17, 2016

CPU stuck when getdents gets run on some directories #4583

CPU stuck when getdents gets run on some directories #4583

Comments

Marlinc commented May 2, 2016

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016 • edited Loading

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016 • edited Loading

dweeezil commented May 2, 2016

Marlinc commented May 2, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 3, 2016

Marlinc commented May 3, 2016

dweeezil commented May 7, 2016

Marlinc commented May 26, 2016

johnramsden commented Sep 17, 2016

Marlinc commented May 2, 2016 •

edited

Loading

Marlinc commented May 2, 2016 •

edited

Loading