From owner-freebsd-current@FreeBSD.ORG Fri Feb 18 00:05:33 2005 Return-Path: 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 7171C16A4CE for ; Fri, 18 Feb 2005 00:05:33 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9644743D41 for ; Fri, 18 Feb 2005 00:05:32 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j1I05BbL031106; Thu, 17 Feb 2005 16:05:19 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200502180005.j1I05BbL031106@gw.catspoiler.org> Date: Thu, 17 Feb 2005 16:05:11 -0800 (PST) From: Don Lewis To: brooks@one-eyed-alien.net In-Reply-To: <20050217195559.GA6201@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: anderson@centtech.com Subject: Re: newfs limits? 10TB filesystem max? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 00:05:33 -0000 On 17 Feb, Brooks Davis wrote: > On Thu, Feb 17, 2005 at 01:49:12PM -0600, Eric Anderson wrote: >> Brooks Davis wrote: >> [..snip..] >> >>>>>>I've just built an enormous 10TB filesystem. When >> >>>>>>trying to newfs the disk, it bombed with something >> >>>>>>like "cannot allocate memory" after something like >> >>>>>>23xxxxxxxxx sectors.. I noticed disklabel complains >> >>>>>>about disks with more than 2^32-1 sectors not being >> >>>>>>supported.. >> >> [..snip..] >> >In that case, you probably don't actually have a bsdlabel there. It's >> >not longer required with geom since you can newfs disks. >> > >> >-- Brooks >> > >> >> Ok - but I'm still wondering why newfs can't newfs.. Here's the real error >> pasted in: >> >> a newfs -U /dev/vinum/plex/raid.p0 gives: >> ... >> 23425543840, 23425920160, 23426296480, 23426672800, 23427049120, >> 23427425440, 23427801760, 23428178080, 23428554400, 23428930720, >> 23429307040, 23429683360, 23430059680, 23430436000, 23430812320, >> 23431188640, 23431564960, 23431941280, 23432317600, 23432693920, >> 23433070240, 23433446560, 23433822880, 23434199200, 23434575520, >> 23434951840, 23435328160, 23435704480, 23436080800, 23436457120, >> 23436833440, 23437209760, 23437586080, 23437962400, 23438338720,newfs: >> wtfs: 65536 bytes at sector 23438715040: Cannot allocate memory >> >> But: >> newfs -U -s 23438338720 /dev/vinum/plex/raid.p0 >> works.. So I'm losing the last part of my partition.. > > I'm guessing you are hitting the process datasize limit with newfs. You > should be able to raise it a bit from the default. Be warned, that fsck > has much higher memory requirements so recovery may be difficult if not > impossiable without a 64-bit machine. I don't know of any reason that newfs would need a lot of memory. I would think that it's memory usage would be independent of file system size. I just looked at the code, and the error message seems to be triggered by bwrite() in libufs failing. There is a potential pair of calls in malloc()/free() in bwrite(), but I think the more likely problem is that pwrite() is failing. I seem to to recall seeing a recent kernel commit that changed an ENOMEM error return to something else like EFBIG or ENOSPC.