From owner-freebsd-fs@FreeBSD.ORG Wed Jan 23 05:45:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33A87E9F; Wed, 23 Jan 2013 05:45:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E688FA40; Wed, 23 Jan 2013 05:45:28 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r0N5jO4R090480; Tue, 22 Jan 2013 22:45:25 -0700 (MST) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD From: Scott Long In-Reply-To: <50FF7764.2020803@freebsd.org> Date: Tue, 22 Jan 2013 22:45:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DD4A455-A351-4676-979B-4D7199F0FA1C@samsco.org> References: <314B600D-E8E6-4300-B60F-33D5FA5A39CF@sarenet.es> <565CB55B-9A75-47F4-A88B-18FA8556E6A2@samsco.org> <50FF7764.2020803@freebsd.org> To: David Xu X-Mailer: Apple Mail (2.1499) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 05:45:29 -0000 On Jan 22, 2013, at 10:38 PM, David Xu wrote: > On 2013/01/22 22:33, Scott Long wrote: >>=20 >> On Jan 22, 2013, at 4:03 AM, Borja Marcos wrote: >>=20 >>> (Scott, I hope you don't mind to be CC'd, I'm not sure you read the = -FS mailing list, and this is a SCSI//FS issue) >>>=20 >>>=20 >>>=20 >>> Hi :) >>>=20 >>> Hope nobody will hate me too much, but ZFS usage under FreeBSD is = still chaotic. We badly need a well proven "doctrine" in order to avoid = problems. Especially, we need to avoid the braindead Linux HOWTO-esque = crap of endless commands for which no rationale is offered at all, and = which mix personal preferences and even misconceptions as "advice" (I = saw one of those howtos which suggested disabling checksums "because = they are useless"). >>>=20 >>> ZFS is a very different beast from other filesystems, and the setup = can involve some non-obvious decisions. Worse, Windows oriented server = vendors insist on bundling servers with crappy raid controllers which = tend to make things worse. >>>=20 >>> Since I've been using ZFS on FreeBSD (from the first versions) I = have noticed several serious problems. I try to explain some of them, = and my suggestions for a solution. We should collect more use cases and = issues and try to reach a consensus. >>>=20 >>>=20 >>>=20 >>> 1- Dynamic disk naming -> We should use static naming (GPT labels, = for instance) >>>=20 >>> ZFS was born in a system with static device naming (Solaris). When = you plug a disk it gets a fixed name. As far as I know, at least from my = experience with Sun boxes, c1t3d12 is always c1t3d12. FreeBSD's dynamic = naming can be very problematic. >>>=20 >>=20 >> Look up SCSI device wiring in /sys/conf/NOTES. That's one solution = to static naming, just with a slightly different angle than Solaris. I = do agree with your general thesis here, and either wiring should be made = a much more visible and documented feature, or a new mechanism should be = developed to provide naming stability. Please let me know what you = think of the wiring mechanic. >>>=20 >>>=20 >=20 > I am curious, because we already have devfs, why do not the driver = create device entry like following ? >=20 > /dev/scsi/bus0/target0/lun0/ada0 > /dev/scsi/bus0/target0/lun0/ada0s1 > /dev/scsi/bus0/target0/lun0/ada0s2 > ... >=20 > This will eliminate the needs of hints. >=20 The problem is that this structure is east for computers to manipulate, = but hard for humans to manipulate. One thing that could be done with = devfs, however, is to create device aliases. i.e.: crw-r----- 1 root operator 0x86 Jan 2 23:00 c0b0t1l0 lrwxr-xr-x 1 root wheel 6 Jan 2 23:00 da0 -> c0b0t1l0 This gets hairy because aliases then need to be made for partitions, = unless some sort of transparent translator is created in devfs. It also = gets complicated because you still need to arbitrate the controller = numbering (the 'c0' in the above example), so wiring might still be = needed. Scott