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>
|