From owner-freebsd-stable@FreeBSD.ORG Mon Apr 18 06:33:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCACE106566B for ; Mon, 18 Apr 2011 06:33:33 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 598438FC13 for ; Mon, 18 Apr 2011 06:33:33 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p3I6XLJT025609 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Apr 2011 09:33:27 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DABDB31.90301@digsys.bg> Date: Mon, 18 Apr 2011 09:33:21 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110417123232.GA96423@laa.zp.ua> <20110417142135.GA51568@icarus.home.lan> <20110417163135.GC96423@laa.zp.ua> <20110417183014.GA55444@icarus.home.lan> <20110417184538.GG96423@laa.zp.ua> <20110417185402.GA55984@icarus.home.lan> In-Reply-To: <20110417185402.GA55984@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS root on MB Intel S3420GP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:33:33 -0000 On 17.04.11 21:54, Jeremy Chadwick wrote: > I don't recommend enabling ahci.ko after the OS has already been > installed on an adX disk, simply because I believe the combination of > GEOM+CAM+ahci may show different geometry details than GEOM+ata would. > With the disclaimer that I haven't studied all code to confirm this, but adX and adaX (with ahci.ko) have always played the same for me - geometry wise. I believe the translation is always 1:1. At least on modern SATA drives -- olderdrives from the transitional epoch of different CHS, LBA etc experiments might behave differently. Migration from gmirror to zfs(root) is trivial. Having only two gmirror-ed disks, you could replace that with ZFS mirror. Having 4-way gmirror can let you do a 4-disk ZFS migration (raidz1 or raidz2). I tend to do all of my new systems with ZFS on root. Probably because I no longer have to do systems that run with few MB of RAM :) - the I would use UFS alwats. One nice feature of ZFS I have discovered is with USB flash media. You are not typically supposed to write much to that media, but using UFS on USB sticks is awful. On contrary, when used with ZFS, the USB sticks behave much differently, because ZFS will group writes and not do silly things like issue lots of 512 byte writes. So, you may have complete development system on an USB stick, or a pair of these. The only real trouble with USB stisks is that some motherboards behave unpredictable as to boot order, but this is improving. My recent "install procedure" never used the FreeBSD release media. Instead, I have created myself USB stick distribution media (can work with CD/DVD as well, or over diskless boot), using a procedure like this: - on an up to date FreeBSD system, do make buildworld; make buildkernel - insert the USB stick, create filesystem. UFS or ZFS, doesn't matter - make installworld, make installkernel, make distribution to the mounted USB stick - fix fstab and loader.conf on the USB stick (optional) - copy over src and ports tree ro the USB stick - do in place rebuild/reinstall of the world, kernel and any packages you may need (end optional) - put the USB stick in my pocket Next time, I need to install a server on site, take the USB stick out of my pocket, plug it in one of the USB ports, boot the server, run small script (similar to that in the root-on-zfs guides), create ZFS on root and am done with it. I would use either pair of USB sticks for that, a separate set of (two) disk drives, or 'all' of the system's drives for this install, depending on the systems intended usage and hardware configuration. Typically on a multi-bay system I would do the root on a separate set of disks/USB flash in order to simplify documentation and operator training. If the system needs to be installed remotely, I would typically use rKVM (most rackmount-intended motherboards have this functionality), attaching either the prepared USB stick or it's image are virtual media and booting over that the new system. Many of these things can be done differently of course, it will depend on circumstances, but I hope the general idea is useful. Jeremy, one of the reasons I switched many systems to "pure ZFS" was related to the memory allocation troubles between USF and ZFS we observed for quite long time. Having pure ZFS system eliminates these issues completely. I do have still few mixed systems - only laziness and lack of (down)time prevented me from switching these to pure-ZFS too. My rationale is that if something breaks, it is likely it will break with or without ZFS on root. In either case, I would have to load FreeBSD from other media. So it does not matter from where you boot the system. One final note, on ZFS pool naming. I would traditionally name my root-on-zfs pool 'system'. However, this makes it difficult and error prone to create new zpools. Therefore, I have zpool of 'boot' for my install USB sticks and also have addopted the practice of naming the root pool after it's system's name. For example 'hostABCroot' or 'hostABCsystem'. This has never been an issue with UFS, until filesystem labels appeared and still not that many people use these. With ZFS, you cannot escape. Daniel