Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 1734 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos File Server IO load and shortcut behavior

anomaly

Hi,

I just wanted to let you guys know about some weird behavior I have noticed with SAV.  My apologies if this has been brought up before.

A little while ago I was investigating some of the IO behavior on our main file server, and noticed that SAV was responsible for quite a bit of our IO, see the following picture:

file server io load

(We didn't test this just once, we did several times, and we found this to occur both in older and the current version of SAV).

While investigating, I turned on Process Monitor to see just what Sophos was doing, and I noticed a lot of instances where Sophos would attempt to read files that could not possibly exist -- for example I'd notice Sophos attempt to read E:\somepresentation.pptx when our file server had no E:\ drive.

I managed to figure out that whenever a read operation on a shortcut file occurs, Sophos scans not only the .LNK file being accessed, but actually attempts to read the target of the shortcut as well.  Therefore, whenever a user with a roaming profile logged in and consequently transferred his/her roaming profile off of the server, every single .LNK file in the user's recent directory had Sophos running and looking for a file that (likely) did not exist (at least away from the client machine).

Long story short, we ended up adding exclusions to our global Sophos policy for .LNK files (after all, the targetted file should be scanned by SAV when it is inevitably read), INI files (I noticed a lot of scans of desktop.ini files), and we also added a user logoff script to prune a user's recent directory to items created within the last few weeks (some users had accumulated thousands of these shortcuts).

After that, our IO load barely ever exceeded the post-dropoff level in the picture posted above -- rather annoying that Sophos would account for nearly 80% of the total IO load on the server  =/

Of course, my environment isn't yours and YMMV, but I just thought I'd share in case anyone else is having similar issues.

Regards,

Tom

PS, to any Sophos people in here, any reason that .LNK scanning is done in such a way?  The target file will inevitably be scanned anyways, and this opens up the potential for some mischief -- i.e. if I control a directory on a server with Sophos, I could generate a few thousand LNK files (possibly to files that would be large and known to exist)  and read them over and over and somewhat DOS the server.

:20799


This thread was automatically locked due to age.
  • 0

    Hi Tom,

    Thanks for the post - very interesting and something I'm going to investigate on my systems.

    Can I ask which tool you are using to produce your data and chart?

    Also, the issue with the build-up of .lnk files in profiles, can you let me know how you managed that - did you call something like robocopy to move files x days old out of the profile folder?

    Regards,

    Rich

    :21041
  • 0

    Rich,

    I used a variety of tools to investigate this particular problem -- for my more specific point in time analysis of what Sophos was doing, I used Process Monitor (free) from sysinternals -- this allowed me to see what exact file read calls Sophos was making.

    In addition, I used the Windows Performance Toolkit (namely xperf) to track aggregate file IO by process (this kit can do some amazing things if you want to characterize your performance, and can make some great graphs).

    For the graph above, I simply used Cacti, an open source server monitoring/graphing solution -- it's essentially just polling my servers via WMI every 5 minutes and recording that datapoint.

    For the .lnk files, I created a group policy logoff script consisting of:

    Script Name:  forfiles.exe

    Args: -p"%USERPROFILE%\Recent" -s -m*.lnk -d-14 -c"cmd /c del /s /q 0x22@PATH\@FILE0x22"

    (forfiles.exe is readily available on the internet and just needs to be dumped into the 'show files' section of the GP script)

    Regards,

    Tom

    :21247