If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
SSD Defrag ?
It would seem that this is not needed and detrimental ?
|
Ads |
#2
|
|||
|
|||
SSD Defrag ?
|
#4
|
|||
|
|||
SSD Defrag ?
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. |
#5
|
|||
|
|||
SSD Defrag ?
|
#6
|
|||
|
|||
SSD Defrag ?
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 |
#7
|
|||
|
|||
SSD Defrag ?
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. |
#8
|
|||
|
|||
SSD Defrag ?
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 ? |
#9
|
|||
|
|||
SSD Defrag ?
|
#10
|
|||
|
|||
SSD Defrag ?
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 |
#11
|
|||
|
|||
SSD Defrag ?
|
#12
|
|||
|
|||
SSD Defrag ?
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 |
#13
|
|||
|
|||
SSD Defrag ?
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 |
#14
|
|||
|
|||
SSD Defrag ?
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. |
#15
|
|||
|
|||
SSD Defrag ?
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 |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|