Am 01.10.2010 18:23, schrieb Volker Armin Hemmann: > On Friday 01 October 2010, Florian Philipp wrote: >> Am 01.10.2010 03:12, schrieb Adam Carter: >>> Your harddisk seeks, everything is slow. >>> >>> So does that then mean that my options are; >>> 1. Defragment, so there is less seeking >>> 2. Get an SSD >>> >>> Since 2 is too expensive for a decent size drive, is there anything i >>> can do about 1 without a backup and restore operation? Or will the >>> fragmentation be very small on reiser3 anyway (i mount with notail) so I >>> should just accept things as they are. >> >> To prevent fragmentation, try to always keep a decent amount of free >> space on each partition. That way, the FS driver can allocate space for >> new files without too much fragmentation (a fragment every 2 MB or so >> doesn't really hurt performance). > > you obviously never used a tape drive... > >
Hehe, yep. :) While we're at the topic, we can do some basic math to show how bad fragmentation is. Symbols: s [MB]: total size t_f [s]: total read/write time with fragmentation t_nf [s]: total read/write time without fragmentation t_s [s]: seek time v [MB/s]: sequential throughput n [-]: number of fragments f [1/MB]: fragmentation (fragments per MB) e [-]: effectiveness (percentage) Assumptions: 1. Seek time is constant. For HDDs we can take an average value. Of course this doesn't work for tapes. They have a seek time which increases linearly with the distance between the fragments. 2. Throughput is constant. As I've stated in another post this is not true for HDDs but we can again take an average value. Formulas: s = v * t_nf //without fragmentation s = v * (t_f - n*t_s) //with fragmentation s = v*t_f - v*n*t_s t_f = (s + v*n*t_s)/v Without fragmentation we would have t_nf = s/v Now we can normalize the time to get the effectiveness e = t_nf / t_f e = s/v * v/(s * v*n*t_s) e = s/(s * v*n*t_s) e = 1/(n/s * t_s * v + 1) Nearly done. n/s is the fragmentation. Therefore we get: f = n/s e = 1/(f * t_s * v + 1) Great. Now we're done. For laptop HDDs I think a seek time of 12 ms (Wikipedia says so) and an average throughput of 50 MB/s are good values. When we plot effectiveness against fragmentation, we see that with one fragment every two MB we get around 77% effectiveness whereas with two two fragments every MB we already drop to 45%. Worst case would be one fragment per file system block. With 4kB blocks that's 256 fragments per MB. That means we drop to 0.65% effectiveness. The values seem drastic but are plausible: 50 MB/s sequential throughput and 12 ms seek time mean that in the time we need to do one seek operation, we could read 50*12e-3 = 0.6 MB. Hope this helps, Florian Philipp
signature.asc
Description: OpenPGP digital signature
