SSD Defrag ?

It would seem that this is not needed and detrimental ?

On Sun, 02 Dec 2018 14:53:54 -0500, wrote:
It would seem that this is not needed and detrimental ?

It's not needed unless it's used to boot an old OS or bootloader which can't
load its boot file if it's fragmented.

Defragmentation process basically writes the storage solely for moving data
placements. With the above exception, fragmented files doesn't affect
software functionality. So in overall, the process merely writes the storage
for nothing. It only wears down the storage.

This also applies to magnetic HDD, except that for those devices,
defragmented disks would have lesser need to do disk seek. i.e. lesser
grinding.

wrote:
It would seem that this is not needed and detrimental ?

If you do properties on a partition, then use the
Tools tab, there should be a defragment/optimize type
item.

The code in there, knows the difference between an
SSD and a regular hard drive.

For an SSD, you'll see for a fairly short time, a
"TRIM" thing happening. That delivers a "hint" to the
SSD, saying, "these here clusters are no longer being
used, and thus, you can optimize them away". The SSD
responds by putting the associated sectors in the
"free pool".

Don't TRIM a drive, if you just "accidentally deleted"
files and are about to use an undelete program.

For a HDD, the Optimize panel will specify defragmentation,
moving stuff around. "Writes on HDD are free", which is
why Optimize will offer a different option for HDD. SSDs
have close to zero seek time, which is why in many
cases, it doesn't matter how many times the heads
have to move.

*******

At its discretion, the OS can *still* choose to defragment
an SSD. It's a corner case you can read about here.

https://www.hanselman.com/blog/TheRe...YourSS D.aspx

*******

Over the five or six Windows 10 releases, the Optimize panel
has become "confused" at times, about which drives are
HDD and which are SSD. If you see it offering "TRIM for everything"
or offering "Defrag for everything", it might be wise to wait
until they patch out the bug and give the Optimize panel
"proper judgment" again. The last time I checked,
Windows 10 seemed to be working OK. But if you arrive at
the panel, and see nonsense recommendations, hold off
for a while. Humans are not allowed to choose the
"flavor" of operation, so you cannot ignore the mis-detection.

I tried one of the workarounds for that bug and it
didn't work. Detecting SSDs is dead easy, since they
have a *different* SMART table than a HDD does. It's not
really detection that's an issue, but some other,
intermediate behavior. Since the workaround didn't work,
I walked away.

Paul

On 12/2/2018 3:40 PM, Paul wrote:
wrote:
It would seem that this is not needed and detrimental ?

If you do properties on a partition, then use the
Tools tab, there should be a defragment/optimize type
item.

The code in there, knows the difference between an
SSD and a regular hard drive.

For an SSD, you'll see for a fairly short time, a
"TRIM" thing happening. That delivers a "hint" to the
SSD, saying, "these here clusters are no longer being
used, and thus, you can optimize them away". The SSD
responds by putting the associated sectors in the
"free pool".

Don't TRIM a drive, if you just "accidentally deleted"
files and are about to use an undelete program.

For a HDD, the Optimize panel will specify defragmentation,
moving stuff around. "Writes on HDD are free", which is
why Optimize will offer a different option for HDD. SSDs
have close to zero seek time, which is why in many
cases, it doesn't matter how many times the heads
have to move.

*******

At its discretion, the OS can *still* choose to defragment
an SSD. It's a corner case you can read about here.

https://www.hanselman.com/blog/TheRe...YourSS D.aspx


*******

Over the five or six Windows 10 releases, the Optimize panel
has become "confused" at times, about which drives are
HDD and which are SSD. If you see it offering "TRIM for everything"
or offering "Defrag for everything", it might be wise to wait
until they patch out the bug and give the Optimize panel
"proper judgment" again. The last time I checked,
Windows 10 seemed to be working OK. But if you arrive at
the panel, and see nonsense recommendations, hold off
for a while. Humans are not allowed to choose the
"flavor" of operation, so you cannot ignore the mis-detection.

