virtual disk system

Mark Spencer (markster@marko.net)
Fri, 20 Feb 1998 15:35:52 -0600 (CST)


I was driving to school today and thought of a problem and a potential
solution I might try working on for my senior design project, and I wanted
to run it by some kernel people :)

1. I work at a place. We've got lots of machines with lots of disk
drives of lots of different sizes. Some are almost empty, others are at
capacity.

2. It would be great if when my physical disk filled up I could just
start writing on emptier disks located either in my machine or across the
network.

3. It might be difficult to get every filesystem to support the idea of
growing to accomodate more space.

4. Why not implement a virtual disk, somewhat like a virtual memory
system. Think of your local disk as a kind of cache, and the rest of the
network as a kind swap. Ever machine thinks that it has 20 gigs of space
or whatever, but it really doesn't. You just map virtual blocks to real
blocks, either locally or on remote systems. You would have /dev/vd0 or
/dev/vd1, etc etc which could be configured to be just about any size
(larger sizes of course would have heavier fs overhead associated with
them).

5. This is *not* a filesharing system. It would be implemented at the
*block* level. There would be an equivalent of a "page table" for looking
up information. Only the original writer is guaranteed to know where
their files were. Sharing would have to be done with NFS or something
else.

6. The system would be multiple logical volumes, multiple physical
volumes, but with no obvious map between them. I would try to keep it as
close to the virtual memory analogy as possible (see below # 8).

7. The only obvious *filesystem* modification that would be necessary is
that when an inode or equivalent is freed, an ioctl() would have to be
added to tell the disk that it is now free so it could be overwritten.
Perhaps this could be added to the VFS code and no individual filesystems
would need modification at all!

8. Rather than having a dedicated, fixed size cache, the system would be
an all-cache system. When I requested a file to my workstation, if it was
not already local, it would be copied to my local hard drive over
something else, and then whoever I copied it from could mark that block as
"able to be written over" since I have a valid copy.

9. Some kind of redundancy (Can I use anything from RAID in this?) would
be a great feature. Simple mirroring at the least, but that seems rather
inefficient. At the simplest level, imagine that for every block in the
virtual system, there are two physical blocks which contain the data (on
different physical media). Then, if there is a media failure, you simply
replace the bad media and ask all the other devices (which have exactly
one copy of your data) to tell you what you had on it. Instant network
level redundancy without backups.

10. A quota system would probably be desirable to keep it from going
completely out of hand, but then again, if you pick reasonable partition
sizes, it should be okay since you won't expand past what you decide the
partition be.

Anyway, it's an idea that I would like to persue if any of you think it's
viable. It would be alot of work to design, but hey, that's what senior
design is all about, right? Any comments would be greatly appreciated.

If you have any interest, please e-mail me, and maybe I can setup a list.
I've actually thought through the problem more than I can relate here.

-Mark Spencer

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu