How Often Disk Defrag

BillW50 wrote:


Paul, I too have HDTune and while it is a nifty utility and all, but it
doesn't test fragmentation! And that is what this thread is all about.

And I have a bunch of SSDs too. And I hear all of the claims and all...
but I am not seeing it. Nor am I seeing a big advantage of defrag hard
drives either.

Yes I know there is a delay while the head needs to move and position
itself to read the next chunk. This sounds really bad and all. But have
you taken a hard drive apart and actually watched it work? You need a
high speed camera to keep up to how fast the head flies around on a
really bad fragmented drive. Even a hummingbird would be impressed.

Okay let's accept that the head movement slows it down for argument
sake. Then how come defragging does little to nothing as far as
improvement? Sure lots talk about how well it does, but virtually nobody
offers any evidence whatsoever that it really does by much. I have done
the tests and at best 2% is the tops I have found. I don't know about
you, but there are lots of things I can do to improve performance way
over 2%. And 2% is not even noticeable to the user (nor would I care)
anyway.

So what I am asking you (or anybody that cares), is that I totally get
the technical side and all (when I was younger, I ate that all up)...
but nowadays I want to see the results just like the average user would.
As if they can't see it, then I am not impressed.


If you want to see the improvement, you can use nfi.exe, which
lists the position of the data for each file on an NTFS file
system only. nfi.exe doesn't do FAT32.

I mentioned nfi.exe already in this thread.

http://al.howardknight.net/msgid.cgi...nt-email.me%3E

This is an example of a fragmented file on my laptop. nfi.exe can
list the entire drive in a relatively short time. It will also show
directory entries, and even a directory has a structure.

*******
File 110660
\Program Files\Canon\Easy-PhotoPrint EX\Template\frameM004_2L_L.bmp
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 5441600-5441631 (0x530840-0x53085f)
logical sectors 58199592-58199719 (0x3780e28-0x3780ea7)
logical sectors 58066792-58067079 (0x3760768-0x3760887)
logical sectors 58723640-58724231 (0x3800d38-0x3800f87)
logical sectors 61788208-61788831 (0x3aed030-0x3aed29f)
logical sectors 61768528-61768911 (0x3ae8350-0x3ae84cf)
logical sectors 61792480-61793103 (0x3aee0e0-0x3aee34f)
logical sectors 61775416-61775815 (0x3ae9e38-0x3ae9fc7)
logical sectors 57766616-57767287 (0x37172d8-0x3717577)
logical sectors 58825952-58826303 (0x3819ce0-0x3819e3f)
logical sectors 58877712-58878407 (0x3826710-0x38269c7)
logical sectors 58695904-58696231 (0x37fa0e0-0x37fa227)
logical sectors 58740320-58741023 (0x3804e60-0x380511f)
logical sectors 58833808-58834127 (0x381bb90-0x381bccf)
logical sectors 56225112-56225847 (0x359ed58-0x359f037)
logical sectors 58221816-58222103 (0x37864f8-0x3786617)
logical sectors 58811336-58811743 (0x38163c8-0x381655f)

File 110661
*******

I don't know all the steps to finding a file on the disk,
how many accesses are required before the file system has
a pointer to sector 5441600. It could be, that the process
of getting there, is still a significant component.

I think this is the entry for the directory holding that file.

File 108633

\Program Files\Canon\Easy-PhotoPrint EX\Template
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
$INDEX_ALLOCATION $I30 (nonresident)
logical sectors 58623864-58623871 (0x37e8778-0x37e877f)
logical sectors 58624128-58624135 (0x37e8880-0x37e8887)
logical sectors 58625072-58625079 (0x37e8c30-0x37e8c37)
logical sectors 58625160-58625167 (0x37e8c88-0x37e8c8f)
logical sectors 58625344-58625567 (0x37e8d40-0x37e8e1f)
logical sectors 58632840-58632903 (0x37eaa88-0x37eaac7)
logical sectors 53160392-53160455 (0x32b29c8-0x32b2a07)
logical sectors 58721888-58722015 (0x3800660-0x38006df)
logical sectors 5441760-5441887 (0x5308e0-0x53095f)
logical sectors 29425368-29425495 (0x1c0fed8-0x1c0ff57)
logical sectors 38306720-38306975 (0x24883a0-0x248849f)
logical sectors 14448264-14448519 (0xdc7688-0xdc7787)
logical sectors 61786600-61786855 (0x3aec9e8-0x3aecae7)
$BITMAP $I30 (resident)

That directory has 1678 items in it. And they should have been
installed, when the printer software was installed.

Paul

In message , Char Jackson
writes:
On Fri, 23 Mar 2012 22:24:08 +0000, "J. P. Gilliver (John)"
wrote:

