That thought had crossed my mind... but I'm assuming there'd be some issues
related to the buffer cache while doing that. Secondly, I want the
replication to be N Way. For example:
If I write a file on host X, it's filtered over to host Y. Then, if I write
to host Y, it's filtered over to host X.
I'll give it a try, it can't break (much).
Thanks,
Jeff
-----Original Message-----
From: pavel-velo@bug.ucw.cz [mailto:pavel-velo@bug.ucw.cz]
Sent: Monday, July 31, 2000 7:01 PM
To: Jeff McNeil; linux-kernel@vger.rutgers.edu
Subject: RE: Block Layer File/FS Replication?
Hi!
>I've been tossing around the following Idea.
>
>1. Make every block update availabile via a pseudo-device, /dev/rep0 -
>n. Each minor in this case could represent an individual
>(configurable) file system.
>
>2. Add an additional system call, which would update FS blocks based on
>a parameter, which would contain the block data, inode, and an offset.
>Proc file to start/stop replication.
>
>3. Lastly, write a user space network aware daemon to read from the
>pseudo-device, and transfer block information to a (multiple) servers
>running listeners.
>
>Granted, FS and block size would have to be the same on both ends, but
>that's trivial. I've also tossed around the idea of using raid 1over a
>network block device, but I see visions of caching issues with that one
>already.
why not just run raid1 over real disk and nbd?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:07 EST