Follow up to defrag validity discussion: please read
in [Storage]
|
Prev: Samsung HD753lj external drive- computer does'nt see
Next: Hands-on with the ioSafe Solo external hard drive
From: Rod Speed on 6 Jan 2010 01:30 Cronos wrote: > Ed Light wrote: >> But a very fragmented large file is like a bunch of little files spread all over the place, isn't it? > Yes. Nope, its completely different. A lot of small files needs access to the directory information with ever file, a large fragmented file does not.
From: Rod Speed on 6 Jan 2010 01:29 Cronos wrote > Rod Speed wrote >> You're so stupid that you cant grasp that no one >> but a fool uses real world systems anything like that. > That is not the point. Corse it is. How a system so stupidly used ends up proves absolutely nothing. > The point is that defrag does make a difference and you claim it does not. The real point is that no system ever gets anything like that with real world use. > My Mitsubishi Lancer is not an Evo but I still treat it with the same care and maintenance as if it was an Evo. Completely and utterly irrelevant to whether defragging achieves a damned thing with real world personal desktop systems.
From: Arno on 6 Jan 2010 05:55 Cronos <cronos(a)sphere.invalid> wrote: > David Brown wrote: >> A very fragmented large file is like a single large file, it's just that >> its contents are on different parts of the disk. > Well, duh, that is what he meant and what I meant too. Of course it is > not a file split into many smaller files but it may as well be because > the result is the same. Now you are arguing *semantics* in a poor > attempt to discredit me so take a hike. Not quite: With many smaller files there is at likely one additional disk access for the metadata when a new one is opened, while with one large fragmented file, there should be less than one access per pragment for metadata, at least with a sane OS. The observable difference in access times may depend on the filesystem in question. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: 3877 on 6 Jan 2010 16:03 Ed Light wrote: > I'm playing with the trial of HD Tune. > > Testing the random access on a WD Caviar Blue 640 with AAM fully on. > > I tested using the full 640, then short-strokes of 30 and 1 gig. > > This would represent a file strewn all around, strewn around some, and > strewn around just a little bit. Nope, and says nothing useful about what is being discussed, files which have more than one fragment and what effect that has on the speed of access to that file. > Numbers are: > > transfer size | operations/sec | avg. access time | avg. speed > > Full 640 gigs used: > > 512 bytes 55 IOPS 17 ms 0.027 MB/s > 4 KB 53 18 0.211 > 64 KB 52 19 3.273 > 1 MB 34 28 34.610 > Random 43 23 21.894 > > 30 gigs short stroke: > > 512 bytes 101 IOPS 9.8 ms 0.050 MB/s > 4 KB 101 9.8 0.398 > 64 KB 97 10.0 6.071 > 1 MB 52 18.0 52.802 > Random 69 14.0 35.487 > > 1 gig short stroke: > > 512 bytes 154 IOPS 6.5 ms 0.075 MB/s > 4 KB 160 6.2 0.626 > 64 KB 153 6.5 9.595 > 1 MB 63 15.0 63.378 > Random 86 11.0 43.742 > > > Then I noticed "Extra Test" > > Test | IO | Time | Trasfer > > Full 640 gigs: > > Random seek 55 IOPS 18.3 ms 0.027 MB/s > Butterfly seek 50 19.8 0.025 > Random seek / 64 KB 55 18.0 0.853 > Random seek / 8 MB 16 61.3 66.177 > Sequential read outer 1833 0.5 114.560 > Sequential read middle 1581 0.6 98.806 > Sequential read inner 947 1.1 59.192 > Burst rate 2613 0.4 163.315 > > 30 gig short stroke: > > Random seek 108 IOPS 9.3 ms 0.053 MB/s > Butterfly seek 92 10.8 0.045 > Random seek / 64 KB 97 10.4 1.485 > Random seek / 8 MB 21 47.0 86.280 > Sequential read outer 1833 0.5 114.577 > Sequential read middle 1634 0.6 102.122 > Sequential read inner 1817 0.6 113.569 > Burst rate 2894 0.4 162.118 > > > 1 gig short stroke: > > Random seek 156 IOPS 6.4 ms 0.076 MB/s > Butterfly seek 168 6.0 0.082 > Random seek / 64 KB 138 7.3 2.115 > Random seek / 8 MB 23 43.8 92.514 > Sequential read outer 1833 0.5 114.585 > Sequential read middle 1806 0.6 102.904 > Sequential read inner 1848 0.5 115.521 > Burst rate 2699 0.4 168.704
From: Joep on 7 Jan 2010 03:28
"Arno" <me(a)privacy.net> schreef in bericht news:7qj8ghFb2bU1(a)mid.individual.net... > > Not quite: With many smaller files there is at likely one additional > disk access for the metadata when a new one is opened, At some point while with > one large fragmented file, there should be less than one access per > pragment for metadata, at least with a sane OS. > > The observable difference in access times may depend on the > filesystem in question. > > Arno Joep |