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

Disk fragmentation

Why does Sophos AU cause so much fragmentation?

Each minor update downloads but a few KB however every time there's something to do, the entire SAV package is copied (that's > 70Mb's), the new IDE is then integrated and then this entire package is copied back again. This huge > 140MB copy which occurs several times a day is destroying small disk partitions causing machines to grind to a halt during the update cycle.

I'm pretty sure we've all experienced this slowdown and it's time to start making Sophos aware of this so we get a change. It makes no sense at all to copy the entire installation folder each time there's an update. It makes no sense to copy it again once the IDE's added. The process should happen in-place i.e.. checksum the install folder and integrate the update directly. Don't copy the folder. This way, we dramatically reduce fragmentation and speed up the whole update process.

I've got users with typically < 60% disk usage so 'ideal' and plenty of RAM. Give them 3 weeks and the machine always says 'you should defragment this volume' and it's always because the Sophos updates. Anyone else out there have users groaning every five minutes that they can't look at the screen at the moment 'cause Sophos is updating. Now you know why!

Matt

:1720


This thread was automatically locked due to age.
Parents
  • Thanks for the feedback. We've been looking at the copying issue to improve overall updating performance. Disk fragmentation isn't something we've analysed in detail, but cutting down on the copies should help with this.

    I'll try to find out where we've got to with this.

    Cheers,

    John Reynolds

    :1754
Reply
  • Thanks for the feedback. We've been looking at the copying issue to improve overall updating performance. Disk fragmentation isn't something we've analysed in detail, but cutting down on the copies should help with this.

    I'll try to find out where we've got to with this.

    Cheers,

    John Reynolds

    :1754
Children
No Data