Ryan,
The vulnerability affects base GPFS, and all client and server nodes will need to be updated fix this vulnerability.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
Barry,
At least from the development point of view, the fix should have very minimal impact. ("none", based on the nature of the code change itself)
Felipe
----Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 1260
at this point. Though the development team is unaware of how this vulnerability can be exploited in practice, it does not mean that such exploitation is infeasible.
The fix itself is simple and should pose a very small risk of breakage.
Regards,
Felipe
Felipe Knop k...@us.ibm.comGPFS
workaround mentioned is not "actionable" . The APAR page should have been clear that there is a fix available.
Regards,
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original
Ray,
I wonder if you are hitting the problem which was fixed on the following APAR:
https://www.ibm.com/support/pages/apar/IJ28891
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293
Joe,
The message below indicates that your node has more CPUs than what have been validated with. Please open a PMR for the problem.
This issue should not be sporadic: the error is detected based on the number of CPUs configured on the node.
Thanks,
Felipe
Felipe Knop k
blocks changed from only 32. Does it still hold true that unused data replica’s use metadata space with v5?
The same remains true for v5 file systems with more than 32 subblocks per block.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 Sou
is invoked.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Ryan Novosielski Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main
.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Jaime Pinto Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug-discuss
fected how the nodes are reported. After the cluster is configured, DNS does not play a significant role in nodes joining or being expelled from the cluster.
Felipe
----Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 43
being introduced in 5.0.5 are not present in 5.0.4.4).
As you indicate, the decision on 7.8 on 5.0.4.4 has not been made yet. If a decision is made to backport the 7.8 changes to 5.0.4.4, that would take place via an efix.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM
Spectrum Scale V4.2.0.0 through V4.2.3.20, reference APAR IJ23426
"V5.0.0.0 through V5.0.4.1" should have been "V5.0.0.0 through V5.0.4.2". (I have asked the text to be corrected)
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Build
for the fix.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Lukas Hejtmanek Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion
problems.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Lukas Hejtmanek Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main
Laurence,
The problem affects all the Scale releases / PTFs.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: "Schuler, Laurence (GSFC-
] [] cxiPruneDCacheEntry+0x13a/0x1c0 [mmfslinux][1224278.498798] [] _ZN10gpfsNode_t16invalidateOSNodeEPS_Pvij+0x108/0x350 [mmfs26]
RHEL 7.8 is also impacted by the same problem, but validation of Scale with 7.8 is still under way.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM
xStatCache could be increased to (say) 300, at a cost of 1.4GB. But maxFilesToCache = 300 uses up to 27GB. The next questions are then
1) Can such memory become available on the node, given the pagepool size ?
2) Does the workload require caching that many files?
Felipe
----Fel
Fred, George,
An update from 3.5 to 4.2 is supported, but it requires the entire cluster to be shut down during the update. (since the update goes across two major releases)
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd
ported for both rhel6 servers and clients?
5.0 is not supported on RHEL 6, for either NSD clients or servers.
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original m
retrieve keys independently from mmfsd would be useful capability to have. Could you submit an RFE to request such function?
Thanks,
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
Heiner,
Apologies for the delay. I have consulted with a colleague, who confirmed that log recovery is not triggered on a clean mmshutdown or mmumount -- since the file system activities from the node are completed, thus no longer requiring any log replay.
Felipe
Felipe Knop k
rect value of SECURITY_INODE_INIT_SECURITY() . And that led to the crash.
The problem did not happen when mmbuildgpl was used since the correct value of LINUX_KERNEL_VERSION_VERBOSE was then set up.
Felipe
----Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughk
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Ryan Novosielski Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: "gpfsug-discuss@spectrumscal
nel module
Felipe
----Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Ryan Novosielski Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discu
,
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: "Popescu, Razvan" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: Kuei-Yu Wa
accepting connections from nodes running below 4.2 .
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd, Poughkeepsie, NY 12601(845) 433-9314 T/L 293-9314
- Original message -From: Luke Raimbach Sent by: gpfsug-discuss-
Rafael,
Changing the value of maxblocksize today does require the entire cluster to be stopped -- this is a current limitation in the product (which we are looking into eliminating).
Felipe
Felipe Knop k...@us.ibm.comGPFS Development and SecurityIBM SystemsIBM Building 0082455 South Rd
Bryan,
Could you open an RFE for this item? We took an initial look at what it
will take to raise this limit and found that it will require an RPC format
change. So it's something that would need to go through a normal release
cycle.
Thanks and regards,
Felipe
Felipe Knop
Andi,
Thank you. At least from the point of view of the change in the kernel
(RHBA-2019:1337) that triggered the compatibility break between the GPFS
kernel module and the kernel, the GPFS efix should work with the newer
kernel.
Felipe
Felipe Knop k
for
both 4.2.3 and 5.0.x . The fix should be included in the upcoming PTFs for
4.2.3 and 5.0.3.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
Kiran,
If SELinux is disabled (SELinux mode set to 'disabled') then the crash
should not happen, and it should be OK to upgrade to (say) 3.10.0-957.21.2
or stay at that level.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM
the mkdir() call.
We are working on an official notification on the issue.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From
Renar,
Thanks. Of the changes below, it appears that
* security: double-free attempted in security_inode_init_security()
(BZ#1702286)
was the one that ended up triggering the problem. Our investigations now
show that RHEL kernels >= 3.10.0-957.19.1 are impacted.
Felipe
----
Felipe K
there. In that
case, rolling back to the prior kernel level (one which has been tested
before) may be advisable.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293
Zach,
This appears to be affecting all Scale versions, including 5.0.2 -- but
only when moving to the new 3.10.0-957.21.2 kernel. (3.10.0-957 is not
impacted)
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building
All,
There have been reported issues (including kernel crashes) on Spectrum
Scale with the latest RHEL7.6 kernel 3.10.0-957.21.2. Please consider
delaying upgrades to this kernel until further information is provided.
Thanks,
Felipe
Felipe Knop k
V5.0.2.3 or |
| | | | later in the 5.0 | later in the 5.0 |
| | | | release| release|
|-+---+---++|
Felipe
Felipe Knop
FS format 'tweak' to
allow GPFS to fix a complex deadlock. (I'm searching for a publication on
that)
Felipe
----
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/
a large FS block
is broken into smaller pieces. On non-GNR environments (when
nsdCksumTraditional is set), the checksum is computed sequentially on the
server.
Felipe
----
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
245
a
problem in mmnetverify itself. (perhaps some aspect in mmnetverify is not
taking into account that ports other than 22, 1191, 6-61000 may be
getting blocked by the firewall)
Could you open a PMR for this one?
Thanks,
Felipe
Felipe Knop k
(they are supposed to
be?), then CentOS 7.5 should work with Scale V5.0.1.1 or later.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: Ty
fragment (subblock)
size in bytes (other pools)
but I do not yet understand how.
The subblocks-per-full-block parameter is not supported with mmcrfs .
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd
KN devices.
Felipe
----
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: Joseph Mendoza
To: gpfsug main discussion list
Date: 06/25/201
Fred,
Correct. The FAQ should be updated shortly.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: "Frederick
Peter, Simon,
While I believe Power9 / RHEL 7.5 will be supported with the upcoming PTFs
on 4.2.3 and 5.0.1 later in June, I'm working on getting confirmation for
that.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM
Simon,
The support statement for Power9 / RHEL 7.4 has not yet been included in
the FAQ, but I understand that a FAQ update is under way:
4.2.3.8 for the 4.2.3 release
5.0.0.0 for the 5.0.0 release
Kernel level tested with: 4.11.0-44.6.1.el7a
Felipe
Felipe Knop
,
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: Andi Rhod Christiansen <a...@b4restore.com>
To: gpfsug main discussion list &
Luis,
Correct.
Jeff: The Spectrum Scale team has been actively working on the support for
RHEL 7.5 . Since code changes will be required, the support will require
upcoming 4.2.3 and 5.0 PTFs. The FAQ will be updated when support for 7.5
becomes available.
Regards,
Felipe
Felipe Knop
sizes' in 'man mmcrfs'.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: "Marc A Kaplan" <makap...@us.ibm.com>
To:
of maxblocksize (which requires the entire cluster to be stopped).
For clusters newly created with 5.0.0, the value of maxblocksize is set to
4MB. See the references to maxblocksize in the mmchconfig and mmcrfs man
pages in 5.0.0 .
Felipe
Felipe Knop k
for the
availability of the fix.
Thanks,
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: Bryan Banister <bbanis...@jumptrading.
Kevin,
The improved rebalance function (mmrestripefs -b) only depends on the
cluster level being (at least) 5.0.0, and will work with older file system
formats as well. This particular improvement did not require a change in
the format/structure of the file system.
Felipe
Felipe Knop
Richard,
I see that 4.2.3-4 efix2 has two defects, 1032655 (IV99796) and 1020461
(IV99675), and both these fixes are included in 4.2.3.5 .
Regards,
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455
Tomasz,
The fix (APAR 1IJ00398) has been included in 4.2.3.5, despite the APAR
number having been omitted from the list of fixes in the PTF.
Regards,
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455
ormation as possible/available on the known triggers and
mitigation circumstances.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
Fro
uot;1403" when the format is v2.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: "Oesterlin, Robert" <rober
sion 4.1.1)?
That is expected to work.
Felipe
----
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: "tomasz.wol...@ts.fujitsu.c
defect number 981469), but that should be fixed in 4.2.1 as well. I have
not seen recent reports of this problem.
Perhaps this could be pursued via a PMR.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
Brian,
This seems to match a problem which was fixed in 4.1.1.7 and 4.2.0.0.
Regards,
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
Otherwise, expel whoever joined the cluster more recently.
The statement below from Dr. Uwe Falke is also correct: addressing the
network connectivity is the better long-term approach, but the callback
script could be used to control which node to expel.
Felipe
Felipe Knop
There is a chance the problem might be related to an upgrade from 3.5 to
4.1, or perhaps a remote mount between versions 3.5 and 4.1. It would be
useful to know details related to any such migration and different
releases when the PMR is opened.
Thanks,
Felipe
Felipe Knop
for the Spectrum
Scale 4.2 publications . The team is working to rectify that.
Felipe
Felipe Knop k...@us.ibm.com
GPFS Development
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
From: "Simon Tho
62 matches
Mail list logo
