Date: Thu, 10 Jul 2003 13:38:21 -0700 From: Joshua Oreman <oremanj@webserver.get-linux.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: hackers@freebsd.org Subject: Re: Mirroring using vinum+NFS Message-ID: <20030710203821.GA5576@webserver.get-linux.org> In-Reply-To: <20030710201013.GA1892@cirb503493.alcatel.com.au> References: <20030710201013.GA1892@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 11, 2003 at 06:10:13AM +1000 or thereabouts, Peter Jeremy wrote: > I'm looking at building a fileserver and want to mirror the data > across two systems (if one fails, I can use the other). > > Consider system A as the server and system B as the mirror. In theory, > on system A I should be able to: > mount B:/big/data/blob /remote > vnconfig /big/data/block as vn0 > vnconfig /remote as vn1 > vinum mirror vn0+vn1 as serverdata > mount /dev/vinum/serverdata /serverdata > export /serverdata > > (The reason for running the local filesystem through a vnode mount is > to make system A and system B interchangeable). Does anyone see any > problems with this? Any ideas on how much overhead a 50-100GB vnode > mount adds over a raw device? This will not help you at all. Vnconfig only deals with *files*. Directories are outside its realm. Since you have no direct write permission to the device over NFS, Vinum has no chance of working there. > > Can anyone suggest the behaviour if system B fails? Can vinum treat > this as a "failed disk" or will it get caught by the NFS I/O blocking > until the failed server returns? Irrevelant. See above. > > Does anyone have any alternative suggestions? It would probably be > enough to watch all local writes and mirror them onto the remote > system. This approach might even be cleaner than a true mirror but I > don't believe I can do this without a fair amount of local development > (watching writes either using kqueue or a custom geom module and > queueing them into a second filesystem via some protocol). The volume > of data (size and number of files) makes an rsync approach fairly > impractical. Try kqueue. Also, even though rsync seems impractical, it may be necessary for this setup. -- Josh > > Peter > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030710203821.GA5576>