We have an issue with a client that when he tries to change permissions it takes about 5 days to complete.
I know, nobody should ever change permissions from a root folder with more than 1 million subfolders but now the client thinks that the cluster is not performing well.
We saw in the analysis that the customer had path name length with more than 1180 characters I guess this would slow down the process also.
My question is, would an SSD upgrade (use it as metadata accelerator) help with the performance of changing permissions and if so by how much approximately?
Their setup currently: 3x X200 Nodes with 3 TB disks no SSD currently.
Adding SSD may help. It depends on which version of OneFS the client is running. If they are on OneFS 7 then having SSD and having the metadata acceleration policy be read and write will help. If you are on OneFS 6.5 you would need engineering approval to enable the metadata write on SSD. In normal circumstances, if you are on OneFS 6.5 or you only have metadata read acceleration, SSD will not help with a permission change.
The reason is that for metadata read acceleration, an additional inode copy is saved to the SSDs. However this is only a cache of what is on spinning disk. When you do a metadata modify, you would have to go to spinning disk to write the data and then update the cache in SSD. With metadata read and write, you put ALL copies of the inodes on SSD so all reads and writes would be accelerated.
6.5 has the read-acceleration and the data-on-SSD options.
I had previously assumed the data-on-SSD would simply
include metadata in this context, as one would have
with an all-SSD cluster. But it seems it's either metadata
OR data, never both, is that correct (for 6.5)? Can you also
re-confirm that with 6.5 read/write metadata acceleration
is technically possible (and is there a certain keyword, comparable
to "GNA", that needs to be mentioned)?
Besides going to SSDs, I would look at the PermissionRepair Job when changing permissions on a lot of files.
You can point the job to a template directory with the exact permssions you want on your files and then apply it to a path.
The advantage here is that is going from a single client, via a single thread, walking the file system and change permissions all over the wire to a parallel process that runs on the cluster using all the nodes to do the work locally. Should be many times faster.
You can have both metadata AND data on SSD in 6.5 The metadata in this case is a read-only copy of the metadata. Metadata read/write is possible on 6.5. It's not something that a customer should enable on their own. I stress again that there needs to be engineering approval here for this in 6.5. If you really need it you can open a case and get it worked through support.
You need to add at least 3 SSD nodes to the cluster to enable GNA.
You will also need SmartPools license for all the nodes(at least 6 in minimum in your case).
All-SSD nodes do need to have a SmartPools license. Otherwise, data and metadata will end up on those nodes, potentially filling them up. This is something I have seen on a couple of clusters in the wild.