So what's funny is needing to do a shrink operation with, say PerfectDisk 12.5. I actually use this quite a bit when migrating an OS to different SSDs, or taking an exact copy. Why migrate a huge volume when you can shrink it first. But to do that, Windows thinks it needs to know that the blocks have been all bunched up into one section of the drive, so you can shrink the volume. PD offers an extremely efficient shrink prep job to do this. Works great, but in reality, what is it actually doing? Where it thinks the blocks it knows about are, has no bearing on where they physically live on the NAND.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Defrag SSD
- Thread starter Pleb
- Start date
- Status
Why is that funny? I guess this statement stems from a lack of understanding of how filesystems work.
NTFS (and most other common filesystems) map the files to ranges or extents of LBAs on the block devices. If you just shrink a partition or filesystem without first making sure that the LBAs at the end (which will no longer be part of the filesystem) are unused, then some of your files will be corrupted. So you first have to move all the data in the LBAs at the end to LBAs that will not be truncated by the shrink process. It does not matter where the data is in the flash memory, just as long as the LBAs the SSD has in its map get updated properly.
lol JoeComp, lol... You are good at arguing, but you're wrong. Because of write combining and interleaving large data is sent to several nand die's. This is how SSD's achieve their speed. Do yourself a favor and read the entire article.
Proof:
http://www.anandtech.com/show/2829/5
Proof:
http://www.anandtech.com/show/2829/5
Ok genius, I know exactly how it works. I meant it was funny in how it pertains to this particular conversation of late. Think about it, and get off your high horse.
I have read everything Anand has written about SSDs. He gets most of it right, although he occasionally has some minor mistakes. But that is mostly irrelevant to this discussion.
Anyway, that article does not disprove anything I have said. You will notice that I did mention the possibility of interleaving already. If the data is split up for interleaving, it is done in order to speed up the writes and reads. It is equivalent to having the data be in sequential flash pages.
Nothing I am discussing is a difficult concept. You would do better to try to understand how SSDs and flash memory works rather than continuing to post nonsense.
You obviously did not understand before my explanation. You are welcome. And my advice is to stop calling people idiots when you clearly did not know what you were talking about.
I'm not sure how I'm not making sense when mentioning "the OS" since myDefrag uses "the OS"'s defrag API to do it's magic.
Yup.
Yup.
Wrong yet again. I do not run a defrag on my SSDs because it is of negligible benefit to me.
The OP was asking about a third-party defrag program which he said has an SSD-specific algorithm.
Whether it uses some OS-calls to write to disk or not makes little difference in the question of what program is responsible for the pattern of writes.
It's the standard defrag API that's included as system library in Windows 2000, 2003, XP, Vista, 2008, and Win7. The defrag program that OP was asking about uses it.
The "SSD-specific algorithm" that OP is speaking of is only a script that consolidates files to the beginning of the drive as the OS sees it.
Dev center info regarding the API:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363911(v=vs.85).aspx
If that is all the information that they tell you, then I certainly would not use that on an SSD. If the OP is going to even consider running a defrag on his SSD (as I have said, it is unlikely to help most consumer workloads), he should at least pick something that has a specific algorithm designed for SSDs.
Do you find the statement (below) difficult to understand? Or did you just not bother reading my previous posts in this thread before posting your nonsense?
- Joined
- Jul 27, 2006
- Messages
- 9,484
Doesn't an SSDs power come from its randomness in nature? I would like to see someone write a Fragmenter program so that proper benchmarks could be done
The script is part of the Mydefrag program and is just one of the options supported by the API. It's not windows that does that it specifically.
- Status