1 |
On Saturday 02 October 2010, Florian Philipp wrote: |
2 |
> Am 01.10.2010 18:23, schrieb Volker Armin Hemmann: |
3 |
> > On Friday 01 October 2010, Florian Philipp wrote: |
4 |
> >> Am 01.10.2010 03:12, schrieb Adam Carter: |
5 |
> >>> Your harddisk seeks, everything is slow. |
6 |
> >>> |
7 |
> >>> So does that then mean that my options are; |
8 |
> >>> 1. Defragment, so there is less seeking |
9 |
> >>> 2. Get an SSD |
10 |
> >>> |
11 |
> >>> Since 2 is too expensive for a decent size drive, is there anything i |
12 |
> >>> can do about 1 without a backup and restore operation? Or will the |
13 |
> >>> fragmentation be very small on reiser3 anyway (i mount with notail) so |
14 |
> >>> I should just accept things as they are. |
15 |
> >> |
16 |
> >> To prevent fragmentation, try to always keep a decent amount of free |
17 |
> >> space on each partition. That way, the FS driver can allocate space for |
18 |
> >> new files without too much fragmentation (a fragment every 2 MB or so |
19 |
> >> doesn't really hurt performance). |
20 |
> > |
21 |
> > you obviously never used a tape drive... |
22 |
> |
23 |
> Hehe, yep. :) |
24 |
> |
25 |
> While we're at the topic, we can do some basic math to show how bad |
26 |
> fragmentation is. |
27 |
> |
28 |
> Symbols: |
29 |
> |
30 |
> s [MB]: total size |
31 |
> t_f [s]: total read/write time with fragmentation |
32 |
> t_nf [s]: total read/write time without fragmentation |
33 |
> t_s [s]: seek time |
34 |
> v [MB/s]: sequential throughput |
35 |
> n [-]: number of fragments |
36 |
> f [1/MB]: fragmentation (fragments per MB) |
37 |
> e [-]: effectiveness (percentage) |
38 |
> |
39 |
> Assumptions: |
40 |
> |
41 |
> 1. Seek time is constant. For HDDs we can take an average value. Of |
42 |
> course this doesn't work for tapes. They have a seek time which |
43 |
> increases linearly with the distance between the fragments. |
44 |
|
45 |
I think you misunderstood my remark. |
46 |
|
47 |
Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed. |
48 |
Slow, isn't it? |
49 |
|
50 |
But when you do a backup on such an old tape even with a modern harddisk you |
51 |
have problems keeping it streaming. As soon as you hit a directory with many |
52 |
small files - like ~/Mail or /usr/portage you are screwed. |
53 |
|
54 |
Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single |
55 |
small file. But when you have houndreds, thousands or hundreds of thousands of |
56 |
small files, harddisks suck. |
57 |
And your tape drive has to stop and rewind every couple of seconds because |
58 |
your harddisks were not able to keep up the required 10mb/sec. Trueley |
59 |
pathetic. |
60 |
|
61 |
Besides, seek times are not constant ;) |