Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EHtmt27421 for linux-xfs-outgoing; Thu, 14 Feb 2002 09:55:48 -0800 Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EHtb927398 for ; Thu, 14 Feb 2002 09:55:37 -0800 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 14 Feb 2002 09:54:17 -0700 Message-ID: <3C6BEBC4.18AA60E9@echostar.com> Date: Thu, 14 Feb 2002 09:54:28 -0700 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen , Steve Lord CC: XFS List Subject: Re: Mounting an xfs partition twice? References: <3C6BDFC6.14BE4651@echostar.com> <1013703319.17209.3.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > On Thu, 2002-02-14 at 10:03, Jim Buzbee wrote: > > > In the corrupted directory, I see several files listed twice, and a > > simple "ls -l" gives me several "No such file or directory" errors on > > other files that were previously in the directory. > > Oh, and for this problem... what flavor of kernel/xfs are you running? OK, X86, IDE - 2.4.8 Kernel with a number of modifications, compiler : egcs 1.1.2 - The xfs patch we applied to the kernel is : patch-2.4.8-xfs-2001-08-13.bz2 We are pretty much frozen on this kernel right now because of the difficulty of moving forward our 2.4.8 modifications. > xfs_repair -n on the filesystem in question might tell us some > interesting things as well, Here's the output : Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't 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... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. > but it will be hard to know how the > filesystem got into this state. What sorts of interesting things are > you doing with it? :) This condition is unfortunately repeatable (we trashed a number of our set top boxes...). For us it occurs during the automated installation of several compressed tar files - Nothing extraordinary other than the filesystem is quite busy (we are simultaneously recording and playing MPEG 2 video from our satellites) - This problem just started occuring - The only change was a new build of the kernel so that is my current suspicion... Jim Buzbee, Echostar Technologies > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc.