Just came across another SSD based paper from M$. http://research.microsoft.com/pubs/76522/tr-2008-169.pdf It discusses deployment issues into servers. Greg On Fri, Jan 16, 2009 at 7:37 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > For a good technical overview of how a SSD is implemented inside the > SSD itself read > > http://research.microsoft.com/pubs/63596/USENIX-08-SSD.pdf > > This whitepaper was written prior to the TRIM functionality being > implemented in SSDs, so it does not talk about that. But merely says > it would be nice to have a way for the SSD to know when sectors/blocks > are being freed by the filesystem. > > more comments interspersed. > > On Fri, Jan 16, 2009 at 1:56 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> thank you.....but then i don't really understand...please help me out: >> >> quoting from the article: >> >> "At the lower levels, groups like the T13 committee (which manages the >> ATA standards) have created protocol extensions to allow the host >> computer to indicate that certain sectors are no longer in use; T13 >> calls its new command "trim." Upon receipt of a trim command, an ATA >> device can immediately add the indicated sectors to its free list, >> discarding any data stored there. Filesystems, in turn, can cause >> these commands to be issued whenever a file is deleted (or truncated). >> That will allow the storage device to make full use of the space which >> is truly free, making the whole thing work better." >> >> So my question is: so now the hardware maintain something called a >> "freelist"? > > Yes. Part of the SSDs stable memory is used to track status of each > wear leveling unit. ie. To wear level, the SSD has to know how many > times the individual erase zones have been erased, which are free, > etc. See the MS article for a much better discussion of this. > >> the interface between software and hardware are the ATA >> commands, correct? > > Yes, as described in the proposed ATA spec you linked at the end of your post. > >> so anything after the ATA are >> firmware-implementation? > > Yes > >> so is there not now a duplicated list of >> "freelist" of sectors - one at the firmware level, and another at the >> filesystem level? > > Similar, but it is NOT a conceptual problem for SSD to think a sector > is in use that the FS thinks is not. It just means the wear-leveling > algorithm can't use that sector even though the filesystem would not > object. > > Thus ext2/3 will continue to work with SSDs even though they never > discard any sectors. ie. the freelist at the FS level is extremely > different than the one in the SSD. > > BUT the SSD is conservative. Once a logical sector is written, the > only way to get the logical sector back into the SSDs free list is for > the kernel to "discard" it. > >> if true, then it also mean a corresponding ATA >> command for "allocation" of sectors....correct? > > No, the FS just writes to a logical sector. If that logical sector > does not already have a physical sector assigned, the SSD will > allocate one and write to it. Read the MS paper for the gory details > of what really happens. It is surprisingly complex. > >> i think and deduced >> these are needed....because of wear leveling requirements as explained >> earlier in the article. >> >> From the ATA spec: >> >> http://t13.org/Documents/UploadedDocuments/docs2007/e07154r3-Data_Set_Management_Proposal_for_ATA-ACS2.pdf >> >> it can be understood that the requirements for the TRIM (or deallocate >> basically) command is because of frequency statistics needed by the >> firmware.....to implement wear leveling i supposed? > > If I do "dd if=/dev/zero of=/dev/sdc" where sdc is a SSD all of the > sectors are allocated and contain real data. How can the wear > leveling algorithm work? No free sectors?? > > Answers are 2: > > 1) Over build the SSD to always have free sectors, even when it > appears full. This is how flash has worked historically. > > 2) Make the SSD smarter and have the kernel tell the SSD when sectors > are no longer needed and available for wear-leveling use. This is the > new "trim" feature. Linux is using the term DISCARD. > > FYI: > I have researched this because of my profession. With normal HDDs we > have 3 normal things we do: > > 1) Read all sectors of a drive and recover deleted files. > > It is not certain, yet but if the SSD manufacturers make the discarded > sectors unreadable, this will no longer be feasible via normal sector > read requests. > > 2) Wipe a file to ensure it is not recoverable. (ue. shred file) > > Due to wear leveling this is not possible. Maybe the shred tool needs > to be adjusted to test for SSDs and return a fail code if the file is > sitting on one? > > 3) Wipe a drive > > Same. Strangely NIST has a document that says it is an acceptable > solution for "confidential" data. > > I can understand that because there is no way I am aware to get to the > unallocated sectors of the SSD via the ATA interface. But normally > NIST is more paranoid and worries about laboratory attacks. By > modifying the SSD I think a good lab would be able to read those > unallocated sectors. > > Greg > -- > Greg Freemyer > Litigation Triage Solutions Specialist > http://www.linkedin.com/in/gregfreemyer > First 99 Days Litigation White Paper - > http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf > > The Norcross Group > The Intersection of Evidence & Technology > http://www.norcrossgroup.com > -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
