Unsolved
This post is more than 5 years old
9 Posts
0
1002
Does changing acl... params for data migration impact performance ?
Hi everybody,
I'm wondering if I should set the recommended DM parameters during data migrations permanently or if this might slow down performance during normal operation :
$ server_param server_2 -f cifs -m acl.mappingErrorAction -v 3 (default is 0)
$ server_param server_2 -f cifs -m acl.retryAuthSid -v 600 (default is 10)
$ server_param server_2 -f cifs -m acl.FailOnSDRestoreError -v 0 (
The recommendation says that these params should be set for data migration only. However we do data migrations every weekend and move everything older than 1 year to other shares (i.e. based on SATA-disk). Of course this data is not as big as migrating a whole filesystem with hundreds of gigabytes but I'm not sure if I should set the above params permanently and if this would affect cifs performance.
Anyone an idea or suggestion ?
Thanks in advance
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
1
October 31st, 2012 06:00
I left mine in place after numerous windows to celerra migrations, cant tell any difference in terms of performance.
Sent from my Verizon Wireless 4G LTE DROID
Rainer_EMC
8.6K Posts
0
October 31st, 2012 07:00
It is not a performance impact – rather a functionality question
The defaults are there to prevent unresolvable SID’s stored on the system.
Data migration is merely a time when you are very likely to discover unresolvable SIDs.
There can be different reasons why a SID is unresolvable – it could be that the user was deleted but it could also be that the domain controller
we are talking to hasn’t gotten the information replicated from the DC where a new user was created on.
It could also be a config problem – like a missing / not working trust between domains.
The reasoning for the defaults is that without a resolvable SID we cannot do some functionality like user mapping or quotas or others.
So with the defaults we send an error - which gives you an indication and a chance to fix it.
Without it can happen that you copy or restore files and don’t realize that they have an incorrect owner and permissions.
The retry count is there to cater for environments with slower or off-site domain controllers.
Temporarily lowering it for data migration helps improve performance because you get the error earlier and we don’t spend time asking.
So you need to make an informed decision what is suitable for your environment.
lulli1
9 Posts
0
October 31st, 2012 09:00
Thank you Rainer for your detailed information.
But what about eventually unrecognized SIDs after the migration is done? It sounds like having to run an ACL-check tool like emcacl or things like that is mandatory to fix possible problems with unresolved SIDs, because during migration I did not get error messages and migration still goes on, right?
We are running file virtualization appliances from F5 called acopia (ARX4000) which do nearly all of the migrations, the weekly ones for data older than 1 year and the ones between differnt NAS systems (no windows source involved).
As the migration is transparent for the end-user (shares stay online all the time) wouldn't it be better to leave the params on default and if needed run an ACL-check tool against eventually remaining data on the source share ? I think the appliance would try endless to move data, there would only be a growing log file on it with the same errors.
The other option would be to run the ACL-check tool everytime BEFORE starting a migration (regardless which way) on th source filesystem/share to ensure all security information and SIDs are correct.
Would you agree with that? What would you suggest?
Rainer_EMC
8.6K Posts
1
October 31st, 2012 10:00
That is your choice and you need to evaluate what works for your environment
Our preference is to fix unresolvable SIDs before migration.
There are customers though that happily live with unresolvable SIDs where they know the reason – i.e. user was deleted.
Others customer have the policy to never delete a user from the AD – just disable and rename it so that they still have a track record of ownership