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
  • Hello Matt,

    didn't notice the behaviour you describe and therefore I've never checked what is copied and what not - but I'd say it's very unlikely that this is "normal" behaviour: I have a laptop which recently had free space as low as 150MB and Sophos was updating without problems. But maybe you are right and I just have been lucky.

    Taking nothing for granted I checked the file creation dates (if they are a valid indicator of a fresh copy) in the Sophos Anti-Virus folder and - surprise! - found that 112 IDEs (from adloa-lu.ide to bredo-ab.ide) had been (re-)created in the last update cycle. The dates in the autoupdate cache though were correct (i.e. as expected). As I'm checking it gets even more obscure: on several clients 112 IDEs (either the same or all but adloa-lu.ide instead of which the most recent dwnl-lbn.ide is in the list) have been recreated in one of today's update cycles and one has re-written all except adloa-lu.ide. Just as I'm writing this the numbers are rising (adloa-lu.ide and one or two next in the alphabet joined the pack).  The management servers are not affected.

    Don't ask me for an explanation (The Observer Creates Reality Simply By Observing?).  

    Christian

    :1738
Reply
  • Hello Matt,

    didn't notice the behaviour you describe and therefore I've never checked what is copied and what not - but I'd say it's very unlikely that this is "normal" behaviour: I have a laptop which recently had free space as low as 150MB and Sophos was updating without problems. But maybe you are right and I just have been lucky.

    Taking nothing for granted I checked the file creation dates (if they are a valid indicator of a fresh copy) in the Sophos Anti-Virus folder and - surprise! - found that 112 IDEs (from adloa-lu.ide to bredo-ab.ide) had been (re-)created in the last update cycle. The dates in the autoupdate cache though were correct (i.e. as expected). As I'm checking it gets even more obscure: on several clients 112 IDEs (either the same or all but adloa-lu.ide instead of which the most recent dwnl-lbn.ide is in the list) have been recreated in one of today's update cycles and one has re-written all except adloa-lu.ide. Just as I'm writing this the numbers are rising (adloa-lu.ide and one or two next in the alphabet joined the pack).  The management servers are not affected.

    Don't ask me for an explanation (The Observer Creates Reality Simply By Observing?).  

    Christian

    :1738
Children
No Data