From owner-freebsd-hackers Sat Jul 22 6:53:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 04CBC37B7FF; Sat, 22 Jul 2000 06:53:30 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e6MDrCn19806 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 22 Jul 2000 15:53:15 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e6MDqhq59274; Sat, 22 Jul 2000 15:52:44 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id PAA27477; Sat, 22 Jul 2000 15:52:39 +0200 (CEST) (envelope-from ticso) Date: Sat, 22 Jul 2000 15:52:38 +0200 From: Bernd Walter To: Greg Lehey Cc: Geoff Buckingham , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Multiple ro mounts of vinum volume Message-ID: <20000722155238.A27452@cicely8.cicely.de> References: <20000720095513.A50799@chuggalug.clues.com> <20000720183341.I30599@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000720183341.I30599@wantadilla.lemis.com>; from grog@lemis.com on Thu, Jul 20, 2000 at 06:33:42PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 20, 2000 at 06:33:42PM +0930, Greg Lehey wrote: > On Thursday, 20 July 2000 at 9:55:13 +0100, Geoff Buckingham wrote: > A thing that might bite you here is that ufs is currently limited to 1 > TB per volume. Vinum doesn't have that restriction: if you want to > create a 20 TB volume, and you know how to use the space, Vinum should > work. The problem with ufs is that the block numbers in the inodes > are 32 bit signed values. With 512 byte sectors, the only we can do > it, that means a total address space of 2**9 * 2*31, or 1 TB. At some > time I suspect we're going to need to fix that. Block numbers in inodes are not physical blocks (named sectorsize in UFS source) but logical which is equal to the size of an fragment and thus defaults to 1k. The problem is the driver and VM layer. If vinum would simulate 2k "physical" blocksize it may go up to 4TB if you set the fragment size to 4k. I don't know if any middle calculation might harm or VM is missbehaving. The point I never digged deeper here is because you already sugested changing the driver layer to 64bit byte numbers which was accepted if I remember right. Some of the systems I've setup are near this Limit so I spend some time to find out where the show stoppers are. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message