1 |
Am 01.10.2010 18:23, schrieb Volker Armin Hemmann: |
2 |
> On Friday 01 October 2010, Florian Philipp wrote: |
3 |
>> Am 01.10.2010 03:12, schrieb Adam Carter: |
4 |
>>> Your harddisk seeks, everything is slow. |
5 |
>>> |
6 |
>>> So does that then mean that my options are; |
7 |
>>> 1. Defragment, so there is less seeking |
8 |
>>> 2. Get an SSD |
9 |
>>> |
10 |
>>> Since 2 is too expensive for a decent size drive, is there anything i |
11 |
>>> can do about 1 without a backup and restore operation? Or will the |
12 |
>>> fragmentation be very small on reiser3 anyway (i mount with notail) so I |
13 |
>>> should just accept things as they are. |
14 |
>> |
15 |
>> To prevent fragmentation, try to always keep a decent amount of free |
16 |
>> space on each partition. That way, the FS driver can allocate space for |
17 |
>> new files without too much fragmentation (a fragment every 2 MB or so |
18 |
>> doesn't really hurt performance). |
19 |
> |
20 |
> you obviously never used a tape drive... |
21 |
> |
22 |
> |
23 |
|
24 |
Hehe, yep. :) |
25 |
|
26 |
While we're at the topic, we can do some basic math to show how bad |
27 |
fragmentation is. |
28 |
|
29 |
Symbols: |
30 |
|
31 |
s [MB]: total size |
32 |
t_f [s]: total read/write time with fragmentation |
33 |
t_nf [s]: total read/write time without fragmentation |
34 |
t_s [s]: seek time |
35 |
v [MB/s]: sequential throughput |
36 |
n [-]: number of fragments |
37 |
f [1/MB]: fragmentation (fragments per MB) |
38 |
e [-]: effectiveness (percentage) |
39 |
|
40 |
Assumptions: |
41 |
|
42 |
1. Seek time is constant. For HDDs we can take an average value. Of |
43 |
course this doesn't work for tapes. They have a seek time which |
44 |
increases linearly with the distance between the fragments. |
45 |
|
46 |
2. Throughput is constant. As I've stated in another post this is not |
47 |
true for HDDs but we can again take an average value. |
48 |
|
49 |
Formulas: |
50 |
|
51 |
s = v * t_nf //without fragmentation |
52 |
s = v * (t_f - n*t_s) //with fragmentation |
53 |
|
54 |
s = v*t_f - v*n*t_s |
55 |
t_f = (s + v*n*t_s)/v |
56 |
Without fragmentation we would have |
57 |
t_nf = s/v |
58 |
|
59 |
Now we can normalize the time to get the effectiveness |
60 |
e = t_nf / t_f |
61 |
e = s/v * v/(s * v*n*t_s) |
62 |
e = s/(s * v*n*t_s) |
63 |
e = 1/(n/s * t_s * v + 1) |
64 |
|
65 |
Nearly done. n/s is the fragmentation. Therefore we get: |
66 |
f = n/s |
67 |
e = 1/(f * t_s * v + 1) |
68 |
|
69 |
Great. Now we're done. |
70 |
For laptop HDDs I think a seek time of 12 ms (Wikipedia says so) and an |
71 |
average throughput of 50 MB/s are good values. |
72 |
When we plot effectiveness against fragmentation, we see that with one |
73 |
fragment every two MB we get around 77% effectiveness whereas with two |
74 |
two fragments every MB we already drop to 45%. Worst case would be one |
75 |
fragment per file system block. With 4kB blocks that's 256 fragments per |
76 |
MB. That means we drop to 0.65% effectiveness. |
77 |
|
78 |
The values seem drastic but are plausible: 50 MB/s sequential throughput |
79 |
and 12 ms seek time mean that in the time we need to do one seek |
80 |
operation, we could read 50*12e-3 = 0.6 MB. |
81 |
|
82 |
Hope this helps, |
83 |
Florian Philipp |