Generale wrote:
As for microdrives. If I got hold of one of them it'd go straight into a Fujitsu Stylistic 500 I have. Odd machines, but strangely cool.
That takes CF? I gather the old style of PCMCIA (Type III?) hard drive was used on those designs... though I suppose a flatter solution might buy you a slot, depending how they have it arranged. (If you really like those, they took them way past the 486 era, and may have only just renamed the brand as part of the TabletPC mess, I've lost track.)
---
As to the remapping, I'd assume that's snuck in, too (especially as the broader market is forced to use FAT on all these), but even in the best case, how many spares are you guaranteed? The MTBF is probably more than fine for an Amiga -- it certainly works for palmtop users -- but you probably wouldn't want to put something like a swapfile on one.
Edit: Okay, specifically, I'm digging at "dynamically map bad blocks/exhausted blocks out of the available space, and use another sector," just to make sure everyone knows what this means. Drives aren't filesystem-aware, and most filesystems aren't drive-aware to this extent (whether they should be is another question), so the on-disk logic
can remap blocks, but
can't shrink the 'available space' of the volume -- at least without, pardon the pun, fscking up the assumptions made when partition tables were written and filesystems formatted. After that limited number of spares behind the curtain are used up, it's time for the card or drive to hit the bin.
It
would be kind of cool if they'd just shrink the capacity of the drive on you when you run out of spares and let you reformat (perhaps reserving another row's worth of spares each time, until the capacity of the card's down to 0), but there's also kind of no way they can do that without risking access to all your data at the moment, so a) I'm almost completely certain they don't do that, and b) they won't be able to unless 'a miracle occurs' at the host level. It's a lot easier to make the host do it in software -- no coherency concerns, no need for the host to take this 'whoops, we just changed the size of the volume on you' exception at *any* time -- so I gather 'soft' mechanisms and more flexible filesystems are becoming the popular approach for dealing with unreliable media. The other alternative would be to have all sorts of 'mailbox' logic until your humble USB stick becomes its own fileserver, but that's a lot of firmware for what's supposed to be a 'disposable' storage device... still, there are compromises to be made, if I understand how CD and DVD packet-writing actually works at that low level. ('Mailboxing' files gets ridiculous, but 'mailboxing' blocks/sectors/packets just acknowledges what the disks are doing already, and there's a good excuse to let them carry on, what with latency and buffer-lifetime issues if each remap has to be handled 1980s-style by the host.)
My bet is that even, say, Mt. Rainier isn't quite as smart as I wish it is, but after doing all this thinking in public, I'm going to have to look into it now.