I tried one of the workarounds for that bug and it
didn't work. Detecting SSDs is dead easy, since they
have a *different* SMART table than a HDD does. It's not
really detection that's an issue, but some other,
intermediate behavior. Since the workaround didn't work,
I walked away.

Paul
A big part of it seems to be history. How did you get where you are?
If you're changing from a HDD to a SSD, the tool you use MIGHT
be smart enough. My recent experience is that something like macrium
ain't. The Samsung SSD wizard got it right.

My research suggests...it's on the web, so it must be accurate...
that the determination of HDD or SDD is determined by some performance
measurement.
When I had a mismatch between the actual drive and the interpretation
by the optimization tool, I found that running "winsat formal"
without the quotes fixed it.

The explanation was:
Winsat is something akin to the windows experience index. It measures
performance and the OS uses that to determine which kind of drive you have.

In message ,
writes:
It would seem that this is not needed and detrimental ?

Most of the time, correct. A fragmented file on a traditional disc
requires head movement to access it, which slows down access; on an SSD,
there are no heads to move (to a first approximation at least, accessing
parts of an SSD in random order takes the same time as accessing them in
sequential order), so you don't gain anything.

Defrag involves writing to the "disc", obviously; SSDs have a more
limited number of write cycles to any part than HDDs, so doing a defrag
uses up some of those for no gain.

