On Tue, Apr 12, 2016 at 11:02:37PM -0400, Andrew Ryder wrote: > Is it possible the location its searching for at block > > 02:34:43.887528 pread64(4, 0x7fb8f53e0200, 2097152, 3001552175104) = > -1 EIO (Input/output error) so offset is 3001552175104, or roughly around the 3TB mark. Given the log i always placed int eh middle of the filesystem and you have a 6TB device, then the above definitely looks like a valid place to be reading from the log. > xfs_logprint: > data device: 0x902 > log device: 0x902 daddr: 5860130880 length: 4173824 daddr converted to offset is 5860130880 * 512 = 3001552175104, which tells us that the above pread64 failure was definitely coming from an attempt to read the log. That this is coming from the block device from userspace indicates a problem below XFS. There is something going wrong with your underlying block device and/or hardware here; AFAICT it's not related to XFS at all. > >GNU Parted 3.2 > >Using /dev/sdk > >Welcome to GNU Parted! Type 'help' to view a list of commands. > >(parted) p > >Model: ATA ST2000DL001-9VT1 (scsi) > >Disk /dev/sdk: 2000GB > >Sector size (logical/physical): 512B/512B > >Partition Table: msdos > >Disk Flags: > > > >Number Start End Size Type File system Flags > > 1 512B 2000GB 2000GB primary raid > >Number Start End Size Type File system Flags > > 1 1s 3907029167s 3907029167s primary raid Compared to the other devices, it has a different start sector, a different size, and an msdos partition table rather than gpt. Definitely a red flag... > >>>This all began when the RR2722 driver running under 3.18.15 > >>>complained and Reported physical IO errors to a write command. Really, this looks like a hardware issue, not something that can be fixed by running xfs_repair... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
