On 4/16/07, Alexandre Souza <alexandre-listas at e-secure.com.br> wrote:
choice. If,
however, your OS requires a writeable drive and demands
swap space or does lots of filesystems writes outside of human
control, Flash might not be a wise choice, cheap or not.
Ethan, remember that in CFs, if you write a sector more times than
allowed and the sector go bad, it is automatically replaced for a good
sector. In effect, if hundreds of sectors go bad you'll not have bad sectors
on the CF, but the total capacity will get smaller. CFs has automatic
remapping/hiding of all bad sectors.
I am aware that CF does "wear levelling", but there is a substantial
difference of quantity of write activity between, say, CP/M, and
VAX/VMS. With CP/M, if I'm sitting at a prompt or sitting inside
Wordstar, I don't think the OS is writing to the hard disk behind my
back. With VMS, it's pretty much constantly writing to the boot
volume at least (you could mount write-protected data volumes) whether
you are typing any commands or not.
In the case of CP/M, you could decide to accept a 1GB card and present
it to the host as, say, a 5MB drive. That would be rather a lot of
space to a CP/M machine. You'd be able to fill that drive 200 times,
in theory, before you reused a single segment of the CF card. In the
case of VMS, though, a 5MB boot volume isn't particularly useful. The
smallest I've ever shoehorned VMS 6.0 into (and it was a trick) was an
RD54 at 154MB. Practically speaking, unless you are going to use it
only with pre-VMS-5.0 distros, you are going to want to present a
drive to the VAX in the hundreds of megabytes. If you decide on, say,
250MB, that's quadruple sector redundancy for complete drive
re-writes, but in practice, only a percentage of the drive is going to
change on a frequent basis as the machine runs. Since the OP
mentioned VAX/VMS and I'm reasonably certain that the target would be
a MicroVAX with either an RQDX1, RQDX2 or RQDX3, or the near
equivalent in an MicroVAX 2000, it's likely that the RQDX controller
is the only drive controller on the system. Since part of the problem
with machines of that vintage is the lack of available, reliable,
large ST506/ST412-interface MFM drives, the whole point of drive
emulation is to take a MicroVAX and get it running with no real MFM
drives, just emulated ones. Therefore, you will end up with the page
file and swap file on the emulated drive. Even if you aren't doing
anything "interesting" with your machine, the pagefile and swapfile
will still see activity. If you start doing things that need lots of
memory, starting VMS Mail, or running a compiler, or using a word
processor like MASS-11 (to name a few things we used to do all day
long with our departmental VAX 15+ years ago), there will be a flurry
of reads and writes at each image launch.
While it would "work" to run a VAX from a CF drive, I don't think the
lifetime of the CF card would be particularly high. I can't quantify
it off the top of my head, but to speculate wildly, I think I'd rather
depend on an RD53 drive as unreliable as they are (I still have
several from the 1980s,. but I don't tend to use them as boot
volumes).
As for experience with Flash wear and shrinking capacity, I ran an
"Earthdial" at the South Pole over sunny parts of 2004 and 2005. My
camera was an old 2megapixel Olympus, chosen because a) it was in the
cupboard, and b) it had a serial interface. I wrote a script to take
a picture every 2.5 minutes, dump it, add some text at the top and
bottom, and post it to my web page. Over a few weeks of operation,
that flash card lost two photographs-worth of capacity from being
asked to make 576 writes of a few hundred sectors, day after day.
Percentage-wise, it was probably 3% of the capacity lost over 4 months
of constant use. While the card would then last for years in that
arrangement, it does seem like a fast decline to me. This card was an
older one. Perhaps newer ones have 10 or even 100 times as many write
cycles as ones ten years ago, but that only delays the inevitable.
If Flash advances to the point that using it in a write-intensive
environment would have a lifetime measured in multiple years, then
it's probably a viable replacement for rotating media. We are, after
all, accustomed to replacing hard drives every three to five years
anyway. I don't think I'd want to intentionally set up a system where
I have to be concerned about how fast it's degrading, and watch the
hour-meter tick away its remaining lifetime. Yes, the argument could
be made that disks do that anyway, but I don't think it's the same
when you can set your calendar by the self-destruct date.
-ethan