"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?
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.
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
> 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.
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
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.
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.
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.