xfs
[Top] [All Lists]

Re: question on xfs_repair

To: <cattelan@xxxxxxxxxxx>
Subject: Re: question on xfs_repair
From: <roberto@xxxxxxxx>
Date: Thu, 17 Apr 2003 09:59:40 +0200 (CEST)
Cc: <roberto@xxxxxxxx>, <linux-xfs@xxxxxxxxxxx>
Importance: Normal
In-reply-to: <1050530107.31511.1.camel@xxxxxxxxxxxxxxxxxxxxxx>
References: <2704.212.239.118.101.1050313610.squirrel@xxxxxxxxxxxxx> <1050530107.31511.1.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
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>




<Prev in Thread] Current Thread [Next in Thread>