Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

fsck_ufs: cannot alloc 94208 bytes for inoinfo

96 views
Skip to first unread message

Olivier Mueller

unread,
Feb 26, 2008, 5:05:09 PM2/26/08
to freebsd...@freebsd.org
Hello,

"fsck_ufs: cannot alloc 94208 bytes for inoinfo"

This is what I get after about one hour while trying a fsck on a large
(1.4TB) partition "broken" since a power outage.

HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and:

da0: <COMPAQ RAID 5 VOLUME OK> Fixed Direct Access SCSI-4 device
da0: 135.168MB/s transfers
da0: 1430488MB (2929640988 512 byte sectors: 255H 63S/T 65535C)

Mounting with option -f (force) seems to work, so I guess there is
still hope :)


Now I added this to the /boot/loader.conf:
kern.maxdsiz="1073741824" # 1GB
kern.dfldsiz="1073741824" # 1GB
and I'm trying the fsck again, but I'm not sure it will help.

Would you maybe have other suggestions?
Regards,
Olivier


Alfred Perlstein

unread,
Feb 26, 2008, 8:02:49 PM2/26/08
to Olivier Mueller, freebsd...@freebsd.org

See "limit/ulimit" to make sure you're giving the fsck process
unlimited data size.

you can also likely safely increase the maxdsiz to 1.5GB and
still be ok, just make sure to turn on swapping.

-Alfred

Oliver Fromme

unread,
Feb 27, 2008, 1:45:47 PM2/27/08
to freebsd...@freebsd.org, om-lis...@omx.ch
Olivier Mueller wrote:
> "fsck_ufs: cannot alloc 94208 bytes for inoinfo"
>
> This is what I get after about one hour while trying a fsck on a large
> (1.4TB) partition "broken" since a power outage.
>
> HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and:

Your fsck will need roughly 1 GB memory per 1 TB file
system size. That formular was posted some time ago on
the -fs mailing list. It only applies with the default
newfs parameters -- if you used other parameters (inode
density, bsize/fsize), fsck's memory requirements are
different.

> Now I added this to the /boot/loader.conf:
> kern.maxdsiz="1073741824" # 1GB
> kern.dfldsiz="1073741824" # 1GB
> and I'm trying the fsck again, but I'm not sure it will help.

Given the above formula, it's probably not enough, so you
might have to increase it further. Also make sure that
you have enough swap space.

If you have a spare box, it might be helpful to transplant
some RAM from it so fsck doesn't have to swap.

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
-- Tom Cargil, C++ Journal

Matthew Dillon

unread,
Feb 27, 2008, 2:53:01 PM2/27/08
to freebsd...@freebsd.org, om-lis...@omx.ch
fsck's memory usage is directly related to the number of inodes and
the number of directories in the filesystem. Directories are
particularly memory intensive.

I've found on my backup system that a UFS1 filesystem with 40 million
inodes is about the limit that can be fsck'd (at least with a 32 bit
architecture). My cron jobs keep my backup partition below that point.
Even in a 64 bit environment you will be limited by swap and the sheer
time it takes for fsck to run. It takes well over 8 hours for my
backup system to fsck.

You can also reduce fsck time by reducing the number of cylinder
groups on the disk. I usually max them out (-c 999 and newfs then
sets it to the maximum, usually in the 50-80 range). This will
improve performance but not reduce the memory required.

-Matt

Peter Jeremy

unread,
Feb 28, 2008, 1:33:13 AM2/28/08
to freebsd...@freebsd.org, om-lis...@omx.ch
On Wed, Feb 27, 2008 at 11:53:01AM -0800, Matthew Dillon wrote:
> You can also reduce fsck time by reducing the number of cylinder
> groups on the disk. I usually max them out (-c 999 and newfs then
> sets it to the maximum, usually in the 50-80 range). This will
> improve performance but not reduce the memory required.

Note that this advice is relevant for UFS1 only. In UFS2, '-c'
specifies the cylinder group size in _BLOCKS_ not cylinders and
defaults to the maximum size for the given blocksize and IPG etc.

--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.

0 new messages