1

Our FreeNAS file server's /var/log/messages and dmesg logs are filling up with:

Nov 28 14:50:00 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:50:00 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1

My gut feeling is that the SATA drive on which swap resides is going bad. But SMART shows no errors, and I don't see any log messages about I/O errors for /dev/ada2... furthermore, the same physical drive swap is on (/dev/ada2) has a ZFS partition (/dev/ada2p2) which reports no I/O errors nor checksum errors. I'm tempted to do a zpool scrub but don't want to kill the disk if it is actually failing.

I googled for this error but the results were... not definitive.

What does the FreeBSD kernel message vnode_pager_putpages: I/O error 5 mean?

(Here's a larger log sample)

Nov 28 14:50:00 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:50:00 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 14:51:38 chef afpd[69440]: sys_getextattr_size: error: Result too large
Nov 28 14:52:02 chef last message repeated 969 times
Nov 28 14:52:02 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:52:02 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 14:52:05 chef afpd[69440]: sys_getextattr_size: error: Result too large
Nov 28 14:52:36 chef last message repeated 1798 times
Nov 28 14:53:27 chef last message repeated 2952 times
Nov 28 14:54:46 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:54:46 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 14:55:01 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:55:01 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 14:57:00 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:57:00 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 14:58:32 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 14:58:32 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Nov 28 15:00:00 chef kernel: vnode_pager_putpages: I/O error 5
Nov 28 15:00:01 chef kernel: vnode_pager_putpages: residual I/O 12288 at 1
Josh
  • 9,190
  • 28
  • 80
  • 128

2 Answers2

3

Error code 5 is EIO (generic Input/Output Error) per sys/errno.h.
I would take that as an indication that whatever device your system was trying to access is having problems (likely dying as you surmised).

This is may not be related to your swap partition -- the other message you're getting proximate to this one is sys_getextattr_size: error: Result too large from afpd.

My guess is whatever disk afpd is hitting is likely the one with the problem, and the funky extended attributes data & related error message you're seeing is probably an artifact of the underlying I/O error that's upsetting vnode_put_pages()/VOP_WRITE().

voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • The `afpd` errors have been there forever, and are related to Mac OS X clients and Extended Attributes. I've been meaning to try and fix them, but since they haven't been causing any problems I've left them alone. I think adding `ea:ad options:upriv` to the `AppleVolumes` file should fix that... I'll try this and see if the `afpd` messages cease and the `vnode_pager_putpages` messages remain... – Josh Nov 28 '12 at 21:24
  • @Josh If the afpd errors have been there long before the I/O errors it's possible you've got something else mucking up your extended attributes (in which case anything that involves vnode writes is back in play as a possible culprit) -- I've not spent much time with `afpd` so I'm not that familiar with its particular quirks and you probably know more about them than I do :) -- In either case I'd take a good backup and run a disk exerciser (or something intensive like a zpool scrub) to see if you can induce a more obvious error from the drive. – voretaq7 Nov 28 '12 at 21:28
  • Thanks voretaq7! This system has 4 drives in it -- 3 in RAIDz (which is what `afpd` is hitting) so if one of them is bad, no biggie... and one with no redundancy which *is* mostly a backup drive... so I'll back that one up and `scrub` it... – Josh Nov 28 '12 at 21:30
  • There are non-drive possible causes too (flaky controller, or one that throws an I/O error if it's saturated, etc.) -- if your disks come through testing OK don't worry too much as long as you trust your backups :-) – voretaq7 Nov 28 '12 at 21:35
1

Try buying new sata cables. Or clear the logs and then wiggle the cables to see if this error is generated

benathon
  • 492
  • 2
  • 12