>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes:

    re> The win is nonvolatile main memory. When we get this on a
    re> large, fast scale (and it will happen in our lifetime :-) then
    re> we can begin to forget about file systems, with an interim
    re> step through ramdisks.

yeah I still think an unrealized and very cheap winning design would
be to transform part of the main SDRAM into novolatile memory by
adding a hardware watchdog device that backs it up to FLASH (and
writing a software driver to handle the restore on boot).  It's not
hot-pluggable, but at least it's pluggable: with the power off you
could move the flash module from one machine to another.  The
companies that write motherboard BIOS seem way too incompetent to
manage this reliably enough to be useful, but for some high-end
botique server maybe one could pull it off.

but as for not needing filesystems, I can't imagine it.  The smalltalk
zealots like to talk about their persistence layer, but when you ask
them, ``how do you upgrade the software while keeping the old data?''
they hem and haw and say ``it's not really *THAT* bad,'' but I suspect
the reason DabbleDB is only available hosted isn't just revenue
model---I bet they couldn't safely have customers doing their own
software upgrades.  I bet those guys do all upgrades with the Senior
Wizard present and the debugger attached, and use convuluted schemes
of snapshots and parallel development environments to supervise the
whole delicate cutover.

We'll still need snapshots, clones, backup/replication tools, ACL's
MAC-labels zones, byterange locking, recovery/verification tools for
spotting bugs in the NeoFilesystem code itself, u.s.w.  I think the
tree-of-bytestreams metaphor might end up enduring, but squeezing
maximal performance out of a novolatile device that one can access
without a disk driver, sometimes without even a syscall, will need new
userland API's, a thick subtle library that can cooperate with other
untrusted copies of itself, and a strong focus on ``zero copy''.

Attachment: pgpG7hJLu96dV.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to