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.

Nick
  • 171
  • 1
  • 1
  • 6

1 Answers1

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.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • 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)." – Michael Hampton Jul 24 '15 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 '15 at 12:56
  • Thank you. I removed `nobarrier` from the mount options and will see if any further issues occur. – Nick Jul 24 '15 at 17:58