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
