I have written a patch against Folsom, which implement those two fixes.
1) we repeat Refresh request if the monitor finish time returned by DFM was older than our first request. Unfortunately, this introduces a new requirement. Driver host and DFM host should be time synchronized.
2) Instead of running
server.DfmObjectRefresh(.., ChildType='lun_path')
we run
server.DfmObjectRefresh(.., MonitorNames=['file_system', 'lun'])
The former will trigger DFM lun monitor. The later will trigger both file_system and lun monitor. File_system monitor is needed to discover newly created qtree.
> My question is whether it would slow down operations at all in the 85-90% of the time when DFM does the right thing.
I would say it might be slower even if everything works perfectly on DFM side. We trigger two monitors instead of one. Weather they run concurrently, I don't know. Lun monitor seems to be always slower than file_system monitor.
I have written a patch against Folsom, which implement those two fixes.
1) we repeat Refresh request if the monitor finish time returned by DFM was older than our first request. Unfortunately, this introduces a new requirement. Driver host and DFM host should be time synchronized.
2) Instead of running DfmObjectRefres h(.., ChildType= 'lun_path' ) DfmObjectRefres h(.., MonitorNames= ['file_ system' , 'lun'])
server.
we run
server.
The former will trigger DFM lun monitor. The later will trigger both file_system and lun monitor. File_system monitor is needed to discover newly created qtree.
> My question is whether it would slow down operations at all in the 85-90% of the time when DFM does the right thing.
I would say it might be slower even if everything works perfectly on DFM side. We trigger two monitors instead of one. Weather they run concurrently, I don't know. Lun monitor seems to be always slower than file_system monitor.