There are three topics repeatedly appearing in the forums:
High I/O on files diStRptr.dat and diStRptr.dat.log: http://community.norton.com/t5/Norton-360/Very-High-Disk-Usage-Caused-by-diStRptr-dat-file/td-p/893427
Task "Product Maintenance" fails to complete: http://community.norton.com/t5/Norton-Internet-Security-Norton/Product-Maintenance-Failed-to-complete/td-p/655531
Unable to resolve "stats.qalabs.symantec.com": http://community.norton.com/t5/Norton-for-Mac/failed-requests-on-proxy-to-stats-qalabs-symantec-com/td-p/923055
When analyzing high write to files diStRptr.dat[.log], I've correlated events on affected computer and proxy logs. That computer was always connected to the network, where proxy server is the only possibility to reach HTTP(S) servers. My current experience is that all three problems may be related:
In the proxy logs, there were hundreds of failed requests to stats.qalabs.symantec.com (host not found). Since the HTTP connection to stats server was made always via proxy server (and the DNS lookup failure experienced that proxy server, not the computer running NAV), it seems that intended failover to stats.norton.com (resolvable) never occurred.
So status records were never uploaded and size of diStRptr.dat grew up to 59MB in 4 months (on computers with direct internet connection this file has typically dozens of KBs).
High-volume I/O on file diStRptr.dat was then observed when opening Windows Explorer (Win+E) or opening context menu on files/folders/drives, causing responsiveness delayed up to ten seconds on otherwise idle computer. This was worked around by turning off Norton Community Watch.
Time spans of high I/O on diStRptr.dat[.log] files were also aligned with last run of automanaged task "Product Maintenance", which usually ends with "Failed to complete" status.
Now I forced proxy to resolve "stats.qalabs.symantec.com" to the same IP address as "stats.norton.com" and when Product Maintenance task started, something changed. The I/O is still high, but in the proxy log there are dozens of requests to stats.qalabs.symantec.com with status code 200 and the file diStRptr.dat.log (hope it is something like transaction log for the data file diStRptr.dat) slowly but visibly gets smaller. After few days maybe it will hit the bottom.
Nevertheless, it seems that Symantec is aware of the problem and working on fix: http://www.symantec.com/connect/forums/high-disk-write-distrptrdat
Ondrej