From owner-freebsd-firewire@FreeBSD.ORG Mon Aug 18 22:06:50 2003 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CDA416A4EE; Mon, 18 Aug 2003 22:06:48 -0700 (PDT) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [133.11.205.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B84F5441E2; Mon, 18 Aug 2003 21:42:09 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is2.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 944E23783A3; Tue, 19 Aug 2003 13:42:08 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h7J4g7uJ020343; Tue, 19 Aug 2003 13:42:07 +0900 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.135.3])3.3.5-GR) with ESMTP id AJT27191; Tue, 19 Aug 2003 13:42:06 +0900 (JST) Date: Tue, 19 Aug 2003 13:42:06 +0900 Message-ID: From: Hidetoshi Shimokawa To: In-Reply-To: <54827.209.157.141.26.1060837094.squirrel@webmail.meer.net> References: <54827.209.157.141.26.1060837094.squirrel@webmail.meer.net> User-Agent: Wanderlust/2.11.0 (Wonderwall) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 05:06:52 -0000 At Wed, 13 Aug 2003 21:58:14 -0700 (PDT), wrote: > > Hello freebsd-firewire. > > I am new to freebsd, and I am planning on changing my file > server from linux to freebsd. > > At the same time I would also like to move to firewire > (from ide). I don't have large bandwidth requirements, so I'm > just assuming that I'm not going to get too much lower performance. > > One basic question that I have is: Is it possible to set an > automatic spindown of my firewire drives? I looked at the camcontrol > manpage, but it doesn't say anything interesting. freebsd-scsi should be the better place to ask this question. There might be a mode page to control the automatic spindown but I don't know. > I am planning on setting up a raid-5 array (on firewire). Are there > any issues that I should be aware of?? Since I haven't tried > firewire yet, and I am (slightly) worried about performance, I wonder > if putting all drives on one chain will give me problems. Would > splitting drives over multiple firewire busses on the same card help > any, or would I have to get multiple firewire cards to increase > performance? Note, this is a server machine, so I'll only be accessing > data through 100Mbit ethernet via samba. Because ports share the bandwidth of the bus, you need another card(chip) to increase bandwidth. You can have only a bus by a chip even if it has multiple ports. I got about 32MB/s for a drive and 40 MB/s for two drives on a same bus under sequential read. Also, you could notice performance decreasing for buses which have large number of nodes because of arbitration gap count increasing. > Also, I was wondering if there are problems with the order firewire > clients are brought up in the bus. Will they come up as different > each time I boot up? Ie, if I have 2 disks, coming up as da0 and da1, > will the same disk come up as da0? Or will I have cases where one > disk will come up as da0, then after a reboot the other disk will come > up as ad0? If that is in fact the case, will that cause problem with > vinum identifying which disk is which, or will it work because of the > labels vinum puts on the disks themselves? If you plan to use FreeBSD-5.X, geom_vol_ffs kernel module would help. It wires down the specific UFS partition to specific device name. If you don't mind to apply a patch to sbp.c, you can hard-code EUI64->target id mapping table into the source code. The biggest problem for wire-down in SBP is that SBP has (64+48)bit identifier for the device but CAM cannot handle such big number. So we have to map the device to small target numbers sequentially. > Thank you!! > > --george /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html