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."

Comments

Flash

[Zlib pt]

"I'm sorry sir. You can only install OSX 10 times. Then you ran out of read/write operations"

Re:Flash

[FidelCatsro]

That's not really a worry any more , modern flash memory has a substantially greater number of read/ write cycles.
IIRC the numbers are good enough that they would probably live as long if not longer than your average laptop HDDs .

Re:Flash

[advocate_one]

IIRC the numbers are good enough that they would probably live as long if not longer than your average laptop HDDs.

the only people who might possibly run into the write limit would be Gentoo users...

Re:Flash

[MaynardJanKeymeulen]

Thumb drives are slower, let's do a test:

[root@pentie4 /]# hdparm -t /dev/sde2

/dev/sde1:
Timing buffered disk reads: 78 MB in 3.04 seconds = 25.69 MB/sec
[root@pentie4 /]# hdparm -t /dev/sde1

/dev/sdc1:
Timing buffered disk reads: 36 MB in 7.43 seconds = 4.84 MB/sec

with sde my USB2 harddisk and sdc a USB2 thumbdrive.

Re:Flash

[alienw]

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).

Re:Flash

[Just Some Guy]

Thumb drives are slower

...at sequential reading. Wanna run the same test with bonnie++ or another benchmark that slams the drive with random accesses? I'll bet the near-zero seek penalty on solid state media makes up for quite a bit of its currently mediocre sequential access.

Imagine a database where you're writing millions of tiny blocks of data all over the place. Within reason, fast seeks are about as important as fast IO.

Re:Flash

[Hal_Porter]

Here's how it works on NOR flash.

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,

EU 1
lookup table contains (1,2,3)
IDE sector 1
IDE sector 2
IDE sector 3
EU 2
lookup table contains (4,5,6)
IDE sector 4
IDE sector 5
IDE sector 6
EU 3
lookup table contains (7,8,9)
IDE sector 7
IDE sector 8
IDE sector 9
EU 4
lookup table contains (-1,-1,-1)
spare - every bit in this EU is one
EU 5
lookup table contains (-1,-1,-1)
spare - every bit in this EU is one
EU 6
bad

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.

EU 1
lookup table contains (0,2,3)
IDE sector 1 (obsolete data)
IDE sector 2
IDE sector 3
... no change, damn lameness filter
EU 4
lookup table contains (1,-1,-1)
IDE sector 1 (latest copy)
spare (all ones)
spare (all ones)
... no change

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.

EU 1
lookup table contains (-1,-1,-1)
spare (all ones)
spare (all ones)
spare (all ones)
... no change
EU 4
lookup table contains (1,2,3)
IDE sector 1
IDE sector 2
IDE sector 3
... no change

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.

Too Bad pn Junctions cost more than magnets

[Metaphorically]

I remember talking to a guy at Radio Shack about flash-based drives and how this was going to be the new option back in 1992. I think they were calling it a "hard card." Looking back, it was probably the same thing as PCMCIA Flash drive. That's the precursor to Compact Flash cards for you young'uns.

It wasn't new then and it isn't new now. Is it time? Sure. It's long overdue and I'd love to see solid state drives suddenly become financially feasable.

I doubt it's going to happen though because it seems like the cost of the magnetic materials used in disc platters will always be low and a solid state memory cell (flash, ram, eeprom, whatever) takes a couple transistors. The price of both drops, but hard drive price per GB (or MB, TB, whatever) always drops faster because of the lower transistor count.

Re:Too Bad pn Junctions cost more than magnets

[KD5YPT]

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.

Re:Too Bad pn Junctions cost more than magnets

[FidelCatsro]

Sometimes good tech just takes years to catch on and neigh on useless legacy crap takes forever to die off. Just look at the fact that FDDs are still clinging on tooth and nail in the PC world.
LPT ports are still used for printers , serial ports still come as standard on most motherboards .

I think the principle advantage is in the power consumption for laptops, Batteries are really expensive , if you use your Laptop on the road a lot then it has two principle advantages , lower power consumption and its far far more robust to damage due to things like dropping .
In this field of the ultra compact laptops i would say that the Power consumption and durability will outweigh the per GB cost .
If the write/erase cycles are now within the realms that samsung is considering offering these drives for commercial sale then i would defiantly want one in my laptop , i could easily cope with 15GB on a portable device for work.

