It didn't appear to be fixed on my machine so I am guessing the same will be for you but definitely curious to here what happens.
On 04/22/2011 12:27 AM, Tim Nufire wrote: > Dave, > > My spam filter ate the first email you sent on this patch but I got this > one.... THANK YOU, THANK YOU, THANK YOU!! :-) > > I deployed this on all my servers this afternoon and will let you know the > first time it gets tested due to a system crash that would normally have > caused the journal replay problem. > > Cheers, > Tim > > On Apr 20, 2011, at 5:39 AM, Dave Kleikamp wrote: > >> On 04/20/2011 07:50 AM, Sandon Van Ness wrote: >>> On 03/07/2011 02:29 PM, Dave Kleikamp wrote: >>>> On Fri, 2011-03-04 at 14:10 -0800, Tim Nufire wrote: >>>>>> From the changelog it does not look like it... I have been running >>>>> patches for all the changes in the changelog and I still have the >>>>> logredo problem on volumes> 16TB. Several of the other problems that >>>>> I've had *are* fixed here so this release is very welcome news! :-) >>>>> >>>>> Dave, any chance the logredo problem will be fixed? It's easy to >>>>> reproduce but I'm assuming it's much harder to fix. Congratulations on >>>>> your new gig! >>>> Turned out to be pretty simple once I took the time to track it down. >>>> This patch fixes the problem for me. Can you try this fix and let me >>>> know if anything else down the line fails? >>>> >>>> Thanks, >>>> Shaggy >>>> >>>> Index: libfs/log_map.c >>>> =================================================================== >>>> RCS file: /cvsroot/jfs/jfsutils/libfs/log_map.c,v >>>> retrieving revision 1.19 >>>> retrieving revision 1.20 >>>> diff -u -p -r1.19 -r1.20 >>>> --- libfs/log_map.c 24 Mar 2008 19:36:57 -0000 1.19 >>>> +++ libfs/log_map.c 7 Mar 2011 22:21:57 -0000 1.20 >>>> @@ -340,7 +340,8 @@ int bMapInit(int vol, /* index in vopen >>>> caddr_t p0 = NULL; >>>> xtpage_t *xp; >>>> int i, j, k, w, pgidx; >>>> - int32_t nbytes, npages, this_page; >>>> + int64_t nbytes; >>>> + int32_t npages, this_page; >>>> uint32_t *pmap, mask; >>>> pxd_t pxd; >>>> int64_t xaddr; >>>> >>>> >>> Well I had a power-outage today. log-redo succeeded on my small (OS) >>> volume but again failed on my large 36TB (33TiB): >>> >>> fsck.jfs version 1.1.15, 04-Mar-2011 >> This doesn't look like it was built with my patch, which I sent on March 7. >> >>> processing started: 4/19/2011 22:04:25 >>> The current device is: /dev/sdd1 >>> Block size in bytes: 4096 >>> Filesystem size in blocks: 8718748407 >>> **Phase 0 - Replay Journal Log >>> logredo failed (rc=-220). fsck continuing. >>> **Phase 1 - Check Blocks, Files/Directories, and Directory Entries >>> **Phase 2 - Count links >>> **Phase 3 - Duplicate Block Rescan and Directory Connectedness >>> **Phase 4 - Report Problems >>> **Phase 5 - Check Connectivity >>> **Phase 6 - Perform Approved Corrections >>> **Phase 7 - Rebuild File/Directory Allocation Maps >>> **Phase 8 - Rebuild Disk Allocation Maps >>> **Phase 9 - Reformat File System Log >>> 34874993628 kilobytes total disk space. >>> 1777545 kilobytes in 608674 directories. >>> 25042310260 kilobytes in 6240464 user files. >>> 0 kilobytes in extended attributes >>> 9121433 kilobytes reserved for system use. >>> 9825339480 kilobytes are available for use. >>> Filesystem is >>> clean. [ ok ] >>> >>> Could be my imagination but the fsck did seem to go faster this time as >>> I checked iostat/uptime right after it finished and was 12 minutes which >>> means the fsck only took 11 minutes vs the 15-20 minutes I remember it >>> taking before. >> All the recent changes have been bug fixes. I don't see anything that >> would explain a performance gain. Of course, the run time is related to >> the number of files and directories, so changes to the contents of the >> file system will have an effect. >> >>> 05:16:51 up 12 min, 1 user, load average: 0.73, 0.98, 0.72 >>> Linux 2.6.33-web100 (dekabutsu) 04/20/2011 >>> >>> avg-cpu: %user %nice %system %iowait %steal %idle >>> 1.63 0.00 1.38 9.41 0.00 87.58 >>> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Jfs-discussion mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/jfs-discussion ------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
