On Sun, May 22, 2016 at 09:36:39PM +0200, Stefan Priebe - Profihost AG wrote: > Am 16.05.2016 um 03:06 schrieb Brian Foster: > >> sd_mod ehci_pci ehci_hcd usbcore usb_common igb ahci i2c_algo_bit libahci > >> i2c_core ptp mpt3sas pps_core raid_class scsi_transport_sas > >> [Sun May 15 07:00:44 2016] CPU: 2 PID: 108 Comm: kswapd0 Tainted: G O > >> 4.4.10+25-ph #1 > > > > How close is this to an upstream kernel? Upstream XFS? Have you tried to > > reproduce this on an upstream kernel? > > It's a vanilla 4.4.10 + a new adaptec driver and some sched and wq > patches from 4.5 and 4.6 but i can try to replace the kernel on one > machine with a 100% vanilla one if this helps. Please do. > >> [295086.353473] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0x52000 size 0x13d1c8 > >> [295086.353476] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0x53000 size 0x13d1c8 > >> [295086.353478] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0x54000 size 0x13d1c8 > > ... > >> [295086.567508] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0xab000 size 0x13d1c8 > >> [295086.567510] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0xac000 size 0x13d1c8 > >> [295086.567515] XFS (md127p3): ino 0x600204f delalloc 1 unwritten 0 pgoff > >> 0xad000 size 0x13d1c8 > >> > >> The file to the inode number is: > >> /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_i18n_Translation-en > >> > > > > xfs_bmap -v might be interesting here as well. > > # xfs_bmap -v > /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_i18n_Translation-en > /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_i18n_Translation-en: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..2567]: 41268928..41271495 3 (374464..377031) 2568 So the last file offset with a block is 0x140e00. This means the file is fully allocated. However, the pages inside the file range are still marked delayed allocation. That implies that we've failed to write the pages over a delayed allocation region after we've allocated the space. That, in turn, tends to indicate a problem in page writeback - the first page to be written has triggered delayed allocation of the entire range, but then the subsequent pages have not been written (for some as yet unknown reason). When a page is written, we map it to the current block via xfs_map_at_offset(), and that clears both the buffer delay and unwritten flags. This clearly isn't happening which means either the VFS doesn't think the inode is dirty anymore, writeback is never asking for these pages to be written, or XFs is screwing something up in ->writepage. The XFS writepage code changed significantly in 4.6, so it might be worth seeing if a 4.6 kernel reproduces this same problem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
