Slashdot Mirror
Intel Confirms It Will Ship 160GB Flash Drives
Lucas123 writes "Intel has confirmed plans to ship a new line of solid-state drives for laptop and notebook PCs with storage capacities of 80GB to 160GB. While it did not lock in a ship date, Intel told Computerworld that the drives would be available in the second quarter. From the story: 'An aggressive move into the laptop and PC notebook flash disk drive business would catapult Intel into direct competition with hard drive manufacturers such as Toshiba Corp. and Samsung Electronics Co. that are trying to spark demand before their SATA-based offerings are released in the coming months.'"
The 160 GB SSD is probably 1-5x the size of your ipod...
160 = 10 x 2^4. So, probably 10 x 16GB chips
I'm not sure the limit on write cycles will be a major concern at those sizes, especially if you keep the drive maybe 50-75% full.
Je ne parle pas francais.
1997 called, it wants its caveat back.
http://www.storagesearch.com/ssdmyths-endurance.html http://www.bitmicro.com/press_resources_debunking.php
I'm curious at what point we will quit treating these hard drive replacements as that, and instead treat them as what they are - large arrays of addressable memory. Without doing the homework to be sure, I suspect that being able to remove the overhead of an OS building the needed protocol stream to address this memory as a hard drive, and instead treating it as memory, would save significant(?) code/time.
While there is a longer Lifespan for the data... Normally the machinancal parts of the drive die well before I have to worry about the magnitism going away. WHile Flash may have a shorter lifespan I would expect you will have more dependable drives due to the fact there is no moters to burn out or heads crashing down on the dive giving a nice scratch on it. And by the time it becomes a problem it is usally time for a major upgrade and you move the data over.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I was reading up on this a while back and it was recommended to use EXT2 instead of EXT3 since the journal would cause a lot more wear on the flash.
I think there is definitely room for a Linux filesystem that is optimized for dealing with flash devices and limits the number of times data must be written. Furthermore, don't pad with 0's but with 1's (erased flash has all the bits as 1's).
I would love to see a simple universal flash filesystem which could be used by portable devices and PCs without all the limitations of FAT32 (i.e. 4GB file limit) which seems to be the current fs of choice for consumer devices.
JFFS2 is not suitable for regular flash drives (SD/MMC/CF/etc.) since it has its own wear leveling support and is optimized for devices without hardware wear leveling.
For non-flash devices I have switched to XFS due to the higher performance and better tools compared to EXT3.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Current hardware with simple wear leveling will give you about a solid year of continuous writes. That's writing 24/7, nonstop. I don't think a HDD could even survive that. For a consumer device, even under fairly heavy use, the hardware will be long obsolete before it runs out of write cycles.
Done with slashdot, done with nerds, getting a life.
Technically SSD is both:
Reads faster (ie boots quickly, apps open faster)
Writes slower (ie files saves slower, page file churns sluggishly)
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
Hmm...
I just found this:
Unlike DRAM, flash memory chips have a limited lifespan. Further, different flash chips have a different number of write cycles before errors start to occur. Flash chips with 300,000 write cycles are common, and currently the best flash chips are rated at 1,000,000 write cycles per block (with 8,000 blocks per chip). Now, just because a flash chip has a given write cycle rating, it doesn't mean that the chip will self-destruct as soon as that threshold is reached. It means that a flash chip with a 1 million Erase/Write endurance threshold limit will have only 0.02 percent of the sample population turn into a bad block when the write threshold is reached for that block. The better flash SSD manufacturers have two ways to increase the longevity of the drives: First, a "balancing" algorithm is used. This monitors how many times each disk block has been written. This will greatly extend the life of the drive. The better manufacturers have "wear-leveling" algorithms that balance the data intelligently, avoiding both exacerbating the wearing of the blocks and "thrashing" of the disk: When a given block has been written above a certain percentage threshold, the SSD will (in the background, avoiding performance decreases) swap the data in that block with the data in a block that has exhibited a "read-only-like" characteristic. Second, should bad blocks occur, they are mapped out as they would be on a rotating disk. With usage patterns of writing gigabytes per day, each flash-based SSD should last hundreds of years, depending on capacity. If it has a DRAM cache, it'll last even longer.
You forgot the 10x increased chance of unrecoverable failure.
The average seek time for a hard disk is measured in milliseconds, but for continued transfers, they can have a much higher data throughput than a flash based device. File systems, caches, pages, compilers are all organized to take advantage of this ability to load lots of sequential data quickly, once a seek has been completed. It will probably take a few more before SSD make a huge difference in performance because of the use of existing technology. Now for small random accesses (i.e. one page), a SSD wins, hands-down.
Interesting.
JFFS2 is developed specifically for embedded devices, but I think that is because at its time of development the expectation was that only embedded devices would use flash media for primary storage.
It's been a while since I've looked into how it works, but I'm speculating that it attempts to spread out write operations over the entire disk by giving file fragments fairly dynamic addresses. I believe it also has an ECC scheme and uses a reserved storage area for marking bad blocks. Since the SSD almost definitely does the last two in its controller hardware, JFFS2 would be a good option if you can make use of its distributed write operations only.
The ONLY way you can defragment a file is to copy the fragmented file to another partition, remove it and copy it back. If you want to defragment a complete ext2/3 filesystem, make a backup of the filesystem using tar, delete the original and restore the backup.
No, this is not something you want to do while other software may be looking for the file.
Of the common filesystems available for Linux (ext2/3, xfs, jfs, reiserfs) the only one that supports online defragmentation is xfs (using the xfs_fsr utility) and this has to be scheduled manually.
Fragmentation in ext2/3 files is a huge problem when appending to files over long periods of time. You can check the fragmentation of any file on ext2/3 using the filefrag utility. Make a copy of a highly fragmented file (even to the same partition) and you will see the number of fragments go down dramatically, unless you don't have much free space left on the partition and the space you have free is also highly fragmented.
I think wear leveling probably potentially has significant limits that proponents seem to ignore.
Well, I think the earth probably is the center of the universe. 'course, both of our statements are unsupported by anything but guesswork, so why should either statement be believed over the people actually working in the industry on wear-leveling technology in modern flash drives?
Especially if you have less than 10% free space.
a) 10% of a 160GB flash drive is still 16GB... plenty of space, even if you are concerned.
b) Most people don't run their hard disks anywhere near 10% of their storage capacity, so it's a minor issue.
c) Wear leveling drives may very well contain addition free storage space just so that the algorithm can perform optimally.
d) Using a log-structured filesystem, it doesn't really matter how much free space there is, as the free space region always moves through the disk... hence the "leveling" part of wear leveling.
That said, I haven't found a decently detailed write-up on exactly how wear-leveling accomplishes its task
Well, you could just start with Wikipedia, rather than blindly speculating.
However, your defrag method IS NOT SAFE and WILL RESULT IN DATA LOSS on a live system (sorry to yell, but I don't want anyone trying it on a live system - it should be OK if you can guarantee that no-one else will modify the data on the partition)
There is a lot of opportunity in your script for data loss:
1. During the copy. If someone modifies part of the original that has already been copied, your
2. During the rm. Deleting files takes time, so there is more room for a file to try to write to the original. This step is actually completely unnecessary, just overwrite the original with your mv command.
3. After the mv. If a process has the original file open, it will continue writing to that original file, even after it's been deleted and "overwritten". It is very legal to continue file operations on an open file descriptor.
I suggest you actually try your defragmentation trick on a live filesystem which is actively in use. If you don't lose data, you're lucky.
So I'll say it again. The only filesystem which allows you do perform LIVE defragmentation is xfs using it's xfs_fsr utility.
As far as random access on a drive is concerned, a 5MB music file is gigantic. The seek time (1 seek every 3-4 minutes) is a non-issue. If you were playing 20 snippits of different songs every second then it might matter, but for MP3 playing it is not an issue at all. Even if your file gets fragmented for some reason you're only going to be talking about a few dozen seeks at most.
That said, flash does have a bunch of advantages for music players. It's far more shock resistant (for running!), requires less power, and doesn't have to constantly be put to sleep and woken up like spinning magnetic media.
I read the internet for the articles.
I doubt that. Do you really think that in 7 years our internet bandwidth will be able to support that? Most US ISPs can't even handle a few bittorrent users, do you think they will be able to handle every used storing all their photos and videos somewhere else? ...that's not even taking into account things like the increasingly large size of computer games, etc. I have a hard time believing that we will move back towards a "server with many terminals" type type system any time soon. The cost of a personal computer doing everything locally is just too low.
No, this doesn't work. NOR flash can be addressed directly. This is not NOR flash, it's NAND. NAND can only be written and read in blocks. NAND requires block error correction due to the high incidence of bit errors (especially on multi-level cells). NAND uses complex wear-leveling software and a lot of black magic to work well (not just block remapping, but active block moving). NAND is very slow compared to real memory, and if you tried to read it as directly-mapped memory your processor would slow down to a crawl.
NAND flash is really a block device. There's no getting around it. Some assumptions we make today will have to be thrown out (such as assuming there's an advantage to writing blocks close together or trying to reorder reads so the drive head sweeps in the most efficient manner), but in general access to NAND memory makes sense only through the same block serialization stack we use today for disks.