New OCZ Vertex v1.4 Firmware

Fragmentation on SSDs still confuzes me tbh. I always thought u had a file, it's sector locations were like memory addresses, there's no head movement like with regular drives - so where's the beef ?

Think I need to read up on how the SSD electronics work.
 
Interesting - why does it need to clear it ? Why not just erase the memory address pointer.

Without the pointer I don't think the contents of the location mean anything.
 
it's just as deathwish pointed out

as data is deleted, the cells aren't actually erased. the next time the drive wants to write data to those same cells/blocks they have to be erased first before being written to again, causing extra write latency.

TRIM improves this by running after the delete command, queries the volume bitmap, sees data marked for discard and discards it.
 
Just bought a Vertex earlier today, only a 30GB one but will be alright for now until I can buy another for RAID0. Have it just for OS for now, but this firmware is perfectly timed for Windows 7 next week :D
 
name='Ducky Spud' said:
Just bought a Vertex earlier today, only a 30GB one but will be alright for now until I can buy another for RAID0. Have it just for OS for now, but this firmware is perfectly timed for Windows 7 next week :D

Let's hope it fits !! (joke refering to another thread)

name='Pyr0' said:
it's just as deathwish pointed out

as data is deleted, the cells aren't actually erased. the next time the drive wants to write data to those same cells/blocks they have to be erased first before being written to again, causing extra write latency.

TRIM improves this by running after the delete command, queries the volume bitmap, sees data marked for discard and discards it.

That sounds pretty inefficient.

Is that something to do with the intergrity check of the controller or something ?

The matter that the data in a location was $009e0f50, then needs to be made $4c4f4c21, in theory, shouldn't require zero filling b4 hand.

Can u turn the discard thing off to speed things up ?

The root cause of the issue is that SSD drives do not know which blocks are truly in use and which are free. While the file system on the SSD will maintain an in-use list, SSDs don't understand file systems, and cannot access this list. This causes trouble in two places:

SSDs can write 4KB blocks at a time, but only delete 512KB blocks. Since the drive does not know which 4k blocks are still in use if they have been written to previously, each write requires a 512KB read-erase-modify-write cycle

That is crazy.
 
it's just how things work with current SSDs m8

you can disable TRIM in Windows7 (fsutil behavior set disabledeletenotify 1)... but why bother

TRIM happens after deletion and you don't even notice it

and it can't be too inefficient if these ssds rape plain mech. hdds
 
More than that, the more I read up on the tech behind ssds, the more I'm inclined to believe they filled a room full of monkeys to design them.

It's not as simple as memory allocation on memory chips.
 
Who knows, maybe.

What u tend to find more and more these days is tech/industry is being led, initially by thoughts of cash, but following that teams of "IT" or "engineer" people who, quite honestly, u wouldn't trust to do anything if u absolutely needed to.

Being as there are such controllers out there that can saturate an IDE channel by using a card loaded with SATA drives, raiding them and taking the cpu work away from the pc, e.g. the XFX revo64 - the makers of which went bust.

U can take the theory on 1 hand that ur using, or can be using, memory chips - which on the face of it aren't that expensive. There does already exist pci(e) card that u can load with memory dimms and use as an "ssd". This is taking files as they would appear on a regular hard drive and as opposed to using magnetic media in which to store them, u'r using memory. Inherently an old fashioned ram-drive (a harddrive mounted in memory space, tech of which has been around for decades) - u can't get faster r/w than that - ever - (or atleast ur bound by ur OS).

These of which hold problems of which I am not aware. If u like u can load files into memory locations and use them as if they're on a drive. No complications and the OS's interpretation is the only thing that holds u back in terms of access.

Why can't u take the same tech, mount the memory in style that is like the current SSD frame ? 64g u can get smaller than ur thumbnail. Flash drives show this. The size ratio, in terms of physical size, isn't great. 10x thumbnails and u have 640g (roughly). Throw in a controller and a SATA interface and away u go. Limitations are the OS and the SATA channel.

How to allocate files ? Use a table like the FAT on a traditional harddrive. Instead of sector locations on platters, use memory locations.

U write, u have memory to put stuff in, allocating the parts to the table. U delete, u remove the allocation. If ur being forensic or paranoid, u can zero fill the memory - as a choice.

Limitations ? Certainly not 4kb, using the ram-disk mentality, there is no difference to the OS, it sees it as a regular drive. The controller on the drive handles the difference between platter locations and memory locations.

The latter part there -really- is the main difference between using memory for drivespace and magnetic media.

Keep everything else the same and ur not governed by filesystem limitations, or lack of a filesystem. Track location = memory location. Other than that, the OS thinks it's a normal hdd.

I don't honestly see why they're stumbling on issues that are their own creation by invention.

Computer people > IT people.
 
Back
Top