On Fri, Jan 1, 2010 at 11:17 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Fri, 1 Jan 2010, David Magda wrote: >> >> It doesn't exist currently because of the behind-the-scenes re-mapping >> that's being done by the SSD's firmware. >> >> While arbitrary to some extent, and "actual" LBA would presumably the >> number of a particular cell in the SSD. > > There seems to be some severe misunderstanding of that a SSD is. This severe > misunderstanding leads one to assume that a SSD has a "native" blocksize. > SSDs (as used in computer drives) are comprised of many tens of FLASH > memory chips which can be layed out and mapped in whatever fashion the > designers choose to do. They could be mapped sequentially, in parallel, a > combination of the two, or perhaps even change behavior depending on use. > Individual FLASH devices usually have a much smaller page size than 4K. A > 4K write would likely be striped across several/many FLASH devices. > > The construction of any given SSD is typically a closely-held trade secret > and the vendor will not reveal how it is designed. You would have to chip > away the epoxy yourself and reverse-engineer in order to gain some > understanding of how a given SSD operates and even then it would be mostly > guesswork. > > It would be wrong for anyone here, including someone who has participated in > the design of an SSD, to claim that they know how a "SSD" will behave unless > they have access to the design of that particular SSD. >
The main issue is that most flash devices support 128k byte pages, and the smallest "chunk" (for want of a better word) of flash memory that can be written is a page - or 128kb. So if you have a write to an SSD that only changes 1 byte in one 512 byte "disk" sector, the SSD controller has to either read/re-write the affected page or figure out how to update the flash memory with the minimum affect on flash wear. If one did'nt have to worry about flash wear levelling, one could read/update/write the affected page all day long..... And, to date, flash writes are much slower than flash reads - which is another basic property of the current generation of flash devices. For anyone who is interested in getting more details of the challenges with flash memory, when used to build solid state drives, reading the tech data sheets on the flash memory devices will give you a feel for the basic issues that must be solved. Bobs point is well made. The specifics of a given SSD implementation will make the performance characteristics of the resulting SSD very difficult to predict or even describe - especially as the device hardware and firmware continue to evolve. And some SSDs change the algorithms they implement on-the-fly - depending on the characteristics of the current workload and of the (inbound) data being written. There are some links to well written articles in the URL I posted earlier this morning: http://www.anandtech.com/storage/showdoc.aspx?i=3702 Regards, -- Al Hopper Logical Approach Inc,Plano,TX a...@logical-approach.com Voice: 972.379.2133 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
