[gpfsug-discuss] SMB quotas query

[Sobey, Richard A]

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/rootsmb/fileset1
Fileset2: /gpfs/rootsmb/fileset2

The CES export is /gpfs/rootsmb and the name of the share is (for example) “share”. All our filesets have block quotas applied to them with the hard and soft limit being the same. Customers then map drives to these filesets using the following path:

\\ces-cluster\share\fileset1<file://ces-cluster/share/fileset1>
\\ces-cluster\share\fileset2<file://ces-cluster/share/fileset2>
…fileset400

Some customers have one drive mapping only, others have two or more. For the customers that map two or more drives, the quota that Windows reports is identical for each fileset, and is usually for the last fileset that gets mapped. I do not believe this has always been the case: our customers have only recently (since the New Year at least) started complaining in the three+ years we’ve been running GPFS.

In my test cluster I’ve tried rolling back to 4.2.3-2 which we were running last Summer and I can easily reproduce the problem.

So a couple of questions:


  1.  Am I right to think that since GPFS is actually exposing the quota of a fileset over SMB then each fileset mapped as a drive in the manner above *should* each report the correct quota?
  2.  Does anyone else see the same behaviour?
  3.  There is suspicion this could be recent changes from a Microsoft Update and I’m not ruling that out just yet. Ok so that’s not a question 😊

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!

Thanks
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180514/dfd1ac04/attachment-0001.htm>