# Disk Defragmenter - How to make it work.

**URL:** <https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877>\
**Category:** Factual Questions\
**Created:** [March 6, 2012, 1:31am UTC](https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877 "2012-03-06T01:31:43Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![Bambro](https://avatars.discourse-cdn.com/v4/letter/b/df705f/32.png) [@Bambro](https://boards.straightdope.com/u/Bambro)\
**Post date:** [March 7, 2012, 9:32pm UTC](https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877/21 "2012-03-07T21:32:49Z")

</div>

> [@dzero](#):
>
> Aren’t there some people who are of the opinion that putting SSD’s in RAID doesn’t result in a performance boost. I never followed the arguments closely, but it seems to me that data striping would have to be beneficial regardless of the media.
> 
> Would you be able to say if the increase is mostly linear - as in 2 drives = twice as fast, 3 ==\> 3x, etc.? I would imagine that at some point you would have to hit a wall, but IDK. Thanks.

I believe it depends on your controller and the I/Ops it can handle. I have had as many as 4 SSDs in the array and it was considerably faster. I also had them running in a 1+0 at one point for testing so I could sustain multiple failures. I removed them and sold the 2 other SSDs as it was just overkill at that point. But at some point you will reach a bottleneck due to the reaching the maximum I/Ops that your controller can handle.

I think it was determined while specing out my SAN at work that the theoretical limit for a spindle was around 150 I/Ops. In order to get the high I/O we required for the databases we spread them across 14 spindles which also left a lot of room for downward growth. Now an SSD is going to have much higher I/Ops than a spindle, but you should still see improvement when adding more drives to the array…and if you have the ability to span controllers then I would expect even higher benchmarks.

---

<div class="post-metadata">

**Author:** ![voltaire](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/voltaire/32/313_2.png) [@voltaire](https://boards.straightdope.com/u/voltaire)\
**Post date:** [March 8, 2012, 3:35am UTC](https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877/22 "2012-03-08T03:35:25Z")

</div>

Besides access speed, another reason to defrag is that when your HD starts to fail and a certain sector dies, that bad sector will tend to affect less things all at once. It’s better to lose one big chunk of data from a limited amount of sources than it is to lose a whole bunch of tiny pieces of data from a whole lot of different sources.

But hopefully you have everything backed up, anyway.

---

<div class="post-metadata">

**Author:** ![Mgalindo13](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@Mgalindo13](https://boards.straightdope.com/u/Mgalindo13)\
**Post date:** [March 9, 2012, 4:31pm UTC](https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877/23 "2012-03-09T16:31:44Z")

</div>

> [@voltaire](#):
>
> Besides access speed, another reason to defrag is that when your HD starts to fail and a certain sector dies, that bad sector will tend to affect less things all at once. It’s better to lose one big chunk of data from a limited amount of sources than it is to lose a whole bunch of tiny pieces of data from a whole lot of different sources.
> 
> But hopefully you have everything backed up, anyway.

Excellent point!

[Previous page](https://boards.straightdope.com/t/disk-defragmenter-how-to-make-it-work/614877.md?page=1)