DragonFly BSD
DragonFly kernel List (threaded) for 2004-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 13 Aug 2004 11:09:42 -0700 (PDT)

:Thanks for that explanation.  This would be very useful to a lot of
:people, it sounds exciting!
:So the idea could be, every user's workstation in a scientific lab
:could be part of such a cluster: at one level it's their regular
:desktop machine, but at another level it's also a high-performance
:computing cluster.  Much better than the current setup of having a
:256-node cluster but also providing 256 separate workstations, one for
:each user.  At an extreme limit perhaps several labs could network all
:their machines this way to create an enormous cluster.  For some kinds
:of problems the benefits could be huge...  

    Also, the abstraction of 'being part of a cluster' does not necessarily
    imply that a machine's entire resources are devoted to the 'cluster'.
    It is my intention to allow system resources to be partitioned off so
    your workstation could be a standalone box but also provide resources
    (such as a disk partition, memory, cpu, and networking services) to
    a cluster, or to several clusters.  

    I want it to be as simple as a config file:

    cluster lab_cluster {
	hostid "dillon"
	disk /dev/ad0s1e as "disk1"
	netif fxp0 limit 5mbyte/s
	rendezvous [list at least one other machine in the cluster]
	cpu nom 50% max 75%
	memory nom 64mb
	reliability medium

    cluster home_cluster {
	hostid "mylabstation"
	link my.home.machine
	filesystem "/home/dillon" as "/dillon"
	cpu nom 50% max 100%
	memory nom 64mb
	reliability high

    One would be able to export raw disk partitions as block devices, or
    file systems (fully cache coherent within the cluster, managed by
    the kernel), cpu, memory, etc.

    One would be able to 'push into' a cluster (that is, run a shell or a
    program that operates 'as part of the cluster' rather then operates 
    just on the local machine), something like this:

    cexec home_cluster /bin/csh


    cexec home_cluster xterm

    or <grin>:

    cexec lab_cluster startx

    In anycase, we are talking ~2 years down the line for that kind of
    functionality.  It will happen, though, and the more I progress with 
    the VFS work the better I'll be able to guage the cluster.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]