In message , Stefan Patric
writes:
[]
However, what would really be ideal is a new filesystem where performance
is less (or not at all) inexorably linked to fragmentation. NTFS with
[]
Unless you are talking of one which prevents fragmentation in the first
place, I don't see how it can be possible to have one where performance
isn't affected by fragmentation, to some extent at least.

I thought the eventual migration to solid state drives would eliminate
the fragmentation concerns.

Well, in theory not eliminate it/them, but in practice reduce them below
other concerns.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Quantum particles: the dreams that stuff is made of - David Moser

On Sat, 24 Mar 2012 21:15:12 +0000, "J. P. Gilliver (John)"
wrote:

In message , Char Jackson
writes:
On Fri, 23 Mar 2012 22:24:08 +0000, "J. P. Gilliver (John)"
wrote:

In message , Stefan Patric
writes:
[]
However, what would really be ideal is a new filesystem where performance
is less (or not at all) inexorably linked to fragmentation. NTFS with
[]
Unless you are talking of one which prevents fragmentation in the first
place, I don't see how it can be possible to have one where performance
isn't affected by fragmentation, to some extent at least.

I thought the eventual migration to solid state drives would eliminate
the fragmentation concerns.

Well, in theory not eliminate it/them, but in practice reduce them below
other concerns.

I'll admit that I don't know why file fragmentation is a concern with
a SSD. Quite awhile ago I read somewhere that it takes the same amount
of time to read data from here as it does to read it from there,
and I guess I sort of took it as gospel. I think what you're telling
me is that, even with a SSD, it's still faster to read contiguous
memory locations than it is to read scattered locations. If so, I'll
try to Kelly Bundy the first gospel and replace it with this one.

http://www.urbandictionary.com/define.php?term=Kelly%20Bundy

--

Char Jackson

Char Jackson wrote:
On Sat, 24 Mar 2012 21:15:12 +0000, "J. P. Gilliver (John)"
wrote:

In message , Char Jackson
writes:
On Fri, 23 Mar 2012 22:24:08 +0000, "J. P. Gilliver (John)"
wrote:

In message , Stefan Patric
writes:
[]
However, what would really be ideal is a new filesystem where performance
is less (or not at all) inexorably linked to fragmentation. NTFS with
[]
Unless you are talking of one which prevents fragmentation in the first
place, I don't see how it can be possible to have one where performance
isn't affected by fragmentation, to some extent at least.
I thought the eventual migration to solid state drives would eliminate
the fragmentation concerns.

Well, in theory not eliminate it/them, but in practice reduce them below
other concerns.

I'll admit that I don't know why file fragmentation is a concern with
a SSD. Quite awhile ago I read somewhere that it takes the same amount
of time to read data from here as it does to read it from there,
and I guess I sort of took it as gospel. I think what you're telling
me is that, even with a SSD, it's still faster to read contiguous
memory locations than it is to read scattered locations. If so, I'll
try to Kelly Bundy the first gospel and replace it with this one.

http://www.urbandictionary.com/define.php?term=Kelly%20Bundy


I guess it's easiest, to give an Atto benchmark. Try the rightmost
one in the review here. There's a transfer rate penalty, when you
do small block sizes. (I'm thinking a fragmented SSD would do that...)
What is surprising to me, is writes aren't more affected.

http://www.pcgameware.co.uk/kingston...-240gb-review/

There are more results for the same device type (OCZ Vertex 3 128GB)
on this page. It's interesting how the Crystal results don't agree
with the HDTune benchmark. HDTune seems to see better write results
(400MB/sec HDTune versus 177MB/sec in Crystal).

http://www.legitreviews.com/article/1760/11/

Paul

In message , Char Jackson
writes:
On Sat, 24 Mar 2012 21:15:12 +0000, "J. P. Gilliver (John)"
wrote:

In message , Char Jackson
writes:
[]
I thought the eventual migration to solid state drives would eliminate
the fragmentation concerns.

Well, in theory not eliminate it/them, but in practice reduce them below
other concerns.

I'll admit that I don't know why file fragmentation is a concern with
a SSD. Quite awhile ago I read somewhere that it takes the same amount
of time to read data from here as it does to read it from there,
and I guess I sort of took it as gospel. I think what you're telling

The difference (settling time of buses, etc.) is probably within the
clocking time of the devices, so no _practical_ difference ...

me is that, even with a SSD, it's still faster to read contiguous
memory locations than it is to read scattered locations. If so, I'll
try to Kelly Bundy the first gospel and replace it with this one.

http://www.urbandictionary.com/define.php?term=Kelly%20Bundy

.... though Paul's point about block sizing may have a small effect. Sort
of in effect doing two or more block reads possibly taking more time
than one block read, though whether that's a function of the device or
the operating system is arguable. It's going to be a very small amount
of delay, if any, and probably not at all significant, at least until
SSDs are the norm and we're in a whole new mindset, possibly involving
different ways of accessing (possibly asynchronously?).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

"He hasn't one redeeming vice." - Oscar Wilde