OT: Apropos defragging and SSDs.

The point was made that SSDS don't need defragging. It doesn't improve performance
They don't, but they may need TRIMing.
# fstrim /
...is the appropriate Linux command to do this for the root partition..
Not sure on windows
Oh, you need to run the command prompt! hahaha
No different to Linux then
http://www.eightforums.com/tutorials/39569-trim-support-ssd-check-enable-disable.html
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 26/03/16 10:09, The Natural Philosopher wrote:

Thanks - you just reminded me to do mine.
Must set up a cron job, perhaps weekly...
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 26/03/16 10:13, Tim Watts wrote:

Just did mine, and it took a long....time.
Some say do it on boot in the background, but I think a weekly cron is best
--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 26/03/16 10:16, The Natural Philosopher wrote:

Curious - all of mine, including a laptop heavily used and not done for a year at least, 5-10 seconds max, several filesystems were a couple of seconds.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sat, 26 Mar 2016 10:09:09 +0000, The Natural Philosopher

Of course you aren't, like most Linux nerds.

Nope. Typically automatically enabled on W7 onwards.
https://en.wikipedia.org/wiki/Trim_%28computing%29

Very different to Linux still, not only the massive userbase but the level of support for Windows from developers, hardware manufacturers and the desktop support fraternity.

Yes, 'how to 'check' that TRIM is enabled ... (or enable it if for some reason it isn't or to disable it if you want).
Cheers, T i m
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Um
SSDs are NAND devices.
NANDs are "paged" devices. Accessing data which is spread across non contiguous pages is slower that accessing data on the same page or which flows across contiguous pages.
Whilst the time saving will be completely unnoticeable when compared with delays from disk latency the difference is a significant percentage (greater than double) of the actual nominal read time.
repacking your files on the NAND *will* improve access time, even if you don't notice it
whether defrag produces the required level of repacking is another matter
tim
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 26/03/2016 13:06, tim... wrote:

Why are contiguous pages quicker?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 26/03/16 13:45, Nick wrote:

They probably are not.
My IMPRESSION is that SSDS spread the data all over the place according to internally decided algorithm and a 'track sector' call wont access at any given time the same bit of NAND as at another time.
And in any case the SATA bus is probably the bottle neck.
If you like with an SSD., it has its own operating system doing smart stuff internally all the time. Probably linux ;-)

--
Bureaucracy defends the status quo long past the time the quo has lost
its status.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload


cos modern devices internally cache the following page in the expectation that will be the one you ask for next
tim
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 27/03/2016 10:48, tim... wrote:

But unlike a disk an SSD can cache any arbitrary page (no different access time cost) and can dynamically decide what the following page will be. In essence the SSD can know how the data is stored and predict what the next page will be.
I don't have a clue how it is actually done but it seems to me that the old physical benefit of caching contiguous pages has gone. Now the caching mechanism should be more intelligent. More analogous to a cpu pipeline with branch prediction.
So rather than rearrange the data (defragging) the SSD should just be able to rearrange the metadata.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 27/03/16 13:56, Nick wrote:

Given that what the commands are that the SSD sees are 'gimme (track, sector) and there are no longer such things anyway, its fairly clear that there is an operating system operating inside the SSD that is presenting what it really is in a digestible from to the host computer, and apart from TRIM, which says 'trim(track,sector) as I don't need that any more', there is very little the host can do to optimise it *at all*.
In fact tests done seem to suggest that on most SSDS simply erasing *everything* and adding back the data, is the only thing that makes a slight (10%) difference, and that is most likely to be a matter of sub optimal algorithms in the SSD itself anyway.
An SSD is actually a complete computer system. It has memory, IO, 'disk' and a CPU and runs embedded code.
How it performs is largely down to how its designed and very little down to how the host utilises it.
Also, nearly everything I have read that has actual numbers in it, suggests that for personal workstations or laptops (not servers) the disk will outlast its usefulness before it gets fucked from too many writes.
Frankly SSDS have given my personal computers the sort of performance boost that I haven't seen since we went from 8 bit to 16 bit...
For booting off and keeping programs on (as opposed to keeping data) there are the dogs knees. Get one.
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 27 Mar 2016 14:16:30 +0100, The Natural Philosopher wrote:

Interesting information.

Based on your info (above) I may just do that. Now to see if I have a few spare pennies lying about...
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 27/03/2016 14:16, The Natural Philosopher wrote:

Yep I agree I've at least five. Including an 8 year old one now living in my router. Using one in a router was supposed to be a no no due to constant logging but it has been in there for 6 months without problem.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote in message

The underlying device cannot arbitrarily decide for itself what following page it should cache, it has to be told.
If you (the SSD controller) says to it, give me block 23 page 120, it *can* automatically pre-cache page 121 so that it is ready when you come back to say give me block 23 page 121.
but if you know that the next page that you want will be block 24 page 17, you have to tell it this and it has to operate special logic to cope with that
NAND devices have been designed for cheapness (of cost per bit), They are not designed to include comprehensive logic to achieve complicated functions in a timely fashion, thus this "I want a different page as the next page" is not a cheap operation. This is where the delay is.
tim
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 28/03/2016 11:55, tim... wrote:

Why not?

The SSD has the power to know what order it gives out free sectors, it can remember this order and hence have its own concept of contiguousness. This might not be able to defrag an existing file but it could ensure the free sectors were all contiguous when new files were allocated. I would hope some one who had considered the problem for more than the five minutes I just devoted to it could do an even better job.

Actually I think the software mapping physical memory is already very complex, eg this software is required to ensure an even spreading of the number of times each bit get written so that the SSD wears evenly.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote in message

think of a way to do it then
I can't.
(other than completely randomly which doesn't serve a useful purpose)

but that is irrelevant
The primary device likes to read contiguous blocks. No amount of mapping by a controller is going to change that.

storage devices only get fragmented from frequent use.
It's all very well trying to have a system of making sure that all of your free block are contiguous, but you can't do that if someone else is making the decisions about what files to delete.
Not unless you repack after every delete - that would also solve the wear levelling problem.
But would cause an awful lot of thrashing.

I've never seen wear levelling work at a bit level
that is news to me (and would be a flipping nightmare to implement needing as much storage to store the data as you have useful memory)
tim
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 28/03/2016 18:26, tim... wrote:

The point I think you are missing is that with an SSD the concept of contiguous is arbitrary. The SSD will have at least one level of indirection (it may be called an address translation layer) between the logical page id and the physical page memory.
The property you are referring to as contiguous is a total ordering of the logical memory addresses, not an ordering of physical memory. This translation layer will be in terms of blocks or pages which each consist of thousands of bytes. So in order to to reassign the order of a block or page it is only necessary to change a few byte in the translation layer.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 28/03/2016 19:26, Nick wrote:

You do realize you would need a different translation layer for each file system type including the RAW ones used by database engines and the OS would have to know how to update this translation layer and the performance gain would probably be negative due to the extra lookups.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 28/03/16 21:48, dennis@home wrote:

You do realise you haven't a clue what you are talking about, don't you?
--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 28/03/2016 21:49, The Natural Philosopher wrote:

You do realize that you are an idiot and are obviously going senile? Have you had the test yet?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Site Timeline

HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.