Highlighted
ude1
1 Nickel

Changing permissions (metadata performance)

Hi,

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.

Thanks!

Best regards,

ude

Tags (3)
8 Replies
AndrewChung
2 Iron

Re: Changing permissions (metadata performance)

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.

0 Kudos
Peter_Sero
3 Zinc

Re: Changing permissions (metadata performance)

Hi Andrew,

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)?

-- Peter

0 Kudos
osaddict
2 Iron

Re: Changing permissions (metadata performance)

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.

AndrewChung
2 Iron

Re: Changing permissions (metadata performance)

Peter,

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.

Peter_Sero
3 Zinc

Re: Changing permissions (metadata performance)

Andrew, thanks a lot!

0 Kudos
Go.Y
2 Iron

Re: Changing permissions (metadata performance)

FYI

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).

0 Kudos
osaddict
2 Iron

Re: Changing permissions (metadata performance)

If you are adding all SSD S200 nodes just for GNA, I don't believe you need a SmartPools license.

0 Kudos
BernieC2
2 Bronze

Re: Changing permissions (metadata performance)

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.

0 Kudos