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
Jfs-discussion@list...
https://lists.sourceforge.net/lists/listinfo/jfs-discussion