Hi all,
I want to run this past the group to see if I’m going mad or not. We do have an
open PMR about the issue which is currently being escalated.
We have 400 independent filesets all linked to a path in the filesystem. The
root of that path is then exported via SMB, e.g.:
Fileset1: /gpfs/ro
Dear All,
Any one has the same problem?
/usr/bin/make -C /usr/src/kernels/3.10.0-862.2.3.el7.x86_64 ARCH=x86_64
M=/usr/lpp/mmfs/src/gpl-linux CONFIGDIR=/usr/lpp/mmfs/src/config ; \
if [ $? -ne 0 ]; then \
exit 1;\
fi
make[2]: Entering directory `/usr/src/kernels/3.10.0-862.2.3.el7.x86
On Mon, 2018-05-14 at 10:09 +, Sobey, Richard A wrote:
[SNIP]
>
> I am worried that IBM may tell us we’re doing it wrong (humm) and to
> create individual exports for each fileset but this will quickly
> become tiresome!
>
Worst case scenario you could fall back to using the dfree option
Hi Folks
IHAC who is reporting pool-metadata_high_error on GUI.
The inode utilisation on filesystem is as below
Used inodes - 92922895
free inodes - 1684812529
allocated - 135424
max inodes - 1911363520
the inode utilization on one fileset (it is only one being used) is below
Used inodes - 9
Hello,
the pool metadata high error reports issues with the free blocks in the
metadataOnly and/or dataAndMetadata NSDs in the system pool.
mmlspool and subsequently the GPFSPool sensor is the source of the
information that is used be the threshold that reports this error.
So please compare wi
The difference in your inode information is presumably because the fileset
you reference is an independent fileset and it has its own inode space
distinct from the indoe space used for the "root" fileset (file system).
Fred
__
Fred Stock | IBM Pitt
Hi,
Yes, kernel 3.10.0-862.2.3.el7 is not supported yet as it is RHEL 7.5 and
latest support is 7.4. You have to revert back to 3.10.0-693 😊
I just had the same issue
Revert to previous working kernel at redhat 7.4 release which is 3.10.9.693.
Make sure kernel-headers and kernel-devel are als
On Mon, May 14, 2018 at 4:48 PM, Markus Rohwedder
wrote:
> Once inodes are allocated I am not aware of a method to de-allocate them.
> This is what the Knowledge Center says:
>
> *"Inodes are allocated when they are used. When a file is deleted, the
> inode is reused, but inodes are never dealloc
Hi,
The GUI behavior is correct.
You can reduce the maximum number of inodes of an inode space, but not
below the allocated inodes level.
See below:
# Setting inode levels to 30 max/ 20 preallocated
[root@cache-11 ~]# mmchfileset gpfs0 root --inode-limit 30:20
Set maxInodes for i
Thanks Jonathan. What I failed to mention in my OP was that MacOS clients DO
report the correct size of each mounted folder. Not sure how that changes
anything except to reinforce the idea that it's Windows at fault.
Richard
-Original Message-
From: gpfsug-discuss-boun...@spectrumscale.
Thanks. Does IBM care about security, one would ask? In this case
I'd choose to use the new kernel for my virtualization over gpfs
... sigh
https://access.redhat.com/errata/RHSA-2018:1318
Kernel: KVM: error in exception handling leads to wrong debug stack
value (CVE-2018-1087)
Kernel: error
You are welcome.
I see your concern but as long as IBM has not released spectrum scale for 7.5
that is their only solution, in regards to them caring about security I would
say yes they do care, but from their point of view either they tell the
customer to upgrade as soon as red hat releases n
On Mon, 2018-05-14 at 11:54 +, Sobey, Richard A wrote:
> Thanks Jonathan. What I failed to mention in my OP was that MacOS
> clients DO report the correct size of each mounted folder. Not sure
> how that changes anything except to reinforce the idea that it's
> Windows at fault.
>
In which ca
All,
Support for RHEL 7.5 and kernel level 3.10.0-862 in Spectrum Scale is
planned for upcoming PTFs on 4.2.3 and 5.0. Since code changes are needed
in Scale to support this kernel level, upgrading to one of those upcoming
PTFs will be required in order to run with that kernel.
Regards,
Felipe
Hi all,
I got myself into a situation where I was trying to enable a default user quota
on a fileset and remove the existing quotas for all users in that fileset. But
I used the `mmsetquota : --user --block 0:0` command and
now it says that I have explicitly set this quota.
Is there a way to
Hi
What is the output of mmlsfs - does you have --filesetdf enabled ?
Regards
Yaron Daniel
94 Em Ha'Moshavot Rd
Storage Architect
Petach Tiqva, 49527
IBM Global Markets, Systems HW Sales
Israel
Phone:
+972-3-916-5672
Fax:
+972-3-916-5672
Mobile:
+972-52-8395593
e-
check out the -d option for the mmedquota command:
"Reestablish default quota limits for a specific user, group, or fileset that
had an explicit quota limit set by a previous invocation of the mmedquota
command.”
--Peter
> On 2018 May 14 Mon, at 22:29, Bryan Banister
> wrote:
>
> Hi all,
>
Try disabling and re-enabling default quotas withthe -d option for that
fileset.
mmdefquotaon command
Activates default quota limit usage.
Synopsis
mmdefquotaon [‐u] [‐g] [‐j] [‐v] [‐d] {Device [Device... ] | ‐a}
or
mmdefquotaon [‐u] [‐g] [‐v] [‐d] {Device:Fileset ... | ‐a}
...
‐d
That is an interesting point. On the protocol level, the client opens a directory and then issues a QUERY_INFO to ask for the available space. In Samba, we then check the available space and applicable quotas on that path and return the requested information.
The main question is probably on whic
Hallo All,
follow some experiences with the update to 5.0.1.0 (from 5.0.0.2) on rhel7.4.
After the complete yum update to this version, we had a non-function yum cmd.
The reason for this is following packet pyOpenSSL-0.14-1.ibm.el7.noarch This
package break the yum cmds.
The error are:
Loaded plu
20 matches
Mail list logo
