Date: Tue, 25 Jun 2013 21:36:54 +0100 From: Frank Leonhardt <frank2@fjl.co.uk> To: Warren Block <wblock@wonkity.com> Cc: freebsd-doc@freebsd.org Subject: Re: Handbook obsolescence scan: "The vinum Volume Manager" Message-ID: <51C9FF66.6020302@fjl.co.uk> In-Reply-To: <alpine.BSF.2.00.1306251143080.65313@wonkity.com> References: <alpine.BSF.2.00.1306250933560.64224@wonkity.com> <51C9CD3B.4090001@fjl.co.uk> <alpine.BSF.2.00.1306251143080.65313@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25/06/2013 18:47, Warren Block wrote: > On Tue, 25 Jun 2013, Frank Leonhardt wrote: > >> On 25/06/2013 16:43, Warren Block wrote: >>> Next on the list of potentially outdated things in the Handbook: >>> "The vinum Volume Manager", a whole chapter on vinum. Actually, it >>> is really now about gvinum. >>> >>> Are there any situations where new users should be advised to use >>> gvinum rather than ZFS or gconcat/gstripe/gmirror? >>> >>> What reasons are there for this chapter to remain in the Handbook >>> given the newer, simpler alternatives? >>> >>> If the information should remain, why should it be separate from the >>> GEOM chapter? >> >> I remember reading this and the gmirror stuff at the same time and >> wondering what it was all about. Whilst I'm generally not in favour >> of chucking stuff out of a manual if it exists on the ground, at the >> very least this could do with a sanity warning. At the time I had no >> way of knowing whether one method or the other was deprecated. I >> suppose I made a lucky guess. > > That is exactly the problem with old information. gvinum still works, > but there is little reason to recommend it over the newer solutions. > > Rather than just removing this chapter, it could be converted to a > separate article, along with an added introduction about when it was > removed from the Handbook and why. Off list here - Couldn't agree more! In fact the whole disk mirroring thing still confuses me, as there are too many options and no guide for choosing between them. As far as I understand it, gmirror is the way to go in most cases because you end up with two identical drives, either of which can be salvaged from the wreckage after a crash, stuck in to another PC and booted. ZFS is the solution if you want to spread lots of data across lots of drives. Actually, in practical terms, I don't see why ZFS is better than pairs (or threes) of gmirrored drives mounted on to one file system in the traditional way. Perhaps I just don't get it, or perhaps I'm just too traditional to give up on the idea that it's good to know which drive a particular file is on. And then there's are the options for striping, which I avoid in favour of mirroring because disks are big and cheap now, and a RAID-5 crash is a PITA. So yes - please do anything to help make sense of this. It needs someone who knows about all the options to compare them properly. I'm sorry to say that I've only ever bothered with what works for me. Regards, Frank.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C9FF66.6020302>