2

After what appears to be a power outage on my standby postgres database, i'm receiving the error:

XFS: Internal error XFS_WANT_CORRUPTED_GOTO

after the system reboots as well as postgres error log shows:

ERROR:  could not write block 1759002 in file "base/278425/1651445.13": Input/output error
CONTEXT:  writing block 1759002 of relation base/278425/1651445
ERROR:  could not write block 339174 in file "base/278425/1651495.2": Input/output error
CONTEXT:  writing block 339174 of relation base/278425/1651495
PANIC:  could not write to log segment 0000000100001423000000A9 at offset 149696, length 5952: Input/output error

A few days earlier on a separate identical system, I received a postgres error:

ERROR:  could not write block 69511 in file "base/278425/539725": Structure needs cleaning
CONTEXT:  writing block 69511 of relation base/278425/539725
WARNING:  could not write block 69511 of base/278425/539725
DETAIL:  Multiple failures --- write error might be permanent.

The 2TB filesystem is mounted using:

mount -t xfs -o rw,nobarrier,noatime,nodiratime /dev/md0 /postgres_data

  1. Since this is an AWS ELB(GP2) volume, im guessing that it is not battery backed and is the volume corrupted because I chose the nobarrier option?

  2. Since this filesystem is 2TB in size, should I have added the option inode64 and could that be the issue? The filesystem contains 1.2TB of data.

2
  • What Linux distribution? Jul 23, 2015 at 19:56
  • Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-55-generic x86_64)
    – Nick
    Jul 23, 2015 at 20:04

1 Answer 1

2

inode64 is the default mount value, so your system should already use it.

With much probability the issue is due to the nobarrier option, coupled to non-BBU write cache on the host side.

You had to take the filesystem offline and run xfs_repair against it.

3
  • I think you mean xfs_repair. The fsck.xfs doesn't do anything but print "XFS file system" or the following message: "If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_repair(8)." Jul 24, 2015 at 12:42
  • Oh yes, I thought it was symlink to xfs_repair... Checking on the man page, instead, give that: fsck.xfs - do nothing, successfully :) I'll edit my answer... thank you for the catch.
    – shodanshok
    Jul 24, 2015 at 12:56
  • Thank you. I removed nobarrier from the mount options and will see if any further issues occur.
    – Nick
    Jul 24, 2015 at 17:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .