On 7/29/05, Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-07-29 at 16:28 -0400, Alex Deucher wrote:
> > On 7/29/05, Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > On 7/29/05, Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> > > > On Fri, 2005-07-29 at 16:15 -0400, Alex Deucher wrote:
> > > > > On 7/29/05, Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> > > > > > On Fri, 2005-07-29 at 15:47 -0400, Alex Deucher wrote:
> > > > > > > One more thing, fsck find no errors.  the volume is clean.
> > > > > >
> > > > > > Are you running a recent version of jfsutils?  Versions prior to 
> > > > > > 1.1.6
> > > > > > don't do much to verify the directory table.  There was a big-endian
> > > > > > related fix in 1.1.7.
> > > > >
> > > > > 1.1.7-1 from debian.
> > > >
> > > > Hmm.  Maybe it's okay on disk then.  odd.
> > >
> > > I just tried to remove one of the problematic directories and I got this:
> > > blkno = 0, nblocks = 0
> > > ERROR: (device dm-0): dbFree: block to be freed is outside the map
> > > ERROR: (device dm-0): remounting filesystem as read-only
> > >
> >
> > Upon umounting and fscking the volume, I now get this error:
> > fsck 1.37 (21-Mar-2005)
> > fsck.jfs version 1.1.7, 22-Jul-2004
> > processing started: 7/29/2005 16.26.39
> > Using default parameter: -p
> > The current device is:  /dev/vg00/lvol0
> > Block size in bytes:  4096
> > Filesystem size in blocks:  1855565824
> > **Phase 0 - Replay Journal Log
> > **Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
> > Warning... fsck.jfs for device /dev/vg00/lvol0 exited with signal 10.
> 
> SIGUSR1?  Maybe it means something else on sparc64.  Can you run
> fsck.jfs under gdb to see where it traps?  You'll need to give fsck.jfs
> the device (/dev/vg00/lvol0), since fsck figures this out
> from /etc/fstab and sends the device to the lower level command.
> 
> I think there's something about sparc64 that jfs isn't handling
> correctly.  I've run a lot on ppc64, so I don't know what the difference
> would be.
> 

Just wondering if you had any ideas about this behavior.  I'm willing
to run any tests or try any patches.  For reference it seems to be a
sparc64 thing since we have the exact same set up on AMD64 and it
works flawlessly (7 TB JFS volume).

Thanks,



> --
> David Kleikamp
> IBM Linux Technology Center
> 
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to