On Thursday 11 March 2010 14:20:23 Gordan Bobic wrote: > On Thu, 11 Mar 2010 13:59:09 +0100, Stephan von Krawczynski > > <sk...@ithnet.com> wrote: > >> >> > > >On Wed, Mar 10, 2010 at 11:49 AM, Gordan Bobic > >> >> > > ><gor...@bobich.net> > >> >> > > > > >> >> > > >wrote: > >> >> > > >>Are there options available comparable to ext2/ext3 to help > >> > >> reduce > >> > >> >> > > >>wear and improve performance? > >> >> > > >> >> > With SSDs you don't have to worry about wear. > >> >> > >> >> Sorry, but you do have to worry about wear. I was able to destroy a > >> >> relatively > >> >> new SD card (2007 or early 2008) just by writing on the first 10MiB > >> > >> over > >> > >> >> and > >> >> over again for two or three days. The end of the card still works > >> >> without > >> >> problems but about 10 sectors on the beginning give write errors. > >> > > >> > Sorry, the topic was SSD, not SD. > >> > >> SD == SSD with an SD interface. > > > > That really is quite a statement. You really talk of a few-bucks SD card > > (like the one in my android handy) as an SSD comparable with Intel XE > > only with > > > different interface? Come on, stay serious. The product is not only made > > of > > > SLCs and some raw logic. > > I am saying that there is no reason for the firmware in an SD card to not > be as advanced. If the manufacturer has some advanced logic in their SATA > SSD, I cannot see any valid engineering reason to not apply the same logic > in a SD product.
The _SD_standard_ states that the media has to implement wear-leveling. So any card with an SD logo implements it. As I stated previously, the algorithms used in SD cards may not be as advanced as those in top-of-the-line Intel SSDs, but I bet they don't differ by much to the ones used in cheapest SSD drives. Besides, why shouldn't we help the drive firmware by - writing the data only in erase-block sizes - trying to write blocks that are smaller than the erase-block in a way that won't cross the erase-block boundary - using TRIM on deallocated parts of the drive This will not only increase the life of the SSD but also increase its performance. > > >> > Honestly I would just drop the idea of an SSD option simply because > > the > > >> > vendors implement all kinds of neat strategies in their devices. So > > in > > >> the > >> > >> > end you cannot really tell if the option does something constructive > >> > and not destructive in combination with a SSD controller. > >> > >> You can make an educated guess. For starters given that visible sector > >> sizes are not equal to FS block sizes, it means that FS block sizes can > >> straddle erase block boundaries without the flash controller, no matter > >> how > >> fancy, being able to determine this. Thus, at the very least, aligning > > FS > > >> structures so that they do not straddle erase block boundaries is > > useful > > >> in > >> ALL cases. Thinking otherwise is just sticking your head in the sand > >> because you cannot be bothered to think. > > > > And your guess is that intel engineers had no glue when designing the XE > > including its controller? You think they did not know what you and me > > know > > > and > > therefore pray every day that some smart fs designer falls from heaven > > and > > > saves their product from dying in between? Really? > > I am saying that there are problems that CANNOT be solved on the disk > firmware level. Some problems HAVE to be addressed higher up the stack. Exactly, you can't assume that the SSDs firmware understands any and all file system layouts, especially if they are on fragmented LVM or other logical volume manager partitions. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl System Zarządzania Jakością zgodny z normą ISO 9001:2000 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
