Re: newfs limits? 10TB filesystem max?

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Thu, 17 Feb 2005 16:05:11 -0800 (PST)
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.
Received on Thu Feb 17 2005 - 23:05:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:28 UTC