Re: dump/mksnap_ffs & fsck failure

From: Chris Elsworth <chris_at_shagged.org>
Date: Thu, 7 Oct 2004 17:55:20 +0100
On Thu, Oct 07, 2004 at 06:34:15AM -0700, Kris Kennaway wrote:
> On Thu, Oct 07, 2004 at 12:08:03PM +0100, Chris Elsworth wrote:
> > Hello all,
> > 
> > Is this likely to be filesystem corruption in a really bad way, or a
> > ufs bug:
> > 
> > # /sbin/dump -0 -LuaC32 -f /backup/root.dump /
> > mksnap_ffs: Cannot create //.snap/dump_snapshot: Input/output error
> > 
> > # fsck_ufs /dev/mirror/gma
> > ** /dev/mirror/gma (NO WRITE)
> > ** Last Mounted on /
> > ** Root file system
> > ** Phase 1 - Check Blocks and Sizes
> > fsck_ufs: cannot alloc 4294967292 bytes for inoinfo
> 
> Why can't it write to the device?  Is it mounted read-write?  Drop it
> to read-only and retry.  Vice versa for the root filesystem; is it
> mounted read-only?

Ah, sorry, should have said - yes, the filesystem was mounted
read-write (/dev/mirror/gma and / are the same thing), but it does the
same thing in read-only:

# init 1
..
# umount -a
# mount -o ro /
# mount
/dev/mirror/gma on / (ufs, local, read-only)
devfs on /dev (devfs, local)
# fsck -y /
** /dev/mirror/gma
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
fsck_ufs: cannot alloc 4294967292 bytes for inoinfo


Surely fsck doesn't really need 4GB of physical mem? There is 1GB of
physical and 4GB of swap configured in this.

-- 
Chris
Received on Thu Oct 07 2004 - 14:55:26 UTC

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