Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SMkJU19034 for linux-xfs-outgoing; Thu, 28 Jun 2001 15:46:19 -0700 Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SMkHV19031 for ; Thu, 28 Jun 2001 15:46:17 -0700 Received: (from alane@localhost) by wwweasel.geeksrus.net (8.11.2/8.11.2) id f5SMkBR06702 for linux-xfs@oss.sgi.com; Thu, 28 Jun 2001 18:46:11 -0400 Date: Thu, 28 Jun 2001 18:46:10 -0400 From: Alan Eldridge To: Linux XFS Mailing List Subject: Re: Label based mounts with fsck Message-ID: <20010628184610.A20337@wwweasel.geeksrus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwmoore@fnal.gov on Thu, Jun 28, 2001 at 04:46:02PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 28, 2001 at 04:46:02PM -0500, Roger Moore wrote: >Hi, > >We've just updated our cluster to use XFS and have noticed a problem with >using 'LABEL=xxx' in the fstab file. 1. fsck has a bug in the LABEL=xxx handling code. It behaves badly (and non-deterministically) iff sizeof(/proc/partitions) > 1K. 1a. If you have a lot of partitions, and a big /proc/partitions, you could be getting stomped by this. But it typically only affects N partitions, where N = sizeof(/proc/partitions)/1024. That is, it pukes at each 1K boundary. 1b. This generally only happens on the initial mount. It's due to the contents of /proc/partitions changing (getting bigger) in between the time that fsck reads the first 1K and the next 1K from the file. The next 1K block does not start, in terms of the file's contents, where the first 1K block ended. The lines become misaligned. 2. Look at your /proc/partitions. Are there XFS volume labels in there? If not, then that's your problem. fsck reads /proc/partitions to get the label information. If they are there, then you might want to run fsck under gdb to watch it go through the fstab file... BTW The label code from mount is NOT the same code used in fsck (reuse? whazzat?) but it is vulnerable to the same error condition as mentioned in 1 above. -- Alan Eldridge "Smart Tags? We don't need no steenking Smart Tags!"