See the other replies (especially Paul's) for longer more detailed
answers, including the corner cases.
255soft.uk
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"The great tragedy of science, the slaying of a beautiful theory by an ugly
fact. - Thomas Henry Huxley

mike wrote:

A big part of it seems to be history. How did you get where you are?
If you're changing from a HDD to a SSD, the tool you use MIGHT
be smart enough. My recent experience is that something like macrium
ain't. The Samsung SSD wizard got it right.

My research suggests...it's on the web, so it must be accurate...
that the determination of HDD or SDD is determined by some performance
measurement.
When I had a mismatch between the actual drive and the interpretation
by the optimization tool, I found that running "winsat formal"
without the quotes fixed it.

The explanation was:
Winsat is something akin to the windows experience index. It measures
performance and the OS uses that to determine which kind of drive you have.

That suggestion (winsat) did not work.

That's when I walked away.

Today, Optimize panel is working properly again.
But for how long ?

If I actually need defrag, I have two other options
I can use.

*******

Windows 7 always makes disk layouts with megabyte
alignment. I think that was introduced with Vista.

If you prep a drive on WinXP, then install Win7
(I've done that unintentionally), then your layout
won't be SSD compatible (multiple-of-63 alignment).

I noticed a problem just with a 512e drive, rather
than with an SSD. And backup and restore with Macrium,
can realign the partition, even if the disk layout ends
up looking like a "gap-toothed hillbilly". You can
fix it, using the Macrium alignment choice dialog.
Restoring one partition at a time, you can pack them
in there on the restore.

I'm sure you've seen this dialog at some point.

http://reflect.macrium.com/help/v5/p..._alignment.htm

Paul

On 12/2/2018 4:59 PM, Paul wrote:
mike wrote:

A big part of it seems to be history. How did you get where you are?
If you're changing from a HDD to a SSD, the tool you use MIGHT
be smart enough. My recent experience is that something like macrium
ain't. The Samsung SSD wizard got it right.

My research suggests...it's on the web, so it must be accurate...
that the determination of HDD or SDD is determined by some performance
measurement.
When I had a mismatch between the actual drive and the interpretation
by the optimization tool, I found that running "winsat formal"
without the quotes fixed it.

The explanation was:
Winsat is something akin to the windows experience index. It measures
performance and the OS uses that to determine which kind of drive you
have.

That suggestion (winsat) did not work.

That's when I walked away.

Today, Optimize panel is working properly again.
But for how long ?

If I actually need defrag, I have two other options
I can use.

*******

Windows 7 always makes disk layouts with megabyte
alignment. I think that was introduced with Vista.

If you prep a drive on WinXP, then install Win7
(I've done that unintentionally), then your layout
won't be SSD compatible (multiple-of-63 alignment).

I noticed a problem just with a 512e drive, rather
than with an SSD. And backup and restore with Macrium,
can realign the partition, even if the disk layout ends
up looking like a "gap-toothed hillbilly". You can
fix it, using the Macrium alignment choice dialog.
Restoring one partition at a time, you can pack them
in there on the restore.

I'm sure you've seen this dialog at some point.

http://reflect.macrium.com/help/v5/p..._alignment.htm

Paul
Thanks for the link.
Yes, that's what I was screwing up. I just restored to the
existing partition. Didn't work. The SSD was properly aligned
and working, but when I tried to verify that the backup could be
restored, I used a 63 disk and that failed.

Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

A SSD stores data in a grid of columns and rows.
It takes the same amount of time (humans won't notice the trillionth of a second
difference) to access coordinates abc-123 as is does def-456.
A HDD has moving head(s) that fly all over platter(s) looking for clusters.
It takes time for moving mechanical things to move.
Humans notice this time lag.
So, if you were able to defrag a SSD there would be no difference in access time.

On 12/2/18 3:49 PM, JJ wrote:
On Sun, 02 Dec 2018 14:53:54 -0500, wrote:
It would seem that this is not needed and detrimental ?

It's not needed unless it's used to boot an old OS or bootloader which can't
load its boot file if it's fragmented.

In that case, the file was probably created when the disk was formatted
(no files yet) and never rewritten. There's no chance for it to get
fragmented.

[snip]

--
22 days until the winter celebration (Tue Dec 25, 2018 12:00:00 AM for 1
day).

Mark Lloyd
http://notstupid.us/

"It was the schoolboy who said, 'Faith is believing what you know ain't
so.'." -- Mark Twain, Following the Equator

On 12/3/2018 5:17 AM, wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

There's no such thing as "no issue at all". It's always something.
ACCESSING should be relatively immune to file fragmentation.
Writing is another matter.

I have no idea what I'm talking about, but I never let that stop me.
Someone will chime in and clean up my mistakes...

When you delete a file, the operating system does not delete the data.
It ABANDONS the data. The HDD is fine with that and can overwrite that
data on command.

The SSD cannot overwrite data. It must erase it first. But the OS never
told it that the data was abandoned.

An SSD starts out erased.
There are small blocks of data that represent the minimum identifiable
chunk that can be written within the addressing constraints.
Those are grouped into larger blocks that represent the minimum
size that can be erased.
There are secret algorithms that try to spread the writes and level
the wear on the memory.

As the SSD fills up, it's harder and harder to find free blocks to write.
Erasing takes a lot longer than reading.
Writing one file may cause several other files to get moved to make
room and satisfy the leveling algorithm. That's write amplification.
Deleting half the files doesn't help at all. The OS doesn't tell
the drive.

Enter the TRIM command. I have no idea the details, but the result
is that the SDD now understands about the abandoned data and consolidates
the good data to free up and erase some blocks. Not clear that
any improvement in file fragmentation occurs.

That's why you don't want to fill up a SDD.
That's why defragmentation can wear it out.
That's why we need the TRIM command.

Just because this is mostly unrelated to ACCESSING fragmented files
doesn't mean that it's not a really important consequence of fragmented
files.
But you TRIM not DEFRAGMENT to make writes work better.

I ran some drive benchmark tests on a SDD.
I was disappointed to learn that, for very small files,
READ performance was a tiny fraction of WRITE performance.
READ was still about 8X faster than the same test on a HDD,
but about 1/50 the write speed. I expect that has to do with
ram buffers in the drive, but that's a guess.

Are we having fun yet?

wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

https://answers.microsoft.com/en-us/...7-3ed7d231ef81

HKEY_CURRENT_USER\Control Panel\Desktop\

HungAppTimeout REG_SZ 5000 (milliseconds, default)

Set it to a higher value in milliseconds.

https://docs.microsoft.com/en-us/pre...4(v=technet.10)

Paul

wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

Here are some test results.

https://i.postimg.cc/ry7VnwF7/fragmentation.gif

26GB test file

Checksum used as a read test of the file.

Fragmented file has around 396,000 fragments.
Unfragmented file is contiguous.

On a RAMDISK (close to zero seek) 970MB/sec fragmented read
993MB/sec unfragmented read

On an SSD where a 20usec seek time 229MB/sec fragmented read
is present, so 396000 of the 20usec 383MB/sec unfragmented read
seeks are required.

That's to give some idea how much effect
an extremely fragmented file would have
on an SSD.

Paul

On 12/4/2018 3:08 PM, Paul wrote:
wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?

Here are some test results.

https://i.postimg.cc/ry7VnwF7/fragmentation.gif

26GB test file

Checksum used as a read test of the file.

Fragmented file has around 396,000 fragments.
Unfragmented file is contiguous.

On a RAMDISK (close to zero seek) 970MB/sec fragmented read
993MB/sec unfragmented read

On an SSD where a 20usec seek time 229MB/sec fragmented read
is present, so 396000 of the 20usec 383MB/sec unfragmented read
seeks are required.

That's to give some idea how much effect
an extremely fragmented file would have
on an SSD.

Paul

A fragmented drive takes longer to read than an unfragments
(defragmented) drive???


--
David E. Ross
http://www.rossde.com/

Once again, there has been a mass shooting. This time,
it was in Thousand Oaks, California. And once again, just
as he did after the recent mass shooting in Pittsburgh,
President Trump sent his thoughts and prayers to the
families of the victims. Thoughts and prayers will not
stop the carnage. Action is needed on gun control, and
more guns -- as Trump proposed for Pittsburgh and Parkland
in Florida -- is not the answer.

David E. Ross wrote:
On 12/4/2018 3:08 PM, Paul wrote:
wrote:
Appreciate all the info, but not sure I have a clear answer.

Is there no issue at all, accessing a very fragmented file, compared
to accessing an unfragmented file, on an SSD ?
Here are some test results.

https://i.postimg.cc/ry7VnwF7/fragmentation.gif

26GB test file

Checksum used as a read test of the file.

Fragmented file has around 396,000 fragments.
Unfragmented file is contiguous.

On a RAMDISK (close to zero seek) 970MB/sec fragmented read
993MB/sec unfragmented read

On an SSD where a 20usec seek time 229MB/sec fragmented read
is present, so 396000 of the 20usec 383MB/sec unfragmented read
seeks are required.

That's to give some idea how much effect
an extremely fragmented file would have
on an SSD.

Paul

A fragmented drive takes longer to read than an unfragments
(defragmented) drive???

Yes, the extra time to seek from one chunk of the file
to the next.

XXXXXXX XXXXXXX XXX XXXXXXXXXXXX \____ Wasted time reduces
20us 20us 20us / aggregate bandwidth
(SSD)
On a hard drive, it's much worse. Head
switches cost 1ms, seeks are more expensive.

XXXXXXX XXXXXXX XXX XXXXXXXXXXXX \____ Wasted time reduces
8ms 8ms 8ms / aggregate bandwidth
(HDD)
On my RAMDisk (I haven't measured it), it should
be around these numbers. These would be typical
numbers for a "hardware" RAM drive. The OS software
stack probably degrades numbers like this quite
a bit.

XXXXXXX XXXXXXX XXX XXXXXXXXXXXX \____ Wasted time reduces
2us 2us 2us / aggregate bandwidth
(RAM Drive)
HTH,
Paul