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