On 01/23/2017 09:03 PM, Matt McKinnon wrote: > Wondering what to do about this error which says 'reboot needed'. Has > happened a three times in the past week: > > Jan 23 14:16:17 my_machine kernel: [ 2568.595648] BTRFS error (device > sda1): err add delayed dir index item(index: 23810) into the deletion > tree of the delayed node(root id: 257, inode id: 2661433, errno: -17) > Jan 23 14:16:17 my_machine kernel: [ 2568.611010] ------------[ cut here > ]------------ > Jan 23 14:16:17 my_machine kernel: [ 2568.615628] kernel BUG at > fs/btrfs/delayed-inode.c:1557! > Jan 23 14:16:17 my_machine kernel: [ 2568.620942] invalid opcode: 0000 > [#1] SMP > [...] The purpose of the code involved is that if you create a directory or file and quickly remove it again, the filesystem doesn't need to do two disk writes, it can just erase it again from its memory before writing anything to disk. ---- 8< more ---- This is when the functionality was added: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=16cdcec736cd214350cdb591bf1091f8beedefa0 If you look for "err add delayed dir" in the source code of that commit message, you see where the error message is constructed errno: -17, just after it called __btrfs_add_delayed_insertion_item __btrfs_add_delayed_insertion_item calls __btrfs_add_delayed_item, and the only non-0 return in that function is: return -EEXIST, which is -17 I think this means you added a file or directory, and the kernel code tried to add adding the file twice to the list of additions, which it has no way to deal with except making the whole kernel crash. ---- >8 ---- A while ago someone reported this on IRC, running a 4.8.13 kernel. (that's when I looked up the above info). I can also find it in Oct 2016 in my IRC logs, but without any info on kernel version. Anyway, it seems to point to something that's going wrong with changes that are *not* on disk *yet*, and the crash is preventing . -- Hans van Kranenburg -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
