Re: Fwd: confusing "no space left" -- how to troubleshoot and "be prepared"?
On Thu, 18 May 2017, Peter Becker wrote: > I'm not sure if this would be helpfull but can you post the output > from this script? > cd /tmp > wget https://raw.githubusercontent.com/kdave/btrfs-progs/master/btrfs-debugfs > chmod +x btrfs-debugfs > stats=$(sudo ./btrfs-debugfs -b /) > ... Thank you Peter I guess I will use on the next occasion like that. This time I just removed some snapshots/subvolumes (and docker images) to free up some space, rebooted and using the system again. I guess it would make little sense to share that info ATM. With best regards, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
confusing "no space left" -- how to troubleshoot and "be prepared"?
our python-based program crashed with File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/gitdb/stream.py", line 695, in write os.write(self._fd, data) OSError: [Errno 28] No space left on device but as far as I could see there still should be both data and meta data space left: $> sudo btrfs fi df $PWD Data, RAID0: total=33.55TiB, used=30.56TiB System, RAID1: total=32.00MiB, used=1.81MiB Metadata, RAID1: total=83.00GiB, used=64.81GiB GlobalReserve, single: total=512.00MiB, used=0.00B $> sudo btrfs fi usage $PWD Overall: Device size: 43.66TiB Device allocated: 33.71TiB Device unallocated:9.95TiB Device missing: 0.00B Used: 30.69TiB Free (estimated): 12.94TiB (min: 7.96TiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 512.00MiB (used: 0.00B) Data,RAID0: Size:33.55TiB, Used:30.56TiB /dev/md10 8.39TiB /dev/md11 8.39TiB /dev/md12 8.39TiB /dev/md13 8.39TiB Metadata,RAID1: Size:83.00GiB, Used:64.81GiB /dev/md10 41.00GiB /dev/md11 42.00GiB /dev/md12 41.00GiB /dev/md13 42.00GiB System,RAID1: Size:32.00MiB, Used:1.81MiB /dev/md10 32.00MiB /dev/md12 32.00MiB Unallocated: /dev/md10 2.49TiB /dev/md11 2.49TiB /dev/md12 2.49TiB /dev/md13 2.49TiB (so it is RAID0 for data sitting on top of software RAID5s) I am running Debian jessie with custom built kernel Linux smaug 4.9.0-rc2+ #3 SMP Fri Oct 28 20:59:01 EDT 2016 x86_64 GNU/Linux btrfs-tools were 4.6.1-1~bpo8+1 , FWIW upgraded to 4.7.3-1~bpo8+1 I do have a fair number of subvolumes (794! snapshots + used by docker) so what could be the catch -- currently can't even touch a new file (can touch existing ;-/ )? meanwhile removing some snapshots, syncing and rebooting in attempt to mitigate not usable server looking at the logs, I see that there were some traces logged a day ago: ... May 17 01:47:41 smaug kernel: INFO: task kworker/u33:15:318164 blocked for more than 120 seconds. May 17 01:47:41 smaug kernel: Tainted: G I L 4.9.0-rc2+ #3 May 17 01:47:41 smaug kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 17 01:47:41 smaug kernel: kworker/u33:15 D 815e6fd3 0 318164 2 0x May 17 01:47:41 smaug kernel: Workqueue: writeback wb_workfn (flush-btrfs-1) May 17 01:47:41 smaug kernel: 88102dba3400 8810390741c0 88103fc98740 May 17 01:47:41 smaug kernel: 881036640e80 c9002af334e8 815e6fd3 May 17 01:47:41 smaug kernel: 881038800668 c9002af33540 881036640e80 881038800668 May 17 01:47:41 smaug kernel: Call Trace: May 17 01:47:41 smaug kernel: [] ? __schedule+0x1a3/0x670 May 17 01:47:41 smaug kernel: [] ? schedule+0x32/0x80 May 17 01:47:41 smaug kernel: [] ? raid5_get_active_stripe+0x4f0/0x670 [raid456] May 17 01:47:41 smaug kernel: [] ? wake_up_atomic_t+0x30/0x30 May 17 01:47:41 smaug kernel: [] ? raid5_make_request+0x18d/0xc40 [raid456] May 17 01:47:41 smaug kernel: [] ? wake_up_atomic_t+0x30/0x30 May 17 01:47:41 smaug kernel: [] ? md_make_request+0xf5/0x230 [md_mod] May 17 01:47:41 smaug kernel: [] ? generic_make_request+0x106/0x1f0 May 17 01:47:41 smaug kernel: [] ? submit_bio+0x76/0x150 May 17 01:47:41 smaug kernel: [] ? btrfs_map_bio+0x10e/0x370 [btrfs] May 17 01:47:41 smaug kernel: [] ? btrfs_submit_bio_hook+0xb8/0x190 [btrfs] May 17 01:47:41 smaug kernel: [] ? submit_one_bio+0x66/0x90 [btrfs] May 17 01:47:41 smaug kernel: [] ? submit_extent_page+0x138/0x310 [btrfs] May 17 01:47:41 smaug kernel: [] ? end_extent_writepage+0x80/0x80 [btrfs] May 17 01:47:41 smaug kernel: [] ? __extent_writepage_io+0x420/0x4e0 [btrfs] May 17 01:47:41 smaug kernel: [] ? end_extent_writepage+0x80/0x80 [btrfs] May 17 01:47:41 smaug kernel: [] ? __extent_writepage+0x209/0x340 [btrfs] May 17 01:47:41 smaug kernel: [] ? extent_write_cache_pages.isra.40.constprop.51+0x282/0x380 [btrfs] May 17 01:47:41 smaug kernel: [] ? extent_writepages+0x5d/0x90 [btrfs] May 17 01:47:41 smaug kernel: [] ? btrfs_set_bit_hook+0x210/0x210 [btrfs] May 17 01:47:41 smaug kernel: [] ? __writeback_single_inode+0x3d/0x330 May 17 01:47:41 smaug kernel: [] ? writeback_sb_inodes+0x23d/0x470 May 17 01:47:41 smaug kernel: [] ? __writeback_inodes_wb+0x87/0xb0 May 17 01:47:41 smaug kernel: [] ? wb_writeback+0x282/0x310 May 17 01:47:41 smaug kernel: [] ? wb_workfn+0x2b8/0x3e0 May 17 01:47:41 smaug kernel: [] ? process_one_work+0x14b/0x410 May 17 01:47:41 smaug kernel: [] ? worker_thread+0x65/0x4a0 May 17 01:47:41 smaug kernel: [] ? rescuer_thread+0x340/0x340 May 17 01:47:41 smaug kernel: [] ? kthread+0xe0/0x100 May 17 01:47:41 smaug kernel: [] ?
Re: recent complete stalls of btrfs (4.7.0-rc2+) -- any advice?
On Tue, 09 Aug 2016, Yaroslav Halchenko wrote: > The beast has died on me today's morning :-/ Last kern.log msg was > (Fixing recursive fault but reboot is needed!) locked down again but this time seems to be different stack (and no above msg) from before: (full list of oopses since boot at http://www.onerussian.com/tmp/journal-20160909-oopses.log ) Sep 09 02:18:33 smaug kernel: [ cut here ] Sep 09 02:18:33 smaug kernel: WARNING: CPU: 4 PID: 2189174 at lib/list_debug.c:33 __list_add+0x86/0xb0 Sep 09 02:18:33 smaug kernel: list_add corruption. prev->next should be next (8820079d6308), but was 88181e7e0d28. (prev=8810b209fe10). Sep 09 02:18:33 smaug kernel: Modules linked in: veth xt_addrtype ipt_MASQUERADE nf_nat_masquerade_ipv4 bridge stp llc pci_stub cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave xt_pkttype nf_log_ipv4 nf_log_common xt_tcpudp ip6table_mangle nfsd auth_rpcgss oid_registry nfs_acl iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nfs lockd grace nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables fscache sunrpc binfmt_misc ipmi_watchdog intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_poweroff ipmi_devintf kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iTCO_wdt iTCO_vendor_support drbg Sep 09 02:18:33 smaug kernel: ansi_cprng snd_pcm snd_timer aesni_intel snd aes_x86_64 soundcore lrw fuse gf128mul glue_helper ablk_helper cryptd pcspkr ast ttm drm_kms_helper joydev drm mei_me evdev i2c_algo_bit i2c_i801 mei shpchp lpc_ich ioatdma mfd_core ipmi_si wmi ipmi_msghandler tpm_tis tpm acpi_pad acpi_power_meter button ecryptfs cbc sha256_ssse3 sha256_generic hmac encrypted_keys autofs4 ext4 crc16 jbd2 mbcache btrfs dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 md_mod sg ses enclosure sd_mod hid_generic usbhid hid crc32c_intel ahci libahci mpt3sas raid_class scsi_transport_sas ehci_pci xhci_pci xhci_hcd ehci_hcd libata ixgbe dca usbcore usb_common scsi_mod ptp pps_core mdio fjes [last unloaded: vboxdrv] Sep 09 02:18:33 smaug kernel: CPU: 4 PID: 2189174 Comm: git-annex Tainted: G W IO4.7.0-rc2+ #1 Sep 09 02:18:33 smaug kernel: Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 1.0b 09/17/2014 Sep 09 02:18:33 smaug kernel: 0286 0ab947c2 8130c605 881292cfbd28 Sep 09 02:18:33 smaug kernel: 8107a314 881292cfbe10 881292cfbd80 Sep 09 02:18:33 smaug kernel: 8810b209fe10 881037a07a98 881f24b1a800 881037a07800 Sep 09 02:18:33 smaug kernel: Call Trace: Sep 09 02:18:33 smaug kernel: [] ? dump_stack+0x5c/0x77 Sep 09 02:18:33 smaug kernel: [] ? __warn+0xc4/0xe0 Sep 09 02:18:33 smaug kernel: [] ? warn_slowpath_fmt+0x5f/0x80 Sep 09 02:18:33 smaug kernel: [] ? btrfs_write_marked_extents+0x95/0x130 [btrfs] Sep 09 02:18:33 smaug kernel: [] ? __list_add+0x86/0xb0 Sep 09 02:18:33 smaug kernel: [] ? btrfs_sync_log+0x249/0xa80 [btrfs] Sep 09 02:18:33 smaug kernel: [] ? btrfs_sync_file+0x39a/0x3e0 [btrfs] Sep 09 02:18:33 smaug kernel: [] ? do_fsync+0x38/0x60 Sep 09 02:18:33 smaug kernel: [] ? SyS_fdatasync+0xf/0x20 Sep 09 02:18:33 smaug kernel: [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 Sep 09 02:18:33 smaug kernel: ---[ end trace 125800d45db3ce41 ]--- Sep 09 02:18:34 smaug kernel: general protection fault: [#1] SMP Sep 09 02:18:34 smaug kernel: Modules linked in: veth xt_addrtype ipt_MASQUERADE nf_nat_masquerade_ipv4 bridge stp llc pci_stub cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave xt_pkttype nf_log_ipv4 nf_log_common xt_tcpudp ip6table_mangle nfsd auth_rpcgss oid_registry nfs_acl iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nfs lockd grace nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables fscache sunrpc binfmt_misc ipmi_watchdog intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_poweroff ipmi_devintf kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iTCO_wdt iTCO_vendor_support drbg Sep 09 02:18:34 smaug kernel: ansi_cprng snd_pcm snd_timer aesni_intel snd aes_x86_64 soundcore lrw fuse gf128mul glue_helper ablk_helper cryptd pcspkr ast ttm drm_kms_helper joydev drm mei_me evdev i2c_algo_bit i2c_i801 mei shpchp lpc_ich ioatdma mfd_core ipmi_si wmi ipmi_msghandler tpm_tis tpm acpi_pad acpi_power_meter button ecryptfs cbc sha256_ssse3 sha256_generic hmac encrypted_keys autofs4 ext4 crc16 jbd2 mbcache btrfs dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor
Re: recent complete stalls of btrfs (4.7.0-rc2+) -- any advice?
On Sun, 12 Jun 2016, Yaroslav Halchenko wrote: > On Fri, 10 Jun 2016, Chris Murphy wrote: > > > Are those issues something which was fixed since 4.6.0-rc4+ or I should > > > be on look out for them to come back? What other information should I > > > provide if I run into them again to help you troubleshoot/fix it? > > > P.S. Please CC me the replies > > 4.6.2 is current and it's a lot easier to just use that and see if it > > still happens than for someone to track down whether it's been fixed > > since a six week old RC. > Dear Chris, > Thank you for the reply! Now running v4.7-rc2-300-g3d0f0b6 > The thing is that this issue doesn't happen right away, and it takes a > while for it to develop, and seems to be only after an intensive load. > So the version I run will always be "X weeks old" if I just keep hopping > the recent release of master, and it would be an indefinite goose > chase if left un-analyzed. That is why I would still appreciate an > advice on what specifics to report/attempt if such crash happens next > time, or may be if someone is having an idea of what could have lead to > this crash to start with. The beast has died on me today's morning :-/ Last kern.log msg was (Fixing recursive fault but reboot is needed!) One of the tracebacks is the same as before (ending on btrfs_commit_transaction), so I guess it could be the same issue as before? Most probably I will perform the same kernel build/upgrade dance again BUT I still hope that someone might just either spot some sign of recently (since v4.7-rc2-300-g3d0f0b6) fixed issue or, if not spotted, actually looks in detail on possibly a new issue which wasn't addressed yet. I would be "happy" to provide more information or enable any necessary additional monitoring to provide more information in case of the next crash. I have rebooted the box around 11am, and it was completely unresponsive since some time earlier but I think it still "somewhat functioned" after the last traceback reported in the kern.log which I shared at http://www.onerussian.com/tmp/kern-smaug-20160809.log otherwise journalctl -b -1 doesn't show any other grave errors. The very last oops in the kern.log I also cite here. Out of academic interest? why seems to be ext4 functionality within the stack for btrfs_commit_transaction? is some logic common/reused between the two file systems? Or it is just a mere fact that some partitions on ext4 and something in btrfs triggered them as well? Aug 9 07:46:15 smaug kernel: [5132590.362689] Oops: [#3] SMP Aug 9 07:46:15 smaug kernel: [5132590.367913] Modules linked in: uas usb_storage vboxdrv(O) nls_utf8 ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs veth xt_addrtype ipt_MASQUERADE nf_nat_masquerade_ipv4 bridge stp llc cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave xt_pkttype nf_log_ipv4 nf_log_common xt_tcpudp ip6table_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nfsd nf_conntrack_ftp auth_rpcgss oid_registry nfs_acl nfs lockd grace nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables fscache sunrpc binfmt_misc intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_watchdog ipmi_poweroff ipmi_devintf kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass fuse crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng aesni_intel aes_x86_64 lrw gf128mul snd_pcm glue_helper ablk_helper cryptd snd_timer snd soundcore pcspkr evdev joydev ast ttm drm_kms_helper i2c_i801 drm i2c_algo_bit mei_me lpc_ich mfd_core mei ipmi_si ioatdma shpchp wmi ipmi_msghandler ecryptfs cbc tpm_tis tpm acpi_power_meter acpi_pad button sha256_ssse3 sha256_generic hmac encrypted_keys autofs4 ext4 crc16 jbd2 mbcache btrfs dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 md_mod ses enclosure sg sd_mod hid_generic usbhid hid crc32c_intel mpt3sas raid_class scsi_transport_sas xhci_pci xhci_hcd ehci_pci ahci ehci_hcd libahci libata usbcore ixgbe scsi_mod usb_common dca ptp pps_core mdio fjes Aug 9 07:46:15 smaug kernel: [5132590.538375] CPU: 6 PID: 2878531 Comm: git Tainted: G D W IO4.7.0-rc2+ #1 Aug 9 07:46:15 smaug kernel: [5132590.547950] Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 1.0b 09/17/2014 Aug 9 07:46:15 smaug kernel: [5132590.557009] task: 8817b855b0c0 ti: 88000e0dc000 task.ti: 88000e0dc000 Aug 9 07:46:15 smaug kernel: [5132590.566572] RIP: 0010:[] [] jbd2__journal_start+0x33/0x1e0 [jbd2] Aug 9 07:46:15 smaug kernel: [5132590.578009] RSP: 0018:88000e0df8f0 EFLAGS: 00010282 Aug 9 07:46:15 smaug kernel: [5132590.585427] RAX: 88155eae8140 RBX: 881ed5a9d128
Re: recent complete stalls of btrfs (4.6.0-rc4+) -- any advice?
On Fri, 10 Jun 2016, Chris Murphy wrote: > > Are those issues something which was fixed since 4.6.0-rc4+ or I should > > be on look out for them to come back? What other information should I > > provide if I run into them again to help you troubleshoot/fix it? > > P.S. Please CC me the replies > 4.6.2 is current and it's a lot easier to just use that and see if it > still happens than for someone to track down whether it's been fixed > since a six week old RC. Dear Chris, Thank you for the reply! Now running v4.7-rc2-300-g3d0f0b6 The thing is that this issue doesn't happen right away, and it takes a while for it to develop, and seems to be only after an intensive load. So the version I run will always be "X weeks old" if I just keep hopping the recent release of master, and it would be an indefinite goose chase if left un-analyzed. That is why I would still appreciate an advice on what specifics to report/attempt if such crash happens next time, or may be if someone is having an idea of what could have lead to this crash to start with. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
recent complete stalls of btrfs (4.6.0-rc4+) -- any advice?
Dear BTRFS developers, First of all -- thanks for developing BTRFS! So far it served really well, when others falling (or failing) behind in my initial evaluation (http://datalad.org/test_fs_analysis.html). With btrbk backups are a breeze. But it still does fail completely for me at times unfortunately. I know that I should upgrade the kernel, and I will now... but I thought to share this incident(s) report since those might have been of some value. Running Debian jessie but with manually built kernel. btrfs is extensively used for a high meta-data partition (lots of symlinks, lots of directories with a single file in them -- heave use of git-annex), snapshots are taken regularly etc. Setup -- btrfs on top of software raids: # btrfs fi show /mnt/btrfs/ Label: 'tank' uuid: b5fe7f5e-3478-4293-a42c-bf9ca26ea724 Total devices 4 FS bytes used 21.07TiB devid2 size 10.92TiB used 5.30TiB path /dev/md10 devid3 size 10.92TiB used 5.30TiB path /dev/md11 devid4 size 10.92TiB used 5.30TiB path /dev/md12 devid5 size 10.92TiB used 5.30TiB path /dev/md13 Within last 5 days, the beast has stalled twice by now. The last signs were: * 20160605 -- kernel kaboomed at btrfs level smaug login: [3675876.734400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: a03d0354 [3675876.734400] [3675876.745680] CPU: 9 PID: 651474 Comm: git Tainted: GW IO 4.6.0-rc4+ #1 [3675876.753272] Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 1.0b 09/17/2014 [3675876.760431] 0086 5e62edd4 813098f5 817cd080 [3675876.768104] 880036f23da8 811701af 881e0010 880036f23db8 [3675876.775763] 880036f23d50 5e62edd4 880036f23d88 a03d0354 [3675876.783426] Call Trace: [3675876.786057] [] ? dump_stack+0x5c/0x77 [3675876.791575] [] ? panic+0xdf/0x226 [3675876.796812] [] ? btrfs_add_link+0x384/0x3e0 [btrfs] [3675876.803549] [] ? __stack_chk_fail+0x17/0x30 [3675876.809610] [] ? btrfs_add_link+0x384/0x3e0 [btrfs] [3675876.816391] [] ? btrfs_link+0x143/0x220 [btrfs] [3675876.822802] [] ? vfs_link+0x1af/0x280 [3675876.828331] [] ? SyS_link+0x22a/0x260 [3675876.833859] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [3675876.840740] Kernel Offset: disabled [3675876.854050] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: a03d0354 [3675876.854050] * 20160610 -- again, different kaboom [443370.085059] CPU: 10 PID: 1044513 Comm: git-annex Tainted: GW IO 4.6.0-rc4+ #1 [443370.093268] Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 1.0b 09/17/2014 [443370.100356] task: 8806c463d0c0 ti: 8808f9dc8000 task.ti: 8808f9dc8000 [443370.107953] RIP: 0010:[] [] 0x88090f67be10 [443370.115761] RSP: 0018:8808f9dcbe18 EFLAGS: 00010292 [443370.121187] RAX: 88103fd95fc0 RBX: 8808f9dcc000 RCX: [443370.128438] RDX: RSI: 8806c463d0c0 RDI: 88103fd95fc0 [443370.135693] RBP: 8808f9dcbe30 R08: 8808f9dc8000 R09: [443370.142940] R10: 000a R11: R12: 881035beedc8 [443370.150184] R13: 880ff1106800 R14: 88123d6c R15: 88123d6c0068 [443370.157432] FS: 7f0ab3d83740() GS:88103fd8() knlGS: [443370.165645] CS: 0010 DS: ES: CR0: 80050033 [443370.171512] CR2: 88090f67be10 CR3: 000cf7516000 CR4: 001406e0 [443370.178758] Stack: [443370.180880] 88069dda93c0 a0358700 88069dda93c0 880f [443370.188490] 8806c463d0c0 810bb560 8808f9dcbe48 8808f9dcbe48 [443370.196107] d5ce3509 88069dda93c0 0001 8806a64835c8 [443370.203726] Call Trace: [443370.206310] [] ? btrfs_commit_transaction+0x350/0xa30 [btrfs] [443370.213826] [] ? wait_woken+0x90/0x90 [443370.219280] [] ? btrfs_sync_file+0x2fb/0x3d0 [btrfs] [443370.226012] [] ? do_fsync+0x38/0x60 [443370.231267] [] ? SyS_fdatasync+0xf/0x20 [443370.236870] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [443370.243604] Code: 88 ff ff 21 67 5b 81 ff ff ff ff 00 00 6c 3d 12 88 ff ff dd 77 35 a0 ff ff ff ff 00 00 00 00 00 00 00 00 40 e0 91 4b 08 88 ff ff <60> b5 0b 81 ff ff ff ff f0 fd 61 8a 0c 88 ff ff 18 7c 79 3e 00 [443370.264107] RIP [] 0x88090f67be10 [443370.271044] RSP [443370.276177] CR2: 88090f67be10 [443370.284979] ---[ end trace 2c4b690b49d17ebd ]--- and for the last case here is more details with dmesg showing apparently other tracebacks and errors logged before, so might be of help: http://www.onerussian.com/tmp/dmesg-nonet.20160610.txt Are those issues something which was fixed since 4.6.0-rc4+ or I should be on look out for them to come back? What other information should I provide if I run into them again to help you troubleshoot/fix it? P.S. Please CC me the replies -- Yaroslav O.