Re:Too Bad pn Junctions cost more than magnets

[pedantic bore]

No, the "hard card" was a self-contained hard drive that could be installed, like a peripheral card, directly into a mobo slot. Nice idea for old cases that didn't have expansion drive bays. Saw lots in stores, but never saw many in actual computers...

On the other hand, you might be thinking of bubble memory... which was going to be the next big thing in the early 80's. Still waiting on that one.

Re:Too Bad pn Junctions cost more than magnets

[pete-classic]

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

faster writes?

[nblender]

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.

Re:faster writes?

[Metaphorically]

Write speed for flash is slower than read speed for flash, but making a direct comparison like that can be tricky because of differences in the technology.

Flash memory has to be erased before it can be written and has an inherent minimum erase block size. This has made designers put some write buffering in the card (at least in the older PC Card devices, which afaik are just bigger versions of CF cards). That write buffering is one layer of caching, then there can be additional layers of read and write caching in the driver.

Generally those caches improve normal use of the device, but in cases like yours you blow right through all those caches since you're rewriting the whole card.

btw, that caching is why you have to tell Windows to eject the device before you pull it out. Your write might not have actually finished even though you can do other things to the drive in Explorer.

Reliable? Don't think so.

[Anonymous Coward]

Show me a flash drive that survives a couple of million write cycles, and I might consider using a flash drive instead of a normal hard drive.

Re:Reliable? Don't think so.

[kesuki]

I've even read articles

What are you doing on /. then?

but seriously, prior to wear leveling (ie: antique 32MB cards, early controllers/drivers etc..) this was a valid statement, however cards back then only had 10k or fewer rewrite cycles. the rewrite cycles have gone up 10 fold, and wear leveling makes sure that data that is 'rewritten' is actually written on a portion of the disc that was previously determined to be a low write, freely alloctabale block, and they always keep spare low write sectors available. it's even possible for a hard drive such as this to Warn users of impending drive failure. BTW when a block on a 'flash' based drive 'fails' it falls back into read only mode. only the data it attempted to write must now be written somewhere else.

Also, to get back on track the MTBF for most platter based hard drives is something along the lines of 50,0000 hours for a really top notch drive, reading/writing the entire disc will on average take ~2 hours, requardless of capacity, because that's how long it takes the data heads to travel the entire platter surface area... so statistically, you have 25k write cycles before failure on a conventional hard drive. so how is that inferior to flash memory? and remember, this is APPLE Macintosh running of a FreeBSD derived kernel. put the right amount of ram in the laptop, and it will _never_ use swap space.

Re:extra bonus

[rokzy]

who is booting a Mac 1000 times?

you're obviously a Windows user.

18Gb prototype info here:

[Idou]

http://www.physorg.com/news4220.html

Re:Flash still has lots of room to grow

[Anita Coney]

Not every one is concerned about massive drive sizes. There are plenty of people who would choose the battery saving advantages of flash drives in their laptops.

I'm of the opinion that laptops should be as small and energy efficent as possible. I just don't get the point of using them desktop replacements. If you want something as huge and powerful as desktop, buy a friggin' desktop. If you want something portable, buy something portable.

I mean, what's the point of a "portable" computer if you have to plug it in all the time?!

Two drives: one flash, one magnetic

[AdamInParadise]

I've been thinking about this for a long time. What about using a flash drive for the important stuff (OS+user docs) and a hard drive for the unimportant stuff (divxes, CD backups, you name it)? Basically, the hard drive would be powered down most of the time, bringing down noise and heat, therefore driving up the reliability of the whole system. That's certainly possible with every kind of computer out there, but it would be better with specific OS support. For example, the OS could transparently copy your data back and forth between both drives, like the iPod does (with RAM instead of Flash).

Regards

the number of writes is 10,000...

[Anonymous Coward]

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.

Re:the number of writes is 10,000...

[RzUpAnmsCwrds]

Your results are not indicative of flash performance - CF is simply not that fast. I frequently get 10MB/sec with my USB 2.0 SD card reader and generic PQI 1GB SD card.

Flash can be *very* fast. Remember, you can interleave many flash chips using RAID-like techniques without the cost of having multiple disk assemblies.