Generale wrote:
Too tired to format this properly. Sorry. But,
The stylistic has 2 pcmcia for normal use and 1 doublewidth for microdrives if I remember correctly.
To spare you the pain of buying the wrong thing, CF and PCMCIA/Cardbus are different. Modern microdrives are only available in CF form-factor (and I seem to recall there's some 'typing' of CF slots as to whether they're thick enough to let the microdrive fit), but PCMCIA hard drives exist -- they're basically a 1.8"? drive crammed on a hardcard, hence the sheer height of that Type II or Type III PCMCIA slot.
Now for the bad blocks.
Are you saying that microdrives are smart enough to implement the same sort of system as S.M.A.R.T. Ie, having some capacity put aside for bad sectors that is dynamically remapped, and after that threshold has been hit, 'Sorry but you have bad sectors'. Anyway, I don't see how it could be too much of a problem, because as long as the CF card has the ability to say 'this byte is bad', the filesystem handles the bad blocks anyway.
Someone's saying this... the microdrives really ought to, being magnetic and prone to a certain defect rate, and you can probably find out if they do or don't in the product literature; the question is whether they bother doing this for (any? all? some?) of the fully solid-state cards in any of the various formats they come in (CF, SD, USB stick)...
Bad-block remapping is sort of independent of S.M.A.R.T., which, as far as I know, is not much more than a buzzword out in IDE land. They were, in theory, doing remapping long before anyone came up with the S.M.A.R.T. word and the limited ability to let the drive report an 'I personally think I'm about to die for reasons that may or may not be accurate' condition. (Per
this article, I notice IDE S.M.A.R.T. has wobbled a bit in nature, which explains my confusion. Since I'm more of a SCSI guy, I've been able to count on spare-table statistics showing up in mode pages, whether or not its presence there is some requirement of a 'S.M.A.R.T.' spec.)
Also, while Amiga and MS-land filesystems can still deal with bad sectors exposed to them at the software level, not every platform is so lucky. In particular, the code to handle that appears to have suffered 'some' abandonment in BSD-land, and not every *NIX filesystem will bother with the
automatic reallocation that makes life on a dying disk comfortable. (This may have something to do with cultural differences, or maybe I just haven't found the best-practice for creating a soft list in BSD-land. A major problem is, of course, what happens when the sectors containing the bad blocks list go bad, or when a cabling or UDMA mode problem suddenly makes 'every' block on the disk look bad...)
I just had a stupid idea that I shot down instantly. Just thought I'd say it because some people might get a laugh out of it. My logic went as follows:
*CF would wear out too quickly if used for swap.
*What doesn't have the writing limitations?
*RAM doesn't!
*So use a Ramdisk for virtual memory!!
*.....idiot.
The other day I caught myself thinking about creating a VM-backed /tmp, then moving the swapfile to it, because it doesn't have to persist across a reboot, and it would only have to swap when the file grew... :-D
