CentOS 7.4 client mounting a CentOS 7.4 server filesystem over nfs4.
nfs seems to be much slower since the upgrade to 7.4, so I thought it might be nice to mount the directory as v4.0 rather than the new default of v4.1 to see if it makes a difference.
The release notes state, without an example:
"You can retain the original behavior by specifying 0 as the minor version"
nfs(5) states:
** Recent kernels allow the minor version to be specified using the vers= option. For example, specifying vers=4.1 is the same as specifying vers=4,minorversion=1. **
but in fstab or on the command line, using either form (vers=4.0 or vers=4,minorversion=0), if I run mount afterwards, I still see vers=4.1 for the mount.
I'm missing something obvious, but the only thing obvious to me is that I can't see it.
Any help is greatly appreciated.
Cheers, Zube
Is anyone running any Areca RAID controllers with the latest CentOS 7 kernel, 3.10.0-693.2.2.el7.x86_64? We recently updated (from 3.10.0-514.26.2.el7.x86_64), and we’ve started having lots of problems. To add to the confusion, there’s also a hardware problem (either with the controller or the backplane most likely) that we’re in the process of analyzing. Regardless, we have an ARC1883i, and with the older kernel the system is stable, but with the new kernel it locks up within 1-12 hours of boot, with errors in /var/log/messages that start with things like kernel: arcmsr0: abort device command of scsi id = 0 lun = 0 (that is indeed the RAID scsi device) and within a few minutes of those also things like Oct 19 23:06:57 radon kernel: INFO: task xfsaild/dm-9:913 blocked for more than 120 seconds. Oct 19 23:06:57 radon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 19 23:06:57 radon kernel: xfsaild/dm-9 D ffff88103eaa2000 0 913 2 0x00000080 Oct 19 23:06:57 radon kernel: ffff881033f67d48 0000000000000046 ffff88102f7c4f10 ffff881033f67fd8 Oct 19 23:06:57 radon kernel: ffff881033f67fd8 ffff881033f67fd8 ffff88102f7c4f10 ffff88103ada5300 Oct 19 23:06:57 radon kernel: 0000000000000000 ffff88102f7c4f10 ffff88103afe4528 ffff88103eaa2000 Oct 19 23:06:57 radon kernel: Call Trace: Oct 19 23:06:57 radon kernel: [<ffffffff816a94e9>] schedule+0x29/0x70 Oct 19 23:06:57 radon kernel: [<ffffffffc04d1d16>] _xfs_log_force+0x1c6/0x2c0 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffff810c4810>] ? wake_up_state+0x20/0x20 Oct 19 23:06:57 radon kernel: [<ffffffffc04ddb9c>] ? xfsaild+0x16c/0x6f0 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffffc04d1e3c>] xfs_log_force+0x2c/0x70 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffffc04dda30>] ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffffc04ddb9c>] xfsaild+0x16c/0x6f0 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffffc04dda30>] ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs] Oct 19 23:06:57 radon kernel: [<ffffffff810b098f>] kthread+0xcf/0xe0 Oct 19 23:06:57 radon kernel: [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40 Oct 19 23:06:57 radon kernel: [<ffffffff816b4f58>] ret_from_fork+0x58/0x90 Oct 19 23:06:57 radon kernel: [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40 Oct 19 23:06:57 radon kernel: INFO: task nfsd:1604 blocked for more than 120 seconds. Eventually the system locks up completely.
Has anyone seen anything like this with these controllers and the latest kernel, or have any ideas of what to look for?
thanks, Noam
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Noam Bernstein Sent: Sunday, October 22, 2017 8:54 AM To: CentOS mailing list centos@centos.org Subject: [CentOS] Areca RAID controller on latest CentOS 7 (1708 i.e. RHEL 7.4) kernel 3.10.0-693.2.2.el7.x86_64
Is anyone running any Areca RAID controllers with the latest CentOS 7 kernel, 3.10.0-693.2.2.el7.x86_64? We recently updated (from 3.10.0- 514.26.2.el7.x86_64), and we’ve started having lots of problems. To add to the confusion, there’s also a hardware problem (either with the controller or the backplane most likely) that we’re in the process of analyzing. Regardless, we have an ARC1883i, and with the older kernel the system is stable, but with the new kernel it locks up within 1-12 hours of boot, with errors in /var/log/messages that start with things like kernel: arcmsr0: abort device command of scsi id = 0 lun = 0 (that is indeed the RAID scsi device) and within a few minutes of those also things like Oct 19 23:06:57 radon kernel: INFO: task xfsaild/dm-9:913 blocked for more than 120 seconds.
You mention you have hardware problems, what are they? A write is blocked for longer than they host is willing to wait. There are a few sysctl parameters that affect this but I'd be more willing to suggest its related to your hardware problems.
jlc
On Oct 22, 2017, at 4:35 PM, Joseph L. Casale jcasale@activenetwerx.com wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Noam Bernstein Sent: Sunday, October 22, 2017 8:54 AM To: CentOS mailing list centos@centos.org Subject: [CentOS] Areca RAID controller on latest CentOS 7 (1708 i.e. RHEL 7.4) kernel 3.10.0-693.2.2.el7.x86_64
Is anyone running any Areca RAID controllers with the latest CentOS 7 kernel, 3.10.0-693.2.2.el7.x86_64? We recently updated (from 3.10.0- 514.26.2.el7.x86_64), and we’ve started having lots of problems. To add to the confusion, there’s also a hardware problem (either with the controller or the backplane most likely) that we’re in the process of analyzing. Regardless, we have an ARC1883i, and with the older kernel the system is stable, but with the new kernel it locks up within 1-12 hours of boot, with errors in /var/log/messages that start with things like kernel: arcmsr0: abort device command of scsi id = 0 lun = 0 (that is indeed the RAID scsi device) and within a few minutes of those also things like Oct 19 23:06:57 radon kernel: INFO: task xfsaild/dm-9:913 blocked for more than 120 seconds.
You mention you have hardware problems, what are they?
They’re weird is what they are. There’s one slot that’s apparently bad. It was first showing a failed disk (in the web interface, e.g.), but the disk is apparently fine (as checked by putting in other known good disks into that slot, and putting that disk into other slots or into a different machine), and is currently listed as a hot spare, so it’s not actually being accessed. Now that slot has apparently spontaneously fixed itself, in so far as it is showing as a working disk. However, the lights that flash as it scans through the slots on boot clearly behave differently for that slot than all the others (~1 s red flash in the second scan, instead of more like 0.25 s) , so I don’t believe that it’s really fixed. But so far as a I can tell when that slot is empty the array behaves normally, except for these errors with the new kernel only.
A write is blocked for longer than they host is willing to wait. There are a few sysctl parameters that affect this but I'd be more willing to suggest its related to your hardware problems.
As I said, these errors only show up with the latest kernel, so while I agree in principle that it makes sense for it to be related to the hardware problem, it has to be interacting with the kernel somehow as well.
Noam
____________ || |U.S. NAVAL| |_RESEARCH_| LABORATORY Noam Bernstein, Ph.D. Center for Materials Physics and Technology U.S. Naval Research Laboratory T +1 202 404 8628 F +1 202 404 7546 https://www.nrl.navy.mil https://www.nrl.navy.mil/
On Sun, October 22, 2017 3:35 pm, Joseph L. Casale wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Noam Bernstein Sent: Sunday, October 22, 2017 8:54 AM To: CentOS mailing list centos@centos.org Subject: [CentOS] Areca RAID controller on latest CentOS 7 (1708 i.e. RHEL 7.4) kernel 3.10.0-693.2.2.el7.x86_64
Is anyone running any Areca RAID controllers with the latest CentOS 7
kernel,
3.10.0-693.2.2.el7.x86_64? We recently updated (from 3.10.0- 514.26.2.el7.x86_64), and weâve started having lots of problems. To
I run CentOS 7 fully updated, latest; kernel 3.10.0-693.2.2.el7.x86_64 on the machine that has a couple of Areca F/W V1.47 2009-07-16 & Model ARC-1680 Driver Version 1.20.00.15 2010/08/05
(these host three large RAID-6's), system lives on a mirror behind similar controller. No problems whatsoever.
Just a data point.
Valeri
add to the confusion, thereâs also a hardware problem (either with the
controller or
the backplane most likely) that weâre in the process of analyzing.
Regardless,
we have an ARC1883i, and with the older kernel the system is stable, but with the new kernel it locks up within 1-12 hours of boot, with errors in /var/log/messages that start with things like kernel: arcmsr0: abort device command of scsi id = 0 lun = 0 (that is indeed the RAID scsi device) and within a few minutes of those
also
things like Oct 19 23:06:57 radon kernel: INFO: task xfsaild/dm-9:913 blocked for more than 120 seconds.
You mention you have hardware problems, what are they? A write is
blocked
for longer than they host is willing to wait. There are a few sysctl
parameters
that affect this but I'd be more willing to suggest its related to your
hardware
problems.
jlc
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
-
Joseph L. Casale -
Noam Bernstein -
Valeri Galtsev -
Zube