Date: thu. 17 apr 2003
I downloaded the new xfsprogs-2.3.5 and repeated the rebuilding.
Now xfs_repair does not show the same strange messages! it seems OK!
Diffing the sources I found the only differences are:
diff -r old-cmd/xfsprogs-2.3.5/libxfs/rdwr.c xfsprogs-2.3.5/libxfs/rdwr.c
254d253
< off64_t ret;
261,265d259
< ret = lseek64(fd, BBTOOFF64(buf->b_blkno), SEEK_SET);
< fprintf(stderr, "RET %llu writing %ubytes at blkno=%llu(%llu), %p\n",
< ret,
< buf->b_bcount, BBTOOFF64(buf->b_blkno), buf->b_blkno, buf);
< #if 0
267,268d260
< #endif
< sts = write(fd, buf->b_addr, buf->b_bcount);
Please check if the diff are correct!
Another couple of things:
1) the file MD5SUM, according to me, does not match with the downlodable
tar file on your ftp site: please recheck it;
2) again according to me, the default "./configure ; ./Makepkgs verbose"
(that produce a tarball with executable into "/usr/local") should be set
to
./configure
--prefix=/
--exec-prefix=/
--sbindir=/sbin
--bindir=/usr/sbin
--libdir=/lib
--libexecdir=/usr/lib
--includedir=/usr/include
--mandir=/usr/share/man
--datadir=/usr/share
Many Thanks,
Roberto
> Looks like the cmd source tarballs might have been bad ... acl and attr
> were at the wrong version?
>
> I've re-upload the tar files from a generated from a freshly checked out
> tree so things should be all copacetic now.
>
> -Russell
>
>
> On Mon, 2003-04-14 at 04:46, roberto@xxxxxxxx wrote:
>> Hi,
>> I'm running slackware 8.1 with XFS 1.2.0 +acl+quota on kernel 2.4.19 +
>> lvm 1.0.7.
>>
>> I've a question on xfs_repair.
>>
>> If I've ran xfs_check on my /var F.S. and I've got no warning
>> messages, but if I run xfs_repair on the same F.S. I see a strange
>> output (for me):
>>
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>> - zero log...
>> RET 1447051264 writing 512bytes at blkno=1447051264(2826272),
>> 0x813b9d8 RET 1447051776 writing 512bytes at
>> blkno=1447051776(2826273), 0x813b9d8
>> - 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
>> - agno = 1
>> - agno = 2
>> - agno = 3
>> - agno = 4
>> - agno = 5
>> - agno = 6
>> - agno = 7
>> - 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
>> RET 13000704 writing 16384bytes at blkno=13000704(25392), 0x8154928
>> - marking entry "lost+found" to be deleted
>> RET 12996608 writing 4096bytes at blkno=12996608(25384), 0x8153900 RET
>> 32768 writing 16384bytes at blkno=32768(64), 0x814c6a0
>> - check for inodes claiming duplicate blocks...
>> - agno = 0
>> - agno = 1
>> - agno = 2
>> - agno = 3
>> - agno = 4
>> - agno = 5
>> - agno = 6
>> - agno = 7
>> Phase 5 - rebuild AG headers and trees...
>> RET 13889536 writing 4096bytes at blkno=13889536(27128), 0x80e52c8 RET
>> 13914112 writing 4096bytes at blkno=13914112(27176), 0x80e52c8 RET 512
>> writing 512bytes at blkno=512(1), 0x80e52c8
>> ....
>> (the output continue an is quite long)
>>
>> I run the command several time but the output produced is still
>> strange for me. (I'll wait for a clean xfs_repair as for xfs_check)
>>
>> Can anyone explain the meaning of it? and is my file system clean or
>> not? (I've red the man xfs_repair but it does not explain the "RET
>> ..." strings)
>>
>> Thanks in advance,
>> Roberto
>>
> --
> Russell Cattelan <cattelan@xxxxxxxxxxx>
|