bad clientid during mount, xfs_repair doesn't work

[Maciek Borowka <Maciej.BOROWKA@ifaedi.insa-lyon.fr>]

Hello,
This problem was already reported to the list, but searching the archive,
I haven't found any solution.

I am using Gentoo Linux with 2.4.17 kernel on a VIA chipset motherboard 
(Athlon processor) and a two disc RAID 0 array (Promise chip on the 
mainboard).

I set up a XFS partition, I am able to use it (I am really delighted with the 
results of the performance tests by bonnie++ :+)), but if I unmount
it, I am no longer able to remount it.

The log shows :
*********************
XFS mounting filesystem ataraid(114,3)
Starting XFS recovery on filesystem: ataraid(114,3) (dev: 114/3)
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed
XFS: log mount failed
*********************



When I do xfs_repair /dev/ataraid/disc0/part3 I get :
*********************
xfs_repair: warning - cannot set blocksize on block device 
/dev/ataraid/disc0/part3: Invalid argument
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
*********************




But when I try xfs_repair -L /dev/ataraid/disc0/part3 :
*********************
xfs_repair: warning - cannot set blocksize on block device 
/dev/ataraid/disc0/part3: Invalid argument
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
[snip]
        - agno = 39
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
[snip]
        - agno = 4
entry ".." at block 0 offset 32 in directory inode 16777344 references free 
inode 162
        clearing inode number in entry at offset 32...
no .. entry for directory 16777344
        - agno = 5
[snip]
        - agno = 39
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
        - traversal finished ...
        - traversing all unattached subtrees ...
rebuilding directory inode 16777344
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
disconnected dir inode 16777344, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 16777344 nlinks from 5 to 4
done
*********************

And everything works without any problems - until next unmount/mount...

I am pretty sure I didn't screw up anything in my kernel configuration,
the hard disks are 2 new 40GB Maxtor 6L040J2. I am confused.

/Maciek






-- 
If you think C++ is not overly complicated, just what is
a protected abstract virtual base pure virtual private
destructor, and when was the last time you needed one?
-- Tom Cargill, C++ Journal, Fall 1990