From owner-freebsd-current@FreeBSD.ORG Mon Jan 16 21:56:45 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B624116A41F for ; Mon, 16 Jan 2006 21:56:45 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from bugor.portaone.com (bugor.portaone.com [65.61.200.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CC9443D4C for ; Mon, 16 Jan 2006 21:56:45 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.222] ([70.68.0.213]) (authenticated bits=0) by bugor.portaone.com (8.13.4/8.13.4) with ESMTP id k0GLuWIc080431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2006 13:56:37 -0800 (PST) (envelope-from sobomax@portaone.com) Message-ID: <43CC168D.9080708@portaone.com> Date: Mon, 16 Jan 2006 13:56:29 -0800 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Wojciech A. Koszek" References: <20060114223019.GA99634@FreeBSD.czest.pl> In-Reply-To: <20060114223019.GA99634@FreeBSD.czest.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1243/Sun Jan 15 10:35:18 2006 on bugor.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on bugor.portaone.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: [PATCH] Support for large number of md(4) disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2006 21:56:45 -0000 Hi, IMHO there is better approach to fetch unknown amount of data from the kernel using ioctl(2) facility. The main idea is that you allocate some buffer of size sufficient in 95% of cases (for md(4) I think 8-16 entries are enough), attach it to some structure which has size of the buffer as one of its members and send pointer to that structure as an argument to ioctl(2). Upon receiving this structure the kernel compares size of the buffer with amount of information that it needs to send back. If buffer size is sufficient to hold this information it copies it out and returns number of entries in the buffer as one of members of this structure. If the buffer size is insufficient, the kernel fills in desired size of the buffer in structure members and returns some error code indicating that the provided buffer is insufficient. Upon receiving this error userland increases the buffer size to the size suggested by the kernel (perhaps adding some extra space) and repeats the ioctl(2) calls. -Maxim Wojciech A. Koszek wrote: > Hello, > > Here is a patch for md(4) which fixes current limit for ~95 devices. > > http://freebsd.czest.pl/dunstan/FreeBSD/mdconfig-list.1.patch > > (It's possible to create > 95 md(4) based, disks,but they won't be listed > in mdconfig -l). This change breaks ABI, so both geom_md.ko and > mdconfig(8) has to be rebuilt. > > Comments are welcome.