From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 00:04:48 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 00:04:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:56392 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 00:04:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA27946 for ; Mon, 31 Jul 2000 23:56:09 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13155; Tue, 1 Aug 2000 17:01:08 +1000 Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA45707; Tue, 1 Aug 2000 17:01:05 +1000 (EST) From: tes@boing.melbourne.sgi.com (Timothy Shimmin) Message-Id: <200008010701.RAA45707@boing.melbourne.sgi.com> Subject: Re: ll_rw_kio error msgs To: cattelan@thebarn.com Date: Tue, 1 Aug 2000 17:01:05 +1000 (EST) Cc: linux-xfs@oss.sgi.com In-Reply-To: <39866F5B.F11AE688@thebarn.com> from "Russell Cattelan" at Aug 01, 2000 01:34:03 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Timothy Shimmin wrote: > > > Hi, > > > > I p_tupdate today and built the xfs kernel and am now > > getting heaps of > > "ll_rw_kio: Unexpected device [08:07] queueing function encountered" > > That is a scsi device.. correct? Yes. > > The kio buff IO stuff is reported to be broken at the moment. > Oops, sorry, missed this. > Try compiling XFS with KIO bufs's turned off and see if you still > have problems. Will do. Cheers, Tim. From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 06:19:49 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 06:19:39 -0700 Received: from c017-h014.c017.sfo.cp.net ([209.228.12.228]:53684 "HELO c017.sfo.cp.net") by oss.sgi.com with SMTP id ; Tue, 1 Aug 2000 06:19:02 -0700 Received: (cpmta 8310 invoked from network); 1 Aug 2000 06:18:26 -0700 Received: from Sangmc-ISDN.netvision.net.il (HELO kashgar) (212.143.119.30) by smtp.sangate.com with SMTP; 1 Aug 2000 06:18:26 -0700 X-Sent: 1 Aug 2000 13:18:26 GMT Message-ID: <000801bffbc3$299183a0$091ea8c0@kashgar> From: "BenHanokh Gabriel" To: Subject: xfs api Date: Tue, 1 Aug 2000 16:16:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFFBD3.EB253A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFFBD3.EB253A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi where can i find man page or any other documantion for the XFS user = space api( fsctl/ioctl...) ? please CC me for answers as i'm not registered to the mailing list THX /gabriel ------=_NextPart_000_0005_01BFFBD3.EB253A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
 
where can i find man page or any other = documantion=20 for the XFS user space api( fsctl/ioctl...) ?
 
please CC me for answers as i'm not = registered to=20 the mailing list
 
THX
/gabriel
 
 
------=_NextPart_000_0005_01BFFBD3.EB253A60-- From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 06:23:19 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 06:23:00 -0700 Received: from 24-216-159-200.hsacorp.net ([24.216.159.200]:39205 "EHLO front001.cluster1.charter.net") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 06:22:34 -0700 Received: from [24.216.41.140] (HELO charter.net) by front001.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with ESMTP id 14640424 for linux-xfs@oss.sgi.com; Tue, 01 Aug 2000 09:21:53 -0400 Message-ID: <3986CF48.609A705C@charter.net> Date: Tue, 01 Aug 2000 08:23:20 -0500 From: Ted Kline - Charter Pipeline X-Mailer: Mozilla 4.74 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Checkout this review of XFS/Linux. Content-Type: multipart/mixed; boundary="------------7277137410548526BF1ED2EF" Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------7277137410548526BF1ED2EF Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit http://crossnodes.earthweb.com/articles/0719os_xfs.html --------------7277137410548526BF1ED2EF Content-Type: text/html; charset=iso-8859-1; name="0719os_xfs.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="0719os_xfs.html" Content-Base: "http://crossnodes.earthweb.com/article s/0719os_xfs.html" Content-Location: "http://crossnodes.earthweb.com/article s/0719os_xfs.html" EarthWeb's Crossnodes.com - Networking Resources for IT Profession= als 3D""<= BR>
3D""
 3D""
3D"" 3D""          =        
3D"Technolog= 3D=
3D""
  
Find:  
EXPERT SEARCH
SEARCH THE IT WEB
3D"arrow" Convergence<= /a>
3D"arrow" Infrastructure
3D"arrow" Network Management<= /font>
3D"arrow" Security=
3D"arrow" Server Software
3D"arrow" Telecom Services
  
 
Subscribe to the newsletter=

Related Newsletters

 
EarthWeb
International:

EarthWeb sites:=
IT Management
Networking & Telecommunications
IT Jobs
Software Development
Hardware & Systems
Commerce
Community
3D""
3D""
Discussions | = Articles= | = Events =
Software | Books for Sale | Training | = Hardware= | = Online = Books | Job L= istings | = Auctions

XFS: It's worth the wait

The advanced XFS file system is flexible, powerful, and fast. You may wan= t to consider it for use on your Linux network.

By Vincent Danen
July 21, 2000


TechCrawl= er
Want more in= formation on XFS?
Search the IT Web

In 1994, Silicon Graphics Inc., of Mountain View, Calif., (SGI) releas= ed a new journaled file system on IRIX, the company's System V-based vers= ion of UNIX. This advanced file system, called XFS, replaced SGI's old EF= S (Extent File System) file system, which was designed similar to the Ber= keley Fast File System. Coordinating with many other kernel developers, S= GI is currently working to tightly integrate the XFS file system with the= Linux operating system so that we can take advantage of the many benefit= s of XFS over the current ext2 file system. This article discusses XFS an= d its technical specifications.

Origin of XFS

SGI designed XFS with a few very important features in mind, and for v= ery specific reasons. In 1990, SGI realized that it would need to create = something to replace EFS; EFS could not handle the demands of new and for= thcoming applications. The issues facing any file system at that time wer= e demands for increased disk capacity and bandwidth, and parallelism with= new applications such as film, video, and large databases. Because EFS c= ouldn't hope to handle these needs efficiently, SGI created XFS for the p= urpose of handling new applications by providing support in a few key are= as. These areas included fast crash recovery, large file systems, and lar= ge directories and files.

In 1999, SGI began to turn an eye to Linux as a viable and attractive = operating platform to support. Due to the nature of Linux, and because SG= I knew it had something to offer that would provide Linux with the same f= ile-system capabilities as those found in IRIX, SGI released Open XFS to = the Linux community.

Overview of XFS Features

XFS provides some basic and powerful features that meet the requiremen= ts for any large file system, file, or directory. Let's take a look at so= me of these features:

XFS uses B+ trees extensively in place of the traditional linear file = system structure. B+ trees use a highly efficient indexing method to inde= x directory entries, manage file extents, locate free space, and keep tra= ck of the locations of file index information. As a result, reading file = systems and retrieving information from them happens quickly--without usi= ng large amounts of system resources.

Currently, the XFS team is developing enhancements to the Linux page c= ache so XFS can be tightly integrated with the Linux kernel. This work is= being done so XFS relies solely on the page cache to store both file dat= a and file system metadata. This work can also be used to enhance other f= ile systems to improve overall system performance, because it is being de= veloped at a kernel level. These features will most likely be unavailable= until Linux 2.5, except as a part of XFS itself.

XFS also dynamically allocates disk blocks to inodes. If an applicatio= n uses a small number of files that are very large, very little disk data= is used to store the actual files--and the remainder of the disk is free= d for more data. If an application uses many small files, more disk space= is made available for directories and files. This process is handled dyn= amically, with no need for user intervention or configuration; you can cr= eate your initial file system without specifying block sizes according to= what type of application will be using it. For example, you no longer ne= ed to create a file system with a smaller block size for efficient use by= a mail server. XFS handles all of this internally with an advanced space= management technique that utilizes contiguity, parallelism, and fast log= ging.

Many powerful support utilities come with XFS and enhance it remarkabl= y. It includes the following:

  • A very fast mkfs utility to make the file system
  • Advanced dump and restore utilities for backups
  • xfs_db for debugging
  • xfs_check for checking the file system
  • xfs_repair for file system repairs
  • xfs_fsr for defragmenting XFS file systems
  • xfs_bmap, which can be used to interpret the metadata layout= s for the file system
  • grow_fs, which will enlarge XFS file systems online =

XFS also provides file system journaling. This means that XFS u= ses database recovery techniques to recover a consistent file system stat= e after a system crash. Using journaling, XFS is able to accomplish this = recovery in under a second, regardless of the file system size. Tradition= al linear file systems without journaling, however, must run the fsck<= /b> command over the entire file system to check it after a system crash;= this process is rapid on smaller file systems, but can take a lot of tim= e (in some cases measured in hours) on larger file systems. XFS is able t= o accomplish this fast recovery by logging all file transactions with inf= ormation on free lists, inodes, directories, and so on. After a crash, th= e logs are analyzed, and XFS can quickly determine which transactions mus= t be done in order to synchronize the file system to the state it was in = prior to the crash.

XFS scalability

File system scalability is the ability of the file system to pr= ovide support for very large file systems, large files, large directories= , and large numbers of files while still providing good I/O performance. = The scalability of a file system depends somewhat on how it stores inform= ation on files.

XFS Technical Specifications

The following list summarizes most of the features that XFS provides. = Because the Linux implementation of XFS is still in the development stage= s, the features listed may or may not be applicable to the Open XFS for L= inux specification. These features are available to XFS for IRIX, and the= y give a reasonable idea of what we can expect from a Linux implementatio= n of XFS:

  • Scalable file sizes, up to 9 million TB
  • Scalable file systems, up to 18 million TB
  • High performance on all file systems, regardless of size
  • Millions of files per file system
  • Millions of files per directory
  • Rapid file system recovery
  • Rapid transaction rates
  • Rapid directory searches and space allocation using B+ trees
  • NFS version 3 compatibility
  • Journaled 64-bit file system
  • Fast performance. Throughput in excess of 7GBps has been demonstrat= ed on a single file
  • System using a 32-processor Origin2000 server. Single file reads an= d writes exceed 4GBps

To illustrate this point, let us compare XFS (a 64-bit file system) to= any other 32-bit file system. Because XFS uses 64 bits to store inode nu= mbers and addresses for each disk block, a single file can theoretically = be as large as 9 million terabytes. A 32-bit file system, however, cannot= usefully exceed file sizes of 4GB. I don't honestly know anyone who need= s a file to be 9 million TB (or even 4GB!), but by providing such a high = level of scalability, XFS ensures that it will not become an obsolete or = unusable file system for many years to come. For individuals in high-leve= l science applications (for example, NASA), or those in the video or audi= o industries where file sizes can reach ridiculous sizes, XFS is necessar= y to make their work easier and plausible.

Large directories are also an issue with traditional linear file syste= ms. Applications such as Sendmail or news servers often result in spool d= irectories with thousands of files. Looking up a filename in such a direc= tory can take a long time, because typically the directory must be read f= rom the beginning until the desired file is found. Because XFS uses a B+ = tree structure, it makes directory searching extremely fast. Filenames in= the directory are converted to a four-byte hash value and are used to in= dex the B+ tree. Using this method, all directory functions (searching, c= reating, and removing) are very efficient and fast.

Using the same idea, XFS supports large numbers of files efficiently b= ecause inodes are allocated dynamically and multiple file operations are = performed in parallel. The only limitation for XFS in regards to the numb= er of files in a file system is the space available to hold them. Because= XFS dynamically allocates inodes, free space usage is extremely efficien= t, regardless of the file size. With traditional file systems--in which t= he number of inodes is specified during file system creation--you are lim= ited by that initial number of inodes. You can increase or decrease the i= node size and number during the file-system creation, but then you end up= locking the system into a specific state of usability. If you use a larg= e number of inodes up front, you consume a lot of disk space that may nev= er be used. But if you use a smaller number of inodes, any small files st= ored on the file system will use the full inode block size and waste spac= e that could have been saved by using a smaller inode size (which results= in more inodes).

Why choose XFS?

As we've seen, XFS is a flexible, powerful, and fast file system. Curr= ent development of file systems for Linux include a number of forthcoming= journaling file systems. Available right now is the ReiserFS journaling = file system, and coming soon is ext3, which is a backward-compatible jour= naling file system based on ext2. IBM also released an initial release of= its Enterprise JFS, another journaled file system written initially for = AIX.

So, in light of these forthcoming alternatives, why should you be conc= erned with XFS? If ReiserFS is currently available and these others are c= oming out, why should you choose XFS over any of them?

The main factor is maturity. ReiserFS and ext3 are still in-developmen= t immature file systems. XFS is mature--it's been running on IRIX machine= s since 1994. SGI developed it six years ago to be a robust, long-standin= g, viable alternative to linear file systems. In short, SGI knows how to = make a good file system.

Yes, we may have to wait another few months before XFS is a realistic = alternative to ReiserFS, which is currently available; but I think the wa= it will be worth it. I've illustrated the many benefits of XFS over tradi= tional file systems. Because it has commercial backing and--perhaps more = important--because commercial dollars are invested in the project, XFS fo= r Linux will quickly attain the same level of reliability it has had on I= RIX for years. To get more information on XFS or to contribute to the pro= ject, visit the project Web site at oss.sgi.com/projects/xfs/. //<= /p> Vincent Danen is a self-employed Linux consultant and freelance writer= native to Edmonton, Alberta, Canada. He has been using Linux exclusively= since mid-1997. Vincent is a firm believer in the philosophy behind the = Linux "revolution" and attempts to contribute to the Linux cause in as ma= ny ways as possible, from his Freezer Burn Web site to building custom RPM= s for the Linux Mandrake project.

ADVERTIS= ING


Get the Answers You Need!
Incentive-based, question & answer Marketplace. The first 5,000 members receive $12 credit! Try it! Knowledge Market.

FACT:
80/20 search methods find IT answers MUCH faster and cheaper... How? Get= the White Paper with = all the details.

HAVE A WEBSITE?
Join Ea= rthWeb Allies Network and earn $$ by linking your site with ours.

=

Sign-up for YESMAIL a= nd get exclusive deals from leading brands of software, hardware, online magazines, and much more. No kidding! And it's FREE.

3D"" = =
3D""
3D""3D""3D""3D""3D""3D"" =
Use of this site is subject to certain = Terms & Condition= s.
Copyright (c) 1996-2000 EarthWeb Inc. All rights reserved. Reproducti= on in whole or in part in any form or medium without express written permission of Eart= hWeb is prohibited. Read EarthWeb's privacy statement.
--------------7277137410548526BF1ED2EF-- From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 07:16:50 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 07:16:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8061 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 07:16:13 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA26884 for ; Tue, 1 Aug 2000 07:08:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA07108; Tue, 1 Aug 2000 09:14:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id JAA13943; Tue, 1 Aug 2000 09:14:23 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA12528; Tue, 1 Aug 2000 09:14:02 -0500 Message-Id: <200008011414.JAA12528@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "01 Aug 2000 05:42:01 GMT." Date: Tue, 01 Aug 2000 09:14:02 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > As for debugging this hang - it is a little tricky without something like > > kdb. Getting a stack trace for the mount process would be critical to worki ng > > out what went wrong. I suspect some read of a block from disk did not wake > > up the requesting thread. There is tracing in the pagebuf module, but it > > relied on kdb to dump the results, mapping these trace calls onto printk > > messages, or some other mechanism may help. > > i tried it with the poor mans debugger - printk :-) > > i put printk's all over xfs_mountfs_int (which i hope is the right > point for the mounting stage) and to my confusion - non of them were > printed out (the first one was before xfs_mount_common - maybe i > should move it before the xfs_readsb) ... i'll try to look at this > a bit deeper - also i will try to find out how to use xmon (if that > is possible on my machine) > The place you probably need to scatter printk all over is fs/pagebuf/page_buf.c the easiest way to do this is to edit include/linux/page_buf.h and ensure that PAGEBUF_TRACE is defined (it is dependent on CONFIG_KDB at the moment). Make sure that debug_pagebuf is set to 1. Then edit pb_trace_func in page_buf.c and instead of putting data into a trace buffer, take something based on the code in kdb/modules/kdbm_pg.c which does this: if ((trace->event < EV_SIZE) && event_names[trace->event]) { event = event_names[trace->event]; } else if (trace->event == 1000) { event = (char *)trace->misc; } else { event = value; sprintf(value, "%8d", trace->event); kdb_printf("pb 0x%lx [%s] (hold %u lock %d) misc 0x%p", trace->pb, event, trace->hold, trace->lock_value, trace->misc); kdb_symbol_print((unsigned int)trace->ra, NULL, KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); kdb_printf(" offset 0x%Lx size 0x%x task 0x%p\n", trace->offset, trace->size, trace->task); kdb_printf(" flags: %s\n", pb_flags(trace->flags)); (clearly those need to become printk messages). you should then be able to get output which looks something like this: pb 0xc15bd080 [done] (hold 1 lock 0) misc 0x00000000 ([xfs]xfs_buf_iodone_callbacks+0x168) offset 0x100c80000 size 0x2000 task 0xc02d8000 flags: MAPPED ASYNC LOCK LOCKABLE ALL_PAGES_MAPPED ADDR_ALLOCATED MEM_ALLOCATED pb 0xc15bd080 [unlock] (hold 1 lock 1) misc 0x00000000 ([pagebuf]pagebuf_iodone+0x6c) offset 0x100c80000 size 0x2000 task 0xc02d8000 flags: MAPPED ASYNC LOCK LOCKABLE ALL_PAGES_MAPPED ADDR_ALLOCATED MEM_ALLOCATED ...... The first thing to establish is is the first I/O on a pagebuf completing, this is the super block. This is what the super block read ends up looking like: pb 0xc155dee0 [get] (hold 1 lock 0) misc 0xc050eb00 ([pagebuf]pagebuf_get_no_daddr+0x22) offset 0x0 size 0x200 task 0xc237a000 flags: NONE LOCKABLE FORECIO pb 0xc155dee0 [no_daddr] (hold 1 lock 0) misc 0xc6bc0800 ([xfs]xfs_pb_ngetr+0x16) offset 0x0 size 0x200 task 0xc237a000 flags: MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [ioreq] (hold 1 lock 0) misc 0x00000000 ([xfs]xfsbdstrat+0x2b) offset 0x0 size 0x200 task 0xc237a000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [hold] (hold 2 lock 0) misc 0x00000000 ([pagebuf]pagebuf_segment_apply+0x38) offset 0x0 size 0x200 task 0xc237a000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [rele] (hold 2 lock 0) misc 0xc887dbb8 ([pagebuf]pagebuf_segment_apply+0x120) offset 0x0 size 0x200 task 0xc237a000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [iowait] (hold 1 lock 0) misc 0x00000000 ([xfs]xfs_readsb+0x40) offset 0x0 size 0x200 task 0xc237a000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [done] (hold 1 lock 0) misc 0x00000000 ([pagebuf]_end_pagebuf_page_io+0x143) offset 0x0 size 0x200 task 0xc02d8000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [iowaited] (hold 1 lock 0) misc 0x00000000 ([xfs]xfs_readsb+0x40) offset 0x0 size 0x200 task 0xc237a000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [rele] (hold 1 lock 0) misc 0xc887dbb8 ([xfs]xfs_readsb+0xa7) offset 0x0 size 0x200 task 0xc237a000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO pb 0xc155dee0 [unlock] (hold 1 lock 1) misc 0x00000000 ([xfs]xfs_sb_relse+0x10) offset 0x0 size 0x200 task 0xc237a000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO The iowait is the mount thread going to sleep waiting for the read to complete, the done is the interrupt going off on I/O completion and the iowaited is the mount thread waking up. After this it will get really verbose, it has to go read the log to see if a clean unmount was performed. Steve From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 07:56:20 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 07:56:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:13833 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 07:55:31 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA00993 for ; Tue, 1 Aug 2000 07:47:28 -0700 (PDT) mail_from (lord@sgi.com) From: lord@sgi.com Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA11843 for ; Tue, 1 Aug 2000 09:53:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id JAA15745 for ; Tue, 1 Aug 2000 09:53:44 -0500 (CDT) Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id JAA14766; Tue, 1 Aug 2000 09:53:22 -0500 Message-Id: <200008011453.JAA14766@jen.americas.sgi.com> Date: Tue, 1 Aug 2000 09:53:22 -0500 Subject: TAKE - fix kiobuf based I/O in test5 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This makes kiobuf based I/O work again. Date: Tue Aug 1 07:53:02 PDT 2000 Workarea: jen.cray.com:/src/lord/xfs-profile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:70939a linux/drivers/block/ll_rw_blk.c - 1.39 - Remove the bogus test for an initialized request function in ll_rw_kio linux/drivers/scsi/scsi_lib.c - 1.20 - Fix missing initialization of page count in __scsi_collect_kio_sectors From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 08:07:50 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 08:07:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58123 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 08:07:16 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA02352 for ; Tue, 1 Aug 2000 07:59:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA31884; Tue, 1 Aug 2000 10:05:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id KAA17030; Tue, 1 Aug 2000 10:05:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA15101; Tue, 1 Aug 2000 10:05:06 -0500 Message-Id: <200008011505.KAA15101@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "BenHanokh Gabriel" cc: linux-xfs@oss.sgi.com Subject: Re: xfs api In-Reply-To: Message from "BenHanokh Gabriel" of "Tue, 01 Aug 2000 16:16:59 +0200." <000801bffbc3$299183a0$091ea8c0@kashgar> Date: Tue, 01 Aug 2000 10:05:05 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > hi > > where can i find man page or any other documantion for the XFS user = > space api( fsctl/ioctl...) ? > > please CC me for answers as i'm not registered to the mailing list > > THX > /gabriel > > At the moment we do not have anything beyond the source code - since the API is not guaranteed to be fixed yet. One example of this is the interface for extended attributes - we added some system calls, but these calls are probably not going to be the final version. ioctl numbers and structures are defined in include/linux/xfs_fs.h and there are examples of these in the cmd/xfs code, most of these are probably the final versions. Steve From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 08:34:40 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 08:34:20 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:54670 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 08:33:49 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA24708 for ; Tue, 1 Aug 2000 10:33:16 -0500 (CDT) Message-Id: <4.2.0.58.20000801102846.00df9a30@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 01 Aug 2000 10:34:47 -0500 To: linux-xfs@oss.sgi.com From: "William L. Jones" Subject: xfs with LVM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Very minor problem. LVM complains about xfs_reapair doing a unknown ioctl: Jul 31 23:00:04 localhost kernel: lvm -- lvm_blk_ioctl: unknown command 25636 I traced this to some code in the sim library that using the ioctl DIOCGETVOLDEV Bill Jones From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 08:54:11 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 08:54:01 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23569 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 08:53:21 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02377 for ; Tue, 1 Aug 2000 08:58:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA33380 for ; Tue, 1 Aug 2000 10:51:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id KAA20188 for ; Tue, 1 Aug 2000 10:51:34 -0500 (CDT) From: lord@sgi.com Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id KAA15495; Tue, 1 Aug 2000 10:51:12 -0500 Message-Id: <200008011551.KAA15495@jen.americas.sgi.com> Date: Tue, 1 Aug 2000 10:51:12 -0500 Subject: TAKE - add the latest sard patch to the XFS kernel To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Integrate sard 0.6 support into xfs kernel, the sard user space can be obtained from: ftp://ftp.uk.linux.org/pub/linux/sct/fs/profiling/sard-0.6.tar.gz Date: Tue Aug 1 08:49:44 PDT 2000 Workarea: jen.cray.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:70945a linux/include/linux/genhd.h - 1.10 linux/include/linux/blkdev.h - 1.21 linux/drivers/block/ll_rw_blk.c - 1.40 linux/fs/partitions/check.c - 1.16 linux/drivers/scsi/scsi_lib.c - 1.21 From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 12:15:01 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 12:14:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:57689 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 12:14:16 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09730 for ; Tue, 1 Aug 2000 12:06:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA58111 for ; Tue, 1 Aug 2000 14:11:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA18441 for ; Tue, 1 Aug 2000 14:11:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA27162; Tue, 1 Aug 2000 14:10:51 -0500 Message-Id: <200008011910.OAA27162@jen.americas.sgi.com> Date: Tue, 1 Aug 2000 14:10:51 -0500 Subject: TAKE - add pboffset commmand the page buf debug code To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing pboffset 0xe0bda000 would report all recorded pagebuf activity for this offset. Date: Tue Aug 1 12:09:56 PDT 2000 Workarea: jen.cray.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:70984a linux/kdb/modules/kdbm_pg.c - 1.9 - Add a pboffset command - trace access to a specific disk location via pagebuf From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 13:06:31 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 13:06:21 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31081 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 13:05:58 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA16713 for ; Tue, 1 Aug 2000 12:57:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA53365; Tue, 1 Aug 2000 15:02:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA39470; Tue, 1 Aug 2000 15:02:53 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA27963; Tue, 1 Aug 2000 15:02:30 -0500 Message-Id: <200008012002.PAA27963@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mkp@linuxcare.com (Martin K. Petersen), "William L. Jones" cc: linux-xfs@oss.sgi.com Subject: Re: xfs with LVM In-Reply-To: Message from "William L. Jones" of "Tue, 01 Aug 2000 10:34:47 CDT." <4.2.0.58.20000801102846.00df9a30@127.0.0.1> Date: Tue, 01 Aug 2000 15:02:29 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Martin, are you out there to respond to this? Steve > > > Very minor problem. LVM complains about xfs_reapair doing a unknown ioctl: > > Jul 31 23:00:04 localhost kernel: lvm -- lvm_blk_ioctl: unknown command 25636 > > I traced this to some code in the sim library that using the ioctl > > DIOCGETVOLDEV > > Bill Jones From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 13:26:21 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 13:26:11 -0700 Received: from tux.mkp.net ([130.225.60.11]:59406 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 13:25:38 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13JiXr-0002uu-00; Tue, 01 Aug 2000 22:21:52 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id QAA01218; Tue, 1 Aug 2000 16:24:57 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord , "William L. Jones" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs with LVM References: <200008012002.PAA27963@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 01 Aug 2000 16:24:56 -0400 In-Reply-To: Steve Lord's message of "Tue, 01 Aug 2000 15:02:29 -0500" Message-ID: Lines: 23 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Steve" == Steve Lord writes: Steve> Martin, are you out there to respond to this? Yes, I'm here. Been busy all day, though, so I haven't poked at it yet. Will have a look later today or tomorrow... >> Very minor problem. LVM complains about xfs_reapair doing a >> unknown ioctl: >> >> Jul 31 23:00:04 localhost kernel: lvm -- lvm_blk_ioctl: unknown >> command 25636 >> >> I traced this to some code in the sim library that using the ioctl >> >> DIOCGETVOLDEV -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 14:41:12 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 14:41:03 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53306 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 14:40:33 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA06375 for ; Tue, 1 Aug 2000 14:45:55 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA17747; Wed, 2 Aug 2000 07:38:44 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA18300; Wed, 2 Aug 2000 07:38:40 +1000 (EST) From: "Nathan Scott" Message-Id: <10008020738.ZM18437@wobbly.melbourne.sgi.com> Date: Wed, 2 Aug 2000 07:38:39 -0500 In-Reply-To: "Martin K. Petersen" "Re: xfs with LVM" (Aug 2, 6:28am) References: <200008012002.PAA27963@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Martin K. Petersen" , Steve Lord , "William L. Jones" Subject: Re: xfs with LVM Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Bill, On Aug 2, 6:28am, Martin K. Petersen wrote: > Subject: Re: xfs with LVM > >>>>> "Steve" == Steve Lord writes: > > Steve> Martin, are you out there to respond to this? > > Yes, I'm here. Been busy all day, though, so I haven't poked at it > yet. Will have a look later today or tomorrow... > > > >> Very minor problem. LVM complains about xfs_reapair doing a > >> unknown ioctl: > >> > >> Jul 31 23:00:04 localhost kernel: lvm -- lvm_blk_ioctl: unknown > >> command 25636 > >> > >> I traced this to some code in the sim library that using the ioctl > >> > >> DIOCGETVOLDEV This is a hangover from the port from IRIX (have a look in /usr/include/sys/dkio.h on a recent IRIX) ... there is no such ioctl on Linux. In the reworked libsim, I have commented this sort of thing out using a '#ifdef HAVE_VOLUME_MANAGER' ... see libxfs/init.c. The tools which use the sim_init code that have been converted (logprint and db) will no longer issue this bogus ioctl, whereas the tools which have not yet been converted (i.e. mkfs, repair) still go through the code in sim/src/sim.random.c ... these will be fixed in the not too distant future. I'm guessing Martin may be working on a way to do the equivalent of this IRIX ioctl in Linux/LVM (?)... on IRIX the ioctl tells the sim_init which data/log/realtime subvolumes are associated with a given XLV/XVM device. cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 16:22:03 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 16:21:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6980 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 16:21:10 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09743 for ; Tue, 1 Aug 2000 16:26:34 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA55511 for ; Tue, 1 Aug 2000 18:19:24 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id SAA08026 for ; Tue, 1 Aug 2000 18:19:23 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e71NJ2A05254 for ; Tue, 1 Aug 2000 18:19:02 -0500 Message-ID: <39875AE5.F513B91F@thebarn.com> Date: Tue, 01 Aug 2000 18:19:01 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: FYI: Hmm looks like a deadlock Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Linux Mandrake release 7.1b (hydrogen) Kernel 2.4.0-test5 on a Bi-processor i686 / l exclaim.americas.sgi.com login: Entering kdb (0xc1234000) on processor 1 due to Keyboard Entry [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc12d4000 00000001 00000000 0 001 stop 0xc12d4340 init 0xc129e000 00000002 00000001 0 001 stop 0xc129e340 kswapd 0xc129c000 00000003 00000001 0 000 stop 0xc129c340 kflushd 0xc129a000 00000004 00000001 0 000 stop 0xc129a340 kupdate 0xc7d18000 00000017 00000001 0 001 stop 0xc7d18340 devfsd 0xc7df6000 00000409 00000001 0 000 stop 0xc7df6340 portmap 0xc74de000 00000425 00000001 0 000 stop 0xc74de340 ypbind 0xc74dc000 00000431 00000425 0 001 stop 0xc74dc340 ypbind 0xc754a000 00000501 00000001 0 000 stop 0xc754a340 syslogd 0xc7462000 00000509 00000001 0 000 stop 0xc7462340 klogd 0xc7378000 00000522 00000001 0 000 stop 0xc7378340 identd 0xc7438000 00000524 00000522 0 001 stop 0xc7438340 identd 0xc7424000 00000525 00000524 0 000 stop 0xc7424340 identd 0xc743c000 00000526 00000524 0 000 stop 0xc743c340 identd 0xc736e000 00000527 00000524 0 000 stop 0xc736e340 identd 0xc72fc000 00000539 00000001 0 000 stop 0xc72fc340 atd 0xc72d6000 00000552 00000001 0 001 stop 0xc72d6340 crond 0xc7b24000 00000583 00000001 0 001 stop 0xc7b24340 inetd 0xc77b4000 00000596 00000001 0 000 stop 0xc77b4340 lpd 0xc7b0e000 00000630 00000001 0 000 stop 0xc7b0e340 automount 0xc71d0000 00000690 00000001 0 000 stop 0xc71d0340 sendmail 0xc7198000 00000720 00000001 0 000 stop 0xc7198340 gpm [1]more> 0xc6b2e000 00000735 00000001 0 000 stop 0xc6b2e340 httpd 0xc69a4000 00000761 00000735 0 001 stop 0xc69a4340 httpd 0xc6998000 00000762 00000735 0 000 stop 0xc6998340 httpd 0xc698c000 00000763 00000735 0 001 stop 0xc698c340 httpd 0xc6976000 00000764 00000735 0 000 stop 0xc6976340 httpd 0xc6968000 00000765 00000735 0 000 stop 0xc6968340 httpd 0xc6902000 00000766 00000735 0 000 stop 0xc6902340 httpd 0xc68ee000 00000767 00000735 0 000 stop 0xc68ee340 httpd 0xc68e2000 00000768 00000735 0 000 stop 0xc68e2340 httpd 0xc6a02000 00000770 00000735 0 000 stop 0xc6a02340 httpd 0xc6854000 00000771 00000735 0 001 stop 0xc6854340 httpd 0xc6840000 00000772 00000735 0 000 stop 0xc6840340 httpd 0xc6714000 00000787 00000001 0 000 stop 0xc6714340 xfs 0xc7fac000 00000886 00000001 0 000 stop 0xc7fac340 mingetty 0xc7c0a000 00000887 00000001 0 000 stop 0xc7c0a340 mingetty 0xc7b70000 00000888 00000001 0 000 stop 0xc7b70340 mingetty 0xc7a16000 00000889 00000001 0 001 stop 0xc7a16340 mingetty 0xc6d5e000 00000890 00000001 0 001 stop 0xc6d5e340 mingetty 0xc62fa000 00000891 00000001 0 001 stop 0xc62fa340 mingetty 0xc63bc000 00000892 00000001 0 001 stop 0xc63bc340 getty 0xc62e6000 00000893 00000001 0 001 stop 0xc62e6340 kdm 0xc5e1e000 00000902 00000893 0 000 stop 0xc5e1e340 X 0xc5d02000 00000906 00000893 0 001 stop 0xc5d02340 kdm [1]more> 0xc50c0000 00000924 00000001 0 000 stop 0xc50c0340 xterm 0xc5056000 00000925 00000924 0 001 stop 0xc5056340 tcsh 0xc4f8c000 00000941 00000925 0 001 stop 0xc4f8c340 tcsh 0xc4e9e000 00000956 00000001 0 000 stop 0xc4e9e340 pagebuf_daemon 0xc4e9c000 00000957 00000001 0 001 stop 0xc4e9c340 page_daemon 0xc4e1e000 00000961 00000001 0 001 stop 0xc4e1e340 rsync 0xc768e000 00000962 00000961 0 000 stop 0xc768e340 rsync 0xc4eb6000 00000994 00000941 0 001 stop 0xc4eb6340 rsync 0xc625c000 00000995 00000994 0 001 stop 0xc625c340 rsync 0xc7470000 00000996 00000995 0 000 stop 0xc7470340 rsync 0xc1542000 00001002 00000001 0 001 stop 0xc1542340 xterm 0xc0aba000 00001003 00001002 0 000 stop 0xc0aba340 tcsh [1]kdb> btp 961 EBP EIP Function(args) 0xc4e1fd48 0xc0116c82 schedule+0x3ca (0xc5838208) kernel .text 0xc0100000 0xc01168b8 0xc0117170 0xc4e1fd7c 0xc01c969a _sv_wait+0xd2 (0xc5838208, 0xc7a81d74, 0x246, 0x0, 0x0) kernel .text 0xc0100000 0xc01c95c8 0xc01c96b8 0xc4e1fdb0 0xc01a531d xlog_grant_log_space+0x91 (0xc7a81ce0, 0xc5838208, 0xc7ca6400, 0x0, 0xc7a81ce0) kernel .text 0xc0100000 0xc01a528c 0xc01a5574 0xc4e1fde8 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x638, 0x0, 0xc72a15f4, 0x69) kernel .text 0xc0100000 0xc01a3174 0xc01a32a0 0xc4e1fe14 0xc01b48f6 xfs_trans_reserve+0x122 (0xc72a15c0, 0x0, 0x638, 0x0, 0x0) kernel .text 0xc0100000 0xc01b47d4 0xc01b49b4 0xc4e1fea4 0xc01bc66c xfs_setattr+0x238 (0xc5da770c, 0xc4e1fed0, 0x0, 0xc03df780) kernel .text 0xc0100000 0xc01bc434 0xc01bd25c 0xc4e1ff40 0xc01c89c7 linvfs_notify_change+0x177 (0xc236f240, 0xc4e1ff78) kernel .text 0xc0100000 0xc01c8850 0xc01c89f0 0xc4e1ff5c 0xc01442e0 notify_change+0x60 (0xc236f240, 0xc4e1ff78) kernel .text 0xc0100000 0xc0144280 0xc0144350 0xc4e1ffbc 0xc012f1a4 sys_utime+0xa8 (0x806ff5d, 0xbfffd594, 0xbfffd5d4, 0x837ea90, 0x806ff5d) kernel .text 0xc0100000 0xc012f0fc 0xc012f1bc 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [1]kdb> btp 962 EBP EIP Function(args) 0xc768fd2c 0xc0116c82 schedule+0x3ca (0xc5838d9c) kernel .text 0xc0100000 0xc01168b8 0xc0117170 0xc768fd60 0xc01c969a _sv_wait+0xd2 (0xc5838d9c, 0xc7a81d74, 0x246, 0x0, 0x0) kernel .text 0xc0100000 0xc01c95c8 0xc01c96b8 0xc768fd94 0xc01a53d3 xlog_grant_log_space+0x147 (0xc7a81ce0, 0xc5838d9c, 0xc7ca6400, 0x9aa70, 0xc7a81ce0) kernel .text 0xc0100000 0xc01a528c 0xc01a5574 0xc768fdcc 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x4ab38, 0x2, 0xc7823b14, 0x69) kernel .text 0xc0100000 0xc01a3174 0xc01a32a0 0xc768fdf8 0xc01b48f6 xfs_trans_reserve+0x122 (0xc7823ae0, 0x3f, 0x4ab38, 0x0, 0x4) kernel .text 0xc0100000 0xc01b47d4 0xc01b49b4 0xc768fec4 0xc01b0eb2 xfs_rename+0x402 (0xc5c79b84, 0xc3e494e0, 0xc7d67c20, 0xc4aa0c80, 0xc768fef8) kernel .text 0xc0100000 0xc01b0ab0 0xc01b1630 0xc768ff04 0xc01c82d0 linvfs_rename+0xc8 (0xc7d67b40, 0xc4aa0ca0, 0xc7d67b40, 0xc4aa0c20) kernel .text 0xc0100000 0xc01c8208 0xc01c8350 0xc768ff2c 0xc013dcb8 vfs_rename_other+0x274 (0xc7d67b40, 0xc4aa0ca0, 0xc7d67b40, 0xc4aa0c20) kernel .text 0xc0100000 0xc013da44 0xc013dd10 0xc768ff4c 0xc013dd3c vfs_rename+0x2c (0xc7d67b40, 0xc4aa0ca0, 0xc7d67b40, 0xc4aa0c20) kernel .text 0xc0100000 0xc013dd10 0xc013dd54 0xc768ffbc 0xc013df02 sys_rename+0x1ae (0xbfffe6a4, 0x8072f5a, 0x8072f5a, 0x8072f5a, 0xbfffe6a4) kernel .text 0xc0100000 0xc013dd54 0xc013dfc0 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [1]more> q [1]kdb> btp diag: -16: Illegal numeric value [1]kdb> btp 994 EBP EIP Function(args) 0xc4eb7f14 0xc0116c82 schedule+0x3ca (0xc4eb7f28) kernel .text 0xc0100000 0xc01168b8 0xc0117170 0xc4eb7f3c 0xc011659b schedule_timeout+0x73 kernel .text 0xc0100000 0xc0116528 0xc01165bc 0xc4eb7f70 0xc013f80c do_select+0x1c4 (0x6, 0xc4eb7fa4, 0xc4eb7fa0) kernel .text 0xc0100000 0xc013f648 0xc013f844 0xc4eb7fbc 0xc013fb9e sys_select+0x332 (0x6, 0xbfffe33c, 0x0, 0x0, 0xbfffe334) kernel .text 0xc0100000 0xc013f86c 0xc013fcd4 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [1]kdb> btp 995 Unknown kdb command: 'btp' [1]kdb> btp 995 EBP EIP Function(args) 0xc625dd48 0xc0116c82 schedule+0x3ca (0xc583864c) kernel .text 0xc0100000 0xc01168b8 0xc0117170 0xc625dd7c 0xc01c969a _sv_wait+0xd2 (0xc583864c, 0xc7a81d74, 0x246, 0x0, 0x0) kernel .text 0xc0100000 0xc01c95c8 0xc01c96b8 0xc625ddb0 0xc01a531d xlog_grant_log_space+0x91 (0xc7a81ce0, 0xc583864c, 0xc7ca6400, 0x0, 0xc7a81ce0) kernel .text 0xc0100000 0xc01a528c 0xc01a5574 0xc625dde8 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x638, 0x0, 0xc78239d4, 0x69) kernel .text 0xc0100000 0xc01a3174 0xc01a32a0 0xc625de14 0xc01b48f6 xfs_trans_reserve+0x122 (0xc78239a0, 0x0, 0x638, 0x0, 0x0) kernel .text 0xc0100000 0xc01b47d4 0xc01b49b4 0xc625dea4 0xc01bc66c xfs_setattr+0x238 (0xc4e96dc0, 0xc625ded0, 0x0, 0xc03df780) kernel .text 0xc0100000 0xc01bc434 0xc01bd25c 0xc625df40 0xc01c89c7 linvfs_notify_change+0x177 (0xc4f47a40, 0xc625df78) kernel .text 0xc0100000 0xc01c8850 0xc01c89f0 0xc625df5c 0xc01442e0 notify_change+0x60 (0xc4f47a40, 0xc625df78) kernel .text 0xc0100000 0xc0144280 0xc0144350 0xc625dfbc 0xc012f1a4 sys_utime+0xa8 (0x806ef5e, 0xbfffd584, 0xbfffd5c4, 0x8079220, 0x806ef5e) kernel .text 0xc0100000 0xc012f0fc 0xc012f1bc 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [1]kdb> From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 18:20:02 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 18:19:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35393 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 18:19:21 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA27587 for ; Tue, 1 Aug 2000 18:11:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA35568; Tue, 1 Aug 2000 20:16:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id UAA30937; Tue, 1 Aug 2000 20:16:16 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id UAA32642; Tue, 1 Aug 2000 20:15:51 -0500 Message-Id: <200008020115.UAA32642@jen.americas.sgi.com> To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: FYI: Hmm looks like a deadlock In-reply-to: Your message of "Tue, 01 Aug 2000 18:19:01 CDT Date: Tue, 01 Aug 2000 20:15:50 -0500 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing So where did this come from - outside SGI I presume. This is not a deadlock amongst the threads with back traces. Threads waiting for log space will block in xlog_grant_log_space until metadata covering the log space is flushed to disk. I have seen pauses from XFS during unmount on a heavily modified filesystem - this may be something similar. Some change in test5 might be at the back of this - an I/O which used to get pushed out is not completing for some reason. Is this repeatable, and if so how? Were KIOBUFs turned on, and what type of device was the filesystem on (scsi or ide?) Other useful information could be obtained if the xfsidbg module was loaded. use the xlog command on the first argument of xlog_grant_log_space, in about the fourth line of its output you will see the mount pointer (mp: xxxx) use xmount on this, also the information from passing the mount point to the xail command would be useful. Thanks Steve > EBP EIP Function(args) > 0xc4e1fd48 0xc0116c82 schedule+0x3ca (0xc5838208) > kernel .text 0xc0100000 0xc01168b8 > 0xc0117170 > 0xc4e1fd7c 0xc01c969a _sv_wait+0xd2 (0xc5838208, 0xc7a81d74, 0x246, 0x0, > 0x0) > kernel .text 0xc0100000 0xc01c95c8 > 0xc01c96b8 > 0xc4e1fdb0 0xc01a531d xlog_grant_log_space+0x91 (0xc7a81ce0, 0xc5838208, > 0xc7ca6400, 0x0, 0xc7a81ce0) > kernel .text 0xc0100000 0xc01a528c > 0xc01a5574 > 0xc4e1fde8 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x638, 0x0, > 0xc72a15f4, 0x69) > kernel .text 0xc0100000 0xc01a3174 > 0xc01a32a0 > 0xc4e1fe14 0xc01b48f6 xfs_trans_reserve+0x122 (0xc72a15c0, 0x0, 0x638, > 0x0, 0x0) > kernel .text 0xc0100000 0xc01b47d4 > 0xc01b49b4 > 0xc4e1fea4 0xc01bc66c xfs_setattr+0x238 (0xc5da770c, 0xc4e1fed0, 0x0, > 0xc03df780) > kernel .text 0xc0100000 0xc01bc434 > 0xc01bd25c > 0xc4e1ff40 0xc01c89c7 linvfs_notify_change+0x177 (0xc236f240, > 0xc4e1ff78) > kernel .text 0xc0100000 0xc01c8850 > 0xc01c89f0 > 0xc4e1ff5c 0xc01442e0 notify_change+0x60 (0xc236f240, 0xc4e1ff78) > kernel .text 0xc0100000 0xc0144280 > 0xc0144350 > 0xc4e1ffbc 0xc012f1a4 sys_utime+0xa8 (0x806ff5d, 0xbfffd594, 0xbfffd5d4, > 0x837ea90, 0x806ff5d) > kernel .text 0xc0100000 0xc012f0fc > 0xc012f1bc > 0xc010a660 system_call+0x34 > kernel .text 0xc0100000 0xc010a62c > 0xc010a664 > [1]kdb> btp 962 > EBP EIP Function(args) > 0xc768fd2c 0xc0116c82 schedule+0x3ca (0xc5838d9c) > kernel .text 0xc0100000 0xc01168b8 > 0xc0117170 > 0xc768fd60 0xc01c969a _sv_wait+0xd2 (0xc5838d9c, 0xc7a81d74, 0x246, 0x0, > 0x0) > kernel .text 0xc0100000 0xc01c95c8 > 0xc01c96b8 > 0xc768fd94 0xc01a53d3 xlog_grant_log_space+0x147 (0xc7a81ce0, > 0xc5838d9c, 0xc7ca6400, 0x9aa70, 0xc7a81ce0) > kernel .text 0xc0100000 0xc01a528c > 0xc01a5574 > 0xc768fdcc 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x4ab38, 0x2, > 0xc7823b14, 0x69) > kernel .text 0xc0100000 0xc01a3174 > 0xc01a32a0 > 0xc768fdf8 0xc01b48f6 xfs_trans_reserve+0x122 (0xc7823ae0, 0x3f, > 0x4ab38, 0x0, 0x4) > kernel .text 0xc0100000 0xc01b47d4 > 0xc01b49b4 > 0xc768fec4 0xc01b0eb2 xfs_rename+0x402 (0xc5c79b84, 0xc3e494e0, > 0xc7d67c20, 0xc4aa0c80, 0xc768fef8) > kernel .text 0xc0100000 0xc01b0ab0 > 0xc01b1630 > 0xc768ff04 0xc01c82d0 linvfs_rename+0xc8 (0xc7d67b40, 0xc4aa0ca0, > 0xc7d67b40, 0xc4aa0c20) > kernel .text 0xc0100000 0xc01c8208 > 0xc01c8350 > 0xc768ff2c 0xc013dcb8 vfs_rename_other+0x274 (0xc7d67b40, 0xc4aa0ca0, > 0xc7d67b40, 0xc4aa0c20) > kernel .text 0xc0100000 0xc013da44 > 0xc013dd10 > 0xc768ff4c 0xc013dd3c vfs_rename+0x2c (0xc7d67b40, 0xc4aa0ca0, > 0xc7d67b40, 0xc4aa0c20) > kernel .text 0xc0100000 0xc013dd10 > 0xc013dd54 > 0xc768ffbc 0xc013df02 sys_rename+0x1ae (0xbfffe6a4, 0x8072f5a, > 0x8072f5a, 0x8072f5a, 0xbfffe6a4) > kernel .text 0xc0100000 0xc013dd54 > 0xc013dfc0 > 0xc010a660 system_call+0x34 > kernel .text 0xc0100000 0xc010a62c > 0xc010a664 > [1]more> q > [1]kdb> btp > diag: -16: Illegal numeric value > [1]kdb> btp 994 > EBP EIP Function(args) > 0xc4eb7f14 0xc0116c82 schedule+0x3ca (0xc4eb7f28) > kernel .text 0xc0100000 0xc01168b8 > 0xc0117170 > 0xc4eb7f3c 0xc011659b schedule_timeout+0x73 > kernel .text 0xc0100000 0xc0116528 > 0xc01165bc > 0xc4eb7f70 0xc013f80c do_select+0x1c4 (0x6, 0xc4eb7fa4, 0xc4eb7fa0) > kernel .text 0xc0100000 0xc013f648 > 0xc013f844 > 0xc4eb7fbc 0xc013fb9e sys_select+0x332 (0x6, 0xbfffe33c, 0x0, 0x0, > 0xbfffe334) > kernel .text 0xc0100000 0xc013f86c > 0xc013fcd4 > 0xc010a660 system_call+0x34 > kernel .text 0xc0100000 0xc010a62c > 0xc010a664 > [1]kdb> btp 995 > Unknown kdb command: 'btp' > [1]kdb> btp 995 > EBP EIP Function(args) > 0xc625dd48 0xc0116c82 schedule+0x3ca (0xc583864c) > kernel .text 0xc0100000 0xc01168b8 > 0xc0117170 > 0xc625dd7c 0xc01c969a _sv_wait+0xd2 (0xc583864c, 0xc7a81d74, 0x246, 0x0, > 0x0) > kernel .text 0xc0100000 0xc01c95c8 > 0xc01c96b8 > 0xc625ddb0 0xc01a531d xlog_grant_log_space+0x91 (0xc7a81ce0, 0xc583864c, > 0xc7ca6400, 0x0, 0xc7a81ce0) > kernel .text 0xc0100000 0xc01a528c > 0xc01a5574 > 0xc625dde8 0xc01a3294 xfs_log_reserve+0x120 (0xc7ca6400, 0x638, 0x0, > 0xc78239d4, 0x69) > kernel .text 0xc0100000 0xc01a3174 > 0xc01a32a0 > 0xc625de14 0xc01b48f6 xfs_trans_reserve+0x122 (0xc78239a0, 0x0, 0x638, > 0x0, 0x0) > kernel .text 0xc0100000 0xc01b47d4 > 0xc01b49b4 > 0xc625dea4 0xc01bc66c xfs_setattr+0x238 (0xc4e96dc0, 0xc625ded0, 0x0, > 0xc03df780) > kernel .text 0xc0100000 0xc01bc434 > 0xc01bd25c > 0xc625df40 0xc01c89c7 linvfs_notify_change+0x177 (0xc4f47a40, > 0xc625df78) > kernel .text 0xc0100000 0xc01c8850 > 0xc01c89f0 > 0xc625df5c 0xc01442e0 notify_change+0x60 (0xc4f47a40, 0xc625df78) > kernel .text 0xc0100000 0xc0144280 > 0xc0144350 > 0xc625dfbc 0xc012f1a4 sys_utime+0xa8 (0x806ef5e, 0xbfffd584, 0xbfffd5c4, > 0x8079220, 0x806ef5e) > kernel .text 0xc0100000 0xc012f0fc > 0xc012f1bc > 0xc010a660 system_call+0x34 > kernel .text 0xc0100000 0xc010a62c > 0xc010a664 > [1]kdb> > From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 20:07:43 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 20:07:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:49745 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Aug 2000 20:06:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA05521 for ; Tue, 1 Aug 2000 19:58:49 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19913 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 2 Aug 2000 13:03:50 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA31393 for linux-xfs@oss.sgi.com; Wed, 2 Aug 2000 13:03:46 +1000 (EST) Date: Wed, 2 Aug 2000 13:03:46 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008020303.NAA31393@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71118a Date: Tue Aug 1 20:03:21 PDT 2000 Workarea: snort:/build4/nathans/base-2.4.0-test1-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/Makefile - 1.21 - add missing target needed for build. cmd/xfs/db/Makefile - 1.49 cmd/xfs/fsr/Makefile - 1.4 cmd/xfs/include/Makefile - 1.5 cmd/xfs/logprint/Makefile - 1.37 cmd/xfs/mkfs/Makefile - 1.40 cmd/xfs/sim/src/Makefile - 1.80 - add missing HFILES needed for build. From owner-linux-xfs-announce@oss.sgi.com Tue Aug 1 23:19:23 2000 Received: by oss.sgi.com id ; Tue, 1 Aug 2000 23:19:03 -0700 Received: from hermes.mixx.net ([212.84.196.2]:48391 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 1 Aug 2000 23:18:29 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 18050F8D8 for ; Wed, 2 Aug 2000 08:17:57 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 83D892CA87; Wed, 2 Aug 2000 08:17:51 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 06:17:51 GMT Organization: innominate AG, Berlin, Germany Lines: 47 Distribution: local Message-ID: References: <200008011414.JAA12528@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965197071 8269 10.0.0.69 (2 Aug 2000 06:17:51 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > The place you probably need to scatter printk all over is fs/pagebuf/page_buf.c > the easiest way to do this is to edit include/linux/page_buf.h and ensure > that PAGEBUF_TRACE is defined (it is dependent on CONFIG_KDB at the moment). > Make sure that debug_pagebuf is set to 1. > Then edit pb_trace_func in page_buf.c and instead of putting data into a > trace buffer, take something based on the code in kdb/modules/kdbm_pg.c > which does this: > if ((trace->event < EV_SIZE) && event_names[trace->event]) { > event = event_names[trace->event]; > } else if (trace->event == 1000) { > event = (char *)trace->misc; > } else { > event = value; > sprintf(value, "%8d", trace->event); > kdb_printf("pb 0x%lx [%s] (hold %u lock %d) misc 0x%p", > trace->pb, event, > trace->hold, trace->lock_value, > trace->misc); > kdb_symbol_print((unsigned int)trace->ra, NULL, > KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); > kdb_printf(" offset 0x%Lx size 0x%x task 0x%p\n", > trace->offset, trace->size, trace->task); > kdb_printf(" flags: %s\n", > pb_flags(trace->flags)); > (clearly those need to become printk messages). ok - basicaly got the idea - what of the above info is mostly needed to debug this ? (i at a first view see no way to get the kdb_symbol_print thing because it looks like it uses kdb structures for finding and printing the symbol) - everything else should be no problem ... ok - will try to get this going t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 00:49:10 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 00:49:00 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:2832 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 00:48:38 -0700 Received: (qmail 26294 invoked from network); 2 Aug 2000 07:47:51 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Aug 2000 07:47:51 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-reply-to: Your message of "02 Aug 2000 06:17:51 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Aug 2000 17:47:50 +1000 Message-ID: <19079.965202470@ocs3.ocs-net> Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 2 Aug 2000 06:17:51 GMT, Thomas Graichen wrote: >Steve Lord wrote: >> kdb_symbol_print((unsigned int)trace->ra, NULL, >> KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); >ok - basicaly got the idea - what of the above info is mostly needed >to debug this ? (i at a first view see no way to get the >kdb_symbol_print thing because it looks like it uses kdb structures >for finding and printing the symbol) - everything else should be >no problem ... ok - will try to get this going Replace kdb_symbol_print(address, NULL, flags); with printk(" 0x%x\n", address); KDB_SP_SPACEB is space before number, KDB_SP_PAREN is address converted to symbol enclosed in () which you cannot do, KDB_SP_NEWLINE is newline after. From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 01:31:59 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 01:31:50 -0700 Received: from hermes.mixx.net ([212.84.196.2]:3596 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 01:31:26 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 44D0CF8DB for ; Wed, 2 Aug 2000 10:30:54 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B38F42CA7A; Wed, 2 Aug 2000 10:30:32 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 08:30:31 GMT Organization: innominate AG, Berlin, Germany Lines: 221 Distribution: local Message-ID: References: <19079.965202470@ocs3.ocs-net> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965205031 8269 10.0.0.69 (2 Aug 2000 08:30:31 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Keith Owens wrote: > On 2 Aug 2000 06:17:51 GMT, > Thomas Graichen wrote: >>Steve Lord wrote: >>> kdb_symbol_print((unsigned int)trace->ra, NULL, >>> KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); >>ok - basicaly got the idea - what of the above info is mostly needed >>to debug this ? (i at a first view see no way to get the >>kdb_symbol_print thing because it looks like it uses kdb structures >>for finding and printing the symbol) - everything else should be >>no problem ... ok - will try to get this going > Replace > kdb_symbol_print(address, NULL, flags); > with > printk(" 0x%x\n", address); > KDB_SP_SPACEB is space before number, KDB_SP_PAREN is address converted > to symbol enclosed in () which you cannot do, KDB_SP_NEWLINE is newline > after. ok will try this too - here is how far i am so far (trying to get it going on x86 first because right now i have no ppc close - will try that this evening) - please have a short look at it - something is wrong with the event thing (int in pb_trace_func but called as char) - maybe i completely srewed it up - then please don't shoot me :-) ok - here's a diff so far to get page_buf tracing without kdb and after the diff is a sample output - any hints whats wrong here (the event stuff is wrong)? - otherwise i'll look closer to it later ... looks like i have mixed up the events between the kdb and the pb_trace_func part a bit ... Index: fs/pagebuf/page_buf.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf.c,v retrieving revision 1.16 diff -u -r1.16 page_buf.c --- fs/pagebuf/page_buf.c 2000/07/31 16:16:28 1.16 +++ fs/pagebuf/page_buf.c 2000/08/02 08:18:32 @@ -62,6 +62,7 @@ #include #include #include +#include #include #include #include @@ -90,7 +91,7 @@ MODULE_DESCRIPTION("page_buf file system buffer module"); #ifdef PAGEBUF_TRACE #define STATIC -int debug_pagebuf = 0; +int debug_pagebuf = 1; static spinlock_t pb_trace_lock = SPIN_LOCK_UNLOCKED; struct pagebuf_trace_buf pb_trace; EXPORT_SYMBOL(pb_trace); @@ -98,6 +99,7 @@ EXPORT_SYMBOL(pb_trace_func); #define CIRC_INC(i) (((i) + 1) & (PB_TRACE_BUFSIZE - 1)) +#ifdef CONFIG_KDB void pb_trace_func(page_buf_t *pb, int event, void *misc, void *ra) { int j; @@ -123,6 +125,86 @@ pb_trace.buf[j].offset = pb->pb_file_offset; pb_trace.buf[j].size = pb->pb_buffer_length; } +#else +#define EV_SIZE (sizeof(event_names)/sizeof(char *)) + +static char *map_flags(unsigned long flags, char *mapping[]) +{ + static char buffer[256]; + int index; + int offset = 12; + + buffer[0] = '\0'; + + for (index = 0; flags && mapping[index]; flags >>= 1, index++) { + if (flags & 1) { + if ((offset + strlen(mapping[index]) + 1) >= 80) { + strcat(buffer, "\n "); + offset = 12; + } else if (offset > 12) { + strcat(buffer, " "); + offset++; + } + strcat(buffer, mapping[index]); + offset += strlen(mapping[index]); + } + } + + return (buffer); +} + +static char *pb_flag_vals[] = { + "READ", "WRITE", "MAPPED", "PARTIAL", + "ASYNC", "NONE", "DELWRI", "FREED", "SYNC", + "LONG_TERM", "FS_RESERVED_1", "FS_RESERVED_2", "RELEASE", + "LOCK", "TRYLOCK", "ALLOCATE", "FILE_ALLOCATE", "DONT_BLOCK", + "DIRECT", "LOCKABLE", "NEXT_KEY", "ENTER_PAGES", + "ALL_PAGES_MAPPED", "SOME_INVALID_PAGES", "ADDR_ALLOCATED", + "MEM_ALLOCATED", "GRIO", "FORECIO", + NULL }; + +static char *pb_flags(page_buf_flags_t pb_flag) +{ + return(map_flags((unsigned long) pb_flag, pb_flag_vals)); +} + +void pb_trace_func(page_buf_t *pb, int event, void *misc, void *ra) +{ + int j; + unsigned long flags; + char *event_name; + char value[10]; + + if (!debug_pagebuf) return; + + if (ra == NULL) ra = (void *)__builtin_return_address(0); + + spin_lock_irqsave(&pb_trace_lock, flags); + j = pb_trace.start; + pb_trace.start = CIRC_INC(j); + spin_unlock_irqrestore(&pb_trace_lock, flags); + + if ((event < EV_SIZE) && event_names[event]) { + event_name = event_names[event]; + } else if (event == 1000) { + event_name = (char *) misc; + } else { + event_name = value; + sprintf(value, "%8d", event); + } + + printk("pb 0x%lx [%s] (hold %u lock %d) misc 0x%p\n", + (unsigned long) pb, event_name, + pb->pb_hold, PBP(pb)->pb_sema.count.counter, + misc); +/* kdb_symbol_print((unsigned int) trace->ra, NULL, + KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); */ + printk(" offset 0x%Lx size 0x%x task 0x%p\n", + pb->pb_file_offset, pb->pb_buffer_length, (void *) current); + printk(" flags: %s\n", + pb_flags(pb->pb_flags)); +} +#endif #define ENTER(x) printk("Entering " #x "\n"); #define EXIT(x) printk("Exiting " #x "\n"); #else Index: include/linux/page_buf.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/linux/page_buf.h,v retrieving revision 1.54 diff -u -r1.54 page_buf.h --- include/linux/page_buf.h 2000/07/24 21:32:09 1.54 +++ include/linux/page_buf.h 2000/08/02 08:18:33 @@ -39,13 +39,7 @@ #ifndef _LINUX_PAGE_BUF_H #define _LINUX_PAGE_BUF_H -/* Tracing only makes sense when you have kdb support - there is no - * other way to read the trace. - */ -#ifdef CONFIG_KDB #define PAGEBUF_TRACE 1 -#endif - #ifdef __KERNEL__ #include ok and here a sample mount output: Aug 2 10:05:50 qed kernel: page_buf module - Copyright (C) by Silicon Graphics Inc. 2000 Aug 2 10:06:02 qed kernel: pb 0xc3c56ee0 [-926718357] (hold 1 lock 0) misc 0xc15f0e20 Aug 2 10:06:02 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:02 qed kernel: flags: NONE LOCKABLE FORECIO Aug 2 10:06:02 qed kernel: pb 0xc3c56ee0 [-926718400] (hold 1 lock 0) misc 0xc4b79c00 Aug 2 10:06:02 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:02 qed kernel: flags: MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:02 qed kernel: pb 0xc3c56ee0 [-926718450] (hold 1 lock 0) misc 0x00000000 Aug 2 10:06:02 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:02 qed kernel: flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:02 qed kernel: pb 0xc3c56ee0 [-926718405] (hold 2 lock 0) misc 0x00000000 Aug 2 10:06:02 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:02 qed kernel: flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:02 qed kernel: pb 0xc3c56ee0 [-926718410] (hold 2 lock 0) misc 0xc8c968ac Aug 2 10:06:05 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:06 qed kernel: flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:07 qed kernel: pb 0xc3c56ee0 [-926718457] (hold 1 lock 0) misc 0x00000000 Aug 2 10:06:07 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:07 qed kernel: flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:08 qed kernel: pb 0xc3c56ee0 [-926718415] (hold 1 lock 0) misc 0x00000000 Aug 2 10:06:08 qed kernel: offset 0x0 size 0x200 task 0xc02cc000 Aug 2 10:06:08 qed kernel: flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:08 qed kernel: pb 0xc3c56ee0 [-926718466] (hold 1 lock 0) misc 0x00000000 Aug 2 10:06:08 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:08 qed kernel: flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:08 qed kernel: pb 0xc3c56ee0 [-926718410] (hold 1 lock 0) misc 0xc8c968ac Aug 2 10:06:08 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:08 qed kernel: flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:08 qed kernel: pb 0xc3c56ee0 [unlock] (hold 1 lock 1) misc 0x00000000 Aug 2 10:06:08 qed kernel: offset 0x0 size 0x200 task 0xc19d8000 Aug 2 10:06:08 qed kernel: flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO Aug 2 10:06:08 qed kernel: pb 0xc3c56e40 [-926718357] (hold 1 lock 0) misc 0xc15f0e20 ... have to go to a meeting now - any hint aprreciated thanks in advance t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 03:40:40 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 03:40:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:6667 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 03:40:02 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id DAA04334 for ; Wed, 2 Aug 2000 03:31:59 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id FAA82118; Wed, 2 Aug 2000 05:38:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id FAA34379; Wed, 2 Aug 2000 05:38:12 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id FAA01002; Wed, 2 Aug 2000 05:37:43 -0500 Message-Id: <200008021037.FAA01002@jen.americas.sgi.com> To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-reply-to: Your message of "02 Aug 2000 08:30:31 GMT Date: Wed, 02 Aug 2000 05:37:42 -0500 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > ok will try this too - here is how far i am so far (trying to get it > going on x86 first because right now i have no ppc close - will try > that this evening) - please have a short look at it - something is > wrong with the event thing (int in pb_trace_func but called as char) > - maybe i completely srewed it up - then please don't shoot me :-) > > ok - here's a diff so far to get page_buf tracing without kdb and after > the diff is a sample output - any hints whats wrong here (the event > stuff is wrong)? - otherwise i'll look closer to it later ... looks > like i have mixed up the events between the kdb and the pb_trace_func > part a bit ... > Try changing include/linux/page_buf_trace.h to look like this: *** /usr/tmp/TmpDir.5088-0/linux/include/linux/page_buf_trace.h_1.9 Wed Aug 2 06:32:45 2000 --- linux/include/linux/page_buf_trace.h Wed Aug 2 05:31:23 2000 *************** *** 32,39 **** #ident "$Id: $" - #ifndef _PAGEBUF_TRACE_INC_ - #define _PAGEBUF_TRACE_INC_ #ifdef PB_DEFINE_TRACES #define PB_TRACE_START typedef enum { --- 32,37 ---- *************** *** 84,89 **** --- 82,94 ---- PB_TRACE_REC(file_write), PB_TRACE_END + #ifndef PB_DEFINE_TRACES + #undef PB_TRACE_START + #undef PB_TRACE_REC(x) + #undef PB_TRACE_END + #endif + + extern void pb_trace_func(page_buf_t *, int, void *, void *); #ifdef PAGEBUF_TRACE #ifdef _PAGE_BUF_INTERNAL_ *************** *** 104,107 **** #endif - #endif --- 109,111 ---- As it stands it can only be included once, you are including it twice, once to get the event_names array and once to declare the enumerated type. You actually need both - you are probably getting warnings like this when building pagebuf: page_buf.c: In function `pagebuf_rele': page_buf.c:976: warning: passing arg 2 of `pb_trace_func' makes integer from pointer without a cast this is because you are passing the string into pb_trace_fun rather than the enumerated type. Steve p.s. from the trace you are completing the read of the super block From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 05:45:40 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 05:45:21 -0700 Received: from hermes.mixx.net ([212.84.196.2]:37380 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 05:44:57 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 3CF2EF903 for ; Wed, 2 Aug 2000 14:44:25 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 80FB72CA6B; Wed, 2 Aug 2000 14:44:24 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 12:44:24 GMT Organization: innominate AG, Berlin, Germany Lines: 49 Distribution: local Message-ID: References: <200008021037.FAA01002@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965220264 16924 10.0.0.69 (2 Aug 2000 12:44:24 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Try changing include/linux/page_buf_trace.h to look like this: did it and it fixed it - thanks > As it stands it can only be included once, you are including it twice, > once to get the event_names array and once to declare the enumerated > type. You actually need both - you are probably getting warnings like > this when building pagebuf: > page_buf.c: In function `pagebuf_rele': > page_buf.c:976: warning: passing arg 2 of `pb_trace_func' makes integer from pointer without a cast > this is because you are passing the string into pb_trace_fun rather than > the enumerated type. yes i did and they are gone now - thanks again - i now have it running fine on x86 which is i think a really good start for moving back to ppc this evening - thanks a lot again t > p.s. from the trace you are completing the read of the super block yes - but this was on x86 - so it should work quite well there :-) btw. here is the output now which looks ok (but again - only on x86 so far) kernel: page_buf module - Copyright (C) by Silicon Graphics Inc. 2000 kernel: pb 0xc7295ee0 [get] (hold 1 lock 0) misc 0xc15f0e20 kernel: address 0xc8c30f72 kernel: offset 0x0 size 0x200 task 0xc39bc000 kernel: flags: NONE LOCKABLE FORECIO kernel: pb 0xc7295ee0 [no_daddr] (hold 1 lock 0) misc 0xc5033600 kernel: address 0xc8cb6c61 kernel: offset 0x0 size 0x200 task 0xc39bc000 kernel: flags: MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO kernel: pb 0xc7295ee0 [ioreq] (hold 1 lock 0) misc 0x00000000 kernel: address 0xc8cb6c0b kernel: offset 0x0 size 0x200 task 0xc39bc000 kernel: flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO ... -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 07:57:42 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 07:57:22 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:59318 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 07:57:04 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id JAA07383; Wed, 2 Aug 2000 09:56:13 -0500 (CDT) Message-Id: <4.2.0.58.20000802095645.00dfe5a0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Aug 2000 09:57:40 -0500 To: "Nathan Scott" , "Martin K. Petersen" , Steve Lord , "William L. Jones" From: "William L. Jones" Subject: Re: xfs with LVM Cc: linux-xfs@oss.sgi.com In-Reply-To: <10008020738.ZM18437@wobbly.melbourne.sgi.com> References: <"Martin K. Petersen" <200008012002.PAA27963@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 07:38 AM 8/2/00 -0500, Nathan Scott wrote: >hi Bill, > >On Aug 2, 6:28am, Martin K. Petersen wrote: > > Subject: Re: xfs with LVM > > >>>>> "Steve" == Steve Lord writes: > > > > Steve> Martin, are you out there to respond to this? > > > > Yes, I'm here. Been busy all day, though, so I haven't poked at it > > yet. Will have a look later today or tomorrow... > > > > > > >> Very minor problem. LVM complains about xfs_reapair doing a > > >> unknown ioctl: > > >> > > >> Jul 31 23:00:04 localhost kernel: lvm -- lvm_blk_ioctl: unknown > > >> command 25636 > > >> > > >> I traced this to some code in the sim library that using the ioctl > > >> > > >> DIOCGETVOLDEV > >This is a hangover from the port from IRIX (have a look in >/usr/include/sys/dkio.h on a recent IRIX) ... there is no such >ioctl on Linux. In the reworked libsim, I have commented this >sort of thing out using a '#ifdef HAVE_VOLUME_MANAGER' ... see >libxfs/init.c. The tools which use the sim_init code that have >been converted (logprint and db) will no longer issue this bogus >ioctl, whereas the tools which have not yet been converted (i.e. >mkfs, repair) still go through the code in sim/src/sim.random.c >... these will be fixed in the not too distant future. > >I'm guessing Martin may be working on a way to do the equivalent >of this IRIX ioctl in Linux/LVM (?)... on IRIX the ioctl tells >the sim_init which data/log/realtime subvolumes are associated >with a given XLV/XVM device. > >cheers. > >-- >Nathan Ok! I was just checking to make sure that it was intended! Bill Jones From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 08:27:32 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 08:27:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:9020 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 08:26:39 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA27938; Wed, 2 Aug 2000 08:18:35 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA66700; Wed, 2 Aug 2000 08:24:22 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA68975; Wed, 2 Aug 2000 08:23:05 -0700 (PDT) Date: Wed, 2 Aug 2000 08:23:05 -0700 (PDT) Message-Id: <200008021523.IAA68975@info.engr.sgi.com> X-Pv-Incident: 797943 webPV: jen.cray.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 797943 - kiobuf I/O and request queue merging panic system To: chait@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797943 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : chait Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : Linux 2.4.0-test5 now has merge functions on the requests queues by default. These merge functions presume that a request has buffer heads on it and will crash the system when they encounter a kiobuf based request. For example, running doio with a 50 Mbyte file in XFS seems to eventually tip over my system with this stack trace: *pde = 00000000 Entering kdb (0xc12d0000) on processor 1 Panic: Oops due to panic @ 0xc01baab0 eax = 0xc3c89000 ebx = 0xc13ea7c0 ecx = 0x00000040 edx = 0x00000000 esi = 0xc13fd000 edi = 0xc129fd98 esp = 0xc12d1edc eip = 0xc01baab0 ebp = 0xc12d1ee8 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010006 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc12d1ea8 [1]kdb> bt EBP EIP Function(args) 0xc12d1ee8 0xc01baab0 scsi_front_merge_fn_c+0x2c (0xc129fd98, 0xc13ea7c0, 0xc29f24a0, 0xfe) kernel .text 0xc0100000 0xc01baa84 0xc01baaec 0xc12d1f3c 0xc016da75 __make_request+0x2d9 (0xc129fd98, 0x1, 0xc29f24a0) kernel .text 0xc0100000 0xc016d79c 0xc016ddec 0xc12d1f68 0xc016debe generic_make_request+0xd2 (0xc129fd98, 0x1, 0xc29f24a0) kernel .text 0xc0100000 0xc016ddec 0xc016ded0 0xc12d1fac 0xc016dfff ll_rw_block+0x12f (0x1, 0x1, 0xc12d1fd0, 0xc12d0000) kernel .text 0xc0100000 0xc016ded0 0xc016e078 0xc12d1fd4 0xc01353d7 flush_dirty_buffers+0x97 (0x0, 0xf00) kernel .text 0xc0100000 0xc0135340 0xc0135424 0xc12d1fec 0xc01356a9 bdflush+0x8d kernel .text 0xc0100000 0xc013561c 0xc01356e4 0xc0108c3b kernel_thread+0x23 kernel .text 0xc0100000 0xc0108c18 0xc0108c50 The reason being that the merge functions are not kiobuf aware and attempt to dereference the buffer head fields in the request. This request structure happens to contain this: struct request at 0xc13ea7c0 rq_dev 0x804 cmd 1 errors 0 sector 90856 nr_sectors 32 hsect 70176 hnrsect 16 nrseg 4 nrhwseg 1 currnrsect 8 kiobuf 0xc5ffbf40 bh 0x00000000 bhtail 0x00000000 req_q 0xc129fd98 Since there are no buffer heads, dereferencing them will take the system out. From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 08:43:03 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 08:42:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:29504 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 08:42:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA00044 for ; Wed, 2 Aug 2000 08:34:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA08028 for ; Wed, 2 Aug 2000 10:39:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA05497 for ; Wed, 2 Aug 2000 10:39:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id KAA09950; Wed, 2 Aug 2000 10:38:39 -0500 Message-Id: <200008021538.KAA09950@jen.americas.sgi.com> Date: Wed, 2 Aug 2000 10:38:39 -0500 Subject: TAKE - fix vnode tracing compilation To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 2 08:38:50 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71142a linux/fs/xfs/linux/xfs_vnode.c - 1.38 - Make vnode tracing work again From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 09:32:33 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 09:32:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12804 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 09:31:52 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03262; Wed, 2 Aug 2000 09:37:17 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA60918; Wed, 2 Aug 2000 09:31:21 -0700 (PDT) Date: Wed, 2 Aug 2000 09:31:21 -0700 (PDT) Message-Id: <200008021631.JAA60918@info.engr.sgi.com> X-Pv-Incident: 797943 webPV: jen.cray.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: CLOSE 797943 - kiobuf I/O and request queue merging panic system To: chait@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797943 *Status : closed Priority : 1 Assigned Engineer : chait Submitter : lord Opened Date : 08/02/00 *Closed Date : 08/02/00 *Fixed By : lord *Fixed By Domain : sgi.com *Modified Date : 08/02/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: lord@sgi.com (BugWorks) Date: Aug 02 2000 09:31:20AM ========================== This has been fixed by mod 2.4.0-test1-xfs:slinx:71146a From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 09:32:53 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 09:32:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58701 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 09:32:23 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA06433 for ; Wed, 2 Aug 2000 09:24:19 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA06905 for ; Wed, 2 Aug 2000 11:29:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA74771 for ; Wed, 2 Aug 2000 11:29:20 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id LAA11488; Wed, 2 Aug 2000 11:28:48 -0500 Message-Id: <200008021628.LAA11488@jen.americas.sgi.com> Date: Wed, 2 Aug 2000 11:28:48 -0500 Subject: TAKE - fix kiobuf based I/O in test5 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Merge in a fix for Chait who has ptools problems - this should fix the problems seen running XFS on scsi with kiobufs turned on. Date: Wed Aug 2 09:27:44 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71146a linux/drivers/block/elevator.c - 1.4 - Bug fix to get kiobuf based I/O working in test5 kernels, prevent merging of a buffer head into a kiobuf based request. From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 11:04:44 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 11:04:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50197 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 11:04:12 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02138 for ; Wed, 2 Aug 2000 11:09:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA81939 for ; Wed, 2 Aug 2000 13:02:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA98264 for ; Wed, 2 Aug 2000 13:02:17 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA12992; Wed, 2 Aug 2000 13:01:45 -0500 Message-Id: <200008021801.NAA12992@jen.americas.sgi.com> Date: Wed, 2 Aug 2000 13:01:45 -0500 Subject: TAKE - Stop XFS from using address space remapping for inode buffers To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS is pulling some vm remapping tricks to map pages into continuous address spaces for. This is a) expensive, and b) not likely to be accepted into Linus's kernel. This does not remove the remapping code, but drastically reduces the use of it by XFS. Basically it is no longer used for inode buffers. This means that for a filesystem with the default block size the remapping code is not used at all. Another solution will have to be found for the other cases (non default block size filesystems). Date: Wed Aug 2 10:58:46 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71152a linux/fs/xfs/xfsidbg.c - 1.150 - Dump the inode buffer contents without relying on the buffer being mapped. linux/fs/xfs/xfs_ialloc.c - 1.139 - Do not ask for a mapped buffer when creating a new inode buffer linux/fs/xfs/xfs_buf.h - 1.57 - Do not bother asking for a buffer to be mapped when we are just making a read ahead call. linux/fs/xfs/xfs_buf_item.c - 1.107 - When calculating how many chunks a buffer will take to log, take into account non-mapped buffers where there is no contiguous memory image of the buffer. linux/fs/xfs/xfs_itable.c - 1.88 - Change how bulkstat locates an inode in a buffer to not depend on the buffer being mapped. linux/fs/xfs/xfs_log_recover.c - 1.182 - Do log recovery on inodes without mapping the buffers. Turn off some range checking asserts which are based on buffers being mapped. linux/fs/xfs/xfs_btree.c - 1.86 - formatting fix linux/fs/xfs/xfs_inode.c - 1.299 - Do not ask for a mapped buffer when reading an inode buffer in. Also remove some debug code which would not work with unmapped buffers. linux/fs/xfs/xfs_trans_buf.c - 1.90 - Do not automatically request buffer mapping if the caller specified some buffer options. linux/fs/pagebuf/page_buf.c - 1.17 - Always fill in the pb_addr field for a 1 page buffer, even if mapping was not requested. Remove unused module parameters From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 11:20:54 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 11:20:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3610 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 11:20:28 -0700 Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07476 for ; Wed, 2 Aug 2000 11:25:52 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id NAA62675 for linux-xfs@oss.sgi.com; Wed, 2 Aug 2000 13:18:38 -0500 (CDT) Date: Wed, 2 Aug 2000 13:18:38 -0500 (CDT) From: Dean Roehrich Message-Id: <200008021818.NAA62675@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix a dmapi compile problem in test5 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing add another header, so this will link under test5 Modid: 2.4.0-test1-xfs:slinx:71158a Date: Wed Aug 2 11:18:26 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs SPRs closed: Severity: Minor Modtype: Bugfix Test Description: built and linked Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/dmapi/dmapi_register.c - 1.2 - add another header, so this will link under test5 From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 12:06:33 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 12:06:23 -0700 Received: from tux.mkp.net ([130.225.60.11]:54290 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 12:05:50 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13K3mA-0003e8-00; Wed, 02 Aug 2000 21:01:58 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id LAA02128; Wed, 2 Aug 2000 11:05:13 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Nathan Scott" Cc: linux-xfs@oss.sgi.com Subject: Re: xfs with LVM References: <200008012002.PAA27963@jen.americas.sgi.com> <10008020738.ZM18437@wobbly.melbourne.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 02 Aug 2000 11:05:13 -0400 In-Reply-To: "Nathan Scott"'s message of "Wed, 2 Aug 2000 07:38:39 -0500" Message-ID: Lines: 22 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Nathan" == Nathan Scott writes: Nathan> I'm guessing Martin may be working on a way to do the Nathan> equivalent of this IRIX ioctl in Linux/LVM (?)... on IRIX the Nathan> ioctl tells the sim_init which data/log/realtime subvolumes Nathan> are associated with a given XLV/XVM device. Ah, now I remember. In my old xfs-tools tree I had simply ripped out that code since Linux LVM doesn't support subvolumes at all. If we have external realtime/log sections, the application using libsim should require those to be specified on the command line (I did implement that for mkfs). Instead of fixing cmd/*, perhaps we should provide some generic sanity checking in sim_init()? -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 12:59:53 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 12:59:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35601 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 12:59:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA04601 for ; Wed, 2 Aug 2000 12:51:06 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA03153 for ; Wed, 2 Aug 2000 14:56:07 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id OAA14558 for ; Wed, 2 Aug 2000 14:56:06 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e72JtjN14976 for linux-xfs@oss.sgi.com; Wed, 2 Aug 2000 14:55:45 -0500 Date: Wed, 2 Aug 2000 14:55:45 -0500 From: Russell Cattelan Message-Id: <200008021955.e72JtjN14976@gibble.americas.sgi.com> Subject: TAKE - Fix readonly mounts To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jul 31 11:33:52 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:70704a linux/include/asm-ia64/unistd.h - 1.5 - fix typo Subject: TAKE - Date: Wed Aug 2 12:55:27 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71165a linux/fs/xfs/xfs_log_recover.c - 1.183 - Fix readonly recovery. XFS will mount as a root file system again. From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 13:07:54 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 13:07:34 -0700 Received: from hermes.mixx.net ([212.84.196.2]:16388 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 13:07:12 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 051EAF960 for ; Wed, 2 Aug 2000 22:06:40 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 94E782CA6B; Wed, 2 Aug 2000 22:06:39 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 20:06:39 GMT Organization: innominate AG, Berlin, Germany Lines: 58 Distribution: local Message-ID: References: <200008021037.FAA01002@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965246799 10452 10.0.0.69 (2 Aug 2000 20:06:39 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Try changing include/linux/page_buf_trace.h to look like this: > ... ok - got it now going on the ppc and here are the results for the try of a xfs mount (in the hope that this helps someone to get closer to the problem): page_buf module - Copyright (C) by Silicon Graphics Inc. 2000 pb 0xc1d2c080 [get] (hold 1 lock 0) misc 0xc38be360 address 0xc586f200 offset 0x0 size 0x200 task 0xc39fc000 flags: NONE LOCKABLE FORECIO pb 0xc1d2c080 [no_daddr] (hold 1 lock 0) misc 0xc32dd200 address 0xc58fa0b4 offset 0x0 size 0x200 task 0xc39fc000 flags: MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [ioreq] (hold 1 lock 0) misc 0x00000000 address 0xc58fa040 offset 0x0 size 0x200 task 0xc39fc000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [hold] (hold 2 lock 0) misc 0x00000000 address 0xc587090b offset 0x0 size 0x200 task 0xc39fc000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [rele] (hold 2 lock 0) misc 0xc58d7f44 address 0xc5870a2c offset 0x0 size 0x200 task 0xc39fc000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [iowait] (hold 1 lock 0) misc 0x00000000 address 0xc58d621c offset 0x0 size 0x200 task 0xc39fc000 flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [done] (hold 1 lock 0) misc 0x00000000 address 0xc586fc74 offset 0x0 size 0x200 task 0xc39fc000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO pb 0xc1d2c080 [iowaited] (hold 1 lock 0) misc 0x00000000 address 0xc58d621c offset 0x0 size 0x200 task 0xc39fc000 flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO yes and here it hangs ... if you need any other debugging info - just let me know and i'll do my best to provide it a diff of the code used against the current sgi xfs cvs tree from oss.sgi.com can be found at http://innominate.org/~graichen/projects/xfs-ppc/diff.000802 t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 13:45:24 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 13:45:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:40479 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 13:44:48 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA11258 for ; Wed, 2 Aug 2000 13:36:45 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA02435 for ; Wed, 2 Aug 2000 13:39:26 -0700 (PDT) Message-ID: <398886F9.A602A250@sgi.com> Date: Wed, 02 Aug 2000 13:39:21 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - fix a problem in cluster_write Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fix allows lmdd(write) to run to completion, again. Date: Wed Aug 2 13:40:07 PDT 2000 Workarea: dbear.engr.sgi.com:/build2/ananth/slinx24-xfs-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71169a linux/fs/pagebuf/page_buf_io.c - 1.16 - Don't wait for cluster_write to finish. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 13:56:04 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 13:55:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17186 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 13:55:25 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA12616 for ; Wed, 2 Aug 2000 13:47:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA32151; Wed, 2 Aug 2000 15:52:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA74472; Wed, 2 Aug 2000 15:52:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA17657; Wed, 2 Aug 2000 15:51:39 -0500 Message-Id: <200008022051.PAA17657@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "02 Aug 2000 20:06:39 GMT." Date: Wed, 02 Aug 2000 15:51:38 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hmmm, so the super block got read from disk, but you did not get much further than this. The super block read comes out of xfs_readsb in fs/xfs/xfs_mount.c, in this section of code: XFS_BUF_SET_BRELSE_FUNC(bp,xfs_sb_relse); XFS_BUF_SET_ADDR(bp, XFS_SB_DADDR); XFS_BUF_READ(bp); XFS_BUF_SET_TARGET(bp, mp->m_ddev_targp); xfsbdstrat(mp, bp); if (error = xfs_iowait(bp)) { cmn_err(CE_WARN, "XFS: SB read failed\n"); goto err; } /* * Initialize the mount structure from the superblock. * But first do some basic consistency checking. */ sbp = XFS_BUF_TO_SBP(bp); xfs_xlatesb(XFS_BUF_PTR(bp), &(mp->m_sb), 1, ARCH_CONVERT, XFS_SB_ALL_BITS); if (error = xfs_mount_validate_sb(mp, &(mp->m_sb))) { cmn_err(CE_WARN, "XFS: SB validate failed\n"); goto err; } mp->m_sb_bp = bp; xfs_buf_relse(bp); ASSERT(XFS_BUF_VALUSEMA(bp) > 0); return 0; You got as far as returning from xfs_iowait, but you did not get as far as the xfs_buf_relse at the end of the function - the first thing it will end up doing is another pagebuf trace call. There is not a lot in here which could hang you up - the only possibility I can see is cmn_err() which is in fs/xfs/linux/xfs_random.c and looks like this: void cmn_err(register int level, char *fmt, ...) { char *fp = fmt; char message[256]; va_list ap; va_start(ap, fmt); if (*fmt == '!') fp++; vsprintf(message, fp, ap); printk("%s\n", message); va_end(ap); } Possibly this is messing up, but I do not really see how. Maybe scattering prinks through the xfs_readsb will tell us something else. Steve > Steve Lord wrote: > > > Try changing include/linux/page_buf_trace.h to look like this: > > ... > > ok - got it now going on the ppc and here are the results for > the try of a xfs mount (in the hope that this helps someone > to get closer to the problem): > > page_buf module - Copyright (C) by Silicon Graphics Inc. 2000 > pb 0xc1d2c080 [get] (hold 1 lock 0) misc 0xc38be360 > address 0xc586f200 > offset 0x0 size 0x200 task 0xc39fc000 > flags: NONE LOCKABLE FORECIO > pb 0xc1d2c080 [no_daddr] (hold 1 lock 0) misc 0xc32dd200 > address 0xc58fa0b4 > offset 0x0 size 0x200 task 0xc39fc000 > flags: MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [ioreq] (hold 1 lock 0) misc 0x00000000 > address 0xc58fa040 > offset 0x0 size 0x200 task 0xc39fc000 > flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [hold] (hold 2 lock 0) misc 0x00000000 > address 0xc587090b > offset 0x0 size 0x200 task 0xc39fc000 > flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [rele] (hold 2 lock 0) misc 0xc58d7f44 > address 0xc5870a2c > offset 0x0 size 0x200 task 0xc39fc000 > flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [iowait] (hold 1 lock 0) misc 0x00000000 > address 0xc58d621c > offset 0x0 size 0x200 task 0xc39fc000 > flags: READ MAPPED NONE LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [done] (hold 1 lock 0) misc 0x00000000 > address 0xc586fc74 > offset 0x0 size 0x200 task 0xc39fc000 > flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO > pb 0xc1d2c080 [iowaited] (hold 1 lock 0) misc 0x00000000 > address 0xc58d621c > offset 0x0 size 0x200 task 0xc39fc000 > flags: MAPPED LOCKABLE MEM_ALLOCATED FORECIO > > yes and here it hangs ... if you need any other debugging > info - just let me know and i'll do my best to provide it > > a diff of the code used against the current sgi xfs cvs > tree from oss.sgi.com can be found at > > http://innominate.org/~graichen/projects/xfs-ppc/diff.000802 > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 15:05:44 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 15:05:24 -0700 Received: from hermes.mixx.net ([212.84.196.2]:61958 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 15:05:05 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 820A7F97A for ; Thu, 3 Aug 2000 00:04:32 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id F07C32CA6B; Thu, 3 Aug 2000 00:04:31 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 22:04:31 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: <200008022051.PAA17657@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965253871 1355 10.0.0.69 (2 Aug 2000 22:04:31 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Maybe scattering prinks through the xfs_readsb will tell us something > else. ok - i have found the place where it hangs (by the help of lots of printk's and at the end also delays :-) - it loops in xfs_xlatesb through the while loop taking the "if (arch == ARCH_NOCONVERT" and the "if (dir>0) {" (not the "else" one in both cases) ... does this help you in any way ? - should i print out any variables there ? so what next ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 15:26:53 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 15:26:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39743 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 15:26:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25034 for ; Wed, 2 Aug 2000 15:18:06 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA38582; Wed, 2 Aug 2000 17:24:14 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id RAA19676; Wed, 2 Aug 2000 17:24:13 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e72MNpA21603; Wed, 2 Aug 2000 17:23:52 -0500 Message-ID: <39889F77.BD9BADA8@thebarn.com> Date: Wed, 02 Aug 2000 17:23:51 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc References: <200008022051.PAA17657@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Steve Lord wrote: > > > Maybe scattering prinks through the xfs_readsb will tell us something > > else. > > ok - i have found the place where it hangs (by the help of lots of > printk's and at the end also delays :-) - it loops in xfs_xlatesb > through the while loop taking the "if (arch == ARCH_NOCONVERT" and > the "if (dir>0) {" (not the "else" one in both cases) ... does this > help you in any way ? - should i print out any variables there ? > > so what next ? > Hmm this probalby has something to do with the endian conversion macros. Can you print out the value of arch and say the first 10 bytes of buf_ptr and mem_ptr. Before getting into the loop. > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 15:34:43 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 15:34:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58945 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 15:34:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA26120 for ; Wed, 2 Aug 2000 15:26:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA64846; Wed, 2 Aug 2000 17:32:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA22071; Wed, 2 Aug 2000 17:32:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id RAA30167; Wed, 2 Aug 2000 17:31:42 -0500 Message-Id: <200008022231.RAA30167@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "02 Aug 2000 22:04:31 GMT." Date: Wed, 02 Aug 2000 17:31:42 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > Maybe scattering prinks through the xfs_readsb will tell us something > > else. > > ok - i have found the place where it hangs (by the help of lots of > printk's and at the end also delays :-) - it loops in xfs_xlatesb > through the while loop taking the "if (arch == ARCH_NOCONVERT" and > the "if (dir>0) {" (not the "else" one in both cases) ... does this > help you in any way ? - should i print out any variables there ? > > so what next ? > My cheap answer is we wait for the Australians who did the endian conversion work to come in to work. A big endian version of this code has booted but any changes this required have not been put back into the tree, I suspect something in this area, since this code is dealing with byte swapping and should be a noop in your case. You could replace this code: sbp = XFS_BUF_TO_SBP(bp); xfs_xlatesb(XFS_BUF_PTR(bp), &(mp->m_sb), 1, ARCH_CONVERT, XFS_SB_ALL_BITS); if (error = xfs_mount_validate_sb(mp, &(mp->m_sb))) { cmn_err(CE_WARN, "XFS: SB validate failed\n"); goto err; } mp->m_sb_bp = bp; With this code: sbp = XFS_BUF_TO_SBP(bp); if (error = xfs_mount_validate_sb(mp, sbp)) { goto err; } mp->m_sb_bp = bp; mp->m_sb = *sbp; /* bcopy structure */ and see what happens. In theory you do not need the conversion. Steve From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 16:24:43 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 16:24:33 -0700 Received: from hermes.mixx.net ([212.84.196.2]:47368 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 16:24:07 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 5F341F989 for ; Thu, 3 Aug 2000 01:23:25 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 250822CA71; Thu, 3 Aug 2000 01:23:25 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 23:23:25 GMT Organization: innominate AG, Berlin, Germany Lines: 71 Distribution: local Message-ID: References: <200008022231.RAA30167@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965258605 1355 10.0.0.69 (2 Aug 2000 23:23:25 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > My cheap answer is we wait for the Australians who did the endian conversion > work to come in to work. A big endian version of this code has booted but > any changes this required have not been put back into the tree, I suspect > something in this area, since this code is dealing with byte swapping > and should be a noop in your case. > You could replace this code: > sbp = XFS_BUF_TO_SBP(bp); > xfs_xlatesb(XFS_BUF_PTR(bp), &(mp->m_sb), 1, ARCH_CONVERT, > XFS_SB_ALL_BITS); > if (error = xfs_mount_validate_sb(mp, &(mp->m_sb))) { > cmn_err(CE_WARN, "XFS: SB validate failed\n"); > goto err; > } > mp->m_sb_bp = bp; > With this code: > sbp = XFS_BUF_TO_SBP(bp); > if (error = xfs_mount_validate_sb(mp, sbp)) { > goto err; > } > mp->m_sb_bp = bp; > mp->m_sb = *sbp; /* bcopy structure */ > and see what happens. In theory you do not need the conversion. looks like i have right now made the first successful xfs mount on linux/ppc :-) [root@aqua /root]# cat /mnt/floppy/XFS i am here [root@aqua /root]# mount | grep floppy /dev/hda8 on /mnt/floppy type xfs (rw) [root@aqua /root]# it also seems to work a bit ... [root@aqua floppy]# cp -av /bin . /bin -> ./bin /bin/bash -> ./bin/bash but here it crashed with pb 0xc3272380 [unlock] (hold 1 lock 1) misc 0x00000000 address 0xc5870e64 offset 0x400 size 0x200 task 0xc108c000 flags: MAPPED ASYNC DELWRI LOCK LOCKABLE ALL_PAGES_MAPPED MEM_ALLOCATED XFS assertation failed: indlen > 0, file: xfs_bmap.c, line: 4904 kernel BUG at xfs_debug.c:50! before were: ... ioreq, hold, rele, done, done, rele, unlock, walkq1 and something with the debugger prompt ontop of it (which i can't use due to non existant serial port on an imac :-) i will go to bed now - it's quite late again already ... if i should test anything else - just let me know ... a lot of thanks for all your help - more tomorrow t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 16:26:33 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 16:26:13 -0700 Received: from hermes.mixx.net ([212.84.196.2]:49672 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 16:25:52 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 23C5FF989 for ; Thu, 3 Aug 2000 01:25:21 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id E04B82CA71; Thu, 3 Aug 2000 01:25:20 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 2 Aug 2000 23:25:20 GMT Organization: innominate AG, Berlin, Germany Lines: 35 Distribution: local Message-ID: References: <200008022051.PAA17657@jen.americas.sgi.com> <39889F77.BD9BADA8@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965258720 1355 10.0.0.69 (2 Aug 2000 23:25:20 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Thomas Graichen wrote: >> Steve Lord wrote: >> >> > Maybe scattering prinks through the xfs_readsb will tell us something >> > else. >> >> ok - i have found the place where it hangs (by the help of lots of >> printk's and at the end also delays :-) - it loops in xfs_xlatesb >> through the while loop taking the "if (arch == ARCH_NOCONVERT" and >> the "if (dir>0) {" (not the "else" one in both cases) ... does this >> help you in any way ? - should i print out any variables there ? >> >> so what next ? >> Hmm this probalby has something to do with the endian conversion macros. > Can you print out the value of arch and > say the first 10 bytes of buf_ptr and mem_ptr. > Before getting into the loop. arch is "1" - can you please just send me printf's for everything else you want to see ? also see my response to the other mail from steve lord: i finally got it successfully mounted so far with his suggestion (to just ignore the xfs_xlatesb ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 16:51:34 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 16:51:23 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4438 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 16:50:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA05434 for ; Wed, 2 Aug 2000 16:42:49 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA26974; Thu, 3 Aug 2000 09:49:05 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA60836; Thu, 3 Aug 2000 09:49:02 +1000 (EST) Message-Id: <200008022349.JAA60836@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-reply-to: Your message of "Wed, 02 Aug 2000 17:31:42 EST." <200008022231.RAA30167@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Aug 2000 09:49:01 +1000 From: Daniel Moore Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord writes: => > ok - i have found the place where it hangs (by the help of lots of => > printk's and at the end also delays :-) - it loops in xfs_xlatesb => > through the while loop taking the "if (arch == ARCH_NOCONVERT" and => > the "if (dir>0) {" (not the "else" one in both cases) ... does this => > help you in any way ? - should i print out any variables there ? => My cheap answer is we wait for the Australians who did the endian => conversion => work to come in to work. A big endian version of this code has booted but => any changes this required have not been put back into the tree, I suspect => something in this area, since this code is dealing with byte swapping => and should be a noop in your case. We're awake now but soon to be in meetings. Stubbing out xfs_xlatesb is fine in the mount, but later on it gets used to copy selected fields between two superblocks, so you'll need it to work. When you say it loops in xfs_xlatesb, do you mean it loops _forever_? Because it should loop quite a few times (once for each field) but obviously should terminate. If it loops forever, I suspect there must be an endian issue with xfs_lowbit64. Could you print out the value "f" returned by this each time around and let me know what you get? You should get "0", "1", "2"... "42" and then the function should exit The only way I can see it getting stuck is if xfs_lowbit64 has issues and ends up returning the wrong number, never letting the while terminate. You'll need xfs_lowbit64 to be correct for everything to work, so it would be worth checking it out... Let me know how you get on. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 18:18:34 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 18:18:24 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:37067 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 18:18:01 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id UAA13910; Wed, 2 Aug 2000 20:17:28 -0500 (CDT) Date: Wed, 2 Aug 2000 20:17:28 -0500 (CDT) Message-Id: <200008030117.UAA13910@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Possible xfs log problem Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing 1) Create a small xfs file system on /mnt. I used 1g. 2) Create some file on the new xfs file system. 3) sync the file system. 4) Create some more files. Delete an old file made in step 2. Create some more files. (We are tring to get xfs to reuse the delete files inode) 5) umount /mnt 6) mount /mnt 7) If step 7 worked go back to step one and doit again. This should produce the kernel error found at the end of this message. The error was casued by xlog_get_bp returning a NULL when allocating a big_bp in xlog_find_zeroed in xfs_log_recover.c. It was requesting 256 blocks! If you run xfs_repair between step 5 and 6 then step 6 will work. xfs_repair zeros the xfs_log file which I suppect is corrupted some how by the reuse of a delete inode. William L. Jones ------------------------------------------------------------------------------------ Aug 2 18:46:10 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual a ddress 00000008 Aug 2 18:46:10 localhost kernel: printing eip: Aug 2 18:46:10 localhost kernel: c01b3b7a Aug 2 18:46:10 localhost kernel: *pde = 00000000 Aug 2 18:46:10 localhost kernel: Oops: 0002 Aug 2 18:46:10 localhost kernel: CPU: 0 Aug 2 18:46:10 localhost kernel: EIP: 0010:[xlog_bread+18/128] Aug 2 18:46:10 localhost kernel: EFLAGS: 00010202 Aug 2 18:46:10 localhost kernel: eax: 000fa0b9 ebx: 00000000 ecx: 00000099 edx: 00000000 Aug 2 18:46:10 localhost kernel: esi: 0000257f edi: c1c80b80 ebp: c1c844e0 esp: c1999960 Aug 2 18:46:10 localhost kernel: ds: 0018 es: 0018 ss: 0018 Aug 2 18:46:10 localhost kernel: Process mount (pid: 584, stackpage=c1999000) Aug 2 18:46:10 localhost kernel: Stack: c1c80b80 0000257f 00000000 c01b4a24 c1c80b80 00000099 00000000 00000100 Aug 2 18:46:10 localhost kernel: 00000000 c1c80b80 c1c80b80 00000000 00000000 00000100 00000000 00000001 Aug 2 18:46:10 localhost kernel: c19999b4 00000099 00000000 00000000 c1c80b80 00000199 00000000 c01b3e7d Aug 2 18:46:10 localhost kernel: Call Trace: [xlog_find_zeroed+444/612] [xlog_find_head+33/136 0] [xlog_put_bp+10/16] [xlog_test_footer+321/336] [xlog_find_tail+53/876] [pagebuf_get_empty+27 /44] [xlog_alloc_log+569/608] Aug 2 18:46:10 localhost kernel: [xlog_recover+32/196] [xfs_log_mount+82/164] [xfs_log_ mount+117/164] [xfs_mountfs_int+3010/4524] [read_intr+0/316] [xfs_dir2_mount+0/292] [start_requ est+440/560] [xfs_readsb+115/200] Aug 2 18:46:10 localhost kernel: [xfs_sb_relse+14/20] [pagebuf_rele+50/136] [xfs_mountf s+25/32] [xfs_cmountfs+1374/1484] [merge_segments+27/408] [xfs_mount+241/428] [strtok+35/92] [x fs_vfsmount+35/56] Aug 2 18:46:10 localhost kernel: [xfs_vfsmount+0/56] [linvfs_read_super+410/608] [do_in t+109/256] [iput+370/376] [blkdev_get+263/292] [read_super+256/336] [get_sb_bdev+330/416] [do_m ount+420/712] Aug 2 18:46:10 localhost kernel: [copy_mount_options+80/156] [sys_mount+175/288] [syste m_call+56/64] Aug 2 18:46:10 localhost kernel: Code: 81 4b 08 01 00 00 08 89 43 40 8b 4c 24 1c c1 e1 09 89 4 b 20 From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 18:47:05 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 18:46:55 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61254 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 2 Aug 2000 18:46:23 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA00928 for ; Wed, 2 Aug 2000 18:51:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA79613; Wed, 2 Aug 2000 20:44:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id UAA38333; Wed, 2 Aug 2000 20:44:30 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id UAA30380; Wed, 2 Aug 2000 20:43:54 -0500 Message-Id: <200008030143.UAA30380@jen.americas.sgi.com> To: Daniel Moore cc: thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-reply-to: Your message of "Thu, 03 Aug 2000 09:49:01 +1000 Date: Wed, 02 Aug 2000 20:43:54 -0500 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Steve Lord writes: > > => > ok - i have found the place where it hangs (by the help of lots of > => > printk's and at the end also delays :-) - it loops in xfs_xlatesb > => > through the while loop taking the "if (arch == ARCH_NOCONVERT" and > => > the "if (dir>0) {" (not the "else" one in both cases) ... does this > => > help you in any way ? - should i print out any variables there ? > > => My cheap answer is we wait for the Australians who did the endian > => conversion > => work to come in to work. A big endian version of this code has booted bu t > => any changes this required have not been put back into the tree, I suspect > => something in this area, since this code is dealing with byte swapping > => and should be a noop in your case. > > We're awake now but soon to be in meetings. > > Stubbing out xfs_xlatesb is fine in the mount, but later on it gets > used to copy selected fields between two superblocks, so you'll need > it to work. > > When you say it loops in xfs_xlatesb, do you mean it loops _forever_? > Because it should loop quite a few times (once for each field) but > obviously should terminate. This was a loops forever - i.e. get bored waiting for it, there is no kdb on this architecture, so debugging is more interesting! But yes, this needs to work in the long run (tomorrow?). Steve > > If it loops forever, I suspect there must be an endian issue with > xfs_lowbit64. Could you print out the value "f" returned by this > each time around and let me know what you get? You should get > "0", "1", "2"... "42" and then the function should exit > > The only way I can see it getting stuck is if xfs_lowbit64 has issues > and ends up returning the wrong number, never letting the while terminate. > > You'll need xfs_lowbit64 to be correct for everything to work, so it > would be worth checking it out... > > Let me know how you get on. > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- > From owner-linux-xfs-announce@oss.sgi.com Wed Aug 2 22:37:36 2000 Received: by oss.sgi.com id ; Wed, 2 Aug 2000 22:37:26 -0700 Received: from hermes.mixx.net ([212.84.196.2]:47374 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 2 Aug 2000 22:36:44 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 2CE7DF9AC for ; Thu, 3 Aug 2000 07:36:12 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 976BE2CA73; Thu, 3 Aug 2000 07:36:11 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 3 Aug 2000 05:36:11 GMT Organization: innominate AG, Berlin, Germany Lines: 36 Distribution: local Message-ID: References: <200008022231.RAA30167@jen.americas.sgi.com> <200008022349.JAA60836@clouds.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965280971 19897 10.0.0.69 (3 Aug 2000 05:36:11 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > We're awake now but soon to be in meetings. > Stubbing out xfs_xlatesb is fine in the mount, but later on it gets > used to copy selected fields between two superblocks, so you'll need > it to work. > When you say it loops in xfs_xlatesb, do you mean it loops _forever_? > Because it should loop quite a few times (once for each field) but > obviously should terminate. > If it loops forever, I suspect there must be an endian issue with > xfs_lowbit64. Could you print out the value "f" returned by this > each time around and let me know what you get? You should get > "0", "1", "2"... "42" and then the function should exit > The only way I can see it getting stuck is if xfs_lowbit64 has issues > and ends up returning the wrong number, never letting the while terminate. > You'll need xfs_lowbit64 to be correct for everything to work, so it > would be worth checking it out... > Let me know how you get on. ok - i now switched back to use xlatesb again and added a printk for f and the result is: it runs from 0 to 33 and then loops at 33 - looks a bit like some 64bit issue ... what to look for next ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 06:45:27 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 06:45:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:57924 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 06:44:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA00127 for ; Thu, 3 Aug 2000 06:36:39 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA44313; Thu, 3 Aug 2000 08:42:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA43570; Thu, 3 Aug 2000 08:42:52 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA31394; Thu, 3 Aug 2000 08:42:11 -0500 Message-Id: <200008031342.IAA31394@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "03 Aug 2000 05:36:11 GMT." Date: Thu, 03 Aug 2000 08:42:10 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a bit of a shock in the dark, but here goes..... there are two things you can try: 1. in xfs_bit.c try undefining _MIPS_SIM after the header file includes. (we need to generalize the name of this define - it is a hang over from the irix code). Undefining it will cause all the masking code to use 32 bit quantities. An alternative in this file is to try putting LL at the end of the 64 bit constants. I do not know how well the ppc compiler copes with constants like this - if this turns out to be the problem then we will need to look all over XFS for constants which are not explicitly typed to be 64 bit. The body of this function is identical to the code on Irix - where XFS is on a big endian cpu, so the function itself does not have problems. 2. in xfs_xlatesb try changing this statement at the end of the function: fields &= ~(1LL << f); to be fields &= ~(1LL << (long long)f); Here a 64 bit mask value is being generated - it may also be something the compiler has issues with. A simple user space test would be this unsigned int i; for (i = 0; i < 64; i++) { printf("Mask %d is 0x%llx", ~(1LL << i)); } If the compiler was truncating the mask to be 32 bits the behavior you are seeing could be explained. news-innominate.list.sgi.xfs@innominate.de said: >> but here it crashed with >> pb 0xc3272380 [unlock] (hold 1 lock 1) misc 0x00000000 >> address 0xc5870e64 >> offset 0x400 size 0x200 task 0xc108c000 >> flags: MAPPED ASYNC DELWRI LOCK LOCKABLE ALL_PAGES_MAPPED >> MEM_ALLOCATED XFS assertation failed: indlen > 0, file: xfs_bmap.c, >> line: 4904 kernel BUG at xfs_debug.c:50! Go to this location in the file and change the assert to read: ASSERT(indlen > 0LL); again this could be a 64 bit issue (since indlen is 64 bit). Steve > > > You'll need xfs_lowbit64 to be correct for everything to work, so it > > would be worth checking it out... > > > Let me know how you get on. > > ok - i now switched back to use xlatesb again and added a printk for > f and the result is: it runs from 0 to 33 and then loops at 33 - looks > a bit like some 64bit issue ... what to look for next ? > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tgr From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 06:52:57 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 06:52:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:15430 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 06:52:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA00662 for ; Thu, 3 Aug 2000 06:44:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA97289; Thu, 3 Aug 2000 08:50:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA33152; Thu, 3 Aug 2000 08:50:18 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA31434; Thu, 3 Aug 2000 08:49:37 -0500 Message-Id: <200008031349.IAA31434@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Steve Lord of "Thu, 03 Aug 2000 08:42:10 CDT." <200008031342.IAA31394@jen.americas.sgi.com> Date: Thu, 03 Aug 2000 08:49:36 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > This is a bit of a shock in the dark, but here goes..... > That should be shot of course - not enough coffee yet! From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 06:55:57 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 06:55:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64861 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 06:55:23 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01740 for ; Thu, 3 Aug 2000 07:00:48 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id GAA24088 for ; Thu, 3 Aug 2000 06:54:21 -0700 (PDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id IAA39350 for linux-xfs@oss.sgi.com; Thu, 3 Aug 2000 08:51:45 -0500 (CDT) Date: Thu, 3 Aug 2000 08:51:45 -0500 (CDT) From: Dean Roehrich Message-Id: <200008031351.IAA39350@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add xfs_dmapi glue to dmapi Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing add xfs_dmapi glue to dmapi Modid: 2.4.0-test1-xfs:slinx:71218a Date: Thu Aug 3 06:51:30 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs SPRs closed: Severity: Minor Modtype: Bugfix Test Description: built and linked Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/Makefile - 1.106 - add xfs_dmapi glue to dmapi From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 07:24:28 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 07:24:18 -0700 Received: from hermes.mixx.net ([212.84.196.2]:41477 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 07:23:50 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 70A72F9BB for ; Thu, 3 Aug 2000 16:23:18 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 1E7812CA6D; Thu, 3 Aug 2000 16:23:18 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 3 Aug 2000 14:23:17 GMT Organization: innominate AG, Berlin, Germany Lines: 100 Distribution: local Message-ID: References: <200008031342.IAA31394@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965312597 2093 10.0.0.69 (3 Aug 2000 14:23:17 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > This is a bit of a shock in the dark, but here goes..... > there are two things you can try: > 1. in xfs_bit.c try undefining _MIPS_SIM after the header file includes. > ... > 2. in xfs_xlatesb try changing this statement at the end of the function: > ... > Here a 64 bit mask value is being generated - it may also be something > the compiler has issues with. A simple user space test would be this > > unsigned int i; > > for (i = 0; i < 64; i++) { > printf("Mask %d is 0x%llx", ~(1LL << i)); > } > > If the compiler was truncating the mask to be 32 bits the behavior you > are seeing could be explained. here is the result of the userland thing: Mask 1 is 0xfffffffffffffffe Mask 2 is 0xfffffffffffffffd Mask 4 is 0xfffffffffffffffb Mask 8 is 0xfffffffffffffff7 Mask 16 is 0xffffffffffffffef Mask 32 is 0xffffffffffffffdf Mask 64 is 0xffffffffffffffbf Mask 128 is 0xffffffffffffff7f Mask 256 is 0xfffffffffffffeff Mask 512 is 0xfffffffffffffdff Mask 1024 is 0xfffffffffffffbff Mask 2048 is 0xfffffffffffff7ff Mask 4096 is 0xffffffffffffefff Mask 8192 is 0xffffffffffffdfff Mask 16384 is 0xffffffffffffbfff Mask 32768 is 0xffffffffffff7fff Mask 65536 is 0xfffffffffffeffff Mask 131072 is 0xfffffffffffdffff Mask 262144 is 0xfffffffffffbffff Mask 524288 is 0xfffffffffff7ffff Mask 1048576 is 0xffffffffffefffff Mask 2097152 is 0xffffffffffdfffff Mask 4194304 is 0xffffffffffbfffff Mask 8388608 is 0xffffffffff7fffff Mask 16777216 is 0xfffffffffeffffff Mask 33554432 is 0xfffffffffdffffff Mask 67108864 is 0xfffffffffbffffff Mask 134217728 is 0xfffffffff7ffffff Mask 268435456 is 0xffffffffefffffff Mask 536870912 is 0xffffffffdfffffff Mask 1073741824 is 0xffffffffbfffffff Mask -2147483648 is 0xffffffff7fffffff Mask 0 is 0xfffffffeffffffff Mask 0 is 0xfffffffdffffffff Mask 0 is 0xfffffffbffffffff Mask 0 is 0xfffffff7ffffffff Mask 0 is 0xffffffefffffffff Mask 0 is 0xffffffdfffffffff Mask 0 is 0xffffffbfffffffff Mask 0 is 0xffffff7fffffffff Mask 0 is 0xfffffeffffffffff Mask 0 is 0xfffffdffffffffff Mask 0 is 0xfffffbffffffffff Mask 0 is 0xfffff7ffffffffff Mask 0 is 0xffffefffffffffff Mask 0 is 0xffffdfffffffffff Mask 0 is 0xffffbfffffffffff Mask 0 is 0xffff7fffffffffff Mask 0 is 0xfffeffffffffffff Mask 0 is 0xfffdffffffffffff Mask 0 is 0xfffbffffffffffff Mask 0 is 0xfff7ffffffffffff Mask 0 is 0xffefffffffffffff Mask 0 is 0xffdfffffffffffff Mask 0 is 0xffbfffffffffffff Mask 0 is 0xff7fffffffffffff Mask 0 is 0xfeffffffffffffff Mask 0 is 0xfdffffffffffffff Mask 0 is 0xfbffffffffffffff Mask 0 is 0xf7ffffffffffffff Mask 0 is 0xefffffffffffffff Mask 0 is 0xdfffffffffffffff Mask 0 is 0xbfffffffffffffff Mask 0 is 0x7fffffffffffffff which looks like what you said above - but also a (long long)i does not change the behavior here ... results for 1. and 2. above will come soon t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 07:39:07 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 07:38:57 -0700 Received: from hermes.mixx.net ([212.84.196.2]:11014 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 07:38:33 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id E642DF9C2 for ; Thu, 3 Aug 2000 16:38:00 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 75F582CA6F; Thu, 3 Aug 2000 16:37:54 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 3 Aug 2000 14:37:54 GMT Organization: innominate AG, Berlin, Germany Lines: 31 Distribution: local Message-ID: References: <200008031342.IAA31394@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965313474 9925 10.0.0.69 (3 Aug 2000 14:37:54 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: >> unsigned int i; >> >> for (i = 0; i < 64; i++) { >> printf("Mask %d is 0x%llx", ~(1LL << i)); >> } i think the last one was wrong - i assume you were thinking of printf("Mask %d is 0x%llx", i, ~(1LL << i)); instead of the above - then it works fine in userland - with or without the (long long) before the i ... Mask 31 is 0xffffffff7fffffff Mask 32 is 0xfffffffeffffffff Mask 33 is 0xfffffffdffffffff Mask 34 is 0xfffffffbffffffff ... also adding the (long long) before f in the kernel does not change anything ... the MIPS_SIM thing will follow ... t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 08:09:58 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 08:09:48 -0700 Received: from hermes.mixx.net ([212.84.196.2]:30727 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 08:09:18 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 934F1F9C3 for ; Thu, 3 Aug 2000 17:08:46 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 69A592CA6D; Thu, 3 Aug 2000 17:08:46 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 3 Aug 2000 15:08:46 GMT Organization: innominate AG, Berlin, Germany Lines: 28 Distribution: local Message-ID: References: <200008031342.IAA31394@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965315326 24931 10.0.0.69 (3 Aug 2000 15:08:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > This is a bit of a shock in the dark, but here goes..... > there are two things you can try: > 1. in xfs_bit.c try undefining _MIPS_SIM after the header file includes. > (we need to generalize the name of this define - it is a hang over from > the irix code). Undefining it will cause all the masking code to > use 32 bit quantities. does not change anything > An alternative in this file is to try putting LL at the end of the 64 > bit constants. I do not know how well the ppc compiler copes with > constants like this - if this turns out to be the problem then we will > need to look all over XFS for constants which are not explicitly typed > to be 64 bit. LL does not change anything too t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 12:23:59 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 12:23:50 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:9003 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 12:23:11 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA17331 for ; Thu, 3 Aug 2000 12:15:08 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA76352 for ; Thu, 3 Aug 2000 14:21:25 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id OAA27173 for ; Thu, 3 Aug 2000 14:21:24 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e73JL2304272 for linux-xfs@oss.sgi.com; Thu, 3 Aug 2000 14:21:02 -0500 Date: Thu, 3 Aug 2000 14:21:02 -0500 From: Russell Cattelan Message-Id: <200008031921.e73JL2304272@gibble.americas.sgi.com> Subject: TAKE - create fsck.xfs To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 3 12:20:41 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71245a cmd/xfs/fsck/Makefile - 1.1 - Quick Makefile to create symlink fsck.xfs -> ../bin/true at install time cmd/xfs/Makefile - 1.22 - Added fsck subdir From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 12:41:00 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 12:40:50 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:29421 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 12:40:23 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id OAA24253; Thu, 3 Aug 2000 14:39:49 -0500 (CDT) Message-Id: <4.2.0.58.20000803143109.016ec430@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Aug 2000 14:41:18 -0500 To: William L Jones , linux-xfs@oss.sgi.com From: "William L. Jones" Subject: Re: Possible xfs log problem In-Reply-To: <200008030117.UAA13910@spica.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Not a xfs log problem. The machine that I am running xfs on only has 32mb of memory. The xfs_log_recovery needs 131072 bytes of slab memory to do the mount. On such a small memory system after doing a lot of I/O a contiguous 131072 byte memory block is just not available. Bill Jones From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 12:50:50 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 12:50:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22324 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 12:50:11 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21907 for ; Thu, 3 Aug 2000 12:42:08 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA89678; Thu, 3 Aug 2000 14:48:22 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA05455; Thu, 3 Aug 2000 14:48:22 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA11791; Thu, 3 Aug 2000 14:47:39 -0500 Message-Id: <200008031947.OAA11791@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "William L. Jones" cc: linux-xfs@oss.sgi.com Subject: Re: Possible xfs log problem In-Reply-To: Message from "William L. Jones" of "Thu, 03 Aug 2000 14:41:18 CDT." <4.2.0.58.20000803143109.016ec430@127.0.0.1> Date: Thu, 03 Aug 2000 14:47:38 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > Not a xfs log problem. > > > The machine that I am running xfs on only has 32mb of memory. The > xfs_log_recovery > needs 131072 bytes of slab memory to do the mount. On such a small memory > system > after doing a lot of I/O a contiguous 131072 byte memory block is just > not available. > > > Bill Jones Right, sorry for not getting back to you on this one - we still have work to do in making XFS robust against memory failures, and in this case we could just back off to a smaller buffer size and try again - the 128K buffer is already half the size used on Irix. Steve From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 13:02:20 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 13:02:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5688 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 13:01:28 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA23787 for ; Thu, 3 Aug 2000 12:53:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA99736 for ; Thu, 3 Aug 2000 14:59:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA76288 for ; Thu, 3 Aug 2000 14:59:41 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA12005; Thu, 3 Aug 2000 14:58:57 -0500 Message-Id: <200008031958.OAA12005@jen.americas.sgi.com> Date: Thu, 3 Aug 2000 14:58:57 -0500 Subject: TAKE - remove MIPs ABI info from xfs conditional compilation code To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Kill some references to _MIPS_SIM in the xfs code, also add code to explicitly reject access to files which are too big. The actual maximum file size still needs fixing. Date: Thu Aug 3 12:57:24 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71251a cmd/xfs/sim/src/libdisk.c - 1.13 - Include #include linux/fs/xfs/xfs_bit.c - 1.10 - Move from _MIPS_SIM to XFS_64 linux/fs/xfs/xfs_bmap_btree.h - 1.49 - Always use BMBT_USE_64 linux/fs/xfs/xfs_bmap_btree.c - 1.115 - Fix a couple of compile errors in byte flipping code which we do not normally get to. linux/fs/xfs/xfs_dir_leaf.c - 1.88 - Move from _MIPS_SIM to XFS_64 linux/fs/xfs/xfs_mount.c - 1.230 - remove reference to _MIPS_SIM linux/fs/xfs/xfs_inode.h - 1.139 - nothing linux/fs/xfs/xfs_types.h - 1.46 - Remove dependent on _MIPS_SIM linux/fs/xfs/pseudo-inc/sys/types.h - 1.18 - Move from _MIPS_SIM to XFS_64, replace _MIPS_SZLONG with BITS_PER_LONG linux/fs/xfs/linux/xfs_lrw.c - 1.47 - Add some code to reject access to files which are bigger than XFS_MAX_FILE_OFFSET linux/fs/xfs/linux/xfs_linux.h - 1.26 - Move from defining _MIPS_SIM to defining XFS_64 to be 0 or 1 based on the size of a long. From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 13:33:20 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 13:33:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55874 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 13:32:48 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA29136 for ; Thu, 3 Aug 2000 13:24:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA82631; Thu, 3 Aug 2000 15:29:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA22292; Thu, 3 Aug 2000 15:29:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA15107; Thu, 3 Aug 2000 15:28:25 -0500 Message-Id: <200008032028.PAA15107@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "03 Aug 2000 15:08:46 GMT." Date: Thu, 03 Aug 2000 15:28:25 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > This is a bit of a shock in the dark, but here goes..... > > > there are two things you can try: > > > 1. in xfs_bit.c try undefining _MIPS_SIM after the header file includes. > > (we need to generalize the name of this define - it is a hang over from > > the irix code). Undefining it will cause all the masking code to > > use 32 bit quantities. > > does not change anything > > > An alternative in this file is to try putting LL at the end of the 64 > > bit constants. I do not know how well the ppc compiler copes with > > constants like this - if this turns out to be the problem then we will > > need to look all over XFS for constants which are not explicitly typed > > to be 64 bit. > > LL does not change anything too > > t > So I am officially stumped, one comment on your earlier email though, %ll does not work for long long in the kernel as you pointed out, but %L does. We know that the code: fields &= ~(1LL << f); should do the right thing, which tends to imply xfs_lowbit64 is messing up somehow - or the casting being used around the call to it is messing up. It might be worth the pain of pulling this into a user space program and stepping though it in a debugger. So instead of trying to understand what is wrong with that code, try this code instead, it is a bit more simplistic in its approach - it works on ia32, let me know how the ppc does. Steve void xfs_xlatesb(void *data, xfs_sb_t *sb, int dir, xfs_arch_t arch, __int64_t fields) { xfs_caddr_t buf_ptr; xfs_caddr_t mem_ptr; __uint64_t mask; int f; ASSERT(dir); ASSERT(fields); if (!fields) return; buf_ptr=(xfs_caddr_t)data; mem_ptr=(xfs_caddr_t)sb; mask = 1LL; f = 0; while (fields) { int first; int size; if (!(fields & mask)) { mask <<= 1; f++; continue; } first = xfs_sb_info[f].offset; size = xfs_sb_info[f + 1].offset - first; ASSERT(xfs_sb_info[f].type==0 || xfs_sb_info[f].type==1); if (arch == ARCH_NOCONVERT || size==1 || xfs_sb_info[f].type==1) { if (dir>0) { bcopy(buf_ptr + first, mem_ptr + first, size); } else { bcopy(mem_ptr + first, buf_ptr + first, size); } } else { switch (size) { case 2: INT_COPY(*(__uint16_t*)(buf_ptr+first), *(__uint16_t*)(mem_ptr+first), dir, arch); break; case 4: INT_COPY(*(__uint32_t*)(buf_ptr+first), *(__uint32_t*)(mem_ptr+first), dir, arch); break; case 8: INT_COPY(*(__uint64_t*)(buf_ptr+first), *(__uint64_t*)(mem_ptr+first), dir, arch); break; default: ASSERT(0); } } fields &= ~mask; mask <<= 1; f++; } } From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 13:38:50 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 13:38:40 -0700 Received: from Cantor.suse.de ([194.112.123.193]:51214 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 13:38:15 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id A5CA91E373; Thu, 3 Aug 2000 22:37:43 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 72D1610A034; Thu, 3 Aug 2000 22:37:43 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 4199D2F300; Thu, 3 Aug 2000 22:37:42 +0200 (MEST) Date: Thu, 3 Aug 2000 22:37:42 +0200 From: "Andi Kleen" To: Steve Lord Cc: "William L. Jones" , linux-xfs@oss.sgi.com Subject: Re: Possible xfs log problem Message-ID: <20000803223742.A8244@gruyere.muc.suse.de> References: <200008031947.OAA11791@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008031947.OAA11791@jen.americas.sgi.com>; from lord@sgi.com on Thu, Aug 03, 2000 at 02:47:38PM -0500 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Aug 03, 2000 at 02:47:38PM -0500, Steve Lord wrote: > Right, sorry for not getting back to you on this one - we still have work > to do in making XFS robust against memory failures, and in this case we > could just back off to a smaller buffer size and try again - the 128K buffer > is already half the size used on Irix. Can't you just use vmalloc for this case ? -Andi From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 15:21:50 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 15:21:40 -0700 Received: from hermes.mixx.net ([212.84.196.2]:15379 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 15:21:11 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id E050EFA12 for ; Fri, 4 Aug 2000 00:20:38 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 426052CA6B; Fri, 4 Aug 2000 00:20:38 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 3 Aug 2000 22:20:38 GMT Organization: innominate AG, Berlin, Germany Lines: 101 Distribution: local Message-ID: References: <200008032028.PAA15107@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965341238 20915 10.0.0.69 (3 Aug 2000 22:20:38 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > So I am officially stumped, one comment on your earlier email though, > %ll does not work for long long in the kernel as you pointed out, but > %L does. %L does not too - %l does but this is the wrong one for long long ... > We know that the code: > fields &= ~(1LL << f); > should do the right thing, which tends to imply xfs_lowbit64 is messing > up somehow - or the casting being used around the call to it is > messing up. i am so far now that i am shure that there is a bug somewhere in the ppc code for doing shifts for 64bit ints - i nailed it down to the following test: unsigned int myint; for (myint = 0; myint < 64; myint++) { printf("Mask %d is ",myint); printf("0x%8x", (int)((1LL << myint) >> 32)); printf("%8x - ", (int)(1LL << myint)); printf("0x%8x", (int)(~(1LL << myint) >> 32)); printf("%8x\n", (int)(~(1LL << myint))); } which is used to run around the missing %llx (i hope all the shifting stuff is doing the right here to put together the full 64bit number from it's two 32bit parts which i can printk fine) this code results in ... Mask 29 is 0x 020000000 - 0xffffffffdfffffff Mask 30 is 0x 040000000 - 0xffffffffbfffffff Mask 31 is 0x 080000000 - 0xffffffff7fffffff Mask 32 is 0x 1 0 - 0xfffffffeffffffff Mask 33 is 0x 2 0 - 0xfffffffdffffffff Mask 34 is 0x 4 0 - 0xfffffffbffffffff ... in userland on i386 and ppc and also in the kernel on i386 but only in the kernel on ppc it gives ... Mask 29 is 0x 020000000 - 0xffffffffdfffffff Mask 30 is 0x 040000000 - 0xffffffffbfffffff Mask 31 is 0x 080000000 - 0xffffffff7fffffff Mask 32 is 0x 1 0 - 0xfffffffeffffffff Mask 33 is 0x 0 0 - 0xffffffffffffffff Mask 34 is 0x 0 0 - 0xffffffffffffffff ... which is definitely wrong - i'll ask about this on the ppc-dev list - hopefully they have an answer for it (or at least an idea) > It might be worth the pain of pulling this into a user space program > and stepping though it in a debugger. i think this is not nessesary because it looks like it's definitely a result of the above shift problem > So instead of trying to understand what is wrong with that code, try > this code instead, it is a bit more simplistic in its approach - it > works on ia32, let me know how the ppc does. > ... > void > xfs_xlatesb(void *data, xfs_sb_t *sb, int dir, xfs_arch_t arch, > __int64_t fields) > { > ... > } ok - i tried this and it works - which completely fits into the theory - because you now only shift by one - which seems to work (shifts up to 32 work fine) ... and also it crashes later with the same error we had when not using the xlate code at all in the normal operation (the inodelen thing i think) ... also this fits perfect into the picture: somewhere else in the code are most probably other shifts > 32 resulting in garbage and thus the crash i think this is more a ppc problem than an xfs problem now and i will come back here as soon as this is somehow fixed so far a real big "thanks" for all your quick and very good help - this way it is really fun to try to help on this till later ... i will come back if there are any news ... t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 16:51:44 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 16:51:34 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:60936 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Thu, 3 Aug 2000 16:50:58 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e73NoOC11787; Thu, 3 Aug 2000 18:50:24 -0500 (CDT) Message-ID: <398A0540.CF7DA075@thebarn.com> Date: Thu, 03 Aug 2000 18:50:24 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc References: <200008032028.PAA15107@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: This may be an off question, but what version of gcc are you using? We've seen shift problems with the 2.95.x versions. > Steve Lord wrote: > > > So I am officially stumped, one comment on your earlier email though, > > %ll does not work for long long in the kernel as you pointed out, but > > %L does. > > %L does not too - %l does but this is the wrong one for long long ... > > > We know that the code: > > > fields &= ~(1LL << f); > > > should do the right thing, which tends to imply xfs_lowbit64 is messing > > up somehow - or the casting being used around the call to it is > > messing up. > > i am so far now that i am shure that there is a bug somewhere in > the ppc code for doing shifts for 64bit ints - i nailed it down > to the following test: > > unsigned int myint; > > for (myint = 0; myint < 64; myint++) { > printf("Mask %d is ",myint); > printf("0x%8x", (int)((1LL << myint) >> 32)); > printf("%8x - ", (int)(1LL << myint)); > printf("0x%8x", (int)(~(1LL << myint) >> 32)); > printf("%8x\n", (int)(~(1LL << myint))); > } > > which is used to run around the missing %llx (i hope all the shifting > stuff is doing the right here to put together the full 64bit number > from it's two 32bit parts which i can printk fine) > > this code results in > > ... > Mask 29 is 0x 020000000 - 0xffffffffdfffffff > Mask 30 is 0x 040000000 - 0xffffffffbfffffff > Mask 31 is 0x 080000000 - 0xffffffff7fffffff > Mask 32 is 0x 1 0 - 0xfffffffeffffffff > Mask 33 is 0x 2 0 - 0xfffffffdffffffff > Mask 34 is 0x 4 0 - 0xfffffffbffffffff > ... > > in userland on i386 and ppc and also in the kernel on i386 but only > in the kernel on ppc it gives > > ... > Mask 29 is 0x 020000000 - 0xffffffffdfffffff > Mask 30 is 0x 040000000 - 0xffffffffbfffffff > Mask 31 is 0x 080000000 - 0xffffffff7fffffff > Mask 32 is 0x 1 0 - 0xfffffffeffffffff > Mask 33 is 0x 0 0 - 0xffffffffffffffff > Mask 34 is 0x 0 0 - 0xffffffffffffffff > ... > > which is definitely wrong - i'll ask about this on the ppc-dev list > - hopefully they have an answer for it (or at least an idea) > > > It might be worth the pain of pulling this into a user space program > > and stepping though it in a debugger. > > i think this is not nessesary because it looks like it's definitely > a result of the above shift problem > > > So instead of trying to understand what is wrong with that code, try > > this code instead, it is a bit more simplistic in its approach - it > > works on ia32, let me know how the ppc does. > > ... > > void > > xfs_xlatesb(void *data, xfs_sb_t *sb, int dir, xfs_arch_t arch, > > __int64_t fields) > > { > > ... > > } > > ok - i tried this and it works - which completely fits into the > theory - because you now only shift by one - which seems to work > (shifts up to 32 work fine) ... and also it crashes later with > the same error we had when not using the xlate code at all in > the normal operation (the inodelen thing i think) ... also this > fits perfect into the picture: somewhere else in the code are > most probably other shifts > 32 resulting in garbage and thus > the crash > > i think this is more a ppc problem than an xfs problem now and > i will come back here as soon as this is somehow fixed > > so far a real big "thanks" for all your quick and very good help > - this way it is really fun to try to help on this > > till later ... i will come back if there are any news ... > > t > > -- > thomas.graichen@innominate.de > Technical Director innominate AG > Clustering & Security networking people > tel: +49.30.308806-13 fax: -77 web: http://innominate.de -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 22:28:08 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 22:27:48 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4875 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 22:27:18 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 106E1FA30 for ; Fri, 4 Aug 2000 07:26:36 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 308682CA6B; Fri, 4 Aug 2000 07:26:34 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 4 Aug 2000 05:26:34 GMT Organization: innominate AG, Berlin, Germany Lines: 15 Distribution: local Message-ID: References: <200008032028.PAA15107@jen.americas.sgi.com> <398A0540.CF7DA075@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965366794 22351 10.0.0.69 (4 Aug 2000 05:26:34 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Thomas Graichen wrote: > This may be an off question, but what version of gcc are you using? > We've seen shift problems with the 2.95.x versions. 2.95.2 t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 22:37:07 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 22:36:47 -0700 Received: from hermes.mixx.net ([212.84.196.2]:26123 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 22:36:18 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 79FEDFA31 for ; Fri, 4 Aug 2000 07:35:46 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 318AB2CA6B; Fri, 4 Aug 2000 07:35:46 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 4 Aug 2000 05:35:46 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: References: <200008032028.PAA15107@jen.americas.sgi.com> <398A0540.CF7DA075@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965367346 22351 10.0.0.69 (4 Aug 2000 05:35:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Russell Cattelan wrote: >> Thomas Graichen wrote: >> This may be an off question, but what version of gcc are you using? >> We've seen shift problems with the 2.95.x versions. > 2.95.2 ok - due to some response from the ppc-dev list it's a bug in the ppc kernel implementation of the shifts and i have a patch for it now which i'll try this evening and i expect xfs to run then fine on the ppc ... lets see :-) t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Thu Aug 3 23:57:57 2000 Received: by oss.sgi.com id ; Thu, 3 Aug 2000 23:57:48 -0700 Received: from hermes.mixx.net ([212.84.196.2]:8717 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 3 Aug 2000 23:57:33 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id D3AD0F9F6 for ; Fri, 4 Aug 2000 08:56:51 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EF0D12CA6B; Fri, 4 Aug 2000 08:56:50 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: SGI XFS on alpha Date: 4 Aug 2000 06:56:50 GMT Organization: innominate AG, Berlin, Germany Lines: 65 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965372210 22351 10.0.0.69 (4 Aug 2000 06:56:50 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - just tried the next one :-) kernel builds fine (with the below patch - what are the double under- scored types btw.?) and i was able to mount the filesystem instantly without a problem - i also was able to copy the whole /etc tree over to it and remove it again - the try to compile bonnie for running it resulted in a pagebuf error (but no crash - only a fs shutdown due to an io error) - so it looks quite promising - also there were some compile time warnings which i'll look through carefully - maybe it's in there anywhere ... also debugging the pagebuf stuff should be a bit easier now that there is also kdb less pagebuf tracing from the ppc here (btw.: any chance to get this included into the tree if i clean it up a bit? - i think it might be a good help for new kdbless arches) more details about any errors i cannot resolve i will post after the weekend (it's time for a break now :-) looks like it gets time that the mkfs and repair commands get more easily compilable on other arches too so that one can play around with real filesystems instead of my 32mb image ... is there any timeframe planned for the cleanup of those two tools ? ok - for anyone who want to help getting this working (i'll post this to the alpha list too - maybe someone there will help too) - just pick up the sources from oss.sgi.com's cvs tree (linux-2.4-xfs) and my patches from http://innominate.org/~graichen/projects/xfs-ppc/diff.000802 (don't get confused by the ppc - they are good for the alpha too and gives the pagebuf tracing for debugging :-) and have a look at the sgi xfs list (details you can also find at oss.sgi.com) so far thanks for the sgi guys for providing a - so far - very arch- portable code as it looks like t --- fs/xfs/xfs_error.c 2000/06/09 06:40:03 1.27 +++ fs/xfs/xfs_error.c 2000/08/04 06:39:39 @@ -213,7 +213,7 @@ } int -xfs_errortag_clearall_umount(int64_t fsid, char *fsname, int loud) +xfs_errortag_clearall_umount(__int64_t fsid, char *fsname, int loud) { int i; int cleared = 0; @@ -278,7 +278,7 @@ } void -xfs_cmn_err(uint64_t panic_tag, int level, xfs_mount_t *mp, char *fmt, +xfs_cmn_err(__uint64_t panic_tag, int level, xfs_mount_t *mp, char *fmt { va_list ap; -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 00:16:47 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 00:16:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:11836 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 00:16:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA24511 for ; Fri, 4 Aug 2000 00:08:12 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07108; Fri, 4 Aug 2000 17:14:28 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA22661; Fri, 4 Aug 2000 17:14:26 +1000 (EST) From: "Nathan Scott" Message-Id: <10008041714.ZM24012@wobbly.melbourne.sgi.com> Date: Fri, 4 Aug 2000 17:14:21 -0500 In-Reply-To: Thomas Graichen "SGI XFS on alpha" (Aug 4, 5:05pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: SGI XFS on alpha Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Aug 4, 5:05pm, Thomas Graichen wrote: > Subject: SGI XFS on alpha > ok - just tried the next one :-) > ... > looks like it gets time that the mkfs and repair commands get more > easily compilable on other arches too so that one can play around > with real filesystems instead of my 32mb image ... is there any > timeframe planned for the cleanup of those two tools ? > Real soon now ... days, hopefully. mkfs is up and stumbling. I'm debugging. cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 02:03:18 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 02:03:08 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:60944 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 4 Aug 2000 02:02:37 -0700 Received: (qmail 13496 invoked from network); 4 Aug 2000 09:02:01 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Aug 2000 09:02:01 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com, linux-kdb@oss.sgi.com Subject: Re: SGI XFS on alpha In-reply-to: Your message of "04 Aug 2000 06:56:50 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Aug 2000 19:01:56 +1000 Message-ID: <9422.965379716@ocs3.ocs-net> Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On 4 Aug 2000 06:56:50 GMT, Thomas Graichen wrote: >also debugging the pagebuf stuff should be >a bit easier now that there is also kdb less pagebuf tracing from >the ppc here (btw.: any chance to get this included into the tree if >i clean it up a bit? - i think it might be a good help for new kdbless >arches) Once I get kdb for ix86 and kdb for IA64 merged into a single design, I will add dummy kdb functions that can be used on any arch. You won't get debugging, oops handler, back trace etc. but high level code like xfsigdb could be used as is, no source changes required. Since kallsyms works on any arch that has modules, you will even get the full symbol lookup in kdb_symbol_print(). From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 10:31:22 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 10:31:13 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:34198 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 10:30:41 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id MAA06581; Fri, 4 Aug 2000 12:30:08 -0500 (CDT) Date: Fri, 4 Aug 2000 12:30:08 -0500 (CDT) Message-Id: <200008041730.MAA06581@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: minor fix to fsr_xfs.c Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Add ll in fsrpintf statements when printing 64 bit integer. *** fsr_xfs.c.orig Thu Aug 3 20:21:36 2000 --- fsr_xfs.c Thu Aug 3 20:26:48 2000 *************** *** 830,836 **** if (statp->bs_size > ((vfss.f_bfree * bsize) - minimumfree)) { fsrprintf( ! "insufficient freespace for: %s: size=%d: ignoring\n", fname, statp->bs_size); return 1; } --- 830,836 ---- if (statp->bs_size > ((vfss.f_bfree * bsize) - minimumfree)) { fsrprintf( ! "insufficient freespace for: %s: size=%lld: ignoring\n", fname, statp->bs_size); return 1; } *************** *** 996,1002 **** } if (dflag) { ! fsrprintf("DEBUG: fsize=%d blsz_dio=%d d_min=%d d_max=%d pgsz=%d\n", statp->bs_size, blksz_dio, dio.d_miniosz, dio.d_maxiosz, pagesize); } --- 996,1002 ---- } if (dflag) { ! fsrprintf("DEBUG: fsize=%lld blsz_dio=%d d_min=%d d_max=%d pgsz=%d\n", statp->bs_size, blksz_dio, dio.d_miniosz, dio.d_maxiosz, pagesize); } From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 10:34:12 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 10:33:52 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:39830 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 10:33:22 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id MAA06612; Fri, 4 Aug 2000 12:32:49 -0500 (CDT) Date: Fri, 4 Aug 2000 12:32:49 -0500 (CDT) Message-Id: <200008041732.MAA06612@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Fix to xfs_dfrag.c to insure fput done on all error exists Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing *** xfs_dfrag.c.orig Thu Aug 3 19:43:01 2000 --- xfs_dfrag.c Fri Aug 4 12:17:56 2000 *************** *** 104,109 **** --- 104,110 ---- __uint64_t cxfs_val; int aforkblks = 0; int locked = 0; + int cell = 0; if (copyin(sxp, &sx, sizeof sx)) return XFS_ERROR(EFAULT); *************** *** 169,176 **** goto error0; } - locked = 1; CELL_ONLY(cxfs_val = cfs_start_defrag(vp)); /* Lock in i_ino order */ if (ip->i_ino < tip->i_ino) { --- 170,177 ---- goto error0; } CELL_ONLY(cxfs_val = cfs_start_defrag(vp)); + cell = 1; /* Lock in i_ino order */ if (ip->i_ino < tip->i_ino) { *************** *** 182,187 **** --- 183,189 ---- } lock_flags = XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL; xfs_lock_inodes(ips, 2, 0, lock_flags); + locked = 1; /* Check permissions */ if (error = _MAC_XFS_IACCESS(ip, MACWRITE)) { *************** *** 291,297 **** xfs_iunlock(ip, XFS_IOLOCK_EXCL); xfs_iunlock(tip, XFS_IOLOCK_EXCL); xfs_trans_cancel(tp, 0); ! return error; } xfs_lock_inodes(ips, 2, 0, XFS_ILOCK_EXCL); --- 293,300 ---- xfs_iunlock(ip, XFS_IOLOCK_EXCL); xfs_iunlock(tip, XFS_IOLOCK_EXCL); xfs_trans_cancel(tp, 0); ! locked = 0; ! goto error0; } xfs_lock_inodes(ips, 2, 0, XFS_ILOCK_EXCL); *************** *** 305,311 **** xfs_iunlock(ip, lock_flags); xfs_iunlock(tip, lock_flags); xfs_trans_cancel(tp, 0); ! return error; } } --- 308,315 ---- xfs_iunlock(ip, lock_flags); xfs_iunlock(tip, lock_flags); xfs_trans_cancel(tp, 0); ! locked = 0; ! goto error0; } } *************** *** 404,412 **** error0: if (locked) { - CELL_ONLY(cfs_end_defrag(vp, cxfs_val)); xfs_iunlock(ip, lock_flags); xfs_iunlock(tip, lock_flags); } if (fp != NULL) fput(fp); --- 408,418 ---- error0: if (locked) { xfs_iunlock(ip, lock_flags); xfs_iunlock(tip, lock_flags); + } + if (cell) { + CELL_ONLY(cfs_end_defrag(vp, cxfs_val)); } if (fp != NULL) fput(fp); From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 10:36:42 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 10:36:32 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:53910 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 10:36:18 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id MAA06648; Fri, 4 Aug 2000 12:35:45 -0500 (CDT) Date: Fri, 4 Aug 2000 12:35:45 -0500 (CDT) Message-Id: <200008041735.MAA06648@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Work around patch to xfs_dfrag.c to keep it from corrupting inodes! Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It can be remvoed when SGI has a fix to bug 791117 *** xfs_dfrag.c.orig Fri Aug 4 12:19:14 2000 --- xfs_dfrag.c Fri Aug 4 12:19:26 2000 *************** *** 256,261 **** --- 256,276 ---- goto error0; } + /* + * IRIX xfs Bug 791117 - Lunux has it to. + * Verify that there is enough room for the temp file extents data fork. + * With out this check the swapext function could corrupt the + * target files inode if it has file attribute's. + * We just act like it is a busy file so fsr_xfs will do something + * reasonable. + * Remove when installing sgi patch to this problem. + */ + if (XFS_IFORK_FORMAT(tip, XFS_DATA_FORK) == XFS_DINODE_FMT_EXTENTS && + (tip->i_d.di_nextents * sizeof(xfs_bmbt_rec_t)) > XFS_IFORK_DSIZE(ip)) { + error = XFS_ERROR(EBUSY); + goto error0; + } + /* We need to fail if the file is memory mapped, we also need to * prevent it from getting mapped before we have tossed the existing * pages. By setting VREMAPPING here we force a pas_vfault to go to From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 10:41:12 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 10:41:02 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:63894 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 10:40:38 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id MAA06679; Fri, 4 Aug 2000 12:40:06 -0500 (CDT) Date: Fri, 4 Aug 2000 12:40:06 -0500 (CDT) Message-Id: <200008041740.MAA06679@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: minor patch to xfs_log_recover.c Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Return a ENOMEM error if xfs_log_recover.c can't get a big_bp buffer. This can happen a small memory machines, 32mb or less. *** xfs_log_recover.c.orig Thu Aug 3 19:40:04 2000 --- xfs_log_recover.c Thu Aug 3 19:42:54 2000 *************** *** 494,500 **** * we actually look at the block size of the filesystem. */ num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<l_mp); if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed --- 494,504 ---- * we actually look at the block size of the filesystem. */ num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<l_mp); ! if(big_bp == NULL) { ! error = XFS_ERROR(ENOMEM); ! goto bp_err; ! } if (head_blk >= num_scan_bblks) { /* * We are guaranteed that the entire check can be performed *************** *** 962,967 **** --- 966,975 ---- num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<l_mp); + if(big_bp == NULL) { + error = XFS_ERROR(ENOMEM); + goto bp_err; + } ASSERT(big_bp); if (last_blk < num_scan_bblks) -- From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 11:30:52 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 11:30:42 -0700 Received: from hermes.mixx.net ([212.84.196.2]:12805 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 4 Aug 2000 11:30:19 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id EF44AFA82 for ; Fri, 4 Aug 2000 20:29:46 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id A5A332CA6B; Fri, 4 Aug 2000 20:29:46 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on alpha Date: 4 Aug 2000 18:29:46 GMT Organization: innominate AG, Berlin, Germany Lines: 83 Distribution: local Message-ID: References: <8mdpfi$lqf$3@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965413786 10690 10.0.0.69 (4 Aug 2000 18:29:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > ok - just tried the next one :-) > kernel builds fine (with the below patch - what are the double under- > scored types btw.?) and i was able to mount the filesystem instantly > without a problem - i also was able to copy the whole /etc tree over > to it and remove it again - the try to compile bonnie for running it > resulted in a pagebuf error (but no crash - only a fs shutdown due > to an io error) - so it looks quite promising - also there were some > compile time warnings which i'll look through carefully - maybe it's > in there anywhere ... also debugging the pagebuf stuff should be > a bit easier now that there is also kdb less pagebuf tracing from > the ppc here (btw.: any chance to get this included into the tree if > i clean it up a bit? - i think it might be a good help for new kdbless > arches) ok - i played around a bit more with xfs on the alpha now - have made the test machine a bit more comfortable and looked at the compiler warnings - at the end of this mail is a list of changes i did to make the compiler happy - but please have a look at them if they are basically ok (you know the code - i so far only see the warnings :-) ... with this code it so far runs quite fine (no panic, no fs crashes) but it silently corrupts data and has other problems: * the file which was ther from the beginning (XFS containig "i am here") changed its contents to the ones from another file (i copied the /etc tree some times to the xfs filesystem and it looks like the XFS file now contains the contents of the later removed file from etc/hostname - cyan) root@cyan:/mnt/xfs# cat XFS i am here root@cyan:/mnt/xfs# ... some disk operation (cp to or on the xfs filesystem, bonnie, deleting files nothing acting on the file XFS) ... root@cyan:/mnt/xfs# cat XFS cyan root@cyan:/mnt/xfs# * once i had an unremovable directory (something i know from testing xfs about 8 weeks ago) * see the following: root@cyan:/mnt/xfs# tar xvzf /root/Bonnie.tar.Z Bonnie/ Bonnie/Bonnie.c Bonnie/Commentary Bonnie/Makefile root@cyan:/mnt/xfs# cd Bonnie/ root@cyan:/mnt/xfs/Bonnie# make cc -O2 Bonnie.c -o Bonnie collect2: ld terminated with signal 11 [Segmentation fault], core dumped make: *** [Bonnie] Error 1 root@cyan:/mnt/xfs/Bonnie# cd /tmp root@cyan:/tmp# tar xvzf /root/Bonnie.tar.Z Bonnie/ Bonnie/Bonnie.c Bonnie/Commentary Bonnie/Makefile root@cyan:/tmp# cd Bonnie/ root@cyan:/tmp/Bonnie# make cc -O2 Bonnie.c -o Bonnie root@cyan:/tmp/Bonnie# ok - so far i got ... if anyone has any comments to the things above or other things which come to mind on a 64bit machine please let me know - i'll try my best to try out everything to get this moving forward ... btw. do you have xfs running on ia64 (so a 64bit arch of the linux port of it) ? t p.s.: btw. alpha is little endian - just as info -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 11:31:22 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 11:31:12 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42591 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 11:30:53 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00357 for ; Fri, 4 Aug 2000 11:36:19 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA40685; Fri, 4 Aug 2000 13:29:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA36766; Fri, 4 Aug 2000 13:29:00 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA21717; Fri, 4 Aug 2000 13:28:07 -0500 Message-Id: <200008041828.NAA21717@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: William L Jones cc: linux-xfs@oss.sgi.com Subject: Re: fsr and defrag patches In-Reply-To: Message from William L Jones of "Fri, 04 Aug 2000 12:30:08 CDT." <200008041730.MAA06581@spica.cc.utexas.edu> Date: Fri, 04 Aug 2000 13:28:07 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks very much, I will apply these - it will probably be next week some time, I am already in the middle of way too many things! Steve p.s. for the out of memory problem I want to look into a more sophisticated approach than givng up on the mount. It will probably involve doing the I/O in this case in chunks rather than in one go, the 128K byte size is already a reduction from the irix case. This reduction in turn means that we cannot have as many in core log buffers as we can on irix - this will only matter on larger systems. From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 12:01:32 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 12:01:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16994 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 12:00:57 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA03635 for ; Fri, 4 Aug 2000 12:06:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA83128; Fri, 4 Aug 2000 13:58:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA59976; Fri, 4 Aug 2000 13:58:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA21911; Fri, 4 Aug 2000 13:57:57 -0500 Message-Id: <200008041857.NAA21911@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on alpha In-Reply-To: Message from Thomas Graichen of "04 Aug 2000 18:29:46 GMT." Date: Fri, 04 Aug 2000 13:57:57 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing You missed out the diffs! I just hit a corruption problem myself, on the i386, this may be something to do with moving up to test5 - and may or may not be the same problem you hit. If I get that out of the way then we can establish if you are seeing the same issue or not. Did you select KIOBUF based I/O in the configuration options - this only affects SCSI drives right now, but at the moment I am suspecting it being related to the corruption I saw. On a topic related to porting XFS to other architectures, I now have a system which does not need the 64 bit divide and modulus support functions. All the places XFS does this turn out to be dividing by a 32 bit quantity and there is a function called do_div provided for that on all architectures. This will show up after we get the corruption sorted out. An ia64 port has been attempted, not sure what the current status is, and XFS does come from a 64 bit background in the first place, all modern Irix platforms are 64 bit. However, this is a good check that we did not lose information in the port to Linux. ----- other things: there are some tests in cmd/xfs/stress - getting these to build may or may not be a problem. Also check out this web site, you can download yet more tests for xfs from here: http://oss.sgi.com/projects/ltp/ - again porting to other platforms may be some work. I will take a look at packaging the changes you did for the pagebuf debug mechanism next week. Thanks for all your work by the way! Steve > > ok - i played around a bit more with xfs on the alpha now - have > made the test machine a bit more comfortable and looked at the > compiler warnings - at the end of this mail is a list of changes > i did to make the compiler happy - but please have a look at them > if they are basically ok (you know the code - i so far only see > the warnings :-) ... with this code it so far runs quite fine > (no panic, no fs crashes) but it silently corrupts data and has > other problems: > > * the file which was ther from the beginning (XFS containig "i am > here") changed its contents to the ones from another file (i copied > the /etc tree some times to the xfs filesystem and it looks like > the XFS file now contains the contents of the later removed file > from etc/hostname - cyan) > > root@cyan:/mnt/xfs# cat XFS > i am here > root@cyan:/mnt/xfs# > ... > some disk operation (cp to or on the xfs filesystem, bonnie, deleting > files nothing acting on the file XFS) > ... > root@cyan:/mnt/xfs# cat XFS > cyan > root@cyan:/mnt/xfs# > > * once i had an unremovable directory (something i know from > testing xfs about 8 weeks ago) > > * see the following: > > root@cyan:/mnt/xfs# tar xvzf /root/Bonnie.tar.Z > Bonnie/ > Bonnie/Bonnie.c > Bonnie/Commentary > Bonnie/Makefile > root@cyan:/mnt/xfs# cd Bonnie/ > root@cyan:/mnt/xfs/Bonnie# make > cc -O2 Bonnie.c -o Bonnie > collect2: ld terminated with signal 11 [Segmentation fault], core dumped > make: *** [Bonnie] Error 1 > root@cyan:/mnt/xfs/Bonnie# cd /tmp > root@cyan:/tmp# tar xvzf /root/Bonnie.tar.Z > Bonnie/ > Bonnie/Bonnie.c > Bonnie/Commentary > Bonnie/Makefile > root@cyan:/tmp# cd Bonnie/ > root@cyan:/tmp/Bonnie# make > cc -O2 Bonnie.c -o Bonnie > root@cyan:/tmp/Bonnie# > > ok - so far i got ... if anyone has any comments to the things above > or other things which come to mind on a 64bit machine please let me > know - i'll try my best to try out everything to get this moving > forward ... btw. do you have xfs running on ia64 (so a 64bit > arch of the linux port of it) ? > > t > > p.s.: btw. alpha is little endian - just as info > > -- > thomas.graichen@innominate.de > Technical Director innominate AG > Clustering & Security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 12:05:32 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 12:05:12 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47714 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 12:05:09 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01295 for ; Fri, 4 Aug 2000 12:10:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA50107 for ; Fri, 4 Aug 2000 14:03:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA86044 for ; Fri, 4 Aug 2000 14:03:21 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA22805; Fri, 4 Aug 2000 14:02:28 -0500 Message-Id: <200008041902.OAA22805@jen.americas.sgi.com> Date: Fri, 4 Aug 2000 14:02:28 -0500 Subject: TAKE - remove some unlocked use of pages To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This was a bad idea, do the proper locking on pages Date: Fri Aug 4 12:00:50 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-profile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71388a linux/include/linux/page_buf.h - 1.55 linux/fs/pagebuf/page_buf.c - 1.18 - do not do conditional locking on kiobuf pages during I/O. Always do the locking. From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 12:59:02 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 12:58:42 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55142 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 12:58:22 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08848 for ; Fri, 4 Aug 2000 13:03:47 -0700 (PDT) mail_from (ananth@dbear.engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA02322 for ; Fri, 4 Aug 2000 12:56:59 -0700 (PDT) mail_from (ananth@dbear.engr.sgi.com) Received: (from ananth@localhost) by dbear.engr.sgi.com (8.9.3/8.8.7) id MAA21994 for linux-xfs@oss.sgi.com; Fri, 4 Aug 2000 12:56:51 -0700 Date: Fri, 4 Aug 2000 12:56:51 -0700 From: Ananth Ananthanarayanan Message-Id: <200008041956.MAA21994@dbear.engr.sgi.com> Subject: TAKE - don't wait on lock for pages to cluster To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Aug 4 12:55:53 PDT 2000 Workarea: dbear.engr.sgi.com:/build2/ananth/slinx24-xfs-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71396a linux/mm/filemap.c - 1.51 linux/kernel/ksyms.c - 1.57 linux/include/linux/pagemap.h - 1.17 - Introduce a nowait variant of find_lock_page. linux/fs/pagebuf/page_buf_io.c - 1.17 - Use nowait variant to find the page for clustering. From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 13:59:52 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 13:59:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58730 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 13:59:31 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA16507 for ; Fri, 4 Aug 2000 13:51:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA34319 for ; Fri, 4 Aug 2000 15:57:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA03884 for ; Fri, 4 Aug 2000 15:57:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id PAA00654; Fri, 4 Aug 2000 15:56:51 -0500 Message-Id: <200008042056.PAA00654@jen.americas.sgi.com> Date: Fri, 4 Aug 2000 15:56:51 -0500 Subject: TAKE - fix printing of 64 bit values in fsr To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Aug 4 13:57:18 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-profile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71402a cmd/xfs/fsr/fsr_xfs.c - 1.6 - Fix fsr to use %ll for 64 bit output values From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 15:52:33 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 15:52:24 -0700 Received: from [207.1.122.10] ([207.1.122.10]:34973 "HELO bouncer.lucasdigital.com") by oss.sgi.com with SMTP id ; Fri, 4 Aug 2000 15:52:00 -0700 Received: by bouncer.lucasdigital.com; id QAA29882; Fri, 4 Aug 2000 16:02:30 -0700 Received: from malone.lucasdigital.com(10.10.192.51) by bouncer.lucasdigital.com via smap (V4.2) id xma029876; Fri, 4 Aug 00 16:01:35 -0700 Received: from lucasdigital.com (krill [10.5.5.132]) by malone.lucasdigital.com (8.8.8+Sun/8.8.8/990524-/HUB) with ESMTP id PAA08971 for ; Fri, 4 Aug 2000 15:48:15 -0700 (PDT) Message-ID: <398B484A.166F3A0@ilm.com> Date: Fri, 04 Aug 2000 15:48:42 -0700 From: Seth Olitzky X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Making the XFS cmds Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have not been able to locate the README.build instructions and have not been able to successfully build the xfs commands (cmd). I have the test5 patch archive which I have been able to successfully install. Any help on how to build the commands in cmd/xfs thanks -- seth olitzky video software engineer video engineering solitzy@ilm.com From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:00:53 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:00:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10358 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:00:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA04448 for ; Fri, 4 Aug 2000 16:06:00 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12234; Sat, 5 Aug 2000 08:58:45 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA12451; Sat, 5 Aug 2000 08:58:43 +1000 (EST) From: "Nathan Scott" Message-Id: <10008050858.ZM12484@wobbly.melbourne.sgi.com> Date: Sat, 5 Aug 2000 08:58:40 -0500 In-Reply-To: Seth Olitzky "Making the XFS cmds" (Aug 5, 8:53am) References: <398B484A.166F3A0@ilm.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Seth Olitzky , linux-xfs@oss.sgi.com Subject: Re: Making the XFS cmds Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Aug 5, 8:53am, Seth Olitzky wrote: > Subject: Making the XFS cmds > I have not been able to locate the README.build instructions and have > not been able to successfully build the xfs commands (cmd). I have the > test5 patch archive which I have been able to successfully install. > > Any help on how to build the commands in cmd/xfs > A "cd cmd/xfs; make" should be all you need to do. There is additional documentation in cmd/xfs/README, cmd/xfs/INSTALL, and cmd/xfs/build/Porting-Guide. What is the nature of the build errors you're seeing? cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:01:03 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:00:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:9484 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:00:45 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA00619 for ; Fri, 4 Aug 2000 15:52:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA05228; Fri, 4 Aug 2000 17:57:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA46386; Fri, 4 Aug 2000 17:57:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id RAA01942; Fri, 4 Aug 2000 17:56:45 -0500 Message-Id: <200008042256.RAA01942@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Seth Olitzky cc: linux-xfs@oss.sgi.com Subject: Re: Making the XFS cmds In-Reply-To: Message from Seth Olitzky of "Fri, 04 Aug 2000 15:48:42 PDT." <398B484A.166F3A0@ilm.com> Date: Fri, 04 Aug 2000 17:56:45 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > I have not been able to locate the README.build instructions and have > not been able to successfully build the xfs commands (cmd). I have the > test5 patch archive which I have been able to successfully install. > > Any help on how to build the commands in cmd/xfs Hmmm, two things: 1. you need to install e2fsprogs-devel-1.18-5 which you should be able to get via www.rpmfind.net 2. cd to cmd/xfs and type make a make install will actually put the commands out onto your system. After that you get to make a filesystem - have you used Irix? mkfs -t xfs -f /dev/xxxx will do it once you have the commands installed. Steve p.s. sorry this is brief, I have to run now. p.p.s. no GRIO or direct I/O yet (I saw your job title ;-) > > thanks > > -- > seth olitzky > video software engineer > video engineering > solitzy@ilm.com > > From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:01:34 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:01:23 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:15884 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:01:17 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA00675 for ; Fri, 4 Aug 2000 15:53:12 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA68431; Fri, 4 Aug 2000 17:58:13 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id RAA07627; Fri, 4 Aug 2000 17:58:12 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e74MvoA07714; Fri, 4 Aug 2000 17:57:50 -0500 Message-ID: <398B4A6E.EDEE08D5@thebarn.com> Date: Fri, 04 Aug 2000 17:57:50 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Olitzky CC: linux-xfs@oss.sgi.com Subject: Re: Making the XFS cmds References: <398B484A.166F3A0@ilm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Olitzky wrote: > I have not been able to locate the README.build instructions and have > not been able to successfully build the xfs commands (cmd). I have the > test5 patch archive which I have been able to successfully install. > > Any help on how to build the commands in cmd/xfs Could you pass a long a bit more info... like what exactly is failing the output of the make command would be helpful. > > > thanks > > -- > seth olitzky > video software engineer > video engineering > solitzy@ilm.com From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:15:03 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:14:53 -0700 Received: from [207.1.122.10] ([207.1.122.10]:8864 "HELO bouncer.lucasdigital.com") by oss.sgi.com with SMTP id ; Fri, 4 Aug 2000 16:14:33 -0700 Received: by bouncer.lucasdigital.com; id QAA00552; Fri, 4 Aug 2000 16:23:44 -0700 Received: from malone.lucasdigital.com(10.10.192.51) by bouncer.lucasdigital.com via smap (V4.2) id xma000543; Fri, 4 Aug 00 16:22:58 -0700 Received: from lucasdigital.com (krill [10.5.5.132]) by malone.lucasdigital.com (8.8.8+Sun/8.8.8/990524-/HUB) with ESMTP id QAA10349; Fri, 4 Aug 2000 16:09:35 -0700 (PDT) Message-ID: <398B4D4A.66305621@ilm.com> Date: Fri, 04 Aug 2000 16:10:02 -0700 From: Seth Olitzky X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Making the XFS cmds References: <398B484A.166F3A0@ilm.com> <398B4A6E.EDEE08D5@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Here what happened. (I admit that I am somewhat new to Linux/Unix, stuck in the Microsoft World for too many years) When I did the original make in cmd/xfs i got an unresolved include to . I then created a link in /usr/include to the pseudo-inc directory under linux/fs/xfs. This then caused an unknown type of ushort_t which i then copied from the type.h include in the pseudo-inc directory into the /usr/include/sys/types.h file. No doing the make in cmd/xfs causes an unknown reference to /usr/lib/libuuid.a which I have not figured out how to generate. Russell Cattelan wrote: > Seth Olitzky wrote: > > > I have not been able to locate the README.build instructions and have > > not been able to successfully build the xfs commands (cmd). I have the > > test5 patch archive which I have been able to successfully install. > > > > Any help on how to build the commands in cmd/xfs > > Could you pass a long a bit more info... like what exactly is failing > > the output of the make command would be helpful. > > > > > > > thanks > > > > -- > > seth olitzky > > video software engineer > > video engineering > > solitzy@ilm.com -- seth olitzky video software engineer video engineering solitzy@ilm.com From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:20:23 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:20:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12407 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:20:07 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA00081 for ; Fri, 4 Aug 2000 16:25:33 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12410; Sat, 5 Aug 2000 09:18:19 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA25333; Sat, 5 Aug 2000 09:18:18 +1000 (EST) From: "Nathan Scott" Message-Id: <10008050918.ZM25426@wobbly.melbourne.sgi.com> Date: Sat, 5 Aug 2000 09:18:16 -0500 In-Reply-To: Seth Olitzky "Re: Making the XFS cmds" (Aug 5, 9:15am) References: <398B484A.166F3A0@ilm.com> <398B4A6E.EDEE08D5@thebarn.com> <398B4D4A.66305621@ilm.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Seth Olitzky Subject: Re: Making the XFS cmds Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Aug 5, 9:15am, Seth Olitzky wrote: > Subject: Re: Making the XFS cmds > Here what happened. (I admit that I am somewhat new to Linux/Unix, stuck in > the Microsoft World for too many years) > > When I did the original make in cmd/xfs i got an unresolved include to > . I then created a link in /usr/include to the pseudo-inc > directory under linux/fs/xfs. This then caused an unknown type of ushort_t > which i then copied from the type.h include in the pseudo-inc directory into > the /usr/include/sys/types.h file. No doing the make in cmd/xfs causes an > unknown reference to /usr/lib/libuuid.a which I have not figured out how to > generate. > You need to install the e2fsprogs-devel rpm, and that link you created is likely to do more harm than good - I'd remove it. cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:40:13 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:40:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21012 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:39:48 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA04790 for ; Fri, 4 Aug 2000 16:31:44 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA38332; Fri, 4 Aug 2000 18:36:40 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id SAA08236; Fri, 4 Aug 2000 18:36:39 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e74NaHA07902; Fri, 4 Aug 2000 18:36:17 -0500 Message-ID: <398B536F.19B9E27B@thebarn.com> Date: Fri, 04 Aug 2000 18:36:15 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: Seth Olitzky , linux-xfs@oss.sgi.com Subject: Re: Making the XFS cmds References: <398B484A.166F3A0@ilm.com> <398B4A6E.EDEE08D5@thebarn.com> <398B4D4A.66305621@ilm.com> <10008050918.ZM25426@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Nathan Scott wrote: > hi, > > On Aug 5, 9:15am, Seth Olitzky wrote: > > Subject: Re: Making the XFS cmds > > Here what happened. (I admit that I am somewhat new to Linux/Unix, stuck in > > the Microsoft World for too many years) > > > > When I did the original make in cmd/xfs i got an unresolved include to > > . I then created a link in /usr/include to the pseudo-inc > > directory under linux/fs/xfs. This then caused an unknown type of ushort_t > > which i then copied from the type.h include in the pseudo-inc directory into > > the /usr/include/sys/types.h file. No doing the make in cmd/xfs causes an > > unknown reference to /usr/lib/libuuid.a which I have not figured out how to > > generate. > > > > You need to install the e2fsprogs-devel rpm, I put a copy of the rpm's on oss. oss.sgi.com:/oss/ftp/projects/xfs/download/ > and that link you > created is likely to do more harm than good - I'd remove it. Correct! don't mess with your /usr/include dir... I shouldn't be necessary. > > > cheers. > > -- > Nathan From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 16:42:03 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 16:41:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42772 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Aug 2000 16:41:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA05007 for ; Fri, 4 Aug 2000 16:33:48 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12492 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Sat, 5 Aug 2000 09:38:49 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA50489 for linux-xfs@oss.sgi.com; Sat, 5 Aug 2000 09:38:48 +1000 (EST) Date: Sat, 5 Aug 2000 09:38:48 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008042338.JAA50489@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - doc Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71431a Date: Fri Aug 4 16:38:25 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/INSTALL - 1.2 - note the need to have the e2fsprogs-devel package installed. From owner-linux-xfs-announce@oss.sgi.com Fri Aug 4 17:45:34 2000 Received: by oss.sgi.com id ; Fri, 4 Aug 2000 17:45:24 -0700 Received: from [207.1.122.10] ([207.1.122.10]:54182 "HELO bouncer.lucasdigital.com") by oss.sgi.com with SMTP id ; Fri, 4 Aug 2000 17:45:04 -0700 Received: by bouncer.lucasdigital.com; id RAA02396; Fri, 4 Aug 2000 17:55:32 -0700 Received: from malone.lucasdigital.com(10.10.192.51) by bouncer.lucasdigital.com via smap (V4.2) id xma002390; Fri, 4 Aug 00 17:55:08 -0700 Received: from lucasdigital.com (krill [10.5.5.132]) by malone.lucasdigital.com (8.8.8+Sun/8.8.8/990524-/HUB) with ESMTP id RAA17475; Fri, 4 Aug 2000 17:41:47 -0700 (PDT) Message-ID: <398B62E6.B688EBC@ilm.com> Date: Fri, 04 Aug 2000 17:42:14 -0700 From: Seth Olitzky X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - doc References: <200008042338.JAA50489@snort.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing To all who gave me the answer to the problem of building the xfs commands, thanks. Also thanks for putting the package on the ftp site and changing the documentation. Im sure this will help the next neophyte. seth olitzky video software engineer video engineering solitzky@ilm.com Nathan Scott wrote: > Modid: 2.4.0-test1-xfs:slinx:71431a > Date: Fri Aug 4 16:38:25 PDT 2000 > Workarea: snort:/build4/nathans/linux-xfs > Author: nathans > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs > > cmd/xfs/INSTALL - 1.2 From owner-linux-xfs-announce@oss.sgi.com Sat Aug 5 00:48:26 2000 Received: by oss.sgi.com id ; Sat, 5 Aug 2000 00:48:16 -0700 Received: from hermes.mixx.net ([212.84.196.2]:63250 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 5 Aug 2000 00:47:52 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8BF5AFA98 for ; Sat, 5 Aug 2000 09:47:20 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 9E97A2CA6B; Sat, 5 Aug 2000 09:47:19 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on alpha Date: 5 Aug 2000 07:47:19 GMT Organization: innominate AG, Berlin, Germany Lines: 173 Distribution: local Message-ID: References: <200008041857.NAA21911@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965461639 10233 10.0.0.69 (5 Aug 2000 07:47:19 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > You missed out the diffs! oh yes - i seem to have forgotten them - they are at the end of this mail now ... > I just hit a corruption problem myself, on the i386, this may be > something to do with moving up to test5 - and may or may not be > the same problem you hit. If I get that out of the way then we > can establish if you are seeing the same issue or not. Did you > select KIOBUF based I/O in the configuration options - this only > affects SCSI drives right now, but at the moment I am suspecting > it being related to the corruption I saw. no - so far i don't use kiobufs - i keeped them turned of due to the problems from the beginning with test5 > On a topic related to porting XFS to other architectures, I now > have a system which does not need the 64 bit divide and modulus > support functions. All the places XFS does this turn out to be > dividing by a 32 bit quantity and there is a function called > do_div provided for that on all architectures. This will show > up after we get the corruption sorted out. yes - this should make it running on other arches without that more easy > An ia64 port has been attempted, not sure what the current status > is, and XFS does come from a 64 bit background in the first place, > all modern Irix platforms are 64 bit. However, this is a good check > that we did not lose information in the port to Linux. i think the code itself is quite clean - but the linux related parts are so far then not really tested to be 64bit safe - for instance - most of the compiler warnings came from the linux related things like in the linux subdir or the pagebuf (which i assume to be heavily linux related too) > other things: there are some tests in cmd/xfs/stress - getting these > to build may or may not be a problem. Also check out this web site, you > can download yet more tests for xfs from here: > http://oss.sgi.com/projects/ltp/ - again porting to other platforms may > be some work. i'll have a look at them > I will take a look at packaging the changes you did for the pagebuf > debug mechanism next week. that would be fine - thanks btw. are there any docs available about how to read the pagebuf traces to find things out or something else about the internals of xfs (because due to the amount of source code it would take really long for me i assume to even get a rough picture just from reading the code :-) ok - below the changes to make the compiler happier ... all the other warnings were definitely harmless (printk wrong formats etc.) t cast from/to pointer to/from integer of different size Index: fs/pagebuf/page_buf_io.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf_io.c,v retrieving revision 1.16 diff -u -r1.16 page_buf_io.c --- fs/pagebuf/page_buf_io.c 2000/08/02 20:40:07 1.16 +++ fs/pagebuf/page_buf_io.c 2000/08/04 18:10:01 @@ -898,7 +898,7 @@ do_generic_file_read(filp, lp, (read_descriptor_t *) rdp, _pagebuf_read_helper); } else { - if ((unsigned int) buf & (inode->i_sb->s_blocksize - 1)) + if ((unsigned long int) buf & (inode->i_sb->s_blocksize - 1)) return -EINVAL; inode->i_op->pagebuf_fileread(filp, rdp); @@ -934,7 +934,7 @@ if (bh->b_size == PAGE_SIZE) PageBlockSetAllValid(page); else - PageBlockSetValid(page, (int) bh->b_private); + PageBlockSetValid(page, (long int) bh->b_private); } /* @@ -993,7 +993,7 @@ if (bh->b_size == PAGE_SIZE) PageBlockSetAllValid(page); else - PageBlockSetValid(page, (int) bh->b_private); + PageBlockSetValid(page, (long int) bh->b_private); unlock_buffer(bh); } @@ -1017,7 +1017,7 @@ struct buffer_head *bh, *head, *arr[PAGE_CACHE_SIZE / 512]; int blocksize, bbits = inode->i_sb->s_blocksize_bits; unsigned long kaddr = 0; - int nr, i, status = 0; + long int nr, i, status = 0; if (!PageLocked(page) || (inode->i_op->pagebuf_bmap == NULL)) PAGE_BUG(page); comparision always true due to limited range of data type Index: fs/xfs/xfs_rw.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c,v retrieving revision 1.322 diff -u -r1.322 xfs_rw.c --- fs/xfs/xfs_rw.c 2000/07/31 16:16:28 1.322 +++ fs/xfs/xfs_rw.c 2000/08/04 18:10:04 @@ -659,7 +659,7 @@ for (i = 0; i < nimaps; i++) { imapp = &imaps[i]; count_fsb -= imapp->br_blockcount; - ASSERT(((long)count_fsb) >= 0); + ASSERT(((int)count_fsb) >= 0); ASSERT(offset_fsb == imapp->br_startoff); offset_fsb += imapp->br_blockcount; ASSERT(offset_fsb <= last_fsb); Index: fs/xfs/xfs_vnodeops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c,v retrieving revision 1.469 diff -u -r1.469 xfs_vnodeops.c --- fs/xfs/xfs_vnodeops.c 2000/07/31 16:16:28 1.469 +++ fs/xfs/xfs_vnodeops.c 2000/08/04 18:10:05 @@ -5053,7 +5053,7 @@ for (i = 0; i < nimaps; i++) { ASSERT(imap[i].br_startblock != HOLESTARTBLOCK); count_fsb -= imap[i].br_blockcount; - ASSERT(((long)count_fsb) >= 0); + ASSERT(((int)count_fsb) >= 0); curr_off_fsb += imap[i].br_blockcount; ASSERT(curr_off_fsb <= last_fsb); } initialization from incompatible pointer type Index: fs/xfs/linux/xfs_file.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c,v retrieving revision 1.32 diff -u -r1.32 xfs_file.c --- fs/xfs/linux/xfs_file.c 2000/07/31 21:38:52 1.32 +++ fs/xfs/linux/xfs_file.c 2000/08/04 18:10:05 @@ -37,9 +37,9 @@ #include #include -STATIC long long linvfs_file_lseek( +STATIC loff_t linvfs_file_lseek( struct file *file, - long long offset, + loff_t offset, int origin) { struct inode *inode = file->f_dentry->d_inode; -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Sat Aug 5 07:01:09 2000 Received: by oss.sgi.com id ; Sat, 5 Aug 2000 07:01:00 -0700 Received: from hermes.mixx.net ([212.84.196.2]:48906 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 5 Aug 2000 07:00:42 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 18610FA7C for ; Sat, 5 Aug 2000 16:00:10 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 2CA7F2CA6D; Sat, 5 Aug 2000 16:00:09 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 5 Aug 2000 14:00:09 GMT Organization: innominate AG, Berlin, Germany Lines: 157 Distribution: local Message-ID: References: <200008032028.PAA15107@jen.americas.sgi.com> <398A0540.CF7DA075@thebarn.com> <8mdkni$lqf$2@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965484009 8946 10.0.0.69 (5 Aug 2000 14:00:09 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > ok - due to some response from the ppc-dev list it's a bug in the > ppc kernel implementation of the shifts and i have a patch for it > now which i'll try this evening and i expect xfs to run then fine > on the ppc ... lets see :-) [one question before i begin: do you have interchanging filesystems on disk between irix/mips and linux/i386 working completely and without errors so far - so that one can expect the on disk layout to be completely portable and tested and use an i386 generated diskimage for other arches to test - what i do here ? - i think and hope so ...] ok - now tried the fix for the ppc >32 shift bug and it now shifts correctly and thus it now also mounts fine with the original xlatesb with the shifts > 32 in it - so this problem is fixed now ... but if i try to write to the filesystem it crashes with XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 so - lets do this step by step: what do i do: mount the xfs fs, cd into it and copy the one file (XFS) there to "test" - somewhere there it crashes what i tried: i tried to get a full page_buf trace for this but ran into another problem - there seems to be so far no way to capture the traceoutput - klogd/syslog seems to loose some of the printk's (the XFS assertion failed does not even appear in it *) and also delays do not help here - because i don't have a serial port on an imac i can't capture it on a remote serial console - so the only way so far is to write it down from screen :-( (but i did it :-) *) although it appears on the console screen ... does anyone have an idea how to get all the kernel printk's definitely to somewhere (file or somehow remote or maybe redirecting the console or something like ...) ? ok - lets go on: so that the kernel crash output does not trash the trace i removed the BUG() in assertfail and replaced it by an infinite loop so that i have time to type the trace from the screen - i did it in two ways: first reduced - only the events (this way a lot of them fit on screen) and later the last few trace entries complete - ok - here they are - i hope that is a good start (together with the used 32mb diskimage from http://innominate.org/~graichen/projects/xfs-pp/xfs.dd.gz which is used here too) to reproduce the sequence for you and maybe get an idea by comparing the trace outputs - so now first the reduced output and then the full for the last entries avl_ins look_pg get_obj TRANS_READ XFS_RELSE unlock rele free_obj free_lk freed_l lock locked XFS_PIN pin XFS_PIN pin XFS_PIN pin XFS_UNLOCK unlock rele delwri_q XFS_UNLOCK rele unlock delwri_q walkq1 walkq1 walkq1 get look_pg iostart ioreq hold rele iowait done iowaited hold rele rele free_obj XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 ok and now the detailed one: pb 0xc1d0d500 [iostart] (hold 1 lock 0) misc 0x00000001 address 0xc5871f04 offset 0x0 size 0x1000 task 0xc1840000 flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [ioreq] (hold 1 lock 0) misc 0x00000000 address 0xc586f958 offset 0x0 size 0x1000 task 0xc1840000 flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [hold] (hold 2 lock 0) misc 0x00000000 address 0xc5870908 offset 0x0 size 0x1000 task 0xc1840000 flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [rele] (hold 2 lock 0) misc 0x00000000 address 0xc5870a2c offset 0x0 size 0x1000 task 0xc1840000 flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [iowait] (hold 1 lock 0) misc 0x00000000 address 0xc586f9ac offset 0x0 size 0x1000 task 0xc1840000 flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [done] (hold 1 lock 0) misc 0x00000000 address 0xc586fc74 offset 0x0 size 0x1000 task 0xc01cfff0 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [iowaited] (hold 1 lock 0) misc 0x00000000 address 0xc586f9ac offset 0x0 size 0x1000 task 0xc1840000 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [hold] (hold 2 lock 0) misc 0x00000000 address 0xc5870908 offset 0x0 size 0x1000 task 0xc1840000 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [rele] (hold 2 lock 0) misc 0x00000000 address 0xc5870a2c offset 0x0 size 0x1000 task 0xc1840000 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [rele] (hold 1 lock 0) misc 0x00000000 address 0xc5871f24 offset 0x0 size 0x1000 task 0xc1840000 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED pb 0xc1d0d500 [free_obj] (hold 1 lock 0) misc 0x00000000 address 0xc586f4b4 offset 0x0 size 0x1000 task 0xc1840000 flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 ok - that is all for now - i hope this gets you to the right track somehow a lot of thanks in advance t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Sat Aug 5 22:34:56 2000 Received: by oss.sgi.com id ; Sat, 5 Aug 2000 22:34:37 -0700 Received: from srv1.ecropolis.com ([209.173.8.8]:59919 "HELO srv1.ecropolis.com") by oss.sgi.com with SMTP id ; Sat, 5 Aug 2000 22:34:18 -0700 Received: (qmail 31039 invoked from network); 6 Aug 2000 05:34:02 -0000 Received: from srv1.ecropolis.com (jeremy@209.173.8.8) by srv1.ecropolis.com with SMTP; 6 Aug 2000 05:34:02 -0000 Date: Sun, 6 Aug 2000 01:34:02 -0400 (EDT) From: Jeremy Hansen X-Sender: jeremy@srv1.ecropolis.com To: linux-xfs@oss.sgi.com Subject: confused about how to actually build xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm confused as to how to actually build xfs. How do I actually get xfs to build. I checked the code out of cvs, but it leaves me rather confused. There's supposed to be a README.build file in the top level, but that doesn't exist. It looks like it's support to build into an rpm from a spec file, but the spec file is looking for linux-2.4.0-test5-xfs-alpha.patch which does exist from the cvs tree. I'm just confused and I'd like to try xfs out. Thanks for any help. The Linux-xfs faq doesn't seem to exist. -jeremy -- http://www.xxedgexx.com | jeremy@xxedgexx.com --------------------------------------------- From owner-linux-xfs-announce@oss.sgi.com Sun Aug 6 00:20:56 2000 Received: by oss.sgi.com id ; Sun, 6 Aug 2000 00:20:44 -0700 Received: from hermes.mixx.net ([212.84.196.2]:29706 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 6 Aug 2000 00:19:57 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 0C79EF804 for ; Sun, 6 Aug 2000 09:15:24 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BAE182CA6B; Sun, 6 Aug 2000 09:15:23 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: confused about how to actually build xfs Date: 6 Aug 2000 07:15:23 GMT Organization: innominate AG, Berlin, Germany Lines: 44 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965546123 4363 10.0.0.69 (6 Aug 2000 07:15:23 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jeremy Hansen wrote: > I'm confused as to how to actually build xfs. > How do I actually get xfs to build. I checked the code out of cvs, but it > leaves me rather confused. There's supposed to be a README.build file in > the top level, but that doesn't exist. It looks like it's support to > build into an rpm from a spec file, but the spec file is looking for > linux-2.4.0-test5-xfs-alpha.patch which does exist from the cvs tree. > I'm just confused and I'd like to try xfs out. > Thanks for any help. The Linux-xfs faq doesn't seem to exist. don't know if there is any doc there (i think somewhere it is) but it is quite simple: you have to checkout the linux and the cmd tree from cvs - the linux tree is a kernel source tree you have to build your kernel from (enable xfs under filesystems) and in the cmd tree just go to the xfs subdir and enter make (and maybe make install) this will build you the tools like mkfs_xfs etc. - then (after booting the xfs kernel) you may create an xfs filesytem mkfs_xfs /dev/xxx and mount it mount -t xfs /dev/xxx /somewhere thats it - also keep in mind it most probably still has some bugs in it - but it works quite well so far for me (i am running our company squid for about a week now on an xfs only system - except /boot) and had so far _no_ problems with it - so it's really useable but you shouldn't at the current point setup any real production systems with it (but i am quite optimistic that it will be there really soon) i hope this helps t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Sun Aug 6 00:31:57 2000 Received: by oss.sgi.com id ; Sun, 6 Aug 2000 00:31:42 -0700 Received: from srv1.ecropolis.com ([209.173.8.8]:39184 "HELO srv1.ecropolis.com") by oss.sgi.com with SMTP id ; Sun, 6 Aug 2000 00:30:49 -0700 Received: (qmail 1014 invoked from network); 6 Aug 2000 07:30:30 -0000 Received: from srv1.ecropolis.com (jeremy@209.173.8.8) by srv1.ecropolis.com with SMTP; 6 Aug 2000 07:30:30 -0000 Date: Sun, 6 Aug 2000 03:30:30 -0400 (EDT) From: Jeremy Hansen X-Sender: jeremy@srv1.ecropolis.com To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: confused about how to actually build xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ahh, so there's no actual "patching" that needs to be done. This is where I was confused, plus I see what looks like the spec file to build an rpm. I though the linux tree just got dump on top of the vanilla test5 source...plus freshmeat posting has a patch you can download. I didn't see any docs that pointed these things out so I was a bit cornfoozed. Thanks. -jeremy > Jeremy Hansen wrote: > > > I'm confused as to how to actually build xfs. > > > How do I actually get xfs to build. I checked the code out of cvs, but it > > leaves me rather confused. There's supposed to be a README.build file in > > the top level, but that doesn't exist. It looks like it's support to > > build into an rpm from a spec file, but the spec file is looking for > > linux-2.4.0-test5-xfs-alpha.patch which does exist from the cvs tree. > > > I'm just confused and I'd like to try xfs out. > > > Thanks for any help. The Linux-xfs faq doesn't seem to exist. > > don't know if there is any doc there (i think somewhere it is) but > it is quite simple: you have to checkout the linux and the cmd tree > from cvs - the linux tree is a kernel source tree you have to build > your kernel from (enable xfs under filesystems) and in the cmd tree > just go to the xfs subdir and enter make (and maybe make install) > this will build you the tools like mkfs_xfs etc. - then (after > booting the xfs kernel) you may create an xfs filesytem > > mkfs_xfs /dev/xxx > > and mount it > > mount -t xfs /dev/xxx /somewhere > > thats it - also keep in mind it most probably still has some bugs in > it - but it works quite well so far for me (i am running our company > squid for about a week now on an xfs only system - except /boot) and > had so far _no_ problems with it - so it's really useable but you > shouldn't at the current point setup any real production systems with > it (but i am quite optimistic that it will be there really soon) > > i hope this helps > > t > > -- http://www.xxedgexx.com | jeremy@xxedgexx.com --------------------------------------------- From owner-linux-xfs-announce@oss.sgi.com Sun Aug 6 10:33:42 2000 Received: by oss.sgi.com id ; Sun, 6 Aug 2000 10:33:33 -0700 Received: from hermes.mixx.net ([212.84.196.2]:44038 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 6 Aug 2000 10:32:59 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 7531FF814 for ; Sun, 6 Aug 2000 19:32:23 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id C42502CA6B; Sun, 6 Aug 2000 19:32:22 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs after a week of use Date: 6 Aug 2000 17:32:22 GMT Organization: innominate AG, Berlin, Germany Lines: 163 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965583142 6244 10.0.0.69 (6 Aug 2000 17:32:22 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - after a week of use on a squid running machine (for about 50 users) i rebooted this otherwise full xfs machine and checked the xfs filesystems on it - here are the results so far: / filesystem [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda5 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 7 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 data fork in ino 2097285 claims free block 131122 data fork in ino 2097288 claims free block 131088 imap claims in-use inode 2097288 is free, correcting imap data fork in ino 2097289 claims free block 131087 imap claims in-use inode 2097289 is free, correcting imap data fork in ino 2097290 claims free block 131089 imap claims in-use inode 2097290 is free, correcting imap data fork in ino 2097291 claims free block 131106 data fork in ino 2097291 claims free block 131107 data fork in ino 2097291 claims free block 131108 data fork in ino 2097291 claims free block 131109 data fork in ino 2097291 claims free block 131110 data fork in ino 2097291 claims free block 131111 data fork in ino 2097291 claims free block 131112 data fork in ino 2097291 claims free block 131113 data fork in ino 2097291 claims free block 131114 data fork in ino 2097291 claims free block 131115 data fork in ino 2097291 claims free block 131116 data fork in ino 2097291 claims free block 131117 data fork in ino 2097291 claims free block 131118 data fork in ino 2097291 claims free block 131119 data fork in ino 2097291 claims free block 131120 data fork in ino 2097291 claims free block 131121 imap claims in-use inode 2097291 is free, correcting imap data fork in ino 2097292 claims free block 131090 imap claims in-use inode 2097292 is free, correcting imap data fork in ino 2097294 claims free block 131124 imap claims in-use inode 2097294 is free, correcting imap data fork in ino 2097295 claims free block 131141 imap claims in-use inode 2097295 is free, correcting imap - agno = 3 - agno = 4 - agno = 5 imap claims in-use inode 5243053 is free, correcting imap imap claims in-use inode 5243056 is free, correcting imap imap claims in-use inode 5243057 is free, correcting imap imap claims in-use inode 5243058 is free, correcting imap imap claims in-use inode 5243059 is free, correcting imap imap claims in-use inode 5243060 is free, correcting imap imap claims in-use inode 5243061 is free, correcting imap imap claims in-use inode 5243062 is free, correcting imap imap claims in-use inode 5243064 is free, correcting imap imap claims in-use inode 5243067 is free, correcting imap - 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 - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 entry "squid.pid" at block 0 offset 400 in directory inode 2097285 references fr ee inode 2180103 clearing inode number in entry at offset 400... - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 rebuilding directory inode 2097285 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 7340166, moving to lost+found disconnected inode 7340168, moving to lost+found Phase 7 - verify and correct link counts... done [root@january /root]# /var/spool/squid filesystem [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda6 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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) ... - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done [root@january /root]# looks better - so it looks like that xfs maybe have some problems running as / fs ? - ok will keep posting my observations over time ... btw. the kernel was from about july 31st ... august 1st and the machine was all time shutdown cleanly (maybe i have something to change on the halt scripts for xfs unmounting - it's default redhat 6.2 for now ? - for booting i use the lilo read-write option) t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Sun Aug 6 10:42:12 2000 Received: by oss.sgi.com id ; Sun, 6 Aug 2000 10:41:52 -0700 Received: from hermes.mixx.net ([212.84.196.2]:54278 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 6 Aug 2000 10:41:29 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 0BCEAF814 for ; Sun, 6 Aug 2000 19:40:58 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BEC612CA6B; Sun, 6 Aug 2000 19:40:57 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs after a week of use Date: 6 Aug 2000 17:40:57 GMT Organization: innominate AG, Berlin, Germany Lines: 67 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965583657 6244 10.0.0.69 (6 Aug 2000 17:40:57 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > looks better - so it looks like that xfs maybe have some problems > running as / fs ? - ok will keep posting my observations over > time ... just noticed that even running xfs_repair again (and again :-) over the fs with problems results in the following: [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda5 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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 - marking entry "lost+found" to be deleted - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 7340166, moving to lost+found disconnected inode 7340168, moving to lost+found Phase 7 - verify and correct link counts... done [root@january /root]# will update the kernel now and see what the next week brings :-) t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:14:41 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:14:31 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2136 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:13:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA07098 for ; Mon, 7 Aug 2000 09:19:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA79338; Mon, 7 Aug 2000 11:11:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA01366; Mon, 7 Aug 2000 11:11:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id LAA21799; Mon, 7 Aug 2000 11:10:02 -0500 Message-Id: <200008071610.LAA21799@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "05 Aug 2000 14:00:09 GMT." Date: Mon, 07 Aug 2000 11:10:02 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Thomas Graichen wrote: > > > ok - due to some response from the ppc-dev list it's a bug in the > > ppc kernel implementation of the shifts and i have a patch for it > > now which i'll try this evening and i expect xfs to run then fine > > on the ppc ... lets see :-) > > [one question before i begin: do you have interchanging filesystems > on disk between irix/mips and linux/i386 working completely and > without errors so far - so that one can expect the on disk layout > to be completely portable and tested and use an i386 generated > diskimage for other arches to test - what i do here ? - i think > and hope so ...] In theory this should be true - it is always possible there is a glitch lurking out there somewhere. One issue might be how a specific architecture lays out a structure in memory. We reply on the compiler to generate the correct layout for on disk structures. For example, if you run # gdb modules/xfs.o you can do things like (gdb) print sizeof(xfs_sb_t) $1 = 200 This and other on disk structures need to come out the same size on the ppc for things to work. > > ok - now tried the fix for the ppc >32 shift bug and it now shifts > correctly and thus it now also mounts fine with the original xlatesb > with the shifts > 32 in it - so this problem is fixed now ... but > if i try to write to the filesystem it crashes with > > XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 I do not think pagebuf tracing is going to help here (but thanks for capturing them). This assert is coming out of a very specific function. indlen = (xfs_extlen_t) xfs_bmap_worst_indlen(ip, alen); ASSERT(indlen > 0); Instead of just calling ASSERT here, put in an explicit check for indlen being less than zero, if it is then print out indlen and alen, they are both unsigned 32 bit quantities (which makes the assert somewhat bogus). However, indlen should not be huge, it is supposed to be the worst case calculation of the amount of disk space to hold alen of data (worst case metadata overhead). Adding printk calls to xfs_bmap_worst_indlen would be the next step - it is in xfs_bmap.c. Something in this function is probably the cause, maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too. Steve > > so - lets do this step by step: > > what do i do: mount the xfs fs, cd into it and copy the one file (XFS) > there to "test" - somewhere there it crashes > > what i tried: i tried to get a full page_buf trace for this but ran > into another problem - there seems to be so far no way to capture > the traceoutput - klogd/syslog seems to loose some of the printk's > (the XFS assertion failed does not even appear in it *) and also > delays do not help here - because i don't have a serial port on an > imac i can't capture it on a remote serial console - so the only > way so far is to write it down from screen :-( (but i did it :-) > > *) although it appears on the console screen ... > > does anyone have an idea how to get all the kernel printk's definitely > to somewhere (file or somehow remote or maybe redirecting the console > or something like ...) ? > > ok - lets go on: so that the kernel crash output does not trash > the trace i removed the BUG() in assertfail and replaced it by > an infinite loop so that i have time to type the trace from the > screen - i did it in two ways: first reduced - only the events > (this way a lot of them fit on screen) and later the last few > trace entries complete - ok - here they are - i hope that is > a good start (together with the used 32mb diskimage from > > http://innominate.org/~graichen/projects/xfs-pp/xfs.dd.gz > > which is used here too) to reproduce the sequence for you and > maybe get an idea by comparing the trace outputs - so now first > the reduced output and then the full for the last entries > > avl_ins > look_pg > get_obj > TRANS_READ > XFS_RELSE > unlock > rele > free_obj > free_lk > freed_l > lock > locked > XFS_PIN > pin > XFS_PIN > pin > XFS_PIN > pin > XFS_UNLOCK > unlock > rele > delwri_q > XFS_UNLOCK > rele > unlock > delwri_q > walkq1 > walkq1 > walkq1 > get > look_pg > iostart > ioreq > hold > rele > iowait > done > iowaited > hold > rele > rele > free_obj > XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 > > ok and now the detailed one: > > pb 0xc1d0d500 [iostart] (hold 1 lock 0) misc 0x00000001 > address 0xc5871f04 > offset 0x0 size 0x1000 task 0xc1840000 > flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [ioreq] (hold 1 lock 0) misc 0x00000000 > address 0xc586f958 > offset 0x0 size 0x1000 task 0xc1840000 > flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [hold] (hold 2 lock 0) misc 0x00000000 > address 0xc5870908 > offset 0x0 size 0x1000 task 0xc1840000 > flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [rele] (hold 2 lock 0) misc 0x00000000 > address 0xc5870a2c > offset 0x0 size 0x1000 task 0xc1840000 > flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [iowait] (hold 1 lock 0) misc 0x00000000 > address 0xc586f9ac > offset 0x0 size 0x1000 task 0xc1840000 > flags: READ MAPPED NONE ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [done] (hold 1 lock 0) misc 0x00000000 > address 0xc586fc74 > offset 0x0 size 0x1000 task 0xc01cfff0 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [iowaited] (hold 1 lock 0) misc 0x00000000 > address 0xc586f9ac > offset 0x0 size 0x1000 task 0xc1840000 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [hold] (hold 2 lock 0) misc 0x00000000 > address 0xc5870908 > offset 0x0 size 0x1000 task 0xc1840000 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [rele] (hold 2 lock 0) misc 0x00000000 > address 0xc5870a2c > offset 0x0 size 0x1000 task 0xc1840000 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [rele] (hold 1 lock 0) misc 0x00000000 > address 0xc5871f24 > offset 0x0 size 0x1000 task 0xc1840000 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > pb 0xc1d0d500 [free_obj] (hold 1 lock 0) misc 0x00000000 > address 0xc586f4b4 > offset 0x0 size 0x1000 task 0xc1840000 > flags: MAPPED ALL_PAGES_MAPPED MEM_ALLOCATED > XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 > > ok - that is all for now - i hope this gets you to the right > track somehow > > a lot of thanks in advance > > t > -- > thomas.graichen@innominate.de > Technical Director innominate AG > Clustering & Security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:17:11 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:17:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17676 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:16:38 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA02749 for ; Mon, 7 Aug 2000 07:11:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA22121 for ; Mon, 7 Aug 2000 09:16:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA03891 for ; Mon, 7 Aug 2000 09:16:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA14761; Mon, 7 Aug 2000 09:14:58 -0500 Message-Id: <200008071414.JAA14761@jen.americas.sgi.com> Date: Mon, 7 Aug 2000 09:14:58 -0500 Subject: TAKE - fix a kiobuf locking hang To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Aug 7 07:15:46 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71479a linux/mm/memory.c - 1.35 - Fix lock_kiovec, the code path for dealing with lock contention on a page was broken. It never calls wait_on_page - unless the page was not locked - in which case it would do nothing anyhow. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:20:01 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:19:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1037 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:19:29 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA27429 for ; Mon, 7 Aug 2000 06:27:49 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA96276; Mon, 7 Aug 2000 08:32:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA72008; Mon, 7 Aug 2000 08:32:50 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA14349; Mon, 7 Aug 2000 08:31:30 -0500 Message-Id: <200008071331.IAA14349@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen cc: linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: Message from Thomas Graichen of "06 Aug 2000 17:40:57 GMT." Date: Mon, 07 Aug 2000 08:31:29 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing One comment here - the lost+found directory is removed by xfs_repair, so if you run repair and it reconnects some files, then running repair again without moving those files somewhere else will result in them getting reconnected again. Steve > Thomas Graichen wrote: > > > looks better - so it looks like that xfs maybe have some problems > > running as / fs ? - ok will keep posting my observations over > > time ... > > just noticed that even running xfs_repair again (and again :-) over > the fs with problems results in the following: > > [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda5 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - 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 > - marking entry "lost+found" to be deleted > - 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... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 7340166, moving to lost+found > disconnected inode 7340168, moving to lost+found > Phase 7 - verify and correct link counts... > done > [root@january /root]# > > will update the kernel now and see what the next week brings :-) > > t > > -- > thomas.graichen@innominate.de > Technical Director innominate AG > Clustering & Security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:21:31 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:21:21 -0700 Received: from scaup.prod.itd.earthlink.net ([207.217.121.49]:21464 "EHLO scaup.prod.itd.earthlink.net") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:20:58 -0700 Received: from mickey (sdn-ar-001txhousP051.dialsprint.net [168.191.154.35]) by scaup.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id JAA10292 for ; Mon, 7 Aug 2000 09:20:27 -0700 (PDT) Reply-To: From: "Jason Holland" To: "Linux-XFS" Subject: latest cvs checkout and lvm Date: Sun, 6 Aug 2000 18:22:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing has anyone had any luck using the latest cvs tree (2.4.0-test5) with lvm enabled?? i had a few test volume groups setup, and wanted to test out xfs. however, i get a core dump when i do a vgscan with the xfs-enabled kernel running, and vgchange -a y returns errors about /proc not being mounted and physical devices not found on the system. the vg's are fine as far as i can tell, booting with a xfs-disabled 2.4.0-test5 kernel works. any ideas or suggestions??? btw, i went ahead and recompiled all my lvm tools just in case. same problem occurred. Jason From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:26:31 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:26:21 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9561 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:25:59 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03735 for ; Mon, 7 Aug 2000 08:22:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA30591 for ; Mon, 7 Aug 2000 10:14:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA74626 for ; Mon, 7 Aug 2000 10:14:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id KAA21553; Mon, 7 Aug 2000 10:13:27 -0500 Message-Id: <200008071513.KAA21553@jen.americas.sgi.com> Date: Mon, 7 Aug 2000 10:13:27 -0500 Subject: TAKE - make 64 bit division in XFS an explicit operation To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS does some 64 bit divide and mod operations, we had added library support for the i386 compiler intrinsics gcc generates to do this. This mod removes reliance on those intrinsics, and either changes XFS to no longer use the 64 bit math where possible, or to use the do_div function - which does 64 bit / 32 bit unsigned divide which is all we require. Date: Mon Aug 7 08:12:24 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71481a linux/arch/i386/lib/Makefile - 1.11 - Remove 64 bit divide support functions linux/arch/i386/kernel/i386_ksyms.c - 1.29 - Do not export the 64 divide library functions - they are gone again linux/fs/xfs/xfs_ag.h - 1.36 - move XFS_DADDR_TO_AGNO and XFS_DADDR_TO_AGBNO to xfs_mount.h, they are inline functions and need the contents of mount_t to compile now. linux/fs/xfs/xfs_rw.c - 1.323 - Fix an assert to be 64 bit friendly linux/fs/xfs/xfs_buf_item.c - 1.108 - Fix an argument in a kprint call linux/fs/xfs/xfs_vnodeops.c - 1.470 - Make 64 bit divide and modulus operations explicit linux/fs/xfs/xfs_mount.h - 1.115 - move XFS_DADDR_TO_AGNO and XFS_DADDR_TO_AGBNO here as they need the definition of xfs_mount_t. linux/fs/xfs/xfs_mount.c - 1.231 - Make 64 bit divide and modulus operations explicit linux/fs/xfs/xfs_inode.h - 1.140 - Change inode hash functions to not require 64 bit math linux/fs/xfs/xfs_fsops.c - 1.53 linux/fs/xfs/xfs_bmap.c - 1.257 - Make 64 bit divide and modulus operations explicit linux/fs/xfs/xfs_dir2_node.c - 1.15 - Fix an assert to not require 64 bit divide. linux/fs/xfs/pseudo-inc/sys/param.h - 1.9 - Add roundup_64 with an explicit call to do_div() linux/fs/xfs/linux/xfs_lrw.c - 1.48 - Make 64 bit divide and modulus operations explicit linux/fs/xfs/xfs_os_defs.h - 1.10 - Include asm/div64.h for 64 bit math interface, defined do_mod as a side effect free version of do_div, define user space versions. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:34:01 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:33:42 -0700 Received: from tux.mkp.net ([130.225.60.11]:64018 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:33:18 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13Lpm3-0007dQ-00; Mon, 07 Aug 2000 18:29:12 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id MAA03581; Mon, 7 Aug 2000 12:32:41 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: Cc: "Linux-XFS" Subject: Re: latest cvs checkout and lvm References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 07 Aug 2000 12:32:41 -0400 In-Reply-To: "Jason Holland"'s message of "Sun, 6 Aug 2000 18:22:52 -0500" Message-ID: Lines: 21 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Jason" == Jason Holland writes: Jason> has anyone had any luck using the latest cvs tree (2.4.0-test5) Jason> with lvm enabled?? i had a few test volume groups setup, and Jason> wanted to test out xfs. however, i get a core dump when i do a Jason> vgscan with the xfs-enabled kernel running Our tree adds a few fields to /proc/partitions that causes liblvm to barf. I'll create a tarball of my patched LVM utilities later today and put it on oss.sgi.com. Please note that LVM doesn't work with KIOBUF_IO yet. That's being worked on. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:41:31 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:41:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1811 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:40:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA03793 for ; Sun, 6 Aug 2000 23:49:01 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24556 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 7 Aug 2000 16:55:18 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA74674 for linux-xfs@oss.sgi.com; Mon, 7 Aug 2000 16:55:16 +1000 (EST) Date: Mon, 7 Aug 2000 16:55:16 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008070655.QAA74674@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libxfs Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Next set of changes to provide a portable user tool build. I have a working mkfs based on this, but will need to do at least one more day of testing on mkfs before I check it in. I also have converted xfs_repair, but haven't begun testing that as yet (I believe most of the hard work is done though - mkfs is looking good). Not long now, Thomas. =) cheers. Modid: 2.4.0-test1-xfs:slinx:71472a Date: Sun Aug 6 23:40:13 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/check.c - 1.55 cmd/xfs/db/frag.c - 1.17 cmd/xfs/db/mount.c - 1.20 - use modified libxfs dinode & sb xlate routines. cmd/xfs/include/libxfs.h - 1.6 - numerous changes to provide an interface for mkfs and repair which is not based on libsim, but allows code sharing between user & XFS kernel code in a portable manner. cmd/xfs/libxfs/Makefile - 1.4 - bunch of new files, extra options to compile without warnings. cmd/xfs/libxfs/arch.c - 1.2 - remove now defunct xlate routines. cmd/xfs/libxfs/init.c - 1.4 - last set of changes required for a functional, non-sim mkfs & repair. cmd/xfs/libxfs/kernel.c - 1.3 - remove lots of routines which are available from other .c files now. cmd/xfs/libxfs/rdwr.c - 1.4 - last set of changes required for a functional, non-sim mkfs & repair. cmd/xfs/logprint/logprint.c - 1.43 - use modified libxfs dinode & sb xlate routines. cmd/xfs/logprint/logprint.h - 1.5 - rework some interfaces to cooperate with other changes required for mkfs and repair in a non-sim build. cmd/xfs/include/acl.h - 1.1 - copy over from kernel, suitable for userland compile (for repair). cmd/xfs/libxfs/util.c - 1.1 - contains routines which were once kernel routines, but which have had to be so hacked up in the kernel code to be able to be used in both kernel and user mode that its not worth keeping them in sync. Some routines which were shared between mkfs and repair also, which may as well be kept in one place rather than in two. cmd/xfs/libxfs/xfs.h - 1.1 - magic glue which allows kernel XFS code to be built in userspace, and also provides the namespace mapping between kernel names and libxfs. cmd/xfs/libxfs/xfs_alloc.c - 1.1 cmd/xfs/libxfs/xfs_alloc_btree.c - 1.1 cmd/xfs/libxfs/xfs_attr_leaf.c - 1.1 cmd/xfs/libxfs/xfs_bit.c - 1.1 cmd/xfs/libxfs/xfs_bmap.c - 1.1 cmd/xfs/libxfs/xfs_bmap_btree.c - 1.1 cmd/xfs/libxfs/xfs_btree.c - 1.1 cmd/xfs/libxfs/xfs_da_btree.c - 1.1 cmd/xfs/libxfs/xfs_dir.c - 1.1 cmd/xfs/libxfs/xfs_dir2.c - 1.1 cmd/xfs/libxfs/xfs_dir2_block.c - 1.1 cmd/xfs/libxfs/xfs_dir2_data.c - 1.1 cmd/xfs/libxfs/xfs_dir2_leaf.c - 1.1 cmd/xfs/libxfs/xfs_dir2_node.c - 1.1 cmd/xfs/libxfs/xfs_dir2_sf.c - 1.1 cmd/xfs/libxfs/xfs_dir_leaf.c - 1.1 cmd/xfs/libxfs/xfs_ialloc.c - 1.1 cmd/xfs/libxfs/xfs_ialloc_btree.c - 1.1 cmd/xfs/libxfs/xfs_inode.c - 1.1 cmd/xfs/libxfs/xfs_rtalloc.c - 1.1 cmd/xfs/libxfs/xfs_rtbit.c - 1.1 - subset of same file in the XFS kernel code required for userland tools. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:43:31 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:43:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50522 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:42:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01613 for ; Mon, 7 Aug 2000 07:44:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA94322 for ; Mon, 7 Aug 2000 09:36:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA70691 for ; Mon, 7 Aug 2000 09:36:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA16749; Mon, 7 Aug 2000 09:35:32 -0500 Message-Id: <200008071435.JAA16749@jen.americas.sgi.com> Date: Mon, 7 Aug 2000 09:35:32 -0500 Subject: TAKE - fix some 64 bit isms in XFS + a pagebuf fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing A couple of compile fixes for the Alpha from Thomas Graichen , plus change the disk location passed into pagebufs to be a 64 bit quantity, plus a workaround for the page daemon going into infinite loops looking for pages which are not there. Date: Mon Aug 7 07:33:51 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71480a linux/fs/xfs/xfs_buf.h - 1.58 - Use page_buf_daddr_t as the casting type for pb_bn. linux/fs/xfs/linux/xfs_file.c - 1.33 - Change long long to loff_t for 64 bit builds linux/include/linux/page_buf.h - 1.56 - use loff_t as the type for a pagebuf disk address. linux/fs/pagebuf/page_buf_io.c - 1.18 - Fix some type issues on 64 bit platforms, a couple of code cleanups, and do not allow the page cleaner to loop for ever. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 09:45:02 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 09:44:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1811 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 09:44:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA02190 for ; Sun, 6 Aug 2000 23:15:40 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24352 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 7 Aug 2000 16:21:56 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA42810 for linux-xfs@oss.sgi.com; Mon, 7 Aug 2000 16:21:54 +1000 (EST) Date: Mon, 7 Aug 2000 16:21:54 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008070621.QAA42810@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing xfs_repair needs to know about __psunsigned_t ... this is platform specific, so we'll have configure work it out. Modid: 2.4.0-test1-xfs:slinx:71471a Date: Sun Aug 6 23:20:33 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/configure.in - 1.9 cmd/xfs/include/platform_defs.h.in - 1.6 - check for __psunsigned_t. From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 10:28:19 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 10:28:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38945 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 10:27:32 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA28633 for ; Mon, 7 Aug 2000 10:19:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA71844; Mon, 7 Aug 2000 12:25:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA09256; Mon, 7 Aug 2000 12:25:37 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id MAA21873; Mon, 7 Aug 2000 12:24:15 -0500 Message-Id: <200008071724.MAA21873@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Martin K. Petersen" cc: jphollan@earthlink.net, "Linux-XFS" Subject: Re: latest cvs checkout and lvm In-Reply-To: Message from "Martin K. Petersen" of "07 Aug 2000 12:32:41 EDT." Date: Mon, 07 Aug 2000 12:24:15 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > >>>>> "Jason" == Jason Holland writes: > > Jason> has anyone had any luck using the latest cvs tree (2.4.0-test5) > Jason> with lvm enabled?? i had a few test volume groups setup, and > Jason> wanted to test out xfs. however, i get a core dump when i do a > Jason> vgscan with the xfs-enabled kernel running > > Our tree adds a few fields to /proc/partitions that causes liblvm to > barf. Just in case anyone wonders what these are, it is actually Stephen Tweedie's sard patch which lets you get better statistics out of the block device layer. Steve From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 10:40:19 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 10:40:09 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61023 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 10:39:34 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA06194 for ; Mon, 7 Aug 2000 10:45:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA34290; Mon, 7 Aug 2000 12:37:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA05593; Mon, 7 Aug 2000 12:37:46 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id MAA21900; Mon, 7 Aug 2000 12:36:24 -0500 Message-Id: <200008071736.MAA21900@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: Message from Thomas Graichen of "06 Aug 2000 17:32:22 GMT." Date: Mon, 07 Aug 2000 12:36:24 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > ok - after a week of use on a squid running machine (for about 50 > users) i rebooted this otherwise full xfs machine and checked the > xfs filesystems on it - here are the results so far: > > / filesystem > Just thinking about this, if you did the xfs_repair on a live filesystem then you really cannot rely on it being correct. Repair uses the block device interface which will not use the same caching as XFS is using for its meta-data. In general, repair should not be run on a live filesystem (repair -n can be since it does not modify anything). Also if a filesystem was not cleanly unmounted then it should be remounted and unmounted again before running repair - as the log may contain the missing parts of the picture. Steve > [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda5 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > error following ag 7 unlinked list > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > data fork in ino 2097285 claims free block 131122 > data fork in ino 2097288 claims free block 131088 > imap claims in-use inode 2097288 is free, correcting imap > data fork in ino 2097289 claims free block 131087 > imap claims in-use inode 2097289 is free, correcting imap > data fork in ino 2097290 claims free block 131089 > imap claims in-use inode 2097290 is free, correcting imap > data fork in ino 2097291 claims free block 131106 > data fork in ino 2097291 claims free block 131107 > data fork in ino 2097291 claims free block 131108 > data fork in ino 2097291 claims free block 131109 > data fork in ino 2097291 claims free block 131110 > data fork in ino 2097291 claims free block 131111 > data fork in ino 2097291 claims free block 131112 > data fork in ino 2097291 claims free block 131113 > data fork in ino 2097291 claims free block 131114 > data fork in ino 2097291 claims free block 131115 > data fork in ino 2097291 claims free block 131116 > data fork in ino 2097291 claims free block 131117 > data fork in ino 2097291 claims free block 131118 > data fork in ino 2097291 claims free block 131119 > data fork in ino 2097291 claims free block 131120 > data fork in ino 2097291 claims free block 131121 > imap claims in-use inode 2097291 is free, correcting imap > data fork in ino 2097292 claims free block 131090 > imap claims in-use inode 2097292 is free, correcting imap > data fork in ino 2097294 claims free block 131124 > imap claims in-use inode 2097294 is free, correcting imap > data fork in ino 2097295 claims free block 131141 > imap claims in-use inode 2097295 is free, correcting imap > - agno = 3 > - agno = 4 > - agno = 5 > imap claims in-use inode 5243053 is free, correcting imap > imap claims in-use inode 5243056 is free, correcting imap > imap claims in-use inode 5243057 is free, correcting imap > imap claims in-use inode 5243058 is free, correcting imap > imap claims in-use inode 5243059 is free, correcting imap > imap claims in-use inode 5243060 is free, correcting imap > imap claims in-use inode 5243061 is free, correcting imap > imap claims in-use inode 5243062 is free, correcting imap > imap claims in-use inode 5243064 is free, correcting imap > imap claims in-use inode 5243067 is free, correcting imap > - 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 > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > entry "squid.pid" at block 0 offset 400 in directory inode 2097285 references fr > ee inode 2180103 > clearing inode number in entry at offset 400... > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > rebuilding directory inode 2097285 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 7340166, moving to lost+found > disconnected inode 7340168, moving to lost+found > Phase 7 - verify and correct link counts... > done > [root@january /root]# > > /var/spool/squid filesystem > > [root@january /root]# /usr/src/xfs/cmd/xfs/repair/xfs_repair /dev/hda6 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - 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) ... > - 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... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > done > [root@january /root]# > > looks better - so it looks like that xfs maybe have some problems > running as / fs ? - ok will keep posting my observations over > time ... > > btw. the kernel was from about july 31st ... august 1st and the > machine was all time shutdown cleanly (maybe i have something to > change on the halt scripts for xfs unmounting - it's default > redhat 6.2 for now ? - for booting i use the lilo read-write > option) In theory XFS should unmount correctly, although I think there are some issues with making a remount read-only look like a clean unmount - this may be what is happening on the root disk. Steve p.s. Lilo does work from XFS! From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 10:41:49 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 10:41:30 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:3975 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 10:41:08 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA14240; Mon, 7 Aug 2000 12:40:33 -0500 (CDT) Message-Id: <4.2.0.58.20000807121957.00a1f100@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 07 Aug 2000 12:42:10 -0500 To: , "Linux-XFS" From: "William L. Jones" Subject: Re: latest cvs checkout and lvm In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 06:22 PM 8/6/00 -0500, Jason Holland wrote: >has anyone had any luck using the latest cvs tree (2.4.0-test5) with lvm >enabled?? i had a few test volume groups setup, and wanted to test out xfs. >however, i get a core dump when i do a vgscan with the xfs-enabled kernel >running, and vgchange -a y returns errors about /proc not being mounted and >physical devices not found on the system. the vg's are fine as far as i can >tell, booting with a xfs-disabled 2.4.0-test5 kernel works. any ideas or >suggestions??? btw, i went ahead and recompiled all my lvm tools just in >case. same problem occurred. > >Jason The lvm has several bugs in the utility programs. Take a look at the LVM site http://linux.msede.com/lvm/. You might find some patches their. I also sent you a patch that I use that may fix your problem. Bill Jones From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 10:54:20 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 10:54:00 -0700 Received: from hermes.mixx.net ([212.84.196.2]:54023 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 10:53:38 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A660BF890 for ; Mon, 7 Aug 2000 19:52:55 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 64AFB2CA6D; Mon, 7 Aug 2000 19:52:55 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs after a week of use Date: 7 Aug 2000 17:52:55 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: <200008071331.IAA14349@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965670775 16136 10.0.0.69 (7 Aug 2000 17:52:55 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > One comment here - the lost+found directory is removed by xfs_repair, > so if you run repair and it reconnects some files, then running repair > again without moving those files somewhere else will result in them > getting reconnected again. so it is a bit different in this aspect to a classic ufs - right (or this does no longer cry about it) ... but i'm now really convinced - i think it connects lost inodes to lost+found but the second run they are connected and don't need to be reconnected again - do i miss anything here ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 10:56:19 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 10:56:10 -0700 Received: from hermes.mixx.net ([212.84.196.2]:59911 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 10:55:40 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 05499F890 for ; Mon, 7 Aug 2000 19:55:09 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BA7AC2CA6D; Mon, 7 Aug 2000 19:55:08 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs after a week of use Date: 7 Aug 2000 17:55:08 GMT Organization: innominate AG, Berlin, Germany Lines: 37 Distribution: local Message-ID: References: <200008071736.MAA21900@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965670908 16136 10.0.0.69 (7 Aug 2000 17:55:08 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> ok - after a week of use on a squid running machine (for about 50 >> users) i rebooted this otherwise full xfs machine and checked the >> xfs filesystems on it - here are the results so far: >> >> / filesystem >> > Just thinking about this, if you did the xfs_repair on a live filesystem > then you really cannot rely on it being correct. Repair uses the block > device interface which will not use the same caching as XFS is using > for its meta-data. In general, repair should not be run on a live > filesystem (repair -n can be since it does not modify anything). > Also if a filesystem was not cleanly unmounted then it should be > remounted and unmounted again before running repair - as the log > may contain the missing parts of the picture. no - all tests were done after a clean reboot into an ext2 based system - so no repair_xfs is done with the fs online > In theory XFS should unmount correctly, although I think there are some > issues with making a remount read-only look like a clean unmount - this > may be what is happening on the root disk. maybe i'll have a closer look at what exactly redhat is doing here > p.s. Lilo does work from XFS! oh - thats is fine t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:01:50 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:01:30 -0700 Received: from hermes.mixx.net ([212.84.196.2]:8712 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 11:01:09 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8815BF890 for ; Mon, 7 Aug 2000 20:00:37 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 403AD2CA6F; Mon, 7 Aug 2000 20:00:37 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: TAKE - libxfs Date: 7 Aug 2000 18:00:37 GMT Organization: innominate AG, Berlin, Germany Lines: 25 Distribution: local Message-ID: References: <200008070655.QAA74674@snort.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965671237 16136 10.0.0.69 (7 Aug 2000 18:00:37 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Nathan Scott wrote: > Next set of changes to provide a portable user tool build. > I have a working mkfs based on this, but will need to do at > least one more day of testing on mkfs before I check it in. > I also have converted xfs_repair, but haven't begun testing > that as yet (I believe most of the hard work is done though > - mkfs is looking good). > Not long now, Thomas. =) thanks - i think this maybe even help a bit in debugging on the other arches (first a/b tests with native or "imported" filesystem and i think they use the exacly same datastructures as the kernel xfs - will say: same includes - so maybe i can find bugs here in- stead of having to be in kernel for checking all the structures etc. ...) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:04:20 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:04:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:57644 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 11:03:44 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA04156 for ; Mon, 7 Aug 2000 10:55:39 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA17609; Mon, 7 Aug 2000 13:00:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA70997; Mon, 7 Aug 2000 13:00:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id MAA23178; Mon, 7 Aug 2000 12:59:18 -0500 Message-Id: <200008071759.MAA23178@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: Message from Thomas Graichen of "07 Aug 2000 17:52:55 GMT." Date: Mon, 07 Aug 2000 12:59:18 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > One comment here - the lost+found directory is removed by xfs_repair, > > so if you run repair and it reconnects some files, then running repair > > again without moving those files somewhere else will result in them > > getting reconnected again. > > so it is a bit different in this aspect to a classic ufs - right > (or this does no longer cry about it) ... but i'm now really > convinced - i think it connects lost inodes to lost+found > but the second run they are connected and don't need to > be reconnected again - do i miss anything here ? Well, not quite, if there are inodes in lost+found which are not connected anywhere else, then xfs_repair ends up disconnecting them again, it then proceeds to find them and reconnect them. A bit braindead I suppose, but that is what happens. Steve > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:13:50 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:13:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:18480 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 11:13:00 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA05869 for ; Mon, 7 Aug 2000 11:04:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA10920; Mon, 7 Aug 2000 13:09:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA40674; Mon, 7 Aug 2000 13:09:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA23277; Mon, 7 Aug 2000 13:08:35 -0500 Message-Id: <200008071808.NAA23277@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: Message from Thomas Graichen of "07 Aug 2000 17:55:08 GMT." Date: Mon, 07 Aug 2000 13:08:35 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Just thinking about this, if you did the xfs_repair on a live filesystem > > then you really cannot rely on it being correct. Repair uses the block > > device interface which will not use the same caching as XFS is using > > for its meta-data. In general, repair should not be run on a live > > filesystem (repair -n can be since it does not modify anything). > > Also if a filesystem was not cleanly unmounted then it should be > > remounted and unmounted again before running repair - as the log > > may contain the missing parts of the picture. > > no - all tests were done after a clean reboot into an ext2 based > system - so no repair_xfs is done with the fs online OK, this is good, provided we really managed to unmount the xfs filesystem cleanly before rebooting into the ext2 system. By the way, is it possible to find out what these inodes were? If they contain text is it anything you recognize. I am wondering if they could be things like the syslog file which could be written very close to system shutdown. I am confident that an unmount of an xfs filesystem is working correctly, but I am not confident that the root filesystem gets unmounted correctly. Steve > > > In theory XFS should unmount correctly, although I think there are some > > issues with making a remount read-only look like a clean unmount - this > > may be what is happening on the root disk. > > maybe i'll have a closer look at what exactly redhat is doing here Looks like this: mount -n -o remount,ro / Which will not look like a clean shutdown when we remount an XFS filesystem. Steve From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:16:20 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:16:00 -0700 Received: from hermes.mixx.net ([212.84.196.2]:37896 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 11:15:36 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 1A6ACF894; Mon, 7 Aug 2000 20:15:04 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id 73C112CA6E; Mon, 7 Aug 2000 20:15:03 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id UAA02113; Mon, 7 Aug 2000 20:16:21 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Mon, 7 Aug 2000 20:16:21 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: <200008071808.NAA23277@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 7 Aug 2000, Steve Lord wrote: > By the way, is it possible to find out what these inodes were? If they > contain text is it anything you recognize. I am wondering if they could > be things like the syslog file which could be written very close to > system shutdown. I am confident that an unmount of an xfs filesystem is > working correctly, but I am not confident that the root filesystem gets > unmounted correctly. > it's the squid.log and cache log - the two files which were definitely actively used at the end - so i assume there is something wrong with the umount ... > > Looks like this: > > mount -n -o remount,ro / > > Which will not look like a clean shutdown when we remount an XFS filesystem. > ... which proves to be right here :-) how it should perfectly look like for xfs ? t p.s.: is there any XFS faq so far (oss.sgi.com says "not available yet") - if not i may start one - because looks like it's needed now that more people start testing xfs -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:28:50 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:28:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17205 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 11:28:29 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA08395 for ; Mon, 7 Aug 2000 11:20:25 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA28474; Mon, 7 Aug 2000 13:25:26 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA06686; Mon, 7 Aug 2000 13:25:25 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e77IP1g02555; Mon, 7 Aug 2000 13:25:01 -0500 Message-ID: <398EFEFC.DA8AB4A0@thebarn.com> Date: Mon, 07 Aug 2000 13:25:00 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > On Mon, 7 Aug 2000, Steve Lord wrote: > > > By the way, is it possible to find out what these inodes were? If they > > contain text is it anything you recognize. I am wondering if they could > > be things like the syslog file which could be written very close to > > system shutdown. I am confident that an unmount of an xfs filesystem is > > working correctly, but I am not confident that the root filesystem gets > > unmounted correctly. > > > it's the squid.log and cache log - the two files which were definitely > actively used at the end - so i assume there is something wrong with > the umount ... > > > > Looks like this: > > > > mount -n -o remount,ro / > > > > Which will not look like a clean shutdown when we remount an XFS filesystem. > > > ... which proves to be right here :-) > > how it should perfectly look like for xfs ? > > t > > p.s.: is there any XFS faq so far (oss.sgi.com says "not available > yet") - if not i may start one - because looks like it's needed > now that more people start testing xfs If you want... It's been on my list of things to do. Whatever you come up with send it my way and I will put it up. BTW I'm close to a boot floppy that should be able to understand xfs file systems. Hopefully I will be able to install a system from scratch using only XFS. This remounting from rw to ro is something we need to get ironed out before running a root xfs system is recommended. Thanks for all your efforts. > > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 11:29:20 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 11:29:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22325 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 11:28:49 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA08422 for ; Mon, 7 Aug 2000 11:20:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA36784; Mon, 7 Aug 2000 13:25:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA85162; Mon, 7 Aug 2000 13:25:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA23314; Mon, 7 Aug 2000 13:24:24 -0500 Message-Id: <200008071824.NAA23314@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: thomas.graichen@innominate.de cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs after a week of use In-Reply-To: Message from Thomas Graichen of "Mon, 07 Aug 2000 20:16:21 +0200." Date: Mon, 07 Aug 2000 13:24:24 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > > Looks like this: > > > > mount -n -o remount,ro / > > > > Which will not look like a clean shutdown when we remount an XFS filesystem . > > > ... which proves to be right here :-) > > how it should perfectly look like for xfs ? > At the moment I think it needs code changes, XFS expects to get unmounted by the kernel shutdown code - which is not happening in Linux. There is a partially working patch in my mailbox somewhere, maybe it is time to finish it. > > p.s.: is there any XFS faq so far (oss.sgi.com says "not available > yet") - if not i may start one - because looks like it's needed > now that more people start testing xfs > No, there are little bits and pieces scattered around the place, currently we have bandwidth problems around here so we have been ignoring it..... Steve From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 12:51:51 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 12:51:43 -0700 Received: from hermes.mixx.net ([212.84.196.2]:61706 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 12:51:07 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 1B142F898 for ; Mon, 7 Aug 2000 21:50:02 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 50CD72CA6D; Mon, 7 Aug 2000 21:50:01 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs after a week of use Date: 7 Aug 2000 19:50:01 GMT Organization: innominate AG, Berlin, Germany Lines: 39 Distribution: local Message-ID: References: <200008071824.NAA23314@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965677801 8939 10.0.0.69 (7 Aug 2000 19:50:01 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> > Looks like this: >> > >> > mount -n -o remount,ro / >> > >> > Which will not look like a clean shutdown when we remount an XFS filesystem > . >> > >> ... which proves to be right here :-) >> >> how it should perfectly look like for xfs ? >> > At the moment I think it needs code changes, XFS expects to get unmounted > by the kernel shutdown code - which is not happening in Linux. There is a > partially working patch in my mailbox somewhere, maybe it is time to finish > it. ho yes :-) ... just let me know whenever you have something to test >> >> p.s.: is there any XFS faq so far (oss.sgi.com says "not available >> yet") - if not i may start one - because looks like it's needed >> now that more people start testing xfs >> > No, there are little bits and pieces scattered around the place, currently > we have bandwidth problems around here so we have been ignoring it..... ok - i'll try to look into this too ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 12:59:40 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 12:59:33 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4619 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 12:59:18 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id AE071F89E for ; Mon, 7 Aug 2000 21:58:02 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 639982CA6D; Mon, 7 Aug 2000 21:58:02 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 7 Aug 2000 19:58:02 GMT Organization: innominate AG, Berlin, Germany Lines: 83 Distribution: local Message-ID: References: <200008071610.LAA21799@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965678282 8939 10.0.0.69 (7 Aug 2000 19:58:02 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> Thomas Graichen wrote: > In theory this should be true - it is always possible there is a glitch > lurking out there somewhere. One issue might be how a specific architecture > lays out a structure in memory. We reply on the compiler to generate the > correct layout for on disk structures. For example, if you run > # gdb modules/xfs.o > you can do things like > (gdb) print sizeof(xfs_sb_t) > $1 = 200 > This and other on disk structures need to come out the same size on > the ppc for things to work. this one is the same for x86 and ppc - can you just write down the names of some other structures of interest - so that i may compare their sizes ? >> ok - now tried the fix for the ppc >32 shift bug and it now shifts >> correctly and thus it now also mounts fine with the original xlatesb >> with the shifts > 32 in it - so this problem is fixed now ... but >> if i try to write to the filesystem it crashes with >> >> XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904 > I do not think pagebuf tracing is going to help here (but thanks for > capturing them). > This assert is coming out of a very specific function. > indlen = (xfs_extlen_t) > xfs_bmap_worst_indlen(ip, alen); > ASSERT(indlen > 0); > Instead of just calling ASSERT here, put in an explicit check for > indlen being less than zero, if it is then print out indlen and > alen, they are both unsigned 32 bit quantities (which makes the > assert somewhat bogus). However, indlen should not be huge, it is > supposed to be the worst case calculation of the amount of disk > space to hold alen of data (worst case metadata overhead). i think you meant "greater than zero" ? - if so it's indlen 5 and alen 16 all time ... what exactly does the ASSERT do and where is it defined ? (will install lxr as the next step to be able to navigate through the code better - do you know it - if not it's really worth a look: http://lxr.linux.no/) > Adding printk calls to xfs_bmap_worst_indlen would be the next step - it > is in xfs_bmap.c. Something in this function is probably the cause, > maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing > out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too. will do that as the next step - btw. i just updated to the current cvs code and while recompiling it i noticed the following: gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-unused -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_vnodeops.o xfs_vnodeops.c xfs_vnodeops.c: In function `xfs_allocstore': xfs_vnodeops.c:5056: warning: comparison is always true due to limited range of data type gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-unused -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_rw.o xfs_rw.c xfs_rw.c: In function `xfs_build_gap_list': xfs_rw.c:662: warning: comparison is always true due to limited range of data type which i do not see on the x86 from the same source - both times its an ASSERT(count_fsb >= 0LL); any idea ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 13:17:11 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 13:17:04 -0700 Received: from Cantor.suse.de ([194.112.123.193]:16904 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 7 Aug 2000 13:16:38 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 092801E20A; Mon, 7 Aug 2000 22:16:00 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id A4D5210A034; Mon, 7 Aug 2000 22:15:55 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 9F1F52F300; Mon, 7 Aug 2000 22:15:44 +0200 (MEST) Date: Mon, 7 Aug 2000 22:15:44 +0200 From: "Andi Kleen" To: Thomas Graichen , thomas.graichen@innominate.de Cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc Message-ID: <20000807221544.A17734@gruyere.muc.suse.de> References: <200008071610.LAA21799@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from news-innominate.list.sgi.xfs@innominate.de on Mon, Aug 07, 2000 at 07:58:02PM +0000 Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Aug 07, 2000 at 07:58:02PM +0000, Thomas Graichen wrote: > Steve Lord wrote: > >> Thomas Graichen wrote: > > > In theory this should be true - it is always possible there is a glitch > > lurking out there somewhere. One issue might be how a specific architecture > > lays out a structure in memory. We reply on the compiler to generate the > > correct layout for on disk structures. For example, if you run > > > # gdb modules/xfs.o > > > you can do things like > > > (gdb) print sizeof(xfs_sb_t) > > $1 = 200 > > > This and other on disk structures need to come out the same size on > > the ppc for things to work. > > this one is the same for x86 and ppc - can you just write down the > names of some other structures of interest - so that i may compare > their sizes ? This looks like a very boring exercise. From a quick look at config/rs6000/rs6000.h and config/i386/i386.h in gcc source the structure alignment rules of PPC and i386 are the same. For types XFS will hopefully only use its own well defined types. So I would just try and only complain when it breaks. -Andi From owner-linux-xfs-announce@oss.sgi.com Mon Aug 7 13:22:10 2000 Received: by oss.sgi.com id ; Mon, 7 Aug 2000 13:22:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:19057 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 7 Aug 2000 13:21:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA04307 for ; Mon, 7 Aug 2000 13:25:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA05881; Mon, 7 Aug 2000 15:18:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA41203; Mon, 7 Aug 2000 15:18:09 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA24478; Mon, 7 Aug 2000 15:16:47 -0500 Message-Id: <200008072016.PAA24478@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: Message from Thomas Graichen of "07 Aug 2000 19:58:02 GMT." Date: Mon, 07 Aug 2000 15:16:46 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > >> Thomas Graichen wrote: > > > In theory this should be true - it is always possible there is a glitch > > lurking out there somewhere. One issue might be how a specific architecture > > lays out a structure in memory. We reply on the compiler to generate the > > correct layout for on disk structures. For example, if you run > > > # gdb modules/xfs.o > > > you can do things like > > > (gdb) print sizeof(xfs_sb_t) > > $1 = 200 > > > This and other on disk structures need to come out the same size on > > the ppc for things to work. > > this one is the same for x86 and ppc - can you just write down the > names of some other structures of interest - so that i may compare > their sizes ? Glurk! I will have to go dig around a little for that.... but since it was my idea...... > > > Instead of just calling ASSERT here, put in an explicit check for > > indlen being less than zero, if it is then print out indlen and > > alen, they are both unsigned 32 bit quantities (which makes the > > assert somewhat bogus). However, indlen should not be huge, it is > > supposed to be the worst case calculation of the amount of disk > > space to hold alen of data (worst case metadata overhead). > An ASSERT actually means ASSERT that the statement is true, so it is supposed to die if it is fault. So ASSERT(indlen > 0); means panic is indlen <= 0. The ASSERT macro is coming from: fs/xfs/pseudo-inc/sys/debug.h > i think you meant "greater than zero" ? - if so it's indlen 5 and > alen 16 all time ... what exactly does the ASSERT do and where is > it defined ? (will install lxr as the next step to be able to > navigate through the code better - do you know it - if not it's > really worth a look: http://lxr.linux.no/) 5 and 16 are good values, maybe doing the comparison of an unsigned type being > 0 is the problem here! You could just remove the assert. As for looking at the source code, we use cscope, which you can get from here: http://cscope.sourceforge.net/ Understanding XFS is pretty much impossible without a source code browser. > > > Adding printk calls to xfs_bmap_worst_indlen would be the next step - it > > is in xfs_bmap.c. Something in this function is probably the cause, > > maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing > > out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too. > > will do that as the next step - btw. i just updated to the current > cvs code and while recompiling it i noticed the following: > > gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 - fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 - Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-un used > -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL - funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_vnodeops.o x fs_vnodeops.c > xfs_vnodeops.c: In function `xfs_allocstore': > xfs_vnodeops.c:5056: warning: comparison is always true due to limited range of > data type > gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 - fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 - Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-un used > -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL - funsigned-char -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG -c -o xfs_rw.o xfs_rw. c > xfs_rw.c: In function `xfs_build_gap_list': > xfs_rw.c:662: warning: comparison is always true due to limited range of data type > > which i do not see on the x86 from the same source - both times its > an > > ASSERT(count_fsb >= 0LL); > > any idea ? Yes, these look like unsigned types being compared against 0. It may be that stricter type checking is happening on the ppc platform. Steve From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 00:56:53 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 00:56:43 -0700 Received: from hermes.mixx.net ([212.84.196.2]:28936 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 00:56:09 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B65D7F899 for ; Tue, 8 Aug 2000 09:55:25 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 129762CA6D; Tue, 8 Aug 2000 09:55:24 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: SGI XFS on ppc Date: 8 Aug 2000 07:55:24 GMT Organization: innominate AG, Berlin, Germany Lines: 22 Distribution: local Message-ID: References: <200008071610.LAA21799@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965721324 3631 10.0.0.69 (8 Aug 2000 07:55:24 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > indlen being less than zero, if it is then print out indlen and > alen, they are both unsigned 32 bit quantities (which makes the > assert somewhat bogus). However, indlen should not be huge, it is > supposed to be the worst case calculation of the amount of disk > space to hold alen of data (worst case metadata overhead). > Adding printk calls to xfs_bmap_worst_indlen would be the next step - it > is in xfs_bmap.c. Something in this function is probably the cause, > maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing > out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too. i think we can ignore this now that we know that indlen is ok (right ?) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 01:53:03 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 01:52:53 -0700 Received: from hermes.mixx.net ([212.84.196.2]:59145 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 01:52:12 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id BE6F2F8BC for ; Tue, 8 Aug 2000 10:51:40 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id 94DF32CA6D; Tue, 8 Aug 2000 10:51:40 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id KAA02918; Tue, 8 Aug 2000 10:53:00 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Tue, 8 Aug 2000 10:53:00 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: <200008072016.PAA24478@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 7 Aug 2000, Steve Lord wrote: > An ASSERT actually means ASSERT that the statement is true, so it is > supposed to die if it is fault. So > ASSERT(indlen > 0); > > means panic is indlen <= 0. > > The ASSERT macro is coming from: > > fs/xfs/pseudo-inc/sys/debug.h > > > i think you meant "greater than zero" ? - if so it's indlen 5 and > > alen 16 all time ... what exactly does the ASSERT do and where is > > it defined ? (will install lxr as the next step to be able to > > navigate through the code better - do you know it - if not it's > > really worth a look: http://lxr.linux.no/) > > 5 and 16 are good values, maybe doing the comparison of an unsigned > type being > 0 is the problem here! You could just remove the assert. done - ok i looked a bit further now - i mounted the filesystem can read the XFS file fine - can copy it to another file called test for instance and also this contains what it should - i can create an directory - works fine too - but if i copy for instance /etc recursively into the xfs filesystem then i get after a few files (about a dozen) ASSERT(xfs_dir_ino_validate(mp, INT_GET(dep->inumber, ARCH_CONVERT)) == 0); from within xfs_dir2_data_check in xfs_dir2_data.c and the xfs_dir_ino_validate from xfs_dir_leaf.c says Invalid inode number 0x0 before - any idea where to search further - there this inodenumber of zero might come from ? - maybe as a sidenote: the etc dir is then not visible by ls (so there's definitely something broken :-) would it be of any help for you if i would send you an dd of the filesystem (32mb, zeroed before, mkfs_xfs'ed and containing only one testfile and then the copied /etc) to have a look at ? > As for looking at the source code, we use cscope, which you can get from > here: > > http://cscope.sourceforge.net/ > > Understanding XFS is pretty much impossible without a source code browser. ah - thanks i'll have a look at it > > xfs_rw.c: In function `xfs_build_gap_list': > > xfs_rw.c:662: warning: comparison is always true due to limited > > range of data type > > > > which i do not see on the x86 from the same source - both times its > > an > > > > ASSERT(count_fsb >= 0LL); > > > > any idea ? > > Yes, these look like unsigned types being compared against 0. It may > be that stricter type checking is happening on the ppc platform. maybe it's the difference egcs (x86 redhat) - gcc 2.95.2 (ppc) - but so far these asserts are ueseless then (?) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 01:56:33 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 01:56:23 -0700 Received: from hermes.mixx.net ([212.84.196.2]:64265 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 01:55:56 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 32CC6F8BC; Tue, 8 Aug 2000 10:55:25 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id E5D6D2CA6D; Tue, 8 Aug 2000 10:55:24 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id KAA02926; Tue, 8 Aug 2000 10:56:45 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Tue, 8 Aug 2000 10:56:44 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: ak@suse.de Cc: linux-xfs@oss.sgi.com Subject: Re: SGI XFS on ppc In-Reply-To: <20000807221544.A17734@gruyere.muc.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 7 Aug 2000, Andi Kleen wrote: > On Mon, Aug 07, 2000 at 07:58:02PM +0000, Thomas Graichen wrote: > > Steve Lord wrote: > > >> Thomas Graichen wrote: > > > > > In theory this should be true - it is always possible there is a glitch > > > lurking out there somewhere. One issue might be how a specific architecture > > > lays out a structure in memory. We reply on the compiler to generate the > > > correct layout for on disk structures. For example, if you run > > > > > # gdb modules/xfs.o > > > > > you can do things like > > > > > (gdb) print sizeof(xfs_sb_t) > > > $1 = 200 > > > > > This and other on disk structures need to come out the same size on > > > the ppc for things to work. > > > > this one is the same for x86 and ppc - can you just write down the > > names of some other structures of interest - so that i may compare > > their sizes ? > > This looks like a very boring exercise. From a quick look at > config/rs6000/rs6000.h and config/i386/i386.h in gcc source the structure > alignment rules of PPC and i386 are the same. For types XFS will hopefully > only use its own well defined types. So I would just try and only > complain when it breaks. > yes - maybe you are right - but something is broken on the ppc and i am not shure that there are even compiler or other kernel bugs like the "kernel can't shift > 32" thing around ... but maybe this is something to try later ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 02:39:33 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 02:39:24 -0700 Received: from hermes.mixx.net ([212.84.196.2]:2571 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 02:38:59 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id ACCD2F8C2 for ; Tue, 8 Aug 2000 11:38:27 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 7D9D62CA6D; Tue, 8 Aug 2000 11:38:27 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: linux XFS FAQ available Date: 8 Aug 2000 09:38:27 GMT Organization: innominate AG, Berlin, Germany Lines: 13 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965727507 3631 10.0.0.69 (8 Aug 2000 09:38:27 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i have written down the beginning of an linux XFS FAQ at http://innominate.org/~graichen/projects/xfs/FAQ please mail me any comments and addtions t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 07:42:34 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 07:42:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43051 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 07:41:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA06733 for ; Tue, 8 Aug 2000 07:33:37 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA61392; Tue, 8 Aug 2000 09:39:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA40365; Tue, 8 Aug 2000 09:39:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA04805; Tue, 8 Aug 2000 09:38:13 -0500 Message-Id: <200008081438.JAA04805@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: linux XFS FAQ available In-Reply-To: Message from Thomas Graichen of "08 Aug 2000 09:38:27 GMT." Date: Tue, 08 Aug 2000 09:38:13 -0500 From: Steve Lord Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > i have written down the beginning of an linux XFS FAQ at > > http://innominate.org/~graichen/projects/xfs/FAQ > > please mail me any comments and addtions > Cool, here are a couple of things which jump out straight away. On building the kernel, the xfs configuration options are marked experimental, so you need to turn on experimental build options. On building the commands, you can run ./Makepkgs verbose in the cmd/xfs directory to build source and binary RPM packages of the commands (this needs to be run as root). >> Q: How do i use XFS ? >> Just reboot the new build kernel and create a filesytem on an empty >> partition >> >> mkfs_xfs /dev/foo If you install the commands via a make install in the command tree then mkfs_xfs is installed as mkfs.xfs which means you can also use mkfs -t xfs /dev/foo there are also man pages, see mkfs.xfs for lots of mkfs options, e.g. mkfs -t xfs -l size=16000b /dev/foo changes the default size of the on disk log. >> >> where /dev/foo is the the partition you want to use (you may have to >> use the -f option of mkfs_xfs if this partition already con- tains an >> old filesystem which you want to overwrite). Now you can mount the >> filesystem using: >> >> mount -t xfs /dev/foo /somewhere There are also lots of mount options, looks like we do not install a man page for these right now, I will get one added. From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 07:50:05 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 07:49:54 -0700 Received: from hermes.mixx.net ([212.84.196.2]:29190 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 07:49:37 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id DF378F80D for ; Tue, 8 Aug 2000 16:49:05 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BC06A2CA6D; Tue, 8 Aug 2000 16:49:05 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: linux XFS FAQ available Date: 8 Aug 2000 14:49:05 GMT Organization: innominate AG, Berlin, Germany Lines: 58 Distribution: local Message-ID: References: <200008081438.JAA04805@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965746145 14359 10.0.0.69 (8 Aug 2000 14:49:05 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Cool, here are a couple of things which jump out straight away. > On building the kernel, the xfs configuration options are marked > experimental, so you need to turn on experimental build options. added > On building the commands, you can run > ./Makepkgs verbose > in the cmd/xfs directory to build source and binary RPM packages of the > commands (this needs to be run as root). added >>> Q: How do i use XFS ? >>> Just reboot the new build kernel and create a filesytem on an empty >>> partition >>> >>> mkfs_xfs /dev/foo > If you install the commands via a make install in the command tree then > mkfs_xfs is installed as mkfs.xfs which means you can also use > mkfs -t xfs /dev/foo added > there are also man pages, see mkfs.xfs for lots of mkfs options, e.g. > mkfs -t xfs -l size=16000b /dev/foo > changes the default size of the on disk log. added >>> where /dev/foo is the the partition you want to use (you may have to >>> use the -f option of mkfs_xfs if this partition already con- tains an >>> old filesystem which you want to overwrite). Now you can mount the >>> filesystem using: >>> >>> mount -t xfs /dev/foo /somewhere > There are also lots of mount options, looks like we do not install a man > page for these right now, I will get one added. tell me whenever you have something ready so that i can add it t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 09:13:35 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 09:13:25 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4361 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 09:12:52 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 3C93CF80C for ; Tue, 8 Aug 2000 18:12:20 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 219782CA78; Tue, 8 Aug 2000 18:12:20 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: linux XFS FAQ available Date: 8 Aug 2000 16:12:20 GMT Organization: innominate AG, Berlin, Germany Lines: 18 Distribution: local Message-ID: References: <200008081438.JAA04805@jen.americas.sgi.com> <20000808165441.A3188@gruyere.muc.suse.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965751140 14359 10.0.0.69 (8 Aug 2000 16:12:20 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Andi Kleen" wrote: > On Tue, Aug 08, 2000 at 02:49:05PM +0000, Thomas Graichen wrote: >> > page for these right now, I will get one added. >> >> tell me whenever you have something ready so that i can add it > You could add that it doesn't work over the loopback device ATM. ATM = at the moment ? - i hope yes - so i added it ... btw. why it does not work ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 16:11:28 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 16:11:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20309 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 16:09:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA24246 for ; Tue, 8 Aug 2000 16:01:19 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA11200 for ; Tue, 8 Aug 2000 18:07:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id SAA21811 for ; Tue, 8 Aug 2000 18:07:37 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id SAA28646; Tue, 8 Aug 2000 18:06:03 -0500 Message-Id: <200008082306.SAA28646@jen.americas.sgi.com> Date: Tue, 8 Aug 2000 18:06:03 -0500 Subject: TAKE - small speedup found in code read To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Aug 8 16:04:22 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71635a linux/mm/filemap.c - 1.52 - Use a cheaper call to initialize page validity for pagebuf use. From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 17:56:08 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 17:55:58 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48644 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 17:55:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA05000 for ; Tue, 8 Aug 2000 16:54:07 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08695; Wed, 9 Aug 2000 09:46:49 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA03693; Wed, 9 Aug 2000 09:46:47 +1000 (EST) From: "Nathan Scott" Message-Id: <10008090946.ZM3773@wobbly.melbourne.sgi.com> Date: Wed, 9 Aug 2000 09:46:46 -0500 In-Reply-To: Thomas Graichen "Re: linux XFS FAQ available" (Aug 9, 12:54am) References: <200008081438.JAA04805@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de Subject: Re: linux XFS FAQ available Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Aug 9, 12:54am, Thomas Graichen wrote: > Subject: Re: linux XFS FAQ available > Steve Lord wrote: > > > > On building the commands, you can run > > > > ./Makepkgs verbose > > > > in the cmd/xfs directory to build source and binary RPM packages of the > > commands (this needs to be run as root). > > added > Not sure why you say this, Steve? - AFAIK there's nothing in the cmd/xfs package build which needs to be run as root. I build the packages as myself all the time (actually, I've never even tried it as root). To install to '/' (i.e. typing "make install"), obviously you need to be root, but not to build the packages (although this does a "make install" also, it doesn't install to '/'). cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 21:03:50 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 21:03:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:36631 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 21:03:03 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA25103 for ; Tue, 8 Aug 2000 20:54:57 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10246 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 9 Aug 2000 14:00:00 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA55311 for linux-xfs@oss.sgi.com; Wed, 9 Aug 2000 13:59:59 +1000 (EST) Date: Wed, 9 Aug 2000 13:59:59 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008090359.NAA55311@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ioctls Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing - add XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS - remove some old stuff - add a test program for these ioctls - fix up XFS_IOC_*HANDLE Modid: 2.4.0-test1-xfs:slinx:71658a Date: Tue Aug 8 20:57:49 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/xfs_fsops.h - 1.2 - remove cruft cmd/xfs/stress/src/Makefile - 1.10 - add ioctl linux/fs/xfs/linux/xfs_ioctl.c - 1.14 - implement XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS fix up handling of XFS_IOC_*HANDLE linux/fs/xfs/xfs_fsops.c - 1.54 - export XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS through ioctl linux/fs/xfs/xfs_fsops.h - 1.15 - remove cruft linux/include/linux/xfs_fs.h - 1.10 - add XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS cmd/xfs/stress/src/ioctl.c - 1.1 - test program for some ioctls From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 21:22:50 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 21:22:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5146 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 21:22:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA26507 for ; Tue, 8 Aug 2000 21:14:12 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10380 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 9 Aug 2000 14:20:29 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id OAA88887 for ; Wed, 9 Aug 2000 14:20:28 +1000 (EST) Message-Id: <200008090420.OAA88887@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: inode/vnode/xfs_inode locking Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Aug 2000 14:20:27 +1000 From: Daniel Moore Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm a bit puzzled about what locking needs to be done when handling inodes, vnodes and xfs_inodes. struct vnode (vnode_t) is a hangover from IRIX, right? And the both it and the xfs_inode_t are stored in the linux struct inode, right? As far as I can see, if I want to access stuff within an inode, a vnode or an xfs_inode, I must hold the inode lock (use iget, iput, igrab). Is that the case? Here's an example (my new code in xfs_ioctl.c simplified for the example): struct nameidata nd; path_init(path, 0, &nd); path_walk(path, &nd); vp = LINVFS_GET_VP(nd.dentry->d_inode); path_release(&nd); The inode in question is held by the dentry in nd, so it's ok to extract the vnode pointer with LINVFS_GET_VP. But when I release the nameidata structure, the dentry is freed, and therefore I'm expecting vp is unlocked. Is there any way to grab the inode before calling path_release or do I just have to defer doing the path_release until after I'm done with the inode, xfs_inode & vnode? I've got almost exactly the same problem when I use fget to return a file from a fd and I want to hold onto the associated inode, vnode etc. Any clarification would be most welcome... Ta ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 21:40:50 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 21:40:40 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24078 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 21:40:07 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id VAA06037 for ; Tue, 8 Aug 2000 21:45:37 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10457; Wed, 9 Aug 2000 14:38:18 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA06646; Wed, 9 Aug 2000 14:38:17 +1000 (EST) From: "Nathan Scott" Message-Id: <10008091438.ZM6127@wobbly.melbourne.sgi.com> Date: Wed, 9 Aug 2000 14:38:16 -0500 In-Reply-To: Thomas Graichen "Re: linux XFS FAQ available" (Aug 9, 12:54am) References: <200008081438.JAA04805@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de Subject: Re: linux XFS FAQ available Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Thomas, On Aug 9, 12:54am, Thomas Graichen wrote: > Subject: Re: linux XFS FAQ available > ... > >>> Q: How do i use XFS ? > >>> Just reboot the new build kernel and create a filesytem on an empty > >>> partition > >>> > >>> mkfs_xfs /dev/foo > > > If you install the commands via a make install in the command tree then > > mkfs_xfs is installed as mkfs.xfs which means you can also use > > > mkfs -t xfs /dev/foo > > added > When I check in my mkfs changes (unless someone protests) I was planning to change the cmd/xfs/mkfs/Makefile such that mkfs.xfs is the only binary anywhere (i.e. there'll no longer be a "mkfs_xfs") - hopefully this will prevent any confusion, man page and other documentation discrepencies, etc. cheers. -- Nathan From owner-linux-xfs-announce@oss.sgi.com Tue Aug 8 22:18:11 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 22:18:00 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:20484 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 22:17:32 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e795GxC50909; Wed, 9 Aug 2000 00:16:59 -0500 (CDT) Message-ID: <3990E94A.CFE8ACBC@thebarn.com> Date: Wed, 09 Aug 2000 00:16:59 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Moore CC: linux-xfs@oss.sgi.com Subject: Re: inode/vnode/xfs_inode locking References: <200008090420.OAA88887@clouds.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs-announce@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > I'm a bit puzzled about what locking needs to be done when > handling inodes, vnodes and xfs_inodes. > > struct vnode (vnode_t) is a hangover from IRIX, right? And > the both it and the xfs_inode_t are stored in the linux > struct inode, right? > > As far as I can see, if I want to access stuff within an > inode, a vnode or an xfs_inode, I must hold the inode lock > (use iget, iput, igrab). > > Is that the case? It really depends upon what your are modifying? The XFS code it self uses the vnode portion of the now linux "supers structure" inode. xfs_inode modifications are protected by xfs_ilock, xfs_iunlock. Similarly there are locks on the linux inode, dentry and a global dcache lock. > > > Here's an example (my new code in xfs_ioctl.c simplified for the > example): > > struct nameidata nd; > > path_init(path, 0, &nd); > path_walk(path, &nd); > vp = LINVFS_GET_VP(nd.dentry->d_inode); > path_release(&nd); Ok I'm really not sure what you need to do here but just because you have an dentry doesn't necessarily mean you have all the data structures under it, that all has to be set up. In fact a dentry may simply have the the cached inode number, which could then be passed to read_inode, which would then proceed to set everything up. Look at the linvfs_*_inode routines in xfs_super.c > > > The inode in question is held by the dentry in nd, so it's > ok to extract the vnode pointer with LINVFS_GET_VP. But when > I release the nameidata structure, the dentry is freed, and > therefore I'm expecting vp is unlocked. > > Is there any way to grab the inode before calling path_release > or do I just have to defer doing the path_release until after > I'm done with the inode, xfs_inode & vnode? > > > I've got almost exactly the same problem when I use fget to > return a file from a fd and I want to hold onto the associated > inode, vnode etc. > > Any clarification would be most welcome... > > Ta > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:00:50 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:00:40 -0700 Received: from hermes.mixx.net ([212.84.196.2]:47881 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 23:00:29 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 105D9F822 for ; Wed, 9 Aug 2000 08:00:22 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 30B502CA8E; Wed, 9 Aug 2000 08:00:21 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: linux XFS FAQ available Date: 9 Aug 2000 06:00:21 GMT Organization: innominate AG, Berlin, Germany Lines: 18 Distribution: local Message-ID: References: <200008081438.JAA04805@jen.americas.sgi.com> <10008091438.ZM6127@wobbly.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965800821 9879 10.0.0.69 (9 Aug 2000 06:00:21 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Nathan Scott" wrote: > When I check in my mkfs changes (unless someone protests) > I was planning to change the cmd/xfs/mkfs/Makefile such > that mkfs.xfs is the only binary anywhere (i.e. there'll no > longer be a "mkfs_xfs") - hopefully this will prevent any > confusion, man page and other documentation discrepencies, > etc. added t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:04:10 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:04:01 -0700 Received: from hermes.mixx.net ([212.84.196.2]:53769 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 23:03:58 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CE7C1F822 for ; Wed, 9 Aug 2000 08:03:56 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B401B2CA8C; Wed, 9 Aug 2000 08:03:56 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: XFS and sw RAID ? Date: 9 Aug 2000 06:03:56 GMT Organization: innominate AG, Berlin, Germany Lines: 12 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965801036 9879 10.0.0.69 (9 Aug 2000 06:03:56 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just for the FAQ: did anyone try to run XFS ontop of the linux md sw raid driver ? (i ask because all the other journaled fs's have problems with that due to buffer cache locking issues i think - does this count for XFS too ?) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:17:20 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:17:11 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:29956 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 23:16:48 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e796GjC51246; Wed, 9 Aug 2000 01:16:46 -0500 (CDT) Message-ID: <3990F74D.AEFDC8C1@thebarn.com> Date: Wed, 09 Aug 2000 01:16:45 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: XFS and sw RAID ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > just for the FAQ: did anyone try to run XFS ontop of the linux md > sw raid driver ? (i ask because all the other journaled fs's have > problems with that due to buffer cache locking issues i think - > does this count for XFS too ?) > Well since md is the only lvm to support software raid at this point, and it hasn't been ported up to 2.4 yet. I would guess the answer to that one will have to be a simple NO. :-) I'm sure when we get to it, there will be a new set challenges. > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:19:00 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:18:50 -0700 Received: from hermes.mixx.net ([212.84.196.2]:13834 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 23:18:46 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A7595F802 for ; Wed, 9 Aug 2000 08:18:44 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 4E1722CA8C; Wed, 9 Aug 2000 08:18:44 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: XFS and NFS ? Date: 9 Aug 2000 06:18:44 GMT Organization: innominate AG, Berlin, Germany Lines: 13 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965801924 9879 10.0.0.69 (9 Aug 2000 06:18:44 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing even one more thing for the FAQ: are there any problems to expect then running NFS on top of XFS (like the problems reiserfs has to get the 32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried it in detail ? (i tried it lightly and had no problems - but my tests were not very deep) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:25:01 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:24:51 -0700 Received: from hermes.mixx.net ([212.84.196.2]:19978 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 23:24:41 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 311DDF802; Wed, 9 Aug 2000 08:24:39 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id CEBAD2CA8C; Wed, 9 Aug 2000 08:24:38 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id IAA04384; Wed, 9 Aug 2000 08:26:00 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Wed, 9 Aug 2000 08:26:00 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and sw RAID ? In-Reply-To: <3990F74D.AEFDC8C1@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 9 Aug 2000, Russell Cattelan wrote: > Thomas Graichen wrote: > > > just for the FAQ: did anyone try to run XFS ontop of the linux md > > sw raid driver ? (i ask because all the other journaled fs's have > > problems with that due to buffer cache locking issues i think - > > does this count for XFS too ?) > > > > Well since md is the only lvm to support software raid at this point, and > > it hasn't been ported up to 2.4 yet. > I would guess the answer to that one will have to be a simple NO. :-) > > I'm sure when we get to it, there will be a new set challenges. i'm not shure about the current state in 2.4 - but it's definitely in there ... don't know if it is working stable now i must admit t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:32:21 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:32:11 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:32516 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 23:32:01 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e796VxC51330; Wed, 9 Aug 2000 01:31:59 -0500 (CDT) Message-ID: <3990FADE.78AABFFC@thebarn.com> Date: Wed, 09 Aug 2000 01:31:58 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: thomas.graichen@innominate.de CC: linux-xfs@oss.sgi.com Subject: Re: XFS and sw RAID ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > On Wed, 9 Aug 2000, Russell Cattelan wrote: > > > Thomas Graichen wrote: > > > > > just for the FAQ: did anyone try to run XFS ontop of the linux md > > > sw raid driver ? (i ask because all the other journaled fs's have > > > problems with that due to buffer cache locking issues i think - > > > does this count for XFS too ?) > > > > > > > Well since md is the only lvm to support software raid at this point, and > > > > it hasn't been ported up to 2.4 yet. > > I would guess the answer to that one will have to be a simple NO. :-) > > > > I'm sure when we get to it, there will be a new set challenges. > > i'm not shure about the current state in 2.4 - but it's definitely > in there ... don't know if it is working stable now i must admit >From what I understand the maintainer has been "off doing other stuff" so the state is a little uncertain. It hasn't been tested and I suspect it won't work, certainly not with KIObuf io, but then again we don't have any lvm working with KIObuf io. The plan is to get XFS working with LVM first, and go from there. > > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:38:41 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:38:31 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:34052 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Aug 2000 23:38:23 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e796cKC51362; Wed, 9 Aug 2000 01:38:20 -0500 (CDT) Message-ID: <3990FC5C.DDBA6FB2@thebarn.com> Date: Wed, 09 Aug 2000 01:38:20 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: XFS and NFS ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > even one more thing for the FAQ: are there any problems to expect then > running NFS on top of XFS (like the problems reiserfs has to get the > 32bit nfsv2 handle mapped to the 64bit identifier) ? > Anyone tried > it in detail ? (i tried it lightly and had no problems - but my > tests were not very deep) NFS does work for the most part, if stressed really really hard XFS will blow up. The only why we do this at the moment it with an NFS test program. Normal use seems good. It is on our list of things to test before BETA. The 64bit problem... hmm yes we could run into that. With smaller file systems (< 2TB) things should be ok. Don't quote me on that... I'll have to look into it. > > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Aug 8 23:41:31 2000 Received: by oss.sgi.com id ; Tue, 8 Aug 2000 23:41:21 -0700 Received: from hermes.mixx.net ([212.84.196.2]:46346 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 8 Aug 2000 23:41:10 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 2FC86F802 for ; Wed, 9 Aug 2000 08:41:08 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id D615C2CA8C; Wed, 9 Aug 2000 08:41:07 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: linux XFS FAQ available Date: 9 Aug 2000 06:41:07 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: <8mokej$3hf$6@mate.bln.innominate.de> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965803267 9879 10.0.0.69 (9 Aug 2000 06:41:07 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > i have written down the beginning of an linux XFS FAQ at > http://innominate.org/~graichen/projects/xfs/FAQ > please mail me any comments and addtions i have updated it in big parts and added a lot of new stuff - please check if it is all right and mail me anything else which should go in there ... a lot of thanks in advance t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Aug 9 02:47:32 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 02:47:23 -0700 Received: from he3-2-145.cox.rr.com ([24.28.209.145]:38533 "EHLO troilus.org") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 02:47:00 -0700 Received: (from poole@localhost) by troilus.org (8.9.3/8.9.3) id FAA03050; Wed, 9 Aug 2000 05:46:37 -0400 X-Authentication-Warning: troilus.org: poole set sender to poole@troilus.org using -f To: cattelan@thebarn.com Cc: thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: XFS and sw RAID ? References: <3990FADE.78AABFFC@thebarn.com> From: Michael Poole Date: 09 Aug 2000 05:46:37 -0400 In-Reply-To: Russell Cattelan's message of "Wed, 09 Aug 2000 01:31:58 -0500" Message-ID: Lines: 41 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan writes: > Thomas Graichen wrote: > > > On Wed, 9 Aug 2000, Russell Cattelan wrote: > > > > > Thomas Graichen wrote: > > > > > > > just for the FAQ: did anyone try to run XFS ontop of the linux md > > > > sw raid driver ? (i ask because all the other journaled fs's have > > > > problems with that due to buffer cache locking issues i think - > > > > does this count for XFS too ?) > > > > > > > > > > Well since md is the only lvm to support software raid at this point, and > > > > > > it hasn't been ported up to 2.4 yet. > > > I would guess the answer to that one will have to be a simple NO. :-) > > > > > > I'm sure when we get to it, there will be a new set challenges. > > > > i'm not shure about the current state in 2.4 - but it's definitely > > in there ... don't know if it is working stable now i must admit > > From what I understand the maintainer has been "off doing other stuff" > so the state is a little uncertain. > > It hasn't been tested and I suspect it won't work, certainly not with > KIObuf io, but then again we don't have any lvm working with KIObuf io. > > The plan is to get XFS working with LVM first, and go from there. For what it's worth, I gave XFS-over-raid5 a shot a few days ago, and got a system hang (although still respondent to Magic-SysRq) a few seconds after mounting the partition. I've been running the same kernel with ext2 on that partition with no problems since then. I haven't gotten around to testing XFS on my scratch non-RAID partition yet, so I can't be sure that the breakage is specific to RAID rather than some other peculiar local issue. -- Michael From owner-linux-xfs@oss.sgi.com Wed Aug 9 05:55:13 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 05:55:03 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35876 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 05:54:38 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA09181 for ; Wed, 9 Aug 2000 06:00:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id HAA49588; Wed, 9 Aug 2000 07:52:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id HAA19621; Wed, 9 Aug 2000 07:52:45 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id HAA32510; Wed, 9 Aug 2000 07:51:06 -0500 Message-Id: <200008091251.HAA32510@jen.americas.sgi.com> To: dxm@snort.melbourne.sgi.com (Daniel Moore) cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - ioctls In-reply-to: Your message of "Wed, 09 Aug 2000 13:59:59 +1000 Date: Wed, 09 Aug 2000 07:51:05 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel, you seem to have removed some ops used by the fsr command with this mod. The geometry call was used for starters. Steve > - add XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS > - remove some old stuff > - add a test program for these ioctls > - fix up XFS_IOC_*HANDLE > > Modid: 2.4.0-test1-xfs:slinx:71658a > Date: Tue Aug 8 20:57:49 PDT 2000 > Workarea: snort:/build1/people/dxm/isms/slinx-xfs > Author: dxm > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs > > cmd/xfs/include/xfs_fsops.h - 1.2 > - remove cruft > > cmd/xfs/stress/src/Makefile - 1.10 > - add ioctl > > linux/fs/xfs/linux/xfs_ioctl.c - 1.14 > - implement XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS > fix up handling of XFS_IOC_*HANDLE > > linux/fs/xfs/xfs_fsops.c - 1.54 > - export XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS th rough > ioctl > > linux/fs/xfs/xfs_fsops.h - 1.15 > - remove cruft > > linux/include/linux/xfs_fs.h - 1.10 > - add XFS_IOC_FSCOUNTS, XFS_IOC_GET_RESBLKS & XFS_IOC_SET_RESBLKS > > cmd/xfs/stress/src/ioctl.c - 1.1 > - test program for some ioctls From owner-linux-xfs@oss.sgi.com Wed Aug 9 06:41:53 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 06:41:43 -0700 Received: from thorium.uunet.be ([194.7.1.46]:38154 "EHLO thorium.uunet.be") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 06:41:18 -0700 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by thorium.uunet.be (8.9.1/8.9.3) with SMTP id PAA22432 for ; Wed, 9 Aug 2000 15:40:10 +0200 (CEST) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id IAA28601 for ; Wed, 9 Aug 2000 08:28:07 +0200 (METDST) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id IAA06887 for ; Wed, 9 Aug 2000 08:26:51 +0200 Message-ID: <3990F9AB.1EBCA85@vum.be> Date: Wed, 09 Aug 2000 08:26:51 +0200 From: kris buggenhout X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and NFS ? Content-Type: multipart/mixed; boundary="------------6EA52D625CC115DF3247B818" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------6EA52D625CC115DF3247B818 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6EA52D625CC115DF3247B818 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3990F96B.F7143CBA@vum.be> Date: Wed, 09 Aug 2000 08:25:47 +0200 From: kris buggenhout X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen Subject: Re: XFS and NFS ? References: Content-Type: multipart/alternative; boundary="------------85368251CA2FEC40A6B584E2" --------------85368251CA2FEC40A6B584E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Graichen wrote: > even one more thing for the FAQ: are there any problems to expect then > running NFS on top of XFS (like the problems reiserfs has to get the > 32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried > it in detail ? (i tried it lightly and had no problems - but my > tests were not very deep) > If its anything like the IRIX version, XFS will cope until the number of entry's in a directory exceeds a certain number IRIX has the ability to map it in the nfs code (i think) when U export and are going te expect trouble, U export it with the option 32bitclients I dont know how it relates to the linux version ... with reiserfs it will always try to use a 64bit number ... which confuses the nfs ... --------------85368251CA2FEC40A6B584E2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Graichen wrote:

even one more thing for the FAQ: are there any problems to expect then
running NFS on top of XFS (like the problems reiserfs has to get the
32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried
it in detail ? (i tried it lightly and had no problems - but my
tests were not very deep)
 
If its anything like the IRIX version,
XFS will cope until the number of entry's in a directory exceeds a certain number

IRIX has the ability to map it in the nfs code (i think) when U export and are going te expect trouble, U export it with the option 32bitclients
I dont know how it relates to the linux version ...

with reiserfs it will always try to use a 64bit number ... which confuses the nfs ...
  --------------85368251CA2FEC40A6B584E2-- --------------6EA52D625CC115DF3247B818-- From owner-linux-xfs@oss.sgi.com Wed Aug 9 06:58:03 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 06:57:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19314 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 06:57:26 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA09318 for ; Wed, 9 Aug 2000 06:49:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA86068; Wed, 9 Aug 2000 08:55:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA45671; Wed, 9 Aug 2000 08:55:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA01388; Wed, 9 Aug 2000 08:53:58 -0500 Message-Id: <200008091353.IAA01388@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: kris buggenhout cc: linux-xfs@oss.sgi.com Subject: Re: XFS and NFS ? In-Reply-To: Message from kris buggenhout of "Wed, 09 Aug 2000 08:26:51 +0200." <3990F9AB.1EBCA85@vum.be> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Wed, 09 Aug 2000 08:53:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Kris Buggenhout wrote: >> Thomas Graichen wrote: = >> even one more thing for the FAQ: are there any problems to expect th= en = >> running NFS on top of XFS (like the problems reiserfs has to get the= = >> 32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried = >> it in detail ? (i tried it lightly and had no problems - but my = >> tests were not very deep) = >>=A0 >> If its anything like the IRIX version, = >> XFS=A0will cope until the number of entry's in a directory exceeds a c= ertain >> number IRIX has the ability to map it in the nfs code (i think) when U= export >> and are going te expect trouble, U export it with the option 32bitclie= nts = >> I dont know how it relates to the linux version ... >> with reiserfs it will always try to use a 64bit number ... >> which confuses the nfs ... = There are two separate issues here: 1. XFS inode numbers are actually 64 bit - and the linux inode number is = 32 = bits, this only becomes an issue when the filesystem size exceeds 2 Tbytes, = which = is when the top 32 bits of the inode number starts getting used (the numb= er is really a disk address) This is a general problem in Linux - only the bottom half of the inode= = number is visible above the VFS. Since NFS just encodes the inode number into= its file handle, and is the only caller of iget above the vfs level, it wi= ll = break once this size boundary is crossed. Reiserfs has similar issues in thi= s = area. An ideal solution from our point of view would be to move the file han= dle contstruction and interpretation below the VFS layer - NFS would ask t= he VFS to build a handle, and to return the inode associated with a handl= e - = this is the norm in most Unix systems I have seen. 2. Directory hash values - the original directory format in XFS returned = a = directory offset which was actually a 64 bit hash value - the NFS protocol chops= this = down to 32 bits. With this truncation there is a possibility of getdents ca= lls = starting to loop in some directories where the hash value if several entries is= the = same, skipping entries has also been seen. XFS has a newer directory format (the default on Linux) which will not= = exhibit this problem since the directory offset is now actually an offset - so unti= l a = directory gets REALLY big, 32 bits is enough. Moving a filesystem from irix which was built with the old directory f= ormat = will potentially expose this problem, filesystems built on Linux will work = - = unless you tell mkfs to use the old format. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 9 07:08:23 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 07:08:13 -0700 Received: from hawk.prod.itd.earthlink.net ([207.217.120.22]:30926 "EHLO hawk.prod.itd.earthlink.net") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 07:07:47 -0700 Received: from mickey (sdn-ar-001txhousP006.dialsprint.net [168.191.154.14]) by hawk.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id HAA06383 for ; Wed, 9 Aug 2000 07:07:16 -0700 (PDT) Reply-To: From: "Jason Holland" To: "Linux-Xfs" Subject: xfs_vnodeops.c compile problem/question Date: Wed, 9 Aug 2000 09:09:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing can anyone help me identify what this error means and possibly how to fix it?? i began to get this yesterday after doing a cvs update. btw, i'm running debian potato, the latest frozen. thanks! jason ----------- xfs_vnodeops.c: In function `xfs_allocstore': xfs_vnodeops.c:5056: warning: comparison is always true due to limited range of data type xfs_vnodeops.c: In function `xfs_free_file_space': xfs_vnodeops.c:6038: internal error--unrecognizable insn: (insn 456 455 1360 (parallel[ (set (reg:SI 0 %eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_vnodeops.c") 5927)) (set (reg:SI 1 %edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_vnodeops.c") 5927)) ] ) -1 (insn_list 453 (nil)) (nil)) cpp: output pipe has been closed make[2]: *** [xfs_vnodeops.o] Error 1 From owner-linux-xfs@oss.sgi.com Wed Aug 9 07:15:43 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 07:15:34 -0700 Received: from Cantor.suse.de ([194.112.123.193]:54278 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 9 Aug 2000 07:15:08 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 71A0D1E1AE; Wed, 9 Aug 2000 16:14:34 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 5571610A034; Wed, 9 Aug 2000 16:14:33 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id BF06D2F300; Wed, 9 Aug 2000 16:14:31 +0200 (MEST) Date: Wed, 9 Aug 2000 16:14:31 +0200 From: "Andi Kleen" To: "Jason Holland" Cc: "Linux-Xfs" Subject: Re: xfs_vnodeops.c compile problem/question Message-ID: <20000809161431.A26136@gruyere.muc.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jphollan@earthlink.net on Wed, Aug 09, 2000 at 09:09:38AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 09, 2000 at 09:09:38AM -0500, Jason Holland wrote: > can anyone help me identify what this error means and possibly how to fix > it?? i began to get this yesterday after doing a cvs update. btw, i'm > running debian potato, the latest frozen. thanks! I'm seeing the same problem. But you should not be using gcc 2.95 with XFS anyways, because it miscompiles some long long computations. egcs 1.1 seems to be the only compiler that works reliably for XFS right now. -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 9 07:22:43 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 07:22:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38263 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 07:22:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA11925 for ; Wed, 9 Aug 2000 07:14:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA18725; Wed, 9 Aug 2000 09:20:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA51779; Wed, 9 Aug 2000 09:20:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA03505; Wed, 9 Aug 2000 09:18:47 -0500 Message-Id: <200008091418.JAA03505@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: "Jason Holland" , "Linux-Xfs" Subject: Re: xfs_vnodeops.c compile problem/question In-Reply-To: Message from "Andi Kleen" of "Wed, 09 Aug 2000 16:14:31 +0200." <20000809161431.A26136@gruyere.muc.suse.de> Date: Wed, 09 Aug 2000 09:18:46 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Wed, Aug 09, 2000 at 09:09:38AM -0500, Jason Holland wrote: > > can anyone help me identify what this error means and possibly how to fix > > it?? i began to get this yesterday after doing a cvs update. btw, i'm > > running debian potato, the latest frozen. thanks! > > I'm seeing the same problem. But you should not be using gcc 2.95 with > XFS anyways, because it miscompiles some long long computations. egcs 1.1 > seems to be the only compiler that works reliably for XFS right now. > > > -Andi Right, it is the explicit 64 bit divide calls - maybe this one has the wrong types getting passed in. If someone could do a make -k and send me all the errors I will do some type checking on the ones which broke. But as Andi points out, there was some other code which did not get compiled correctly with gcc 2.95 anyway, a shift operation somewhere I think. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 9 07:34:03 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 07:33:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31099 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 07:33:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13698 for ; Wed, 9 Aug 2000 07:25:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA47186; Wed, 9 Aug 2000 09:31:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA87555; Wed, 9 Aug 2000 09:31:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA07783; Wed, 9 Aug 2000 09:30:07 -0500 Message-Id: <200008091430.JAA07783@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: "Jason Holland" , "Linux-Xfs" Subject: Re: xfs_vnodeops.c compile problem/question In-Reply-To: Message from "Andi Kleen" of "Wed, 09 Aug 2000 16:14:31 +0200." <20000809161431.A26136@gruyere.muc.suse.de> Date: Wed, 09 Aug 2000 09:30:07 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Wed, Aug 09, 2000 at 09:09:38AM -0500, Jason Holland wrote: > > can anyone help me identify what this error means and possibly how to fix > > it?? i began to get this yesterday after doing a cvs update. btw, i'm > > running debian potato, the latest frozen. thanks! > > I'm seeing the same problem. But you should not be using gcc 2.95 with > XFS anyways, because it miscompiles some long long computations. egcs 1.1 > seems to be the only compiler that works reliably for XFS right now. > > > -Andi Can you tell me if this fixes it - it will save me a compiler install.... =========================================================================== Index: linux/fs/xfs/xfs_os_defs.h =========================================================================== --- /usr/tmp/TmpDir.7762-0/linux/fs/xfs/xfs_os_defs.h_1.10 Wed Aug 9 09:30:47 2000 +++ linux/fs/xfs/xfs_os_defs.h Wed Aug 9 09:26:49 2000 @@ -41,7 +41,7 @@ typedef __u64 xfs_off_t; typedef __u64 xfs_ino_t; /* type */ -typedef __s64 xfs_daddr_t; /* type */ +typedef __u64 xfs_daddr_t; /* type */ typedef char * xfs_caddr_t; /* ? type */ typedef off_t linux_off_t; Thanks Steve From owner-linux-xfs@oss.sgi.com Wed Aug 9 07:40:44 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 07:40:33 -0700 Received: from Cantor.suse.de ([194.112.123.193]:3081 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 9 Aug 2000 07:40:19 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 940271E1F1; Wed, 9 Aug 2000 16:39:46 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 6D87B10A034; Wed, 9 Aug 2000 16:39:45 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id D9A1E2F300; Wed, 9 Aug 2000 16:39:44 +0200 (MEST) Date: Wed, 9 Aug 2000 16:39:44 +0200 From: "Andi Kleen" To: Steve Lord Cc: "Andi Kleen" , "Jason Holland" , "Linux-Xfs" Subject: Re: xfs_vnodeops.c compile problem/question Message-ID: <20000809163944.A26859@gruyere.muc.suse.de> References: <200008091430.JAA07783@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008091430.JAA07783@jen.americas.sgi.com>; from lord@sgi.com on Wed, Aug 09, 2000 at 09:30:07AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 09, 2000 at 09:30:07AM -0500, Steve Lord wrote: > > On Wed, Aug 09, 2000 at 09:09:38AM -0500, Jason Holland wrote: > > > can anyone help me identify what this error means and possibly how to fix > > > it?? i began to get this yesterday after doing a cvs update. btw, i'm > > > running debian potato, the latest frozen. thanks! > > > > I'm seeing the same problem. But you should not be using gcc 2.95 with > > XFS anyways, because it miscompiles some long long computations. egcs 1.1 > > seems to be the only compiler that works reliably for XFS right now. > > > > > > -Andi > > > Can you tell me if this fixes it - it will save me a compiler install.... It stills breaks. This is SuSE gcc 2.95.2-17, which is about at gcc-2.95-stable from February (so a bit newer than 2.95.2 release) -Andi fs_vnodeops.c: In function `xfs_free_file_space': xfs_vnodeops.c:6038: internal error--unrecognizable insn: (insn 376 375 1198 (parallel[ (set (reg:SI 0 %eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_vnodeops.c") 5927)) (set (reg:SI 1 %edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("xfs_vnodeops.c") 5927)) ] ) -1 (insn_list 373 (nil)) (nil)) make[2]: *** [xfs_vnodeops.o] Error 1 -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 9 08:04:13 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 08:04:03 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:28677 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 08:03:39 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e79F2mC53489; Wed, 9 Aug 2000 10:02:49 -0500 (CDT) Message-ID: <39917298.AEB6FA27@thebarn.com> Date: Wed, 09 Aug 2000 10:02:48 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Steve Lord , Jason Holland , Linux-Xfs Subject: Re: xfs_vnodeops.c compile problem/question References: <200008091430.JAA07783@jen.americas.sgi.com> <20000809163944.A26859@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > On Wed, Aug 09, 2000 at 09:30:07AM -0500, Steve Lord wrote: > > > On Wed, Aug 09, 2000 at 09:09:38AM -0500, Jason Holland wrote: > > > > can anyone help me identify what this error means and possibly how to fix > > > > it?? i began to get this yesterday after doing a cvs update. btw, i'm > > > > running debian potato, the latest frozen. thanks! > > > > > > I'm seeing the same problem. But you should not be using gcc 2.95 with > > > XFS anyways, because it miscompiles some long long computations. egcs 1.1 > > > seems to be the only compiler that works reliably for XFS right now. > > > > > > > > > -Andi > > > > > > Can you tell me if this fixes it - it will save me a compiler install.... I wouldn't chase this to far, even if you get past th is you will run into the problem of disk address being incorrectly calculated. I do have a work around if anybody is really interested. Note the 2.26.x compiler has less luck trying to compile XFS. > > > It stills breaks. This is SuSE gcc 2.95.2-17, which is about at gcc-2.95-stable > from February (so a bit newer than 2.95.2 release) > > -Andi > > fs_vnodeops.c: In function `xfs_free_file_space': > xfs_vnodeops.c:6038: internal error--unrecognizable insn: > (insn 376 375 1198 (parallel[ > (set (reg:SI 0 %eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("xfs_vnodeops.c") 5927)) > (set (reg:SI 1 %edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("xfs_vnodeops.c") 5927)) > ] ) -1 (insn_list 373 (nil)) > (nil)) > make[2]: *** [xfs_vnodeops.o] Error 1 > > -Andi -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Aug 9 08:26:04 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 08:25:53 -0700 Received: from Cantor.suse.de ([194.112.123.193]:57612 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 9 Aug 2000 08:25:26 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 786EF1E201; Wed, 9 Aug 2000 17:25:22 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 50E9010A035; Wed, 9 Aug 2000 17:25:21 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id AF0782F300; Wed, 9 Aug 2000 17:25:20 +0200 (MEST) Date: Wed, 9 Aug 2000 17:25:20 +0200 From: "Andi Kleen" To: "Andi Kleen" Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs_vnodeops.c compile problem/question Message-ID: <20000809172520.A28134@gruyere.muc.suse.de> References: <200008091500.KAA09752@jen.americas.sgi.com> <20000809171957.A27797@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000809171957.A27797@gruyere.muc.suse.de>; from ak@suse.de on Wed, Aug 09, 2000 at 05:19:57PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 09, 2000 at 05:19:57PM +0200, Andi Kleen wrote: > > > > > > Damn, looks like I get to work out what these asm statements really do, any > > pointers? > > info gcc. It is documented in the RTL manual. > > It clearly breaks on the do_div inline assembly, so maybe a C version > of do_div will be a reasonable workaround. > > do_div looks wrong anyways. The asms are not volatile so may be > moved (while it assumes that variables stay in registers between asm > statements), and the > > asm("":"=a" (__low), "=d" (__high):"A" (n)); \ > > trick to force variables into specific registers looks very nasty to the > compiler. Indeed this patch makes it compile. I haven't tested if it runs correctly. Index: include/asm-i386/div64.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/asm-i386/div64.h,v retrieving revision 1.1 diff -u -r1.1 div64.h --- include/asm-i386/div64.h 1999/11/12 18:56:11 1.1 +++ include/asm-i386/div64.h 2000/08/09 15:24:32 @@ -3,7 +3,7 @@ #define do_div(n,base) ({ \ unsigned long __upper, __low, __high, __mod; \ - asm("":"=a" (__low), "=d" (__high):"A" (n)); \ + /* asm("":"=a" (__low), "=d" (__high):"A" (n)); */ \ __upper = __high; \ if (__high) { \ __upper = __high % (base); \ -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 9 09:07:33 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 09:07:24 -0700 Received: from cs.selu.edu ([147.174.59.5]:41227 "EHLO cs.selu.edu") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 09:07:03 -0700 Received: from localhost (jholland@localhost) by cs.selu.edu (8.9.3/8.9.3) with ESMTP id LAA25243 for ; Wed, 9 Aug 2000 11:06:56 -0500 Date: Wed, 9 Aug 2000 11:06:56 -0500 (CDT) From: Jason Holland To: linux-xfs@oss.sgi.com Subject: Re: xfs_vnodeops.c compile problem/question In-Reply-To: <20000809172520.A28134@gruyere.muc.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 9 Aug 2000, Andi Kleen wrote: > On Wed, Aug 09, 2000 at 05:19:57PM +0200, Andi Kleen wrote: > > > > > > > > > Damn, looks like I get to work out what these asm statements really do, any > > > pointers? > > > > info gcc. It is documented in the RTL manual. > > > > It clearly breaks on the do_div inline assembly, so maybe a C version > > of do_div will be a reasonable workaround. > > > > do_div looks wrong anyways. The asms are not volatile so may be > > moved (while it assumes that variables stay in registers between asm > > statements), and the > > > > asm("":"=a" (__low), "=d" (__high):"A" (n)); \ > > > > trick to force variables into specific registers looks very nasty to the > > compiler. > > Indeed this patch makes it compile. I haven't tested if it runs correctly. > > This compiled for me as well. Thanks... Jason From owner-linux-xfs@oss.sgi.com Wed Aug 9 09:33:44 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 09:33:34 -0700 Received: from Cantor.suse.de ([194.112.123.193]:57617 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 9 Aug 2000 09:33:11 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 3356A1E20E; Wed, 9 Aug 2000 18:33:11 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id A6E3810A034; Wed, 9 Aug 2000 18:33:09 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 2C5892F300; Wed, 9 Aug 2000 18:33:09 +0200 (MEST) Date: Wed, 9 Aug 2000 18:33:09 +0200 From: "Andi Kleen" To: "Andi Kleen" Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: xfs_vnodeops.c compile problem/question Message-ID: <20000809183309.A29873@gruyere.muc.suse.de> References: <200008091500.KAA09752@jen.americas.sgi.com> <20000809171957.A27797@gruyere.muc.suse.de> <20000809172520.A28134@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000809172520.A28134@gruyere.muc.suse.de>; from ak@suse.de on Wed, Aug 09, 2000 at 05:25:20PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 09, 2000 at 05:25:20PM +0200, Andi Kleen wrote: > > compiler. > > Indeed this patch makes it compile. I haven't tested if it runs correctly. [...] The patch was wrong of course. Here is a better patch that is not obviously incorrect, but the assembly output seems to be still wrong. I unfortunately don't have time to investigate further right now. -Andi Index: include/asm-i386/div64.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/include/asm-i386/div64.h,v retrieving revision 1.1 diff -u -r1.1 div64.h --- include/asm-i386/div64.h 1999/11/12 18:56:11 1.1 +++ include/asm-i386/div64.h 2000/08/09 16:19:42 @@ -3,13 +3,13 @@ #define do_div(n,base) ({ \ unsigned long __upper, __low, __high, __mod; \ - asm("":"=a" (__low), "=d" (__high):"A" (n)); \ + __high = n>>32; __low = (__u32)n; \ __upper = __high; \ if (__high) { \ __upper = __high % (base); \ __high = __high / (base); \ } \ - asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1" (__upper)); \ + volatile asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1" (__upper)); \ asm("":"=A" (n):"a" (__low),"d" (__high)); \ __mod; \ }) From owner-linux-xfs@oss.sgi.com Wed Aug 9 10:43:04 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 10:42:54 -0700 Received: from Cantor.suse.de ([194.112.123.193]:31238 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 9 Aug 2000 10:42:20 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 9F2131E21C; Wed, 9 Aug 2000 19:41:49 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 7CBE010A035; Wed, 9 Aug 2000 19:41:48 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 3A8E52F300; Wed, 9 Aug 2000 19:41:47 +0200 (MEST) Date: Wed, 9 Aug 2000 19:41:47 +0200 From: "Andi Kleen" To: Jason Holland Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_vnodeops.c compile problem/question Message-ID: <20000809194147.A31389@gruyere.muc.suse.de> References: <20000809172520.A28134@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jholland@cs.selu.edu on Wed, Aug 09, 2000 at 11:06:56AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 09, 2000 at 11:06:56AM -0500, Jason Holland wrote: > > This compiled for me as well. Thanks... Please do not use it. It is broken. -Andi From owner-linux-xfs@oss.sgi.com Wed Aug 9 11:06:34 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 11:06:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64318 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 11:06:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA13143 for ; Wed, 9 Aug 2000 10:57:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA16819 for ; Wed, 9 Aug 2000 13:04:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA75430 for ; Wed, 9 Aug 2000 13:04:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA18738; Wed, 9 Aug 2000 13:02:31 -0500 Message-Id: <200008091802.NAA18738@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 13:02:31 -0500 Subject: TAKE - fix data corruption problem in XFS To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This was only showing up in the kiobuf based I/O path, but was actually present in all cases. Date: Wed Aug 9 11:03:25 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-profile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71689a linux/fs/pagebuf/page_buf_io.c - 1.19 - Fix corruption problem which was visible in kiobuf path - avoid reread of a page from disk when it is actually valid in memory. From owner-linux-xfs@oss.sgi.com Wed Aug 9 11:17:34 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 11:17:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54850 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 11:16:58 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA14999 for ; Wed, 9 Aug 2000 11:08:54 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA59378 for ; Wed, 9 Aug 2000 13:15:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA66059 for ; Wed, 9 Aug 2000 13:15:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA19452; Wed, 9 Aug 2000 13:13:30 -0500 Message-Id: <200008091813.NAA19452@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 13:13:30 -0500 Subject: TAKE - add runtime configuration for pagebuf To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This adds a new /proc/sys/vm/pagebuf interface which lets you tune a number of pagebuf parameters at runtime. The format is as follows: # cat /proc/sys/vm/pagebuf 100 1500 100 128 2048 The numbers are, in order: o sleep interval for the delayed write pagebuf thread - writes out dirty metadata, value in HZ o age of delayed write metadata buffers before they are written, value in HZ o sleep interval for page cleaner thread, value in HZ o maximum cluster size of I/O for delayed allocation conversions, value in pages. o maximum delayed allocate pages allowed before page cleaner thread woken up. The default numbers need tuning. Date: Wed Aug 9 11:10:45 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71691a linux/include/linux/sysctl.h - 1.24 linux/include/linux/page_buf.h - 1.57 - Added /proc/sys/vm/pagebuf configuration interface for pagebuf linux/fs/pagebuf/page_buf.c - 1.19 - Added /proc/sys/vm/pagebuf configuration interface for pagebuf linux/fs/pagebuf/page_buf_io.c - 1.20 - Added /proc/sys/vm/pagebuf configuration interface for pagebuf From owner-linux-xfs@oss.sgi.com Wed Aug 9 11:20:24 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 11:20:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43587 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 11:19:54 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA15427 for ; Wed, 9 Aug 2000 11:11:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA93537 for ; Wed, 9 Aug 2000 13:18:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA62847 for ; Wed, 9 Aug 2000 13:18:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA19535; Wed, 9 Aug 2000 13:16:25 -0500 Message-Id: <200008091816.NAA19535@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 13:16:25 -0500 Subject: TAKE - minor type cleanup To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 9 11:17:45 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71692a linux/fs/xfs/linux/xfs_lrw.c - 1.49 - Use PAGE_BUF_DADDR_NULL instead of -1 for pbm_bn initialization. From owner-linux-xfs@oss.sgi.com Wed Aug 9 12:05:55 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 12:05:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41045 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 12:05:19 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA23827 for ; Wed, 9 Aug 2000 11:57:14 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA97098 for ; Wed, 9 Aug 2000 14:02:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA19929 for ; Wed, 9 Aug 2000 14:02:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA20887; Wed, 9 Aug 2000 14:00:34 -0500 Message-Id: <200008091900.OAA20887@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 14:00:34 -0500 Subject: TAKE - add man page for xfs mount options To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing They do not all work yet.... Date: Wed Aug 9 12:01:51 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71703a cmd/xfs/man/man4/xfs_fstab.4 - 1.1 - Add man page for xfs mount options From owner-linux-xfs@oss.sgi.com Wed Aug 9 12:06:34 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 12:06:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41033 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 12:06:13 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA02984 for ; Wed, 9 Aug 2000 12:11:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA09337 for ; Wed, 9 Aug 2000 14:04:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA12037 for ; Wed, 9 Aug 2000 14:04:25 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA20986; Wed, 9 Aug 2000 14:02:43 -0500 Message-Id: <200008091902.OAA20986@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 14:02:43 -0500 Subject: TAKE - make fsr compile again To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 9 12:04:10 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71704a cmd/xfs/fsr/syssgi.h - 1.2 - make fsr compile again. From owner-linux-xfs@oss.sgi.com Wed Aug 9 13:36:55 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 13:36:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41051 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 13:36:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08918 for ; Wed, 9 Aug 2000 13:41:46 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA03648 for ; Wed, 9 Aug 2000 15:34:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA03353 for ; Wed, 9 Aug 2000 15:34:26 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id PAA25432; Wed, 9 Aug 2000 15:32:44 -0500 Message-Id: <200008092032.PAA25432@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 15:32:44 -0500 Subject: TAKE - add a statistics interface to pagebuf To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This creates /proc/fs/pagebuf/stat - name and contents subject to change. It reports 7 different numbers out of pagebuf in this format: cat /proc/fs/pagebuf/stat pagebuf 1573261 294824 1290019 630309 294812 4462 418748 The values are: o number of pagebuf_get calls o number of pagebufs created o number of requests for a locked pagebuf which succeeded o number of non-blocking requests for a locked which failed o number of requests for a locked pagebuf which failed due to no pagebuf o number of calls to allocate a page for insertion in a pagebuf o number of hits in the page_cache when looking for a page to put in a pagebuf Date: Wed Aug 9 13:30:01 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71710a linux/include/linux/page_buf.h - 1.58 linux/fs/pagebuf/page_buf.c - 1.20 linux/fs/pagebuf/page_buf_locking.c - 1.5 - Add some simple statistics to pagebuf From owner-linux-xfs@oss.sgi.com Wed Aug 9 15:19:56 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 15:19:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:28453 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 15:19:26 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25880 for ; Wed, 9 Aug 2000 15:11:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA35528 for ; Wed, 9 Aug 2000 17:16:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA43260 for ; Wed, 9 Aug 2000 17:16:24 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id RAA00433; Wed, 9 Aug 2000 17:14:40 -0500 Message-Id: <200008092214.RAA00433@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 17:14:40 -0500 Subject: TAKE - small extension to the page buf stats interface To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Add a counter for the number of times we end up sleeping trying to get a pagebuf lock. Date: Wed Aug 9 15:15:40 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71722a linux/include/linux/page_buf.h - 1.59 - Add a new stat counter for page buf locks which have to sleep. linux/fs/pagebuf/page_buf_locking.c - 1.6 - Add a new stat counter for page buf locks which have to sleep. From owner-linux-xfs@oss.sgi.com Wed Aug 9 16:18:15 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 16:18:08 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35948 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 16:17:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01708 for ; Wed, 9 Aug 2000 16:22:59 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA72097 for ; Wed, 9 Aug 2000 18:15:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id SAA80313 for ; Wed, 9 Aug 2000 18:15:40 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id SAA01963; Wed, 9 Aug 2000 18:13:56 -0500 Message-Id: <200008092313.SAA01963@jen.americas.sgi.com> Date: Wed, 9 Aug 2000 18:13:56 -0500 Subject: TAKE - add an rqueue command to kdb To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This dumps a request queue and all of its elements Date: Wed Aug 9 16:15:00 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71730a linux/kdb/modules/kdbm_pg.c - 1.10 - Check in a request queue dumping command From owner-linux-xfs@oss.sgi.com Wed Aug 9 18:43:17 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 18:43:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4695 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 18:42:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA20197 for ; Wed, 9 Aug 2000 18:34:29 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19051; Thu, 10 Aug 2000 11:39:31 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA92311; Thu, 10 Aug 2000 11:39:30 +1000 (EST) Message-Id: <200008100139.LAA92311@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: lord@sgi.com cc: linux-xfs@oss.sgi.com Subject: do_div breakage? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Aug 2000 11:39:30 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing With t-o-t XFS etc, I can trip an assert just by copying a decent size file onto an empty XFS filesystem. Puzzlingly, this doesn't happen for Nathan, running almost exactly the same setup. The assert in question is the "indlen > 0" one mentioned recently: XFS assertion failed: indlen > 0, file: xfs_bmap.c, line: 4921 kernel BUG at xfs_debug.c:50! I've poked around a bit, and the problem appears to be with the do_div call. This debug output shows the divides being done, the expected answer and the actual answer ie 269 div 254 actually equals 1 but do_div says 12755248. It's downhill from there, as you might expect. DXM 269 / 254 = 1 DXM = 12755248 DXM 12755501 / 254 = 50218 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM xfs_bmap_worst_indlen return 12755248 DXM 269 / 254 = 1 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM 253 / 254 = 0 DXM = 0 DXM xfs_bmap_worst_indlen return 0 XFS assertion failed: indlen > 0, file: xfs_bmap.c, line: 4921 kernel BUG at xfs_debug.c:50! I was under the impression that do_div was a 64 bit thing, but in my case at least, xfs_filblks_t is _32_ bits, and I'm guessing the cause of the problems here. If I replace the call do do_div in xfs_bmap_worst_indlen with a normal divide, everything's peachy again: ... DXM 269 / 254 = 1 DXM = 1 DXM xfs_bmap_worst_indlen return 5 (1) DXM 557 / 254 = 2 DXM = 2 DXM 255 / 254 = 1 DXM = 1 DXM xfs_bmap_worst_indlen return 6 (1) ... ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Aug 9 20:00:59 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 20:00:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54626 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 20:00:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA26309 for ; Wed, 9 Aug 2000 19:52:17 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA19691 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 10 Aug 2000 12:58:34 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA66209 for linux-xfs@oss.sgi.com; Thu, 10 Aug 2000 12:58:33 +1000 (EST) Date: Thu, 10 Aug 2000 12:58:33 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008100258.MAA66209@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE remove syssgi calls from fsr_xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing in line with other user tools... Modid: 2.4.0-test1-xfs:slinx:71753a Date: Wed Aug 9 19:56:03 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/fsr/Makefile - 1.5 - remove syssgi.[ch] cmd/xfs/fsr/fsr_xfs.c - 1.7 - replace syssgi calls with small wrappers around ioctls cmd/xfs/fsr/syssgi.c - 1.2 cmd/xfs/fsr/syssgi.h - 1.3 - to be removed p_source_tree_remove: cmd/xfs/fsr/syssgi.c: Assigned modid is 2.4.0-test1-xfs:slinx:71754a cmd/xfs/fsr/syssgi.h: Assigned modid is 2.4.0-test1-xfs:slinx:71755a From owner-linux-xfs@oss.sgi.com Wed Aug 9 20:39:09 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 20:39:00 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17788 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 20:38:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA05610 for ; Wed, 9 Aug 2000 20:44:05 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20062 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 10 Aug 2000 13:36:45 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA50889 for linux-xfs@oss.sgi.com; Thu, 10 Aug 2000 13:36:44 +1000 (EST) Date: Thu, 10 Aug 2000 13:36:44 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008100336.NAA50889@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Alrighty - here's the re-worked mkfs. This should port cleanly - I'd be interested in hearing any news. I've convinced myself that exactly the same bits get written on the disk as the old version, except for inode timestamps (uhuh) and superblock UUIDs (these are now real UUIDs, rather than half-baked ones). I've checked in the previous top-of-tree version below sim/mkfs, if there's any problems at all with the new version, the old one will still be there for a little while yet (a week?). This old version is not built by default though - that'd need to be done by hand, if the need arises. cheers. Modid: 2.4.0-test1-xfs:slinx:71751a Date: Wed Aug 9 19:42:08 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/sim/maxtrres/Makefile - 1.1 cmd/xfs/sim/maxtrres/xfs_maxtrres.c - 1.1 cmd/xfs/sim/mkfs/Makefile - 1.1 cmd/xfs/sim/mkfs/nonsim.c - 1.1 cmd/xfs/sim/mkfs/xfs_mkfs.c - 1.1 cmd/xfs/sim/mkfs/xfs_mkfs.h - 1.1 - temporary copy of current maxtrres & mkfs which uses libsim. Modid: 2.4.0-test1-xfs:slinx:71756a Date: Wed Aug 9 20:12:46 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/Makefile - 1.23 - fix up LDIRT for interrupted configure. move maxtrres in with mkfs. cmd/xfs/include/libxfs.h - 1.7 - fix prototype for getsb routine. cmd/xfs/libxfs/rdwr.c - 1.7 - fix up getsb routine. cmd/xfs/mkfs/Makefile - 1.41 - link with Linux uuid library, no longer create mkfs_xfs, move maxtrres build in here, no longer link with libsim, add some new files. cmd/xfs/mkfs/xfs_mkfs.c - 1.169 - no longer links with libsim, uses libxfs instead. split prototype stuff out into a separate file to assist in debugging & cos its a nice modular piece, fix compile warnings under fullwarn, no longer mess with _KERNEL and __KERNEL__. ensure xfs_alloc_args structure is, uh, actually initialised before using its fields (esp. minalignslop!). cmd/xfs/mkfs/xfs_mkfs.h - 1.16 - fix up function prototypes for exported routines. cmd/xfs/mkfs/linux_fs.h - 1.1 - move over from libsim - mkfs is the only user. cmd/xfs/mkfs/maxtrres.c - 1.1 - fix a minor mem leak, move from ../maxtrres as mkfs is the only user (and we don't have the IRIX "buildtools" concept in Linux). cmd/xfs/mkfs/mountinfo.c - 1.1 cmd/xfs/mkfs/mountinfo.h - 1.1 - move over from libsim - mkfs is the only user. cmd/xfs/mkfs/proto.c - 1.1 cmd/xfs/mkfs/proto.h - 1.1 - abstract prototype routines from xfs_mkfs.c, convert to libxfs. cmd/xfs/mkfs/volume.h - 1.1 - move over from libsim - mkfs is the only user. cmd/xfs/stress/src/devzero.c - 1.1 - simple test program to initialise a device to a known state (e.g. all zeroes or all -1's). might be useful to others - was very useful when converting mkfs from libsim over to libxfs. From owner-linux-xfs@oss.sgi.com Wed Aug 9 21:51:30 2000 Received: by oss.sgi.com id ; Wed, 9 Aug 2000 21:51:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39536 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 9 Aug 2000 21:50:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA03597 for ; Wed, 9 Aug 2000 21:42:46 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20505 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 10 Aug 2000 14:49:03 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA17170 for linux-xfs@oss.sgi.com; Thu, 10 Aug 2000 14:49:01 +1000 (EST) Date: Thu, 10 Aug 2000 14:49:01 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008100449.OAA17170@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fsr use XFS_IOC_FSCOUNTS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71763a Date: Wed Aug 9 21:48:51 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/fsr/fsr_xfs.c - 1.8 - use new XFS_IOC_FSCOUNTS call From owner-linux-xfs@oss.sgi.com Thu Aug 10 08:01:45 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 08:01:28 -0700 Received: from hermes.mixx.net ([212.84.196.2]:6924 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 10 Aug 2000 08:00:55 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id C0031F807 for ; Thu, 10 Aug 2000 17:00:19 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B5E202CA71; Thu, 10 Aug 2000 16:59:48 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: TAKE - add runtime configuration for pagebuf Date: 10 Aug 2000 14:59:48 GMT Organization: innominate AG, Berlin, Germany Lines: 37 Distribution: local Message-ID: References: <200008091813.NAA19452@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965919588 4618 10.0.0.69 (10 Aug 2000 14:59:48 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > This adds a new /proc/sys/vm/pagebuf interface which lets you > tune a number of pagebuf parameters at runtime. The format is > as follows: > # cat /proc/sys/vm/pagebuf > 100 1500 100 128 2048 > The numbers are, in order: > o sleep interval for the delayed write pagebuf thread - writes out > dirty metadata, value in HZ > o age of delayed write metadata buffers before they are written, > value in HZ > o sleep interval for page cleaner thread, value in HZ > o maximum cluster size of I/O for delayed allocation conversions, > value in pages. > o maximum delayed allocate pages allowed before page cleaner thread > woken up. are those parameters (and all the other stuff behind /proc/fs/xfs) anywhere documented ? - if not it would be a good idea to leave at least a basic documentation of then in linux/Documentation/sysctl/ just an idea t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 10 08:35:36 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 08:35:26 -0700 Received: from hermes.mixx.net ([212.84.196.2]:8717 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 10 Aug 2000 08:35:11 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CB239F809; Thu, 10 Aug 2000 17:24:52 +0200 (CEST) Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69]) by mate.bln.innominate.de (Postfix) with ESMTP id 676602CA6F; Thu, 10 Aug 2000 17:24:22 +0200 (CEST) Received: from localhost (graichen@localhost) by h2o.bln.innominate.de (8.9.3/8.9.3) with ESMTP id RAA05926; Thu, 10 Aug 2000 17:25:46 +0200 X-Authentication-Warning: h2o.bln.innominate.de: graichen owned process doing -bs Date: Thu, 10 Aug 2000 17:25:45 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@h2o.bln.innominate.de Reply-To: thomas.graichen@innominate.de To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - add runtime configuration for pagebuf In-Reply-To: <200008101513.KAA10725@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 10 Aug 2000, Steve Lord wrote: > > Steve Lord wrote: > > > This adds a new /proc/sys/vm/pagebuf interface which lets you > > > tune a number of pagebuf parameters at runtime. The format is > > > as follows: > > > > > # cat /proc/sys/vm/pagebuf > > > 100 1500 100 128 2048 > > > > > The numbers are, in order: > > > > > o sleep interval for the delayed write pagebuf thread - writes out > > > dirty metadata, value in HZ > > > > > o age of delayed write metadata buffers before they are written, > > > value in HZ > > > > > o sleep interval for page cleaner thread, value in HZ > > > > > o maximum cluster size of I/O for delayed allocation conversions, > > > value in pages. > > > > > o maximum delayed allocate pages allowed before page cleaner thread > > > woken up. > > > > are those parameters (and all the other stuff behind /proc/fs/xfs) > > anywhere documented ? - if not it would be a good idea to leave at > > least a basic documentation of then in linux/Documentation/sysctl/ > > > > just an idea > > You are correct, there needs to be some documentation to go with this, > I am going to be changing how the sysctl interface is presented to be > a one parameter per file interface in /proc. > that is much better - combined with good names > We have a perl script which interprets the xfs statistics, that should > go into the tree, also the pcp package understands them: > > http://oss.sgi.com/projects/pcp/ > can you put up this script somewhere into the sources - maybe it can at least to help finding out the meanings of all the variables ... > I still need to get back to you on the power pc stuff, I'm a bit buried > at the moment. > oh yeah - i'm ready :-) - but do all that in the order you like or have to do it ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 10 08:57:35 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 08:57:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24930 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 08:56:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA24351 for ; Thu, 10 Aug 2000 08:10:37 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA12979; Thu, 10 Aug 2000 10:15:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA98294; Thu, 10 Aug 2000 10:15:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA10725; Thu, 10 Aug 2000 10:13:39 -0500 Message-Id: <200008101513.KAA10725@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - add runtime configuration for pagebuf In-Reply-To: Message from Thomas Graichen of "10 Aug 2000 14:59:48 GMT." Date: Thu, 10 Aug 2000 10:13:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > This adds a new /proc/sys/vm/pagebuf interface which lets you > > tune a number of pagebuf parameters at runtime. The format is > > as follows: > > > # cat /proc/sys/vm/pagebuf > > 100 1500 100 128 2048 > > > The numbers are, in order: > > > o sleep interval for the delayed write pagebuf thread - writes out > > dirty metadata, value in HZ > > > o age of delayed write metadata buffers before they are written, > > value in HZ > > > o sleep interval for page cleaner thread, value in HZ > > > o maximum cluster size of I/O for delayed allocation conversions, > > value in pages. > > > o maximum delayed allocate pages allowed before page cleaner thread > > woken up. > > are those parameters (and all the other stuff behind /proc/fs/xfs) > anywhere documented ? - if not it would be a good idea to leave at > least a basic documentation of then in linux/Documentation/sysctl/ > > just an idea You are correct, there needs to be some documentation to go with this, I am going to be changing how the sysctl interface is presented to be a one parameter per file interface in /proc. We have a perl script which interprets the xfs statistics, that should go into the tree, also the pcp package understands them: http://oss.sgi.com/projects/pcp/ I still need to get back to you on the power pc stuff, I'm a bit buried at the moment. Steve > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 10 10:40:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 10:40:48 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5895 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 10:40:27 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14895 for ; Thu, 10 Aug 2000 10:32:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA17952 for ; Thu, 10 Aug 2000 12:38:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA79607 for ; Thu, 10 Aug 2000 12:38:40 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id MAA27194; Thu, 10 Aug 2000 12:36:48 -0500 Message-Id: <200008101736.MAA27194@jen.americas.sgi.com> Date: Thu, 10 Aug 2000 12:36:48 -0500 Subject: TAKE - add some more output to kdb commands To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 10 10:38:07 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71798a linux/kdb/modules/kdbm_pg.c - 1.11 - Add some more useful debug output for buffer heads, pages and bmap structures From owner-linux-xfs@oss.sgi.com Thu Aug 10 10:42:28 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 10:42:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41479 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 10:41:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA15095 for ; Thu, 10 Aug 2000 10:33:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA89143 for ; Thu, 10 Aug 2000 12:39:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA76180 for ; Thu, 10 Aug 2000 12:39:51 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id MAA27264; Thu, 10 Aug 2000 12:37:59 -0500 Message-Id: <200008101737.MAA27264@jen.americas.sgi.com> Date: Thu, 10 Aug 2000 12:37:59 -0500 Subject: TAKE - add some error return traps for debugging To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 10 10:39:26 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71800a linux/fs/xfs/linux/xfs_lrw.c - 1.50 - Add some error trap returns in the read/write path From owner-linux-xfs@oss.sgi.com Thu Aug 10 10:44:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 10:44:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38664 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 10:44:22 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA15551 for ; Thu, 10 Aug 2000 10:36:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA35671 for ; Thu, 10 Aug 2000 12:42:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA30953 for ; Thu, 10 Aug 2000 12:42:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id MAA27334; Thu, 10 Aug 2000 12:40:43 -0500 Message-Id: <200008101740.MAA27334@jen.americas.sgi.com> Date: Thu, 10 Aug 2000 12:40:43 -0500 Subject: TAKE - fix a corruption under heavy load bug in pagebuf To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This could have led to disk writes going to the wrong location in a file, dbench is the only place I have seen it happen. Date: Thu Aug 10 10:41:24 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71801a linux/fs/pagebuf/page_buf_io.c - 1.21 - Fix a bug where under heavy write pressure pagebuf could assign the wrong block number to a buffer for writing to disk. From owner-linux-xfs@oss.sgi.com Thu Aug 10 10:52:28 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 10:52:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5131 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 10:52:04 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA16697 for ; Thu, 10 Aug 2000 10:44:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA79343 for ; Thu, 10 Aug 2000 12:50:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id MAA52502 for ; Thu, 10 Aug 2000 12:50:18 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id MAA29572; Thu, 10 Aug 2000 12:48:26 -0500 Message-Id: <200008101748.MAA29572@jen.americas.sgi.com> Date: Thu, 10 Aug 2000 12:48:26 -0500 Subject: TAKE - add xfsstats command to XFS user space To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing xfsstats is a perl script for interpreting the /proc based stats provided by XFS - see also pcp at http://oss.sgi.com/projects/pcp Date: Thu Aug 10 10:49:19 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71802a cmd/xfs/misc/Makefile - 1.1 - New makefile to install xfsstats cmd/xfs/misc/xfsstats - 1.1 - Added xfsstats command for dumping /proc/fs/xfs/stats cmd/xfs/Makefile - 1.24 - Add misc subdirectory and move fsck later in the list, since it needs other files installed first. cmd/xfs/fsck/Makefile - 1.3 - Do not use a relative pathname for true - it does not work for the rpm build. From owner-linux-xfs@oss.sgi.com Thu Aug 10 11:05:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 11:05:48 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31247 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 11:05:33 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA18710 for ; Thu, 10 Aug 2000 10:57:29 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA60763; Thu, 10 Aug 2000 13:03:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA33673; Thu, 10 Aug 2000 13:03:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA29619; Thu, 10 Aug 2000 13:01:51 -0500 Message-Id: <200008101801.NAA29619@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: do_div breakage? In-Reply-To: Message from Daniel Moore of "Thu, 10 Aug 2000 11:39:30 +1000." <200008100139.LAA92311@clouds.melbourne.sgi.com> Date: Thu, 10 Aug 2000 13:01:51 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It looks like you must have undefined XFS_BIG_FILES somewhere, a real fix for this issue involves making the do_div macro compile time sensitive to the variables it is dealing with - which since you cannot do sizeof at compile time means some runtime logic for a compile time change - or I wade through all the calls again changing the macros which are executing on specific types to ones with different names so we can make the compile time decision. Steve > > With t-o-t XFS etc, I can trip an assert just by copying > a decent size file onto an empty XFS filesystem. Puzzlingly, > this doesn't happen for Nathan, running almost exactly the > same setup. > > The assert in question is the "indlen > 0" one mentioned > recently: > > XFS assertion failed: indlen > 0, file: xfs_bmap.c, line: 4921 > kernel BUG at xfs_debug.c:50! > > I've poked around a bit, and the problem appears to be with the > do_div call. This debug output shows the divides being done, > the expected answer and the actual answer ie 269 div 254 actually > equals 1 but do_div says 12755248. > > It's downhill from there, as you might expect. > > DXM 269 / 254 = 1 > DXM = 12755248 > DXM 12755501 / 254 = 50218 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM xfs_bmap_worst_indlen return 12755248 > DXM 269 / 254 = 1 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM 253 / 254 = 0 > DXM = 0 > DXM xfs_bmap_worst_indlen return 0 > XFS assertion failed: indlen > 0, file: xfs_bmap.c, line: 4921 > kernel BUG at xfs_debug.c:50! > > I was under the impression that do_div was a 64 bit thing, but > in my case at least, xfs_filblks_t is _32_ bits, and I'm > guessing the cause of the problems here. > > If I replace the call do do_div in xfs_bmap_worst_indlen > with a normal divide, everything's peachy again: > > ... > DXM 269 / 254 = 1 > DXM = 1 > DXM xfs_bmap_worst_indlen return 5 (1) > DXM 557 / 254 = 2 > DXM = 2 > DXM 255 / 254 = 1 > DXM = 1 > DXM xfs_bmap_worst_indlen return 6 (1) > ... > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Aug 10 11:32:17 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 11:32:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:792 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 11:31:28 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA22637 for ; Thu, 10 Aug 2000 11:23:23 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA90819 for ; Thu, 10 Aug 2000 13:29:41 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA04490 for ; Thu, 10 Aug 2000 13:29:40 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7AITDB05178 for linux-xfs@oss.sgi.com; Thu, 10 Aug 2000 13:29:13 -0500 Date: Thu, 10 Aug 2000 13:29:13 -0500 From: Russell Cattelan Message-Id: <200008101829.e7AITDB05178@gibble.americas.sgi.com> Subject: TAKE - fsck install fix. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 10 11:29:12 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71807a cmd/xfs/fsck/Makefile - 1.4 - The problem was the lack of a destination directory not the lack of a the source file. Added command to create missing directory. From owner-linux-xfs@oss.sgi.com Thu Aug 10 16:00:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 16:00:49 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:2054 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 10 Aug 2000 16:00:29 -0700 Received: (qmail 10808 invoked from network); 10 Aug 2000 22:59:43 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Aug 2000 22:59:43 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Steve Lord cc: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: do_div breakage? In-reply-to: Your message of "Thu, 10 Aug 2000 13:01:51 EST." <200008101801.NAA29619@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 2000 08:59:42 +1000 Message-ID: <12047.965948382@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 10 Aug 2000 13:01:51 -0500, Steve Lord wrote: >It looks like you must have undefined XFS_BIG_FILES somewhere, a real >fix for this issue involves making the do_div macro compile time >sensitive to the variables it is dealing with - which since you >cannot do sizeof at compile time means some runtime logic for a >compile time change Take a look at memcpy() and __constant_memcpy() in include/asm-i386/string.h. They do the equivalent of compile time selection to pick up the correct function, the compiler discards all the unwanted code automatically. From owner-linux-xfs@oss.sgi.com Thu Aug 10 16:06:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 16:06:39 -0700 Received: from hermes.mixx.net ([212.84.196.2]:59911 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 10 Aug 2000 16:06:10 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 6A0DAF80E for ; Fri, 11 Aug 2000 00:37:01 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id A72152CA6F; Fri, 11 Aug 2000 00:37:00 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: random ppc observations ... Date: 10 Aug 2000 22:37:00 GMT Organization: innominate AG, Berlin, Germany Lines: 85 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965947020 27140 10.0.0.69 (10 Aug 2000 22:37:00 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing before i go to bed - some more observations from the ppc (all is with the current cvs tree code) first the good one: [root@aqua mkfs]# uname -a Linux aqua 2.4.0-test5 #13 Tue Aug 8 00:30:19 CEST 2000 ppc unknown [root@aqua mkfs]# ./mkfs.xfs -f /dev/hda8 meta-data=/dev/hda8 isize=256 agcount=8, agsize=65536 blks data = bsize=4096 blocks=524287, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@aqua mkfs]# mkfs.xfs now compiles and works on the ppc - good work - (will try the alpha tomorrow) - the compilation of xfs_mkfs.c gives the following: gcc -g -DDEBUG -funsigned-char -Wall -Wno-parentheses '-DVERSION="1.0.2-0"' -I../include -I../../../linux/include -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c xfs_mkfs.c -o xfs_mkfs.o xfs_mkfs.c: In function `main': xfs_mkfs.c:1663: warning: left-hand operand of comma expression has no effect xfs_mkfs.c:1663: warning: value computed is not used xfs_mkfs.c:1664: warning: left-hand operand of comma expression has no effect xfs_mkfs.c:1664: warning: value computed is not used ... now the expected one: xfs on the ppc with an mkfs.xfs created filesystem is as buggy as with my i386 image on ppc :-) and finally some experiments: root@aqua mkfs]# ./mkfs.xfs -f /dev/hda8 meta-data=/dev/hda8 isize=256 agcount=8, agsize=65536 blks data = bsize=4096 blocks=524287, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@aqua mkfs]# mount -t xfs /dev/hda8 /mnt/floppy [root@aqua mkfs]# df -k Filesystem 1k-blocks Used Available Use% Mounted on ... /dev/hda8 2092348 144 2092204 0% /mnt/floppy [root@aqua mkfs]# cd /mnt/floppy/ [root@aqua floppy]# ls [root@aqua floppy]# cp /etc/hosts . [root@aqua floppy]# ls [root@aqua floppy]# cat hosts 127.0.0.1 localhost ... [root@aqua floppy]# cp hosts test [root@aqua floppy]# ls [root@aqua floppy]# cat test 127.0.0.1 localhost ... [root@aqua floppy]# ... all the problems i see else are the same describes the last time (illegal inode number etc.) ... ok - and if i unmount the filesystem after playing with it a bit and try to remount it then it fails with Start mounting filesystem: ide0(3,8) XFS: xlog_find_verify_log_record: need to backup XFS assertion failed: 0, file: xfs_log_recover.c, line: 347 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed xfs: xfs_mountfs failed: error 5. (btw. the assertfail BUG() is commented out here) maybe this gives any hints - i will go to bed now ... will have a look at the alpha tomorrow t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 10 16:16:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 16:16:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29776 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 16:16:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA06390 for ; Thu, 10 Aug 2000 16:22:00 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27711 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 09:14:40 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA39096 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 09:14:38 +1000 (EST) Date: Fri, 11 Aug 2000 09:14:38 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008102314.JAA39096@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks Steve, external log mount works now. Modid: 2.4.0-test1-xfs:slinx:71826a Date: Thu Aug 10 16:13:31 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/mkfs/xfs_mkfs.c - 1.170 - fix external log initialization (merge Daniel's endian changes). From owner-linux-xfs@oss.sgi.com Thu Aug 10 16:23:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 16:23:48 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38000 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 16:23:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA04579 for ; Thu, 10 Aug 2000 16:15:28 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27787; Fri, 11 Aug 2000 09:20:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA10642; Fri, 11 Aug 2000 09:20:29 +1000 (EST) From: "Nathan Scott" Message-Id: <10008110920.ZM8161@wobbly.melbourne.sgi.com> Date: Fri, 11 Aug 2000 09:20:28 -0500 In-Reply-To: Thomas Graichen "random ppc observations ..." (Aug 11, 9:09am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: random ppc observations ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Thomas, On Aug 11, 9:09am, Thomas Graichen wrote: > Subject: random ppc observations ... > ... > mkfs.xfs now compiles and works on the ppc - good work - (will try > the alpha tomorrow) - the compilation of xfs_mkfs.c gives the > following: > > gcc -g -DDEBUG -funsigned-char -Wall -Wno-parentheses '-DVERSION="1.0.2-0"' -I../include -I../../../linux/include -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c xfs_mkfs.c -o xfs_mkfs.o > xfs_mkfs.c: In function `main': > xfs_mkfs.c:1663: warning: left-hand operand of comma expression has no effect > xfs_mkfs.c:1663: warning: value computed is not used > xfs_mkfs.c:1664: warning: left-hand operand of comma expression has no effect > xfs_mkfs.c:1664: warning: value computed is not used > ... > yeah, this is a result of turning -Wall on & is coming out of the xfs_arch.h macros ... I wasn't game to go and change stuff in there at the same time as checking this all in. I think Daniel said these warnings were bogus too(?). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 10 16:59:58 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 16:59:50 -0700 Received: from [204.94.214.10] ([204.94.214.10]:12919 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 16:59:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA06362 for ; Thu, 10 Aug 2000 16:31:59 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27915 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 09:38:17 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA76698 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 09:38:15 +1000 (EST) Date: Fri, 11 Aug 2000 09:38:15 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008102338.JAA76698@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unconditionally define XFS_BIG_FILES & XFS_BIG_FILESYSTEMS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes my problem with do_div, since xfs_filblks_t is now a 64 bit type. It also fixes all the warnings I was getting about incorrect types to printk. Modid: 2.4.0-test1-xfs:slinx:71832a Date: Thu Aug 10 16:35:51 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_types.h - 1.47 - unconditionally define XFS_BIG_FILES & XFS_BIG_FILESYSTEMS From owner-linux-xfs@oss.sgi.com Thu Aug 10 17:55:28 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 17:55:19 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61525 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 17:54:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA07652 for ; Thu, 10 Aug 2000 18:00:20 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28595 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 10:52:59 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA56282 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 10:52:57 +1000 (EST) Date: Fri, 11 Aug 2000 10:52:57 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008110052.KAA56282@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71851a Date: Thu Aug 10 17:46:03 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Makefile - 1.15 - fix up clean & realclean for xfs cmds. cmd/xfs/Makefile - 1.25 - add realclean target which removes configure-generated files in addition to doing a "make clean". cmd/xfs/misc/Makefile - 1.5 - minor changes to ensure xfsstats ends up in the RPM (LSRCFILES must be set for anything not in CFILES, HFILES, Makefile, etc). also move the fsck symlink creation over here - one less subdir & Makefile. From owner-linux-xfs@oss.sgi.com Thu Aug 10 21:05:40 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 21:05:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54880 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 21:04:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id VAA07251 for ; Thu, 10 Aug 2000 21:10:26 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29993 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 14:03:05 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA45651 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 14:03:04 +1000 (EST) Date: Fri, 11 Aug 2000 14:03:04 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008110403.OAA45651@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71877a Date: Thu Aug 10 21:02:34 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/Makefile - 1.26 cmd/xfs/misc/Makefile - 1.6 cmd/xfs/fsck/Makefile - 1.6 - reinstate fsck subdir & Makefile, at Russell's request. From owner-linux-xfs@oss.sgi.com Thu Aug 10 22:09:01 2000 Received: by oss.sgi.com id ; Thu, 10 Aug 2000 22:08:51 -0700 Received: from [204.94.214.10] ([204.94.214.10]:13616 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Aug 2000 22:08:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA03602 for ; Thu, 10 Aug 2000 21:56:49 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA00401 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 15:01:51 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA51732 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 15:01:50 +1000 (EST) Date: Fri, 11 Aug 2000 15:01:50 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008110501.PAA51732@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - handle code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71881a Date: Thu Aug 10 22:01:34 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/src/ioctl.c - 1.2 - No Message Supplied linux/fs/xfs/linux/xfs_ioctl.c - 1.15 - - fix xfs_find_handle locking - fix inode reference leak in xfs_open_by_handle From owner-linux-xfs@oss.sgi.com Fri Aug 11 01:52:11 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 01:52:01 -0700 Received: from hermes.mixx.net ([212.84.196.2]:2578 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 11 Aug 2000 01:51:26 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 22477F80B for ; Fri, 11 Aug 2000 10:18:25 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 561012CA6F; Fri, 11 Aug 2000 10:18:24 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: FAQ now available at oss.sgi.com Date: 11 Aug 2000 08:18:24 GMT Organization: innominate AG, Berlin, Germany Lines: 14 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 965981904 23363 10.0.0.69 (11 Aug 2000 08:18:24 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - i just checked in my FAQ to http://oss.sgi.com/projects/xfs/faq.html i will make it looking better soon - but the information so far is there now ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 11 09:15:46 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 09:15:36 -0700 Received: from homer.coredp.com ([216.94.116.130]:35960 "EHLO homer.coredp.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 09:15:34 -0700 Received: from twinkie.coredp.com (twinkie.coredp.com [216.94.116.231]) by homer.coredp.com (8.9.1/8.9.1) with ESMTP id LAA19055 for <@homer.coredp.com:linux-xfs@oss.sgi.com>; Fri, 11 Aug 2000 11:44:11 -0400 (EDT) Received: from coredp.com (localhost [127.0.0.1]) by twinkie.coredp.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA11081 for ; Fri, 11 Aug 2000 11:44:10 -0400 (EDT) Message-ID: <39941F4A.BE8486DC@coredp.com> Date: Fri, 11 Aug 2000 11:44:10 -0400 From: Andrew Ho Organization: C.O.R.E. Digital Pictures Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS and NFS ? References: <3990F9AB.1EBCA85@vum.be> Content-Type: multipart/alternative; boundary="------------1B5EB3F28E0C077CFBA6F577" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --------------1B5EB3F28E0C077CFBA6F577 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit kris buggenhout wrote: > ---------------------------------------------------------------- > > Subject: Re: XFS and NFS ? > Date: Wed, 09 Aug 2000 08:25:47 +0200 > From: kris buggenhout > To: Thomas Graichen > References: > > Thomas Graichen wrote: > >> even one more thing for the FAQ: are there any problems to expect >> then >> running NFS on top of XFS (like the problems reiserfs has to get the >> >> 32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried >> it in detail ? (i tried it lightly and had no problems - but my >> tests were not very deep) > > If its anything like the IRIX version, > XFS will cope until the number of entry's in a directory exceeds a > certain number > > IRIX has the ability to map it in the nfs code (i think) when U export > and are going te expect trouble, U export it with the option > 32bitclients > I dont know how it relates to the linux version ... > > with reiserfs it will always try to use a 64bit number ... which > confuses the nfs ... > XFS is perfectly alright exported to IRIX NFS. We need to compile the linux kernel with the configuration of nfs version 3 is on. The "/etc/rc.d/init.d/network" file in Linux needs to change the "nfs" to activate version 3. I did not find another problem for mounting the Linux XFS filesystem from IRIX with NFS. Andrew Ho -- ..................................................................... ANDREW HO email: andrewho@coredp.com c.o.r.e. digital pictures http://www.coredp.com 416 599-2673 fax: 416 599-1212 ..................................................................... --------------1B5EB3F28E0C077CFBA6F577 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit kris buggenhout wrote:

Subject: Re: XFS and NFS ?
Date: Wed, 09 Aug 2000 08:25:47 +0200
From: kris buggenhout <gast6@vum.be>
To: Thomas Graichen <graichen@innominate.de>
References: <news2mail-8mqt44$9kn$3@mate.bln.innominate.de>

Thomas Graichen wrote:

even one more thing for the FAQ: are there any problems to expect then
running NFS on top of XFS (like the problems reiserfs has to get the
32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried
it in detail ? (i tried it lightly and had no problems - but my
tests were not very deep)
If its anything like the IRIX version,
XFS will cope until the number of entry's in a directory exceeds a certain number

IRIX has the ability to map it in the nfs code (i think) when U export and are going te expect trouble, U export it with the option 32bitclients
I dont know how it relates to the linux version ...

with reiserfs it will always try to use a 64bit number ... which confuses the nfs ...
 


XFS is perfectly alright exported to IRIX NFS.
We need to compile the linux kernel with the configuration of
nfs version 3 is on.
The "/etc/rc.d/init.d/network" file in Linux needs to change the "nfs" to activate
version 3.
I did not find another problem for mounting the Linux XFS filesystem from IRIX
with NFS.
 

Andrew Ho
 
 
 
  

-- 
.....................................................................

 ANDREW HO                                email: andrewho@coredp.com
 c.o.r.e. digital pictures                     http://www.coredp.com
 416 599-2673                                      fax: 416 599-1212

.....................................................................
  --------------1B5EB3F28E0C077CFBA6F577-- From owner-linux-xfs@oss.sgi.com Fri Aug 11 09:19:45 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 09:19:37 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:46090 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 09:19:24 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e7BEsTC65693; Fri, 11 Aug 2000 09:54:29 -0500 (CDT) Message-ID: <399412F8.1D7A314B@thebarn.com> Date: Fri, 11 Aug 2000 09:51:36 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Subject: Re: stress test status? References: <200008111416.JAA03557@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > Tests 16 and 17 are failing for me - 17 I think because it needs the > unmount readonly code checked in. Yup... I've been running 17 with Daniel's changes. I could chech in what is there so far, but I'n not sure it completly fixes the problem. I've been discusing with Daniel how to trigger the problem he was seeing From owner-linux-xfs@oss.sgi.com Fri Aug 11 09:36:46 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 09:36:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:36654 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 09:36:05 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA22168 for ; Fri, 11 Aug 2000 08:16:30 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA64904 for ; Fri, 11 Aug 2000 10:21:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA27823 for ; Fri, 11 Aug 2000 10:21:33 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id KAA15880; Fri, 11 Aug 2000 10:19:32 -0500 Message-Id: <200008111519.KAA15880@jen.americas.sgi.com> Date: Fri, 11 Aug 2000 10:19:32 -0500 Subject: TAKE - use tricks from __constant_memcpy to make do_div type safe To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Change do_div and do_mod definitions passed on to the xfs code to be sensitive to the size of the arguments so that XFS should still build and run if the XFS_BIG_FILES and XFS_BIG_FILESYSTEMS definitions are changed. Date: Fri Aug 11 08:20:42 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71907a linux/fs/xfs/xfs_bmap.c - 1.258 - Change a call to do_mod to not pass in an expression - this does not work with the new definition. linux/fs/xfs/xfs_os_defs.h - 1.11 - Change do_div and do_mod definitions passed on to the xfs code to be sensitive to the size of the arguments so that XFS should still build and run if the XFS_BIG_FILES and XFS_BIG_FILESYSTEMS definitions are changed. From owner-linux-xfs@oss.sgi.com Fri Aug 11 10:13:56 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 10:13:46 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18458 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 10:13:18 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA06187 for ; Fri, 11 Aug 2000 07:24:13 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA40703 for ; Fri, 11 Aug 2000 09:16:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA71518 for ; Fri, 11 Aug 2000 09:16:52 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA03534; Fri, 11 Aug 2000 09:14:52 -0500 Message-Id: <200008111414.JAA03534@jen.americas.sgi.com> Date: Fri, 11 Aug 2000 09:14:52 -0500 Subject: TAKE - break apart /proc sysctl interface for pagebuf To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We now have a directory /proc/sys/vm/pagebuf which contails 6 different files each controlling one parameter of the pagebuf module. The files are clean_int Interval in HZ that page cleaner runs cluster_limit Maximum number of pages to cluster in one kiobuf write of delalloc pages debug turns on pagebuf internal logging, needs kdb to view log. delalloc_count maximum delayed allocate pages allowed flush_age Age in HZ before a dirty metadata buffer is a candidate for flushing by the pagebuf daemon flush_int Interval in HZ at which the pagebuf daemon runs Date: Fri Aug 11 07:11:29 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71900a linux/include/linux/page_buf.h - 1.60 - Add some definitions for pagebuf sysctl. linux/kdb/modules/kdbm_pg.c - 1.12 - Remove setting of debug_pagebuf on module load, the sysctl interface should now be used to turn tracing on and off. linux/fs/pagebuf/page_buf.c - 1.21 - Break the sysctl interface for pagebuf up into a set of separate /proc files one per parameter. linux/fs/pagebuf/page_buf_locking.c - 1.7 - Add a small function call to give us a useable stack frame for detecting which pagebuf a thread is sleeping waiting for. From owner-linux-xfs@oss.sgi.com Fri Aug 11 11:47:06 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 11:46:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:52314 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 11:46:22 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20404 for ; Fri, 11 Aug 2000 11:38:18 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA08991 for ; Fri, 11 Aug 2000 13:43:21 -0500 (CDT) Received: from localhost.localdomain (root@eagdhcp-184-21.americas.sgi.com [128.162.184.171]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA29855 for ; Fri, 11 Aug 2000 13:43:20 -0500 (CDT) From: Steve Lord Received: by localhost.localdomain (8.9.3/SGI-client-1.6c) id NAA03712; Fri, 11 Aug 2000 13:49:08 -0500 Message-Id: <200008111849.NAA03712@localhost.localdomain> Date: Fri, 11 Aug 2000 13:49:08 -0500 Subject: TAKE - change resolution on pagebuf time parameters to ms To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing HZ is not a fixed constant between systems, so changing the value to be millisecond based. Date: Fri Aug 11 11:42:11 PDT 2000 Workarea: eagdhcp-184-21.americas.sgi.com:/usr/src/lord/2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71927a linux/include/linux/page_buf.h - 1.61 - Change from int to unsigned long parameters. linux/fs/pagebuf/page_buf.c - 1.22 - Change resolution on timer based configurable parameters to be in milliseconds rather than HZ From owner-linux-xfs@oss.sgi.com Fri Aug 11 14:44:40 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 14:44:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4113 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 14:44:02 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13649 for ; Fri, 11 Aug 2000 14:35:11 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA31491 for ; Fri, 11 Aug 2000 16:41:29 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id QAA27432 for ; Fri, 11 Aug 2000 16:41:28 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7BLet421916 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 16:40:55 -0500 Date: Fri, 11 Aug 2000 16:40:55 -0500 From: Russell Cattelan Message-Id: <200008112140.e7BLet421916@gibble.americas.sgi.com> Subject: TAKE - Added kio and nokio to mount flags; initial checkin of rw -> ro remount. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The mount command now accepts kio as a mount option. pagebuf doesn't use the flag yet... will get that next. Initial changes from Daniel to allow file system to be remounted from rw -> ro. Under really heavy loads this doesn't quite work, but for a normal shutdown of a root file system where most processes are killed off before the remount this should work most of the time. Date: Fri Aug 11 14:36:02 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71948a linux/include/linux/fs.h - 1.55 - Added values for KIOBUF io flag. linux/fs/xfs/xfs_vfsops.c - 1.283 - Initial changes to allow remounting a file system from read write to read only. Not fully correct yet, but working in general cases. linux/fs/xfs/linux/xfs_super.c - 1.80 - check for kiobuf io and flag the superblock. Initial changes to allow remounting a file system from read write to read only. linux/fs/xfs/linux/xfs_mount_opt.c - 1.10 - Added kio and nokio to the mount options. Crurrently only kio is valid, eventually it may be possible to do remounts to turn on or off kiobuf io, at which time both flags will be needed. From owner-linux-xfs@oss.sgi.com Fri Aug 11 14:46:00 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 14:45:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:25618 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 14:45:17 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13950 for ; Fri, 11 Aug 2000 14:36:50 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA19665 for ; Fri, 11 Aug 2000 16:43:08 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id QAA27471 for ; Fri, 11 Aug 2000 16:43:07 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7BLgdL21987 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 16:42:39 -0500 Date: Fri, 11 Aug 2000 16:42:39 -0500 From: Russell Cattelan Message-Id: <200008112142.e7BLgdL21987@gibble.americas.sgi.com> Subject: TAKE - typo To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Aug 11 14:42:43 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71949a linux/fs/xfs/linux/xfs_super.c - 1.81 - Stupid typo From owner-linux-xfs@oss.sgi.com Fri Aug 11 17:36:31 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 17:36:23 -0700 Received: from ftp.torque.com ([209.101.115.162]:52206 "EHLO saturn") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 17:35:46 -0700 Received: from torque.com (localhost [127.0.0.1]) by saturn (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA20535; Fri, 11 Aug 2000 17:26:26 -0700 (PDT) Message-ID: <399499B2.4644F638@torque.com> Date: Fri, 11 Aug 2000 17:26:26 -0700 From: "Gawain N. E. Lavers" Organization: Torque Systems Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-hsm@vulcan.alphanet.ch, linux-fsdevel@vger.rutgers.edu, linux-xfs@oss.sgi.com, gfs-devel@sistina.com, reiserfs@devlinux.com CC: programming@torque.com, Mike Maxey Subject: Announcing the OpenXDSM project Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Announcing the OpenXDSM project I'd like to announce the OpenXDSM project. The OpenXDSM project is intended to create an open source implementation of the Data Storage Management (XDSM) API (also knows as Data Migration Application Programmers Interface (DMAPI)) set forth by The Open Group in 1997 (http://www.opengroup.org/pubs/catalog/c429.htm). By providing an open source implementation of the XDSM API, we hope to provide a platform for launching open source HSM (Hierarchical Storage Management) projects, as well as make it easier for current HSM vendors who use the XDSM to port their HSM solutions to Linux. The OpenXDSM project is supported heavily by BigStorage Inc. (http://www.bigstorage.com), a company dedicated to providing large storage support for Linux. We see the addition of the XDSM API as an important step towards making Linux an enterprise-ready server solution. Our current development site is hosted by SourceForge (http://www.sourceforge.net) and resides at http://openxdsm.sourceforge.net. If you have any interest in HSM on Linux, please visit the OpenXDSM site and look around. We are currently planning the project, but have put together some code ideas which will be available from the site shortly. If you have any questions, comments, or especially suggestions, feel free to drop a line on the mailing list, or contact me directly at gawain@bigstorage.com. -- Gawain Lavers Software Engineer Torque Systems Inc. / BigStorage Inc. 19 Heron Street voice: (415) 252-5521 San Francisco, CA 94103 fax : (415) 252-1521 From owner-linux-xfs@oss.sgi.com Fri Aug 11 20:56:31 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 20:56:22 -0700 Received: from w115.z208177135.sjc-ca.dsl.cnc.net ([208.177.135.115]:61712 "EHLO willyboy.technolunatic.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 20:55:56 -0700 Received: (from dwilson@localhost) by willyboy.technolunatic.com (8.9.3/8.8.7) id UAA17219 for linux-xfs@oss.sgi.com; Fri, 11 Aug 2000 20:55:55 -0700 From: Dionysius Wilson Almeida Date: Fri, 11 Aug 2000 20:55:55 -0700 To: linux-xfs@oss.sgi.com Subject: Corrupted files with 2.4.0-test5 and 08012000 patch Message-ID: <20000811205555.A17208@technolunatic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I'm using 2.4.0-test5 kernel with 08012000linux-2.4-test5-linux-2.4-xfs-.patch. XFS is corrupting files when untarring..Here's what i did.. i created a tarball of /usr directory and then i create a xfs filesystem and then i untarred the tarball to this filesystem.. After that lost of binaries had wrong headers etc.. First time i thought it might be due to some problem while creating the tarball ..so i check the disk space etc..i created this tarball again from freshly installed /usr directory and then i created md5sums and then i created xfs filesystem and untarred the tarball into it. Again some files had wrong headers etc..then i did a md5 checksum compare and i got 3000 checksum failures out of 30000 files. If u want i can send the out of checksum compares... Does anyone know of any know issues with either 2.4.0-test5 or 08012000 patch at the download site ?? thanks -Wilson -- Better to be nouveau than never to have been riche at all. From owner-linux-xfs@oss.sgi.com Fri Aug 11 21:37:32 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 21:37:12 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4422 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 21:36:48 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08638 for ; Fri, 11 Aug 2000 21:42:53 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA13851; Fri, 11 Aug 2000 21:31:44 -0700 (PDT) Message-ID: <3994D32F.4B1C3134@sgi.com> Date: Fri, 11 Aug 2000 21:31:43 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dionysius Wilson Almeida CC: linux-xfs@oss.sgi.com Subject: Re: Corrupted files with 2.4.0-test5 and 08012000 patch References: <20000811205555.A17208@technolunatic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Dionysius Wilson Almeida wrote: > > Hi, > > I'm using 2.4.0-test5 kernel with 08012000linux-2.4-test5-linux-2.4-xfs-.patch. > XFS is corrupting files when untarring..Here's what i did.. > i created a tarball of /usr directory and then i create a xfs filesystem > and then i untarred the tarball to this filesystem.. After that lost of > binaries had wrong headers etc.. There was a corruption related bug fixed earlier this week. That patch is old and does not contain the fix. Please use the cvs tree. Russell, can you please remove the patches so it doesn't confuse people trying to use it? -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Aug 11 21:38:12 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 21:38:02 -0700 Received: from w115.z208177135.sjc-ca.dsl.cnc.net ([208.177.135.115]:20753 "EHLO willyboy.technolunatic.com") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 21:37:47 -0700 Received: (from dwilson@localhost) by willyboy.technolunatic.com (8.9.3/8.8.7) id VAA17389; Fri, 11 Aug 2000 21:37:45 -0700 From: Dionysius Wilson Almeida Date: Fri, 11 Aug 2000 21:37:45 -0700 To: Rajagopal Ananthanarayanan Cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted files with 2.4.0-test5 and 08012000 patch Message-ID: <20000811213745.C17351@technolunatic.com> References: <20000811205555.A17208@technolunatic.com> <3994D32F.4B1C3134@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3994D32F.4B1C3134@sgi.com>; from ananth@sgi.com on Fri, Aug 11, 2000 at 09:31:43PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Is there any way that i can just check out the xfs stuff minus the kernel ?? -Wilson * Rajagopal Ananthanarayanan (ananth@sgi.com) wrote: > Dionysius Wilson Almeida wrote: > > > > Hi, > > > > I'm using 2.4.0-test5 kernel with 08012000linux-2.4-test5-linux-2.4-xfs-.patch. > > XFS is corrupting files when untarring..Here's what i did.. > > i created a tarball of /usr directory and then i create a xfs filesystem > > and then i untarred the tarball to this filesystem.. After that lost of > > binaries had wrong headers etc.. > > There was a corruption related bug fixed earlier this week. > That patch is old and does not contain the fix. Please use > the cvs tree. Russell, can you please remove the patches > so it doesn't confuse people trying to use it? > > > -------------------------------------------------------------------------- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------------------- -- "Inquiry is fatal to certainty." -- Will Durant From owner-linux-xfs@oss.sgi.com Fri Aug 11 22:25:04 2000 Received: by oss.sgi.com id ; Fri, 11 Aug 2000 22:24:54 -0700 Received: from lips.borg.umn.edu ([160.94.232.50]:55819 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Fri, 11 Aug 2000 22:24:30 -0700 Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118]) by lips.borg.umn.edu (8.10.1/8.10.1) with ESMTP id e7C5NxC69533; Sat, 12 Aug 2000 00:24:00 -0500 (CDT) Message-ID: <3994DEC0.176D4D4C@thebarn.com> Date: Sat, 12 Aug 2000 00:21:05 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Dionysius Wilson Almeida CC: linux-xfs@oss.sgi.com Subject: Re: Corrupted files with 2.4.0-test5 and 08012000 patch References: <20000811205555.A17208@technolunatic.com> <3994D32F.4B1C3134@sgi.com> <20000811213745.C17351@technolunatic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Dionysius Wilson Almeida wrote: > Is there any way that i can just check out the xfs stuff minus > the kernel ?? > Technically yes, but you really need to know what you are doing. I will spin new patches, they will but up shortly. ftp://oss.sgi.com/projects/xfs/download/08122000linux-2.4-test5-linux-2.4-xfs-cvs.patch.gz I recommend grabbing the patch with the cvs info in it. It can be used to patch a base 2.4.0-test5 to a XFS + cvs tree. You can then keep your tree up to date by simply doing a 'cvs update' occasionally, the number of files transferred will be minimal. > > -Wilson > * Rajagopal Ananthanarayanan (ananth@sgi.com) wrote: > > Dionysius Wilson Almeida wrote: > > > > > > Hi, > > > > > > I'm using 2.4.0-test5 kernel with 08012000linux-2.4-test5-linux-2.4-xfs-.patch. > > > XFS is corrupting files when untarring..Here's what i did.. > > > i created a tarball of /usr directory and then i create a xfs filesystem > > > and then i untarred the tarball to this filesystem.. After that lost of > > > binaries had wrong headers etc.. > > > > There was a corruption related bug fixed earlier this week. > > That patch is old and does not contain the fix. Please use > > the cvs tree. Russell, can you please remove the patches > > so it doesn't confuse people trying to use it? > > > > > > -------------------------------------------------------------------------- > > Rajagopal Ananthanarayanan ("ananth") > > Member Technical Staff, SGI. > > -------------------------------------------------------------------------- > > -- > "Inquiry is fatal to certainty." > -- Will Durant -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sat Aug 12 10:20:08 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 10:19:49 -0700 Received: from hermes.mixx.net ([212.84.196.2]:11533 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 12 Aug 2000 10:19:20 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id E0EF3F81C for ; Sat, 12 Aug 2000 19:19:17 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 389B72CA6F; Sat, 12 Aug 2000 19:19:17 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs after two weeks of use Date: 12 Aug 2000 17:19:17 GMT Organization: innominate AG, Berlin, Germany Lines: 42 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966100757 6416 10.0.0.69 (12 Aug 2000 17:19:17 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - a new section in my little series: just shutdown the machine again and repair_xfs'ed them to check - root filesystem again had small problems (but i think this will be fixed soon when the umount code is in) and the other partition had no problems at all - so everything is best also this week i had increased the load of the system a bit - it is now running the squid for our company (~50 users, 500mb cache) and a dummy news server (inn) with a feed of about 4000 articles per day and 30 simulated users reading away all articles all few minutes) - everything is running on xfs and i had no problem so far ok - compiled a fresh kernel and will come back next week - but so far xfs looks really good ... one thing i noticed at the repair_xfs is the folowing: ... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... ... i got that "rebuilding directory inode 128" on both / and the other partition - is that normal or an found (and maybe fixed) error in the filesystem ? t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Aug 12 13:43:39 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 13:43:29 -0700 Received: from hermes.mixx.net ([212.84.196.2]:18960 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 12 Aug 2000 13:43:20 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 044B5F820 for ; Sat, 12 Aug 2000 22:43:18 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 952C52CA6F; Sat, 12 Aug 2000 22:43:17 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: XFS sources lxr xrefed available Date: 12 Aug 2000 20:43:17 GMT Organization: innominate AG, Berlin, Germany Lines: 15 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966112997 26743 10.0.0.69 (12 Aug 2000 20:43:17 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i have just set up an lxr indexed xfs source tree at http://innominate.org/~graichen/projects/lxr/source/?v=xfs which will be keeped up to date to the SGI cvs tree daily starting in the next days and should make the navigation through the code much easier for everyone interesed ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Aug 12 17:57:59 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 17:57:50 -0700 Received: from timmo.dsl.psn.net ([209.63.182.212]:30970 "EHLO fileserver.nimmo.org") by oss.sgi.com with ESMTP id ; Sat, 12 Aug 2000 17:57:26 -0700 Received: from comms (comms.nimmo.org [192.254.254.6]) by fileserver.nimmo.org (8.9.3/8.9.3) with ESMTP id RAA12346 for ; Sat, 12 Aug 2000 17:57:07 -0700 From: "T. Nimmo" To: Subject: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Date: Sat, 12 Aug 2000 17:57:00 -0700 Message-ID: <000201c004c1$64e98a40$06fefec0@nimmo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I started building the linux-2.4-xfs kernel on a RedHat 6.2 O/S back on 8/4-8/7; which wasn't stable and locked up the machine. mount/umount or high file copy rates to xfs filesystems seemed to lock it quickly. By 8/9 this problem disappeared and the system no longer locks. Now with the scene setup... I've been building a Oracle 8.1.6 for Linux installation using xfs/scsi for the data volumes with good results. I have Oracle installed on a ext2/scsi filesystem. After this test I rebuilt the Oracle installation tree on the same scsi drive using xfs. I used fdisk/mkfs to create the xfs filesystem. Copying to a xfs volume, the Oracle installer runs along doing it's normal thing, until the end of the installation. At the 98% mark the installer relinks the Oracle executables as part of it's routine. However the linker 'ld' isn't able to properly read the Oracle library files to relink the executables. It's like the file contents are messed up or 'ld' can't read the Oracle library file contents or something. Really wierd! If I scratch the Oracle installation tree and reinstall it back to normal on ext2 it installs just fine. The Oracle datafiles on xfs seem to read/write perfectly as I can make Oracle do it's thing with no hiccups. All of my Oracle xfs filesystems are single sliced on 9 scsi drives and 3 atapi drives. Most filesystems have 5-7 ###MB files with ~6GB across 11 filesystems. The 12th filesystem contains the Oracle installation (/app/oracle/product/blah-blah). Anyone have any thoughts about why the Oracle installer can't read libraries and relink executables on a xfs filesystem? Thanks, Tim... From owner-linux-xfs@oss.sgi.com Sat Aug 12 18:03:00 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 18:02:50 -0700 Received: from Cantor.suse.de ([194.112.123.193]:3598 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sat, 12 Aug 2000 18:02:44 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 9A5911E135; Sun, 13 Aug 2000 03:02:39 +0200 (MEST) Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 674D110A034; Sun, 13 Aug 2000 03:02:39 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id D6EB92F300; Sun, 13 Aug 2000 03:02:35 +0200 (MEST) Date: Sun, 13 Aug 2000 03:02:35 +0200 From: "Andi Kleen" To: "T. Nimmo" Cc: Subject: Re: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Message-ID: <20000813030235.A705@gruyere.muc.suse.de> References: <000201c004c1$64e98a40$06fefec0@nimmo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <000201c004c1$64e98a40$06fefec0@nimmo.org>; from timmo@psn.net on Sat, Aug 12, 2000 at 05:57:00PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, Aug 12, 2000 at 05:57:00PM -0700, T. Nimmo wrote: > Anyone have any thoughts about why the Oracle installer can't read libraries > and relink executables on a xfs filesystem? You could write a simple shell script that starts strace -o/tmp/LDLOG /usr/bin/ld "$@", name it ld and put it in your $PATH before /usr/bin. From the strace log it should be possible to find out where it fails. -Andi From owner-linux-xfs@oss.sgi.com Sat Aug 12 20:07:43 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 20:07:33 -0700 Received: from ing-mat.udec.cl ([152.74.217.2]:58507 "EHLO ing-mat.udec.cl") by oss.sgi.com with ESMTP id ; Sat, 12 Aug 2000 20:07:15 -0700 Received: from localhost by ing-mat.udec.cl (8.9.3/8.9.1) with ESMTP id XAA19197 for ; Sat, 12 Aug 2000 23:10:56 -0400 (CST) Date: Sat, 12 Aug 2000 23:10:55 -0400 (CST) From: Claudio Baeza R To: linux-xfs@oss.sgi.com Subject: problem: can I not build xfs-cmd in last CVS (08/12/00) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, I have problem to successfully build xfs-cmd. I tried compile (on first time, download CVS tree; "cvs -z3 checkout linux-2.4-xfs"), in the linux-2.4-xfs/cmd/xfs directory. make configure make ... ... ... === sim/src === Makefile:81: warning: overriding commands for target `xfs_uuid.c' Makefile:78: warning: ignoring old commands for target `xfs_uuid.c' make[1]: Nothing to be done for `default'. === include === make[1]: Nothing to be done for `default'. === libxfs === gcc -g -DDEBUG -funsigned-char -Wall -Wno-parentheses -Wno-unknown-pragmas -Wno-unused -I. '-DVERSION="1.0.2-0"' -I../include -I../../../linux/include -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o init.o init.c In file included from ../include/libxfs.h:56, from init.c:34: ../include/xfs_fsops.h:50: redefinition of `struct xfs_growfs_data' ../include/xfs_fsops.h:53: redefinition of `xfs_growfs_data_t' ../../../linux/include/linux/xfs_fs.h:250: `xfs_growfs_data_t' previously declared here ../include/xfs_fsops.h:57: redefinition of `struct xfs_growfs_log' ../include/xfs_fsops.h:60: redefinition of `xfs_growfs_log_t' ../../../linux/include/linux/xfs_fs.h:261: `xfs_growfs_log_t' previously declared here ../include/xfs_fsops.h:64: redefinition of `struct xfs_growfs_rt' ../include/xfs_fsops.h:67: redefinition of `xfs_growfs_rt_t' ../../../linux/include/linux/xfs_fs.h:271: `xfs_growfs_rt_t' previously declared here make[1]: *** [init.o] Error 1 make: *** [default] Error 2 Which definitions would have to use? xfs_fsops.h or xfs_fs.h ? claudio From owner-linux-xfs@oss.sgi.com Sat Aug 12 20:57:33 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 20:57:24 -0700 Received: from w115.z208177135.sjc-ca.dsl.cnc.net ([208.177.135.115]:5126 "EHLO willyboy.technolunatic.com") by oss.sgi.com with ESMTP id ; Sat, 12 Aug 2000 20:57:06 -0700 Received: (from dwilson@localhost) by willyboy.technolunatic.com (8.9.3/8.8.7) id UAA20579; Sat, 12 Aug 2000 20:57:04 -0700 From: Dionysius Wilson Almeida Date: Sat, 12 Aug 2000 20:57:03 -0700 To: "T. Nimmo" Cc: linux-xfs@oss.sgi.com Subject: Re: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Message-ID: <20000812205703.A20555@technolunatic.com> References: <000201c004c1$64e98a40$06fefec0@nimmo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000201c004c1$64e98a40$06fefec0@nimmo.org>; from timmo@psn.net on Sat, Aug 12, 2000 at 05:57:00PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It might be due to some issues with file corruption..see my earlier post regarding corrupted files while untarring on xfs ...whereas the same untar on ext2 was fine.. You might want to check out the latest sources..which i'm myself doing to check if the problem still exists. Hope this helps, -Wilson * T. Nimmo (timmo@psn.net) wrote: > I started building the linux-2.4-xfs kernel on a RedHat 6.2 O/S back on > 8/4-8/7; which wasn't stable and locked up the machine. mount/umount or high > file copy rates to xfs filesystems seemed to lock it quickly. By 8/9 this > problem disappeared and the system no longer locks. Now with the scene > setup... > > I've been building a Oracle 8.1.6 for Linux installation using xfs/scsi for > the data volumes with good results. I have Oracle installed on a ext2/scsi > filesystem. After this test I rebuilt the Oracle installation tree on the > same scsi drive using xfs. I used fdisk/mkfs to create the xfs filesystem. > > Copying to a xfs volume, the Oracle installer runs along doing it's normal > thing, until the end of the installation. At the 98% mark the installer > relinks the Oracle executables as part of it's routine. However the linker > 'ld' isn't able to properly read the Oracle library files to relink the > executables. It's like the file contents are messed up or 'ld' can't read > the Oracle library file contents or something. Really wierd! > > If I scratch the Oracle installation tree and reinstall it back to normal on > ext2 it installs just fine. The Oracle datafiles on xfs seem to read/write > perfectly as I can make Oracle do it's thing with no hiccups. > > All of my Oracle xfs filesystems are single sliced on 9 scsi drives and 3 > atapi drives. Most filesystems have 5-7 ###MB files with ~6GB across 11 > filesystems. The 12th filesystem contains the Oracle installation > (/app/oracle/product/blah-blah). > > Anyone have any thoughts about why the Oracle installer can't read libraries > and relink executables on a xfs filesystem? > > Thanks, Tim... -- Do I have a lifestyle yet? From owner-linux-xfs@oss.sgi.com Sat Aug 12 22:59:14 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 22:59:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59228 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 12 Aug 2000 22:58:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA24579 for ; Sat, 12 Aug 2000 22:51:04 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15498 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Sun, 13 Aug 2000 15:56:07 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA42437 for linux-xfs@oss.sgi.com; Sun, 13 Aug 2000 15:56:06 +1000 (EST) Date: Sun, 13 Aug 2000 15:56:06 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008130556.PAA42437@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmd build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:71999a Date: Sat Aug 12 22:55:10 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/xfs_fsops.h - 1.3 - remove duplicate definition of growfs data structures. From owner-linux-xfs@oss.sgi.com Sat Aug 12 23:01:24 2000 Received: by oss.sgi.com id ; Sat, 12 Aug 2000 23:01:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5469 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 12 Aug 2000 23:00:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA24715 for ; Sat, 12 Aug 2000 22:53:22 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15516; Sun, 13 Aug 2000 15:59:39 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA13740; Sun, 13 Aug 2000 15:59:38 +1000 (EST) From: "Nathan Scott" Message-Id: <10008131559.ZM13950@wobbly.melbourne.sgi.com> Date: Sun, 13 Aug 2000 15:59:37 -0500 In-Reply-To: Claudio Baeza R "problem: can I not build xfs-cmd in last CVS (08/12/00)" (Aug 13, 1:08pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Claudio Baeza R , linux-xfs@oss.sgi.com Subject: Re: problem: can I not build xfs-cmd in last CVS (08/12/00) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Aug 13, 1:08pm, Claudio Baeza R wrote: > Subject: problem: can I not build xfs-cmd in last CVS (08/12/00) > > Hello, > > I have problem to successfully build xfs-cmd. > ... > Which definitions would have to use? xfs_fsops.h or xfs_fs.h ? > xfs_fs.h is the right one. I've checked in the fix - thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 13 00:24:14 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 00:23:54 -0700 Received: from timmo.dsl.psn.net ([209.63.182.212]:29691 "EHLO fileserver.nimmo.org") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 00:23:27 -0700 Received: from comms (comms.nimmo.org [192.254.254.6]) by fileserver.nimmo.org (8.9.3/8.9.3) with ESMTP id AAA13520; Sun, 13 Aug 2000 00:23:13 -0700 From: "T. Nimmo" To: "'Dionysius Wilson Almeida'" Cc: Subject: RE: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Date: Sun, 13 Aug 2000 00:23:08 -0700 Message-ID: <000301c004f7$54fbdf80$06fefec0@nimmo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <20000812205703.A20555@technolunatic.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>It might be due to some issues with file corruption..see my earlier post regarding corrupted files while untarring on xfs ...whereas the same untar on ext2 was fine.. You might want to check out the latest sources..which i'm myself doing to check if the problem still exists.<< Good. This matches my other observation. When I tar up my Oracle installation tree (ext2) to a xfs filesystem all goes well. When I list the tar file, or restore from it, it prematurely stops about 20-30MB into the tar set. The tar file has the right byte count when I create it. When it restores it acts as if it cleanly hits EOF and exits with $?=0 Ciao, Tim... > Anyone have any thoughts about why the Oracle installer can't read libraries > and relink executables on a xfs filesystem? > > Thanks, Tim... From owner-linux-xfs@oss.sgi.com Sun Aug 13 00:52:05 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 00:51:54 -0700 Received: from w115.z208177135.sjc-ca.dsl.cnc.net ([208.177.135.115]:18182 "EHLO willyboy.technolunatic.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 00:51:28 -0700 Received: (from dwilson@localhost) by willyboy.technolunatic.com (8.9.3/8.8.7) id AAA21157; Sun, 13 Aug 2000 00:51:26 -0700 From: Dionysius Wilson Almeida Date: Sun, 13 Aug 2000 00:51:26 -0700 To: "T. Nimmo" Cc: linux-xfs@oss.sgi.com Subject: Re: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Message-ID: <20000813005126.A21150@technolunatic.com> References: <20000812205703.A20555@technolunatic.com> <000301c004f7$54fbdf80$06fefec0@nimmo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000301c004f7$54fbdf80$06fefec0@nimmo.org>; from timmo@psn.net on Sun, Aug 13, 2000 at 12:23:08AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yeah.. tar behaves properly...but the checksums differ after the extraction. -Wilson * T. Nimmo (timmo@psn.net) wrote: > >>It might be due to some issues with file corruption..see my earlier post > regarding corrupted files while untarring on xfs ...whereas the same untar > on ext2 was fine.. You might want to check out the latest > sources..which i'm myself doing to check if the problem still exists.<< > > Good. This matches my other observation. When I tar up my Oracle > installation tree (ext2) to a xfs filesystem all goes well. When I list the > tar file, or restore from it, it prematurely stops about 20-30MB into the > tar set. The tar file has the right byte count when I create it. When it > restores it acts as if it cleanly hits EOF and exits with $?=0 > > Ciao, Tim... > > > Anyone have any thoughts about why the Oracle installer can't read > libraries > > and relink executables on a xfs filesystem? > > > > Thanks, Tim... -- A bachelor is an unaltared male. From owner-linux-xfs@oss.sgi.com Sun Aug 13 14:13:09 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 14:12:49 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:22680 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 14:12:19 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id QAA05885; Sun, 13 Aug 2000 16:12:17 -0500 (CDT) Date: Sun, 13 Aug 2000 16:12:17 -0500 (CDT) Message-Id: <200008132112.QAA05885@spica.cc.utexas.edu> From: William L Jones To: Subject: No include Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing In the cmd direcotry dump/common/openutil.c includes , which my version of linux does not have. I think it only does this to get PID_MAX. It probably should use instead. Bill Jones From owner-linux-xfs@oss.sgi.com Sun Aug 13 16:07:40 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 16:07:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21295 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 16:07:13 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA10236 for ; Sun, 13 Aug 2000 15:59:37 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20291 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 09:05:55 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA12485 for linux-xfs@oss.sgi.com; Mon, 14 Aug 2000 09:05:54 +1000 (EST) Date: Mon, 14 Aug 2000 09:05:54 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008132305.JAA12485@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fsops.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cleaner fix to the fsops.h build problem - cmd/xfs/include/xfs_fsops.h has also been removed as its no longer needed by the user tools. Modid: 2.4.0-test1-xfs:slinx:72002a Date: Sun Aug 13 15:53:45 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/libxfs.h - 1.8 cmd/xfs/repair/sb.c - 1.31 cmd/xfs/sim/mkfs/xfs_mkfs.c - 1.2 cmd/xfs/stress/src/global.h - 1.2 - no longer includes xfs_fsops.h linux/fs/xfs/xfs_fsops.c - 1.56 - include xfs_fs.h also. linux/fs/xfs/xfs_fsops.h - 1.17 - move sizes needed for growth checks info xfs_fs.h. linux/fs/xfs/xfs_mount.c - 1.232 linux/fs/xfs/xfs_rtalloc.c - 1.61 - no longer includes xfs_fsops.h linux/include/linux/xfs_fs.h - 1.12 - tidy up typedefs for consistency, move sizes needed for growth checks here (needed by number of command and kernel source files) From owner-linux-xfs@oss.sgi.com Sun Aug 13 16:47:00 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 16:46:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9337 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 16:46:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA00673 for ; Sun, 13 Aug 2000 16:52:26 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20512 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 09:44:56 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA45308 for linux-xfs@oss.sgi.com; Mon, 14 Aug 2000 09:44:55 +1000 (EST) Date: Mon, 14 Aug 2000 09:44:55 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008132344.JAA45308@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - debug Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I noticed that xfs_repair isn't currently evaluating assert statements. This fixes that in a consistent way for all the commands (a few others weren't either) - use of DEBUG can be controlled through "configure" for all commands now (using ASSERT now in all commands, and configure sets the value of ASSERT depending on its $DEBUG parameter). Also tried a non-debug build to check it works - fixed a couple of libxfs build issues there. Note: I haven't actually checked in the xfs_repair assert fix here - that will come with the next round of repair checkins (libxfs/libsim stuff). cheers. Modid: 2.4.0-test1-xfs:slinx:72004a Date: Sun Aug 13 16:34:29 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/configure.in - 1.10 - add some comments to existing parameters. cmd/xfs/db/addr.c - 1.16 cmd/xfs/db/agf.c - 1.19 cmd/xfs/db/agfl.c - 1.19 cmd/xfs/db/agi.c - 1.19 cmd/xfs/db/attr.c - 1.22 cmd/xfs/db/attrshort.c - 1.14 cmd/xfs/db/bit.c - 1.14 cmd/xfs/db/block.c - 1.22 cmd/xfs/db/bmap.c - 1.30 cmd/xfs/db/bmapbt.c - 1.17 cmd/xfs/db/bmroot.c - 1.22 cmd/xfs/db/bnobt.c - 1.17 cmd/xfs/db/check.c - 1.56 cmd/xfs/db/cntbt.c - 1.16 cmd/xfs/db/dir.c - 1.25 cmd/xfs/db/dir2.c - 1.9 cmd/xfs/db/dir2sf.c - 1.6 cmd/xfs/db/dirshort.c - 1.17 cmd/xfs/db/faddr.c - 1.20 cmd/xfs/db/field.c - 1.29 cmd/xfs/db/flist.c - 1.17 cmd/xfs/db/fprint.c - 1.20 cmd/xfs/db/inobt.c - 1.16 cmd/xfs/db/inode.c - 1.35 cmd/xfs/db/print.c - 1.19 cmd/xfs/db/sb.c - 1.31 cmd/xfs/db/type.c - 1.23 cmd/xfs/db/write.c - 1.19 cmd/xfs/dump/common/archdep.c - 1.9 cmd/xfs/dump/common/cldmgr.c - 1.8 cmd/xfs/dump/common/cleanup.c - 1.4 cmd/xfs/dump/common/content.c - 1.8 cmd/xfs/dump/common/content_common.c - 1.7 cmd/xfs/dump/common/dlog.c - 1.10 cmd/xfs/dump/common/drive.c - 1.10 cmd/xfs/dump/common/drive_minrmt.c - 1.18 cmd/xfs/dump/common/drive_scsitape.c - 1.21 cmd/xfs/dump/common/drive_simple.c - 1.10 cmd/xfs/dump/common/fs.c - 1.13 cmd/xfs/dump/common/global.c - 1.10 cmd/xfs/dump/common/inomap.c - 1.9 cmd/xfs/dump/common/inventory.c - 1.7 cmd/xfs/dump/common/inventory_priv.c - 1.9 cmd/xfs/dump/common/inventory_priv.h - 1.5 cmd/xfs/dump/common/lock.c - 1.4 cmd/xfs/dump/common/main.c - 1.16 cmd/xfs/dump/common/media.c - 1.6 cmd/xfs/dump/common/mlog.c - 1.9 cmd/xfs/dump/common/namreg.c - 1.4 cmd/xfs/dump/common/openutil.c - 1.6 cmd/xfs/dump/common/path.c - 1.4 cmd/xfs/dump/common/qlock.c - 1.9 cmd/xfs/dump/common/ring.c - 1.10 cmd/xfs/dump/common/stkchk.c - 1.7 cmd/xfs/dump/common/stream.c - 1.7 cmd/xfs/dump/common/util.c - 1.13 cmd/xfs/dump/dump/content.c - 1.20 cmd/xfs/dump/dump/inomap.c - 1.10 cmd/xfs/dump/dump/var.c - 1.12 - consistent, configure-driven use of assert() across all commands. cmd/xfs/dump/inventory/Makefile - 1.4 - consistent, configure-driven use of assert() across all commands. remove some unnecessary -D options. cmd/xfs/dump/inventory/inv_api.c - 1.8 cmd/xfs/dump/inventory/inv_core.c - 1.6 cmd/xfs/dump/inventory/inv_fstab.c - 1.8 cmd/xfs/dump/inventory/inv_idx.c - 1.6 cmd/xfs/dump/inventory/inv_mgr.c - 1.8 cmd/xfs/dump/inventory/inv_priv.h - 1.6 cmd/xfs/dump/inventory/inv_stobj.c - 1.10 cmd/xfs/dump/inventory/testmain.c - 1.6 - consistent, configure-driven use of assert() across all commands. cmd/xfs/dump/invutil/Makefile - 1.2 - consistent, configure-driven use of assert() across all commands. remove some unnecessary -D options. cmd/xfs/dump/restore/bag.c - 1.3 cmd/xfs/dump/restore/content.c - 1.14 cmd/xfs/dump/restore/dirattr.c - 1.7 cmd/xfs/dump/restore/inomap.c - 1.11 cmd/xfs/dump/restore/namreg.c - 1.5 cmd/xfs/dump/restore/node.c - 1.5 cmd/xfs/dump/restore/tree.c - 1.8 cmd/xfs/dump/restore/win.c - 1.5 - consistent, configure-driven use of assert() across all commands. cmd/xfs/libxfs/xfs.h - 1.4 - fix non-debug build issues (unresolved symbols, only there for DEBUG). From owner-linux-xfs@oss.sgi.com Sun Aug 13 17:43:50 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 17:43:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:15670 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 17:43:20 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA14294 for ; Sun, 13 Aug 2000 17:35:44 -0700 (PDT) mail_from (ivanr@sherman.melbourne.sgi.com) Received: (from ivanr@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id KAA15292 for linux-xfs@oss.sgi.com; Mon, 14 Aug 2000 10:41:17 +1000 Date: Mon, 14 Aug 2000 10:41:17 +1000 From: Ivan Rayner Message-Id: <200008140041.KAA15292@sherman.melbourne.sgi.com> Subject: TAKE - xfsdump To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing common/openutil.c now uses threads.h instead of tasks.h (Thanks Bill). tasks.h comes from linux-2.2.15 which is linked for me via /usr/include/linux ... sigh. Ivan needed for endian conversion Date: Thu Aug 10 01:37:09 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71771a cmd/xfs/dump/common/rec_hdr.h - 1.1 Subject: TAKE - Date: Thu Aug 10 19:40:59 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71873a cmd/xfs/dump/common/inomap.c - 1.8 - minor code cleanup cmd/xfs/dump/restore/inomap.c - 1.8 - endian convert incoming inomap cmd/xfs/dump/common/arch_xlate.c - 1.2 - remove compilation warning Subject: TAKE - fix endian conversion of inomap some more Date: Thu Aug 10 20:26:30 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71875a cmd/xfs/dump/restore/inomap.c - 1.9 cmd/xfs/dump/common/arch_xlate.c - 1.3 Subject: TAKE - fix compiler warnings Date: Thu Aug 10 21:42:38 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71880a cmd/xfs/dump/dump/var.c - 1.11 cmd/xfs/dump/restore/inomap.c - 1.10 cmd/xfs/dump/restore/mmap.h - 1.2 Subject: TAKE - fix global header endian conversion Date: Thu Aug 10 22:55:11 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:71882a cmd/xfs/dump/common/drive_minrmt.c - 1.17 Subject: TAKE - use threads.h instead of tasks.h Date: Sun Aug 13 17:38:12 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72005a cmd/xfs/dump/common/openutil.c - 1.7 From owner-linux-xfs@oss.sgi.com Sun Aug 13 18:38:51 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 18:38:31 -0700 Received: from mail.primerama.es ([195.77.179.4]:53773 "EHLO mail.primerama.es") convert rfc822-to-8bit by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 18:38:11 -0700 Received: from diqwuiu [209.206.4.167] by mail.primerama.es with ESMTP (SMTPD32-6.00) id ADDD291F00CE; Mon, 14 Aug 2000 03:39:41 +0200 From: "Karl Porter" Subject: Your On... # 22D To: gold290d@oss.sgi.com X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sun, 13 Aug 2000 20:33:49 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <200008140339145.SM00160@diqwuiu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS ! INTERNET (Auction Vendors & Online Mall Stores Too!) STOREFRONT OR MAIL ORDER MERCHANTS WE SPECIALIZE IN APPROVING YOU! APPLY TODAY AND START FOR JUST $9.95! FREE APPLICATION!! FREE PROGRAMMING!! DON'T LOSE ANOTHER SALE! APPLY TO ACCEPT CREDIT CARDS AND CALL (888) 264-9272 DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:bbmxt@netscape.net?subject=remove ************************************************************ From owner-linux-xfs@oss.sgi.com Sun Aug 13 18:51:01 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 18:50:51 -0700 Received: from mail2.rdc2.on.home.com ([24.9.0.41]:26099 "EHLO mail2.rdc2.on.home.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 18:50:41 -0700 Received: from coredp.com ([24.68.55.24]) by mail2.rdc2.on.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000814015035.RKWO25041.mail2.rdc2.on.home.com@coredp.com>; Sun, 13 Aug 2000 18:50:35 -0700 Message-ID: <39975191.40397BE2@coredp.com> Date: Sun, 13 Aug 2000 21:55:29 -0400 From: Andrew Ho X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.4.0-test5 i586) X-Accept-Language: en MIME-Version: 1.0 To: nathans@snort.melbourne.sgi.com, linux-xfs@oss.sgi.com Subject: xfs_copy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The error meesages of /usr/src/linux-2.4-xfs/cmd/xfs/copy/ Makefile:35: /usr/include/make/commondefs: No such file or directory Makefile:52: no file name for `include' make: *** No rule to make target `/usr/include/make/commondefs'. Stop Thank you for your attention. Andrew Ho From owner-linux-xfs@oss.sgi.com Sun Aug 13 19:07:21 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 19:07:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43325 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 19:06:36 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA18470 for ; Sun, 13 Aug 2000 18:58:58 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21524; Mon, 14 Aug 2000 12:05:15 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA15498; Mon, 14 Aug 2000 12:05:14 +1000 (EST) From: "Nathan Scott" Message-Id: <10008141205.ZM15556@wobbly.melbourne.sgi.com> Date: Mon, 14 Aug 2000 12:05:12 -0500 In-Reply-To: Andrew Ho "xfs_copy" (Aug 14, 11:50am) References: <39975191.40397BE2@coredp.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: xfs_copy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Aug 14, 11:50am, Andrew Ho wrote: > Subject: xfs_copy > The error meesages of /usr/src/linux-2.4-xfs/cmd/xfs/copy/ > > Makefile:35: /usr/include/make/commondefs: No such file or directory > Makefile:52: no file name for `include' > make: *** No rule to make target `/usr/include/make/commondefs'. Stop > > Thank you for your attention. > yeah - that's an IRIX smake Makefile & hasn't been ported to Linux at all ... not sure why copy is even in the Linux tree. perhaps it should be removed until/if someone actually ports it to Linux. xfsdump/xfsrestore seem (to me) to provide a similar function to copy, so I'm not sure that porting it is all that useful anyway (Steve? Russell? - you guys know the history of this one better than I do). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 13 19:17:22 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 19:17:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27516 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 19:16:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA08985 for ; Sun, 13 Aug 2000 19:22:53 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) From: ivanr@melbourne.sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21576; Mon, 14 Aug 2000 12:15:27 +1000 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA18142; Mon, 14 Aug 2000 12:15:26 +1000 (EST) Date: Mon, 14 Aug 2000 12:15:26 +1000 To: Nathan Scott cc: Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: xfs_copy In-Reply-To: <10008141205.ZM15556@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 14 Aug 2000, Nathan Scott wrote: > On Aug 14, 11:50am, Andrew Ho wrote: > > Subject: xfs_copy > > The error meesages of /usr/src/linux-2.4-xfs/cmd/xfs/copy/ > > > > Makefile:35: /usr/include/make/commondefs: No such file or directory > > Makefile:52: no file name for `include' > > make: *** No rule to make target `/usr/include/make/commondefs'. Stop > > > > Thank you for your attention. > > yeah - that's an IRIX smake Makefile & hasn't been ported to > Linux at all ... not sure why copy is even in the Linux tree. > perhaps it should be removed until/if someone actually ports > it to Linux. xfsdump/xfsrestore seem (to me) to provide a > similar function to copy, so I'm not sure that porting it is > all that useful anyway (Steve? Russell? - you guys know the > history of this one better than I do). (Under IRIX) xfs_copy will copy unmounted xfs filesystems, whereas xfsdump/xfsrestore use mounted filesystems. The only real difference between xfs_copy and dd, is that xfs_copy will generate a new filesystem uuid for the copied filesystems. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Sun Aug 13 19:24:50 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 19:24:40 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:19615 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 19:24:23 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id VAA08373; Sun, 13 Aug 2000 21:24:20 -0500 (CDT) Date: Sun, 13 Aug 2000 21:24:20 -0500 (CDT) Message-Id: <200008140224.VAA08373@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: How do you get stat64 to work? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have created file 8GB on a xfs file system. I cannot seem to get stat64 to give the right size of the file. Any suggestions? Bill Jones From owner-linux-xfs@oss.sgi.com Sun Aug 13 19:33:40 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 19:33:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27456 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 19:33:06 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA20088 for ; Sun, 13 Aug 2000 19:25:28 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21731; Mon, 14 Aug 2000 12:30:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA15643; Mon, 14 Aug 2000 12:30:29 +1000 (EST) From: "Nathan Scott" Message-Id: <10008141230.ZM15654@wobbly.melbourne.sgi.com> Date: Mon, 14 Aug 2000 12:30:26 -0500 In-Reply-To: William L Jones "How do you get stat64 to work?" (Aug 14, 12:25pm) References: <200008140224.VAA08373@spica.cc.utexas.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: William L Jones , linux-xfs@oss.sgi.com Subject: Re: How do you get stat64 to work? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hey Bill, On Aug 14, 12:25pm, William L Jones wrote: > Subject: How do you get stat64 to work? > > I have created file 8GB on a xfs file system. I cannot seem to get > stat64 to give the right size of the file. Any suggestions? > I think you need to at least #define _LARGEFILE64_SOURCE, which sets __USE_LARGEFILE64 - check out /usr/include/features.h For the XFS commands we #define _GNU_SOURCE which includes _LARGEFILE64_SOURCE but gives other stuff we need too, like getsubopts, and so on. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 13 20:13:31 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 20:13:20 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:32160 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 20:13:04 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id WAA08752; Sun, 13 Aug 2000 22:13:02 -0500 (CDT) Date: Sun, 13 Aug 2000 22:13:02 -0500 (CDT) Message-Id: <200008140313.WAA08752@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I think the problem that I am having is that I am getting a comparability version of stat64. I was able to do a stat64 sys call and that gave me the right answer. The large file compile time options may not really do anything depending on how the libraries were builed. I suppect the system librires I have are dong the old stat syscall and then using that information to fill in the stat64 structures. Same for all the 64 bit file operations. >hey Bill, > >On Aug 14, 12:25pm, William L Jones wrote: >> Subject: How do you get stat64 to work? >> >> I have created file 8GB on a xfs file system. I cannot seem to get >> stat64 to give the right size of the file. Any suggestions? >> > >I think you need to at least #define _LARGEFILE64_SOURCE, which >sets __USE_LARGEFILE64 - check out /usr/include/features.h > >For the XFS commands we #define _GNU_SOURCE which includes >_LARGEFILE64_SOURCE but gives other stuff we need too, >like getsubopts, and so on. > >cheers. > >Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 13 20:24:11 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 20:24:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51012 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 20:23:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA22679 for ; Sun, 13 Aug 2000 20:16:08 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21977 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 13:21:12 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA08204 for ; Mon, 14 Aug 2000 13:21:11 +1000 (EST) Message-Id: <200008140321.NAA08204@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: Re: xfs_copy In-reply-to: Your message of "Mon, 14 Aug 2000 12:15:26 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Aug 2000 13:21:11 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ivanr@melbourne.sgi.com writes: => (Under IRIX) xfs_copy will copy unmounted xfs filesystems, whereas => xfsdump/xfsrestore use mounted filesystems. The only real difference => between xfs_copy and dd, is that xfs_copy will generate a new filesystem => uuid for the copied filesystems. xfs_copy also traverses the AGF & it seems only copies the blocks that are actually in use by the filesystem (neat but that means we'd have to SIM -> libxfs it as well as porting it to linux). I think the best option is to remove xfs_copy from the tree. Does anyone have any objections to me nuking it? The already mentioned alternatives are dd and xfs_dump/restore. If uuids are the issue (and xfs_db doesn't already do what is needed), it would be really easy to write a tool to manipulate them as needed. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Aug 13 20:25:00 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 20:24:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54596 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 20:24:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA22696 for ; Sun, 13 Aug 2000 20:16:45 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21980 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 13:23:02 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA08216 for ; Mon, 14 Aug 2000 13:23:01 +1000 (EST) Message-Id: <200008140323.NAA08216@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: qa 005 & kernel bugs Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-10306365180" Date: Mon, 14 Aug 2000 13:23:01 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multipart MIME message. --==_Exmh_-10306365180 Content-Type: text/plain; charset=us-ascii In the process of fixing up qa 005, I've found two kernel bugs, unrelated to XFS. I've attached a patch which fixes both of them. 1. There's two different checks for hitting the maximum symlink depth, one with the maximum depth set at 8, the other at 32. The second one doesn't set the return code correctly and usually returns EISDIR instead of ELOOP. You can test this out by making a chain of symlinks and then touching each of them, you should see no error for symlink 1-7, then ELOOP for symlink 8-31, then EISDIR for 32 on. 2. If you mount "proc" on a read-only FS, then touch it, you'll hang the filesystem. This seems to be due to __follow_down returning an error code that is never checked and namei getting into an infinite loop. I've changed the loop in question to mimic the checking done in other places in namei, and it seems to have the expected behaviour now. I've attached a patch and a little test script. Note both the touches of the symlink should return ELOOP and the touch of proc should do nothing (ie not hang). I'd appreciate any feedback on the patch available, and some advice on where to go next would be good.. Ta. --==_Exmh_-10306365180 Content-Type: application/x-patch ; name="namei.patch" Content-Description: namei.patch Content-Disposition: attachment; filename="namei.patch" *** namei-current.c Mon Aug 14 12:04:35 2000 --- namei.c Mon Aug 14 11:38:42 2000 *************** *** 31,36 **** --- 31,37 ---- #include #define ACC_MODE(x) ("\000\004\002\006"[(x)&O_ACCMODE]) + #define MAX_LINK_DEPTH 8 /* [Feb-1997 T. Schoebel-Theuer] * Fundamental changes in the pathname lookup mechanisms (namei) *************** *** 307,313 **** static inline int do_follow_link(struct dentry *dentry, struct nameidata *nd) { int err; ! if (current->link_count >= 8) goto loop; current->link_count++; UPDATE_ATIME(dentry->d_inode); --- 308,314 ---- static inline int do_follow_link(struct dentry *dentry, struct nameidata *nd) { int err; ! if (current->link_count >= MAX_LINK_DEPTH) goto loop; current->link_count++; UPDATE_ATIME(dentry->d_inode); *************** *** 1006,1012 **** error = -ELOOP; if (flag & O_NOFOLLOW) goto exit_dput; ! do __follow_down(&nd->mnt,&dentry); while(d_mountpoint(dentry)); } error = -ENOENT; if (!dentry->d_inode) --- 1007,1014 ---- error = -ELOOP; if (flag & O_NOFOLLOW) goto exit_dput; ! while (__follow_down(&nd->mnt,&dentry) && d_mountpoint(dentry)) ! ; } error = -ENOENT; if (!dentry->d_inode) *************** *** 1125,1134 **** putname(nd->last.name); goto exit; } ! if (count++==32) { dentry = nd->dentry; putname(nd->last.name); ! goto ok; } dir = nd->dentry; down(&dir->d_inode->i_sem); --- 1127,1137 ---- putname(nd->last.name); goto exit; } ! error = -ELOOP; ! if (count++ >= MAX_LINK_DEPTH) { dentry = nd->dentry; putname(nd->last.name); ! goto exit; } dir = nd->dentry; down(&dir->d_inode->i_sem); --==_Exmh_-10306365180 Content-Type: text/plain ; name="test"; charset=us-ascii Content-Description: test Content-Disposition: attachment; filename="test" #!/bin/sh # DEV1 is a scratch device (it gets clobbered!) # MOUNT is a mountpoint DEV1=/dev/your_scratch_device MOUNT=/mnt mkfs $DEV1 > /dev/null mount $DEV1 $MOUNT ln -s $MOUNT/fish $MOUNT/fish echo "touch infinite symlink" touch $MOUNT/fish mkdir $MOUNT/mp mount -o remount,ro $DEV1 mount -t proc none $MOUNT/mp echo "touch r/o infinite symlink" touch $MOUNT/fish echo "touch r/o mount point" touch $MOUNT/mp echo "done" umount $MOUNT/mp umount $DEV1 --==_Exmh_-10306365180-- From owner-linux-xfs@oss.sgi.com Sun Aug 13 20:50:00 2000 Received: by oss.sgi.com id ; Sun, 13 Aug 2000 20:49:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57726 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 13 Aug 2000 20:49:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA05006 for ; Sun, 13 Aug 2000 20:55:35 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) From: ivanr@melbourne.sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22209 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 13:48:10 +1000 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA22999; Mon, 14 Aug 2000 13:48:09 +1000 (EST) Date: Mon, 14 Aug 2000 13:48:09 +1000 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: xfs_copy In-Reply-To: <200008140321.NAA08204@clouds.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 14 Aug 2000, Daniel Moore wrote: > ivanr@melbourne.sgi.com writes: > > => (Under IRIX) xfs_copy will copy unmounted xfs filesystems, whereas > => xfsdump/xfsrestore use mounted filesystems. The only real difference > => between xfs_copy and dd, is that xfs_copy will generate a new filesystem > => uuid for the copied filesystems. > > xfs_copy also traverses the AGF & it seems only copies the blocks that > are actually in use by the filesystem (neat but that means we'd have > to SIM -> libxfs it as well as porting it to linux). > > I think the best option is to remove xfs_copy from the tree. Does > anyone have any objections to me nuking it? > > The already mentioned alternatives are dd and xfs_dump/restore. > If uuids are the issue (and xfs_db doesn't already do what is > needed), it would be really easy to write a tool to manipulate > them as needed. xfsdump has a problem if two filesystems have the same uuid, as it uses the uuid to identify the filesystem in the inventory. While this may not be a common occurance, it still might be worth putting the uuid generator on the todo list (in place of porting xfs_copy). Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Mon Aug 14 03:37:46 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 03:37:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:9589 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 03:37:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id DAA19036 for ; Mon, 14 Aug 2000 03:29:45 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA24567 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 14 Aug 2000 20:34:49 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id UAA37551 for linux-xfs@oss.sgi.com; Mon, 14 Aug 2000 20:34:47 +1000 (EST) Date: Mon, 14 Aug 2000 20:34:47 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008141034.UAA37551@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72012a Date: Mon Aug 14 03:34:08 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/004 - 1.4 cmd/xfs/stress/004.out - 1.2 - make output deteministic - don't rely on sync completing quickly. From owner-linux-xfs@oss.sgi.com Mon Aug 14 06:38:26 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 06:38:06 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:11536 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 06:37:45 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA00113 for ; Mon, 14 Aug 2000 06:30:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA19693; Mon, 14 Aug 2000 08:36:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA75112; Mon, 14 Aug 2000 08:36:27 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA10065; Mon, 14 Aug 2000 08:33:57 -0500 Message-Id: <200008141333.IAA10065@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: William L Jones cc: linux-xfs@oss.sgi.com In-Reply-To: Message from William L Jones of "Sun, 13 Aug 2000 22:13:02 CDT." <200008140313.WAA08752@spica.cc.utexas.edu> Date: Mon, 14 Aug 2000 08:33:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I think the problem that I am having is that I am getting a comparability > version of stat64. I was able to do a stat64 sys call and that gave me the > right answer. The large file compile time options may not really do anything > depending on how the libraries were builed. I suppect the system librires > I have are dong the old stat syscall and then using that information to fill in > the stat64 structures. Same for all the 64 bit file operations. > > This could be true - RedHat 6.2 has libraries which do the correct thing when it comes to these functions, but this is probably not true for all glibc versions out there. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 14 06:44:36 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 06:44:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27153 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 06:44:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA00736 for ; Mon, 14 Aug 2000 06:36:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA93936; Mon, 14 Aug 2000 08:42:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id IAA63973; Mon, 14 Aug 2000 08:42:49 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA10830; Mon, 14 Aug 2000 08:40:19 -0500 Message-Id: <200008141340.IAA10830@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: xfs_copy In-Reply-To: Message from Daniel Moore of "Mon, 14 Aug 2000 13:21:11 +1000." <200008140321.NAA08204@clouds.melbourne.sgi.com> Date: Mon, 14 Aug 2000 08:40:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > ivanr@melbourne.sgi.com writes: > > => (Under IRIX) xfs_copy will copy unmounted xfs filesystems, whereas > => xfsdump/xfsrestore use mounted filesystems. The only real difference > => between xfs_copy and dd, is that xfs_copy will generate a new filesystem > => uuid for the copied filesystems. > > xfs_copy also traverses the AGF & it seems only copies the blocks that > are actually in use by the filesystem (neat but that means we'd have > to SIM -> libxfs it as well as porting it to linux). > > I think the best option is to remove xfs_copy from the tree. Does > anyone have any objections to me nuking it? > > The already mentioned alternatives are dd and xfs_dump/restore. > If uuids are the issue (and xfs_db doesn't already do what is > needed), it would be really easy to write a tool to manipulate > them as needed. dd does not really cut it unless your filesystem is full. How much of libsim does xfs_copy really use? A quick scan of the source does not seem to indicate that much. It reads the super block and sets up a mount structure so it can do size calculations, apart from that I cannot see much in there. I would prefer to have xfs_copy survive if possible. Steve > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Aug 14 07:05:26 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 07:05:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21526 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 07:04:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA03198 for ; Mon, 14 Aug 2000 06:57:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA86485; Mon, 14 Aug 2000 09:03:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA86433; Mon, 14 Aug 2000 09:03:35 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA12732; Mon, 14 Aug 2000 09:01:05 -0500 Message-Id: <200008141401.JAA12732@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "T. Nimmo" cc: linux-xfs@oss.sgi.com Subject: Re: Feedback: Installing Oracle 8.1.6 on Linux w/xfs In-Reply-To: Message from "T. Nimmo" of "Sat, 12 Aug 2000 17:57:00 PDT." <000201c004c1$64e98a40$06fefec0@nimmo.org> Date: Mon, 14 Aug 2000 09:01:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If at all possible could you please download the latest version of the source - there are new patches from yesterday (8/13) at ftp://oss.sgi.com/projects/xfs/download/ and the cvs tree should always be upto date. Two fixes went in last week, the second not until Thursday, which could have an effect on this. If this does not help, or you have already done this then we would definitely like to chase this one down. It would also be helpful to know if you have the KIOBUF config option on or off. We think it should now make no difference, prior to these two fixes it was more likely to produce corruption. Thanks Steve > I started building the linux-2.4-xfs kernel on a RedHat 6.2 O/S back on > 8/4-8/7; which wasn't stable and locked up the machine. mount/umount or high > file copy rates to xfs filesystems seemed to lock it quickly. By 8/9 this > problem disappeared and the system no longer locks. Now with the scene > setup... > > I've been building a Oracle 8.1.6 for Linux installation using xfs/scsi for > the data volumes with good results. I have Oracle installed on a ext2/scsi > filesystem. After this test I rebuilt the Oracle installation tree on the > same scsi drive using xfs. I used fdisk/mkfs to create the xfs filesystem. > > Copying to a xfs volume, the Oracle installer runs along doing it's normal > thing, until the end of the installation. At the 98% mark the installer > relinks the Oracle executables as part of it's routine. However the linker > 'ld' isn't able to properly read the Oracle library files to relink the > executables. It's like the file contents are messed up or 'ld' can't read > the Oracle library file contents or something. Really wierd! > > If I scratch the Oracle installation tree and reinstall it back to normal on > ext2 it installs just fine. The Oracle datafiles on xfs seem to read/write > perfectly as I can make Oracle do it's thing with no hiccups. > > All of my Oracle xfs filesystems are single sliced on 9 scsi drives and 3 > atapi drives. Most filesystems have 5-7 ###MB files with ~6GB across 11 > filesystems. The 12th filesystem contains the Oracle installation > (/app/oracle/product/blah-blah). > > Anyone have any thoughts about why the Oracle installer can't read libraries > and relink executables on a xfs filesystem? > > Thanks, Tim... From owner-linux-xfs@oss.sgi.com Mon Aug 14 09:15:47 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 09:15:37 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:64694 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 09:15:25 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id LAA15496; Mon, 14 Aug 2000 11:12:01 -0500 (CDT) Message-Id: <4.2.0.58.20000814111242.01690610@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 14 Aug 2000 11:13:42 -0500 To: Steve Lord , William L Jones From: "William L. Jones" Subject: Re: Cc: linux-xfs@oss.sgi.com In-Reply-To: <200008141333.IAA10065@jen.americas.sgi.com> References: <200008140313.WAA08752@spica.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I running redhat 6.1. I have to do a upgrade. At 08:33 AM 8/14/00 -0500, Steve Lord wrote: > > > > I think the problem that I am having is that I am getting a comparability > > version of stat64. I was able to do a stat64 sys call and that gave me the > > right answer. The large file compile time options may not really do > anything > > depending on how the libraries were builed. I suppect the system librires > > I have are dong the old stat syscall and then using that information to > fill >in > > the stat64 structures. Same for all the 64 bit file operations. > > > > > > >This could be true - RedHat 6.2 has libraries which do the correct thing >when it comes to these functions, but this is probably not true for all >glibc versions out there. > >Steve From owner-linux-xfs@oss.sgi.com Mon Aug 14 09:25:37 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 09:25:28 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:2919 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 09:25:04 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA14087 for ; Mon, 14 Aug 2000 09:17:29 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA78659 for ; Mon, 14 Aug 2000 11:23:48 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id LAA11774 for ; Mon, 14 Aug 2000 11:23:47 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7EGNH614959 for linux-xfs@oss.sgi.com; Mon, 14 Aug 2000 11:23:17 -0500 Date: Mon, 14 Aug 2000 11:23:17 -0500 From: Russell Cattelan Message-Id: <200008141623.e7EGNH614959@gibble.americas.sgi.com> Subject: TAKE - HEADS UP. KIOBUF now mount time option. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This removes the compile time decision and moves it to a mount time option. To use kiobuf's on a paticular file system use the kio option ie mount -t xfs -o kio /dev/ / or in fstab. /dev/ / xfs rw,noauto,kio 0 0 A message will be printed out the console for all filesystems using kiobufs. Date: Mon Aug 14 09:18:32 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72021a linux/fs/Config.in - 1.39 - Remove CONFIG_KIOBUF_IO option... code allways compiled in, move to mount flag. linux/fs/pagebuf/page_buf.c - 1.23 linux/fs/pagebuf/page_buf_io.c - 1.22 - Use mount flag to check for KIOBUF io. From owner-linux-xfs@oss.sgi.com Mon Aug 14 11:19:33 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 11:19:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39229 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 11:18:54 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02247; Mon, 14 Aug 2000 11:25:02 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA19670; Mon, 14 Aug 2000 11:18:53 -0700 (PDT) Date: Mon, 14 Aug 2000 11:18:53 -0700 (PDT) Message-Id: <200008141818.LAA19670@info.engr.sgi.com> X-Pv-Incident: 798910 webPV: fsgi075.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (pma@sgi.com) Subject: BUG 798910 - xfsdump -I can't find mnt= mount point To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=798910 Submitter : pma Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs Status : open Description : An xfs filesystem was backed up daily via xfsdump. The mount point of the filesystem was changed, and xfsdump was called to back up the filesystem with the new mount point. When xfsdump -I was called using the NEW filesystem mount point, it failed to retrieve any information, and in fact gave this: xfsdump:INV:open failed on mount point "efs:/groups/ulib" If you run xfsdump -I with mnt= the ORIGINAL mount point, you can see the entry for the NEW mount point. From owner-linux-xfs@oss.sgi.com Mon Aug 14 12:17:53 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 12:17:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32112 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 12:17:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21177 for ; Mon, 14 Aug 2000 12:09:30 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA54336 for ; Mon, 14 Aug 2000 14:14:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA20148 for ; Mon, 14 Aug 2000 14:14:33 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA21368; Mon, 14 Aug 2000 14:12:01 -0500 Message-Id: <200008141912.OAA21368@jen.americas.sgi.com> Date: Mon, 14 Aug 2000 14:12:01 -0500 Subject: TAKE - small locking fix in write path To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This could cause pauses in the write path sometimes - I think, basically a missing wakeup when unlocking a page. Date: Mon Aug 14 12:13:36 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72070a linux/fs/xfs/linux/xfs_lrw.c - 1.51 - Use UnlockPage rather than just clearing the locked bit - there were a couple of these. From owner-linux-xfs@oss.sgi.com Mon Aug 14 14:33:24 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 14:33:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16468 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 14:33:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA07963 for ; Mon, 14 Aug 2000 14:39:12 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA28896; Tue, 15 Aug 2000 07:31:47 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA16888; Tue, 15 Aug 2000 07:31:46 +1000 (EST) From: "Nathan Scott" Message-Id: <10008150731.ZM16890@wobbly.melbourne.sgi.com> Date: Tue, 15 Aug 2000 07:31:45 -0500 In-Reply-To: Steve Lord "Re: xfs_copy" (Aug 14, 11:44pm) References: <200008141340.IAA10830@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Steve Lord , Daniel Moore Subject: Re: xfs_copy Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, On Aug 14, 11:44pm, Steve Lord wrote: > Subject: Re: xfs_copy > ... > dd does not really cut it unless your filesystem is full. How much of > libsim does xfs_copy really use? A quick scan of the source does not seem > to indicate that much. It reads the super block and sets up a mount > structure so it can do size calculations, apart from that I cannot see > much in there. > > I would prefer to have xfs_copy survive if possible. > I'll add this to the list. From a look at the source, this will be a no-brainer to de-SIM - I'll do that this afternoon, + setup a Linux Makefile, etc - the hard work here will be porting from the IRIX arena model to pthreads & testing it thoroughly. I think xfs{dump,restore} has a similar set of issues ... perhaps Tim and/or Ivan could have a look at this after they're done with porting those tools. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 14 16:47:35 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 16:47:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59963 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 16:46:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA26959 for ; Mon, 14 Aug 2000 16:39:21 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29883 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 15 Aug 2000 09:45:40 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA07565 for linux-xfs@oss.sgi.com; Tue, 15 Aug 2000 09:45:38 +1000 (EST) Date: Tue, 15 Aug 2000 09:45:38 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008142345.JAA07565@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_copy Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This now compiles and links on Linux - uses libxfs and libuuid. Its a long way from complete though - mainly needs the thread/sproc stuff to be converted to pthreads (or equivalent) ... but at least its at the point where gdb can become useful. Currently the IRIX threading routines are all stubbed out (see head of locks.h) & will trip an assert if called. cheers. Modid: 2.4.0-test1-xfs:slinx:72106a Date: Mon Aug 14 16:40:17 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/copy/Makefile - 1.6 - convert this to be a gmake Makefile, rather than an smake one. cmd/xfs/copy/locks.c - 1.6 cmd/xfs/copy/locks.h - 1.5 - just enough to get this file compiling on Linux, no more. cmd/xfs/copy/xfs_copy.c - 1.18 - just enough to get this file compiling on Linux, convert over to libxfs. plenty of porting work to do here (some direct IO stuff, lots of thread stuff). From owner-linux-xfs@oss.sgi.com Mon Aug 14 19:26:56 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 19:26:47 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4953 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 19:26:22 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA10514; Mon, 14 Aug 2000 19:18:46 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA68260; Mon, 14 Aug 2000 19:25:03 -0700 (PDT) Date: Mon, 14 Aug 2000 19:25:03 -0700 (PDT) Message-Id: <200008150225.TAA68260@feature.engr.sgi.com> X-Pv-Incident: 798910 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ivanr@engr.sgi.com) Subject: ADD 798910 - xfsdump -I can't find mnt= mount point To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : pma Status : open Assigned Engineer : nb Priority : 2 *Modified Date : 08/14/00 *Modified User : ivanr *Modified User Domain : engr *Description : An xfs filesystem was backed up daily via xfsdump. The mount point of the filesystem was changed, and xfsdump was called to back up the filesystem with the new mount point. When xfsdump -I was called using the NEW filesystem mount point, it failed to retrieve any information, and in fact gave this: xfsdump:INV:open failed on mount point "efs:/groups/ulib" If you run xfsdump -I with mnt= the ORIGINAL mount point, you can see the entry for the NEW mount point. ========================== ADDITIONAL INFORMATION (ADD) From: ivanr@melbourne.sgi.com Date: Aug 14 2000 07:25:03PM [pvnews version: 1.71] ========================== On Mon, 14 Aug 2000, pma@sgi.com wrote: > View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=798910 > > Submitter : pma Submitter Domain : sgi.com > Assigned Engineer : nb Assigned Domain : sgi.com > Assigned Group : xfs-linux Category : software > Customer Reported : F Priority : 2 > Project : xfs Status : open > Description : > An xfs filesystem was backed up daily via xfsdump. The mount point of the > filesystem was changed, and xfsdump was called to back up the filesystem > with the new mount point. When xfsdump -I was called using the NEW > filesystem mount point, it failed to retrieve any information, and in fact gave this: > xfsdump:INV:open failed on mount point "efs:/groups/ulib" > > If you run xfsdump -I with mnt= the ORIGINAL mount point, you can see > the entry for the NEW mount point. I assume from your wording that this is an IRIX bug, rather than a Linux bug? Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Mon Aug 14 19:27:16 2000 Received: by oss.sgi.com id ; Mon, 14 Aug 2000 19:27:06 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25982 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 14 Aug 2000 19:27:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA01433 for ; Mon, 14 Aug 2000 19:33:07 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01199 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 15 Aug 2000 12:25:42 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA19527 for linux-xfs@oss.sgi.com; Tue, 15 Aug 2000 12:25:39 +1000 (EST) Date: Tue, 15 Aug 2000 12:25:39 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008150225.MAA19527@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - namei patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is the patch I sent out yesterday. I'll work on getting this sent to the right person. Modid: 2.4.0-test1-xfs:slinx:72110a Date: Mon Aug 14 19:25:06 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/namei.c - 1.19 - fix ELOOP return from deep symlinks as well as mount proc on ro fs bug. From owner-linux-xfs@oss.sgi.com Tue Aug 15 12:54:33 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 12:54:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59211 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 12:54:11 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05854 for ; Tue, 15 Aug 2000 13:00:19 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA80574 for ; Tue, 15 Aug 2000 14:52:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA32394 for ; Tue, 15 Aug 2000 14:52:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA00930; Tue, 15 Aug 2000 14:50:11 -0500 Message-Id: <200008151950.OAA00930@jen.americas.sgi.com> Date: Tue, 15 Aug 2000 14:50:11 -0500 Subject: TAKE - bring over fsr fix from irix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Aug 15 12:51:08 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72141a linux/fs/xfs/xfs_dfrag.c - 1.22 - Enforce that the target and tmp files either both have or both do not have ext attrs to ensure a consistent XFS_IFORK_DSIZE size. (PV 791117) cmd/xfs/fsr/fsr_xfs.c - 1.9 - Adds extended attrs to the tmp file when the target has extended attrs to maintain the same dfork size. Also added test code to reproduce error. (PV 791117) From owner-linux-xfs@oss.sgi.com Tue Aug 15 13:04:13 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 13:04:03 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:28651 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 13:03:41 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id PAA01274 for ; Tue, 15 Aug 2000 15:03:39 -0500 (CDT) Message-Id: <4.2.0.58.20000815145814.01675cf0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 15 Aug 2000 15:05:23 -0500 To: linux-xfs@oss.sgi.com From: "William L. Jones" Subject: Possible bug in open_by_handle Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing In xfs_ioctl.c in open_by_handle fill_name_hash is call with len: /* * Obtain/create a 'dentry'. */ sqstr.name = sname; sqstr.len = 2 * hlen; sqstr.hash = full_name_hash(sname, hlen); ^^^^ shouldn't be 2 * len: /* * Obtain/create a 'dentry'. */ sqstr.name = sname; sqstr.len = 2 * hlen; sqstr.hash = full_name_hash(sname, 2 * len); ^^^^^^^ From owner-linux-xfs@oss.sgi.com Tue Aug 15 13:12:13 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 13:12:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20814 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 13:11:48 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA04736 for ; Tue, 15 Aug 2000 13:17:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA90902; Tue, 15 Aug 2000 15:10:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA21524; Tue, 15 Aug 2000 15:10:29 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA01650; Tue, 15 Aug 2000 15:07:47 -0500 Message-Id: <200008152007.PAA01650@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "William L. Jones" cc: linux-xfs@oss.sgi.com Subject: Re: Possible bug in open_by_handle In-Reply-To: Message from "William L. Jones" of "Tue, 15 Aug 2000 15:05:23 CDT." <4.2.0.58.20000815145814.01675cf0@127.0.0.1> Date: Tue, 15 Aug 2000 15:07:47 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > sqstr.name = sname; > sqstr.len = 2 * hlen; > sqstr.hash = full_name_hash(sname, 2 * len); > ^^^^^^^ > Or 2 * hlen even? Steve From owner-linux-xfs@oss.sgi.com Tue Aug 15 13:27:54 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 13:27:44 -0700 Received: from Cantor.suse.de ([194.112.123.193]:28167 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 15 Aug 2000 13:27:37 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 4D6AD1E115; Tue, 15 Aug 2000 22:27:36 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 1A25010A034; Tue, 15 Aug 2000 22:27:36 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 5DDDE2F300; Tue, 15 Aug 2000 22:27:34 +0200 (MEST) Date: Tue, 15 Aug 2000 22:27:34 +0200 From: "Andi Kleen" To: Steve Lord Cc: "William L. Jones" , linux-xfs@oss.sgi.com Subject: Re: Possible bug in open_by_handle Message-ID: <20000815222734.A13055@gruyere.muc.suse.de> References: <200008152007.PAA01650@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008152007.PAA01650@jen.americas.sgi.com>; from lord@sgi.com on Tue, Aug 15, 2000 at 03:07:47PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Aug 15, 2000 at 03:07:47PM -0500, Steve Lord wrote: > > > sqstr.name = sname; > > sqstr.len = 2 * hlen; > > sqstr.hash = full_name_hash(sname, 2 * len); > > ^^^^^^^ > > > > > Or 2 * hlen even? Or no name at all, the dcache should take anonymous dentries [because nfsfh.c uses them] -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 15 14:33:54 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 14:33:44 -0700 Received: from stimpy.multiweb.net ([195.114.226.251]:18187 "EHLO stimpy.multiweb.nl") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 14:33:21 -0700 Received: from auto-nb1.xs4all.nl ([192.168.13.14]) by stimpy.multiweb.nl (8.9.3/8.9.3) with ESMTP id XAA03036 for ; Tue, 15 Aug 2000 23:33:15 +0200 Message-Id: <4.3.2.7.2.20000815232910.00b20ac0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Aug 2000 23:30:37 +0200 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Broken Link on oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, from http://oss.sgi.com/projects/xfs/ At the Ottawa Linux Symposium, an updated presentation on porting XFS to Linux was given: http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm This is a 404.... Where is it :-) -- Seth "Have I gone mad?" "Well, yes, but that's beyond the scope of this article." From owner-linux-xfs@oss.sgi.com Tue Aug 15 15:08:44 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 15:08:34 -0700 Received: from [64.240.27.5] ([64.240.27.5]:25604 "EHLO dns.tricord.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 15:08:12 -0700 Received: by dns.tricord with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 17:08:00 -0500 Message-ID: From: "Mostek, Jim" To: 'Seth Mos' , linux-xfs@oss.sgi.com Subject: RE: Broken Link on oss.sgi.com Date: Tue, 15 Aug 2000 17:10:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm works for me. Jim -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Tuesday, August 15, 2000 4:31 PM To: linux-xfs@oss.sgi.com Subject: Broken Link on oss.sgi.com Hi, from http://oss.sgi.com/projects/xfs/ At the Ottawa Linux Symposium, an updated presentation on porting XFS to Linux was given: http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm This is a 404.... Where is it :-) -- Seth "Have I gone mad?" "Well, yes, but that's beyond the scope of this article." From owner-linux-xfs@oss.sgi.com Tue Aug 15 15:35:54 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 15:35:44 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:38129 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 15:35:27 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id RAA02659; Tue, 15 Aug 2000 17:35:19 -0500 (CDT) Message-Id: <4.2.0.58.20000815171608.016a0c20@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 15 Aug 2000 17:36:37 -0500 To: "Andi Kleen" , Steve Lord From: "William L. Jones" Subject: Re: Possible bug in open_by_handle Cc: "William L. Jones" , linux-xfs@oss.sgi.com In-Reply-To: <20000815222734.A13055@gruyere.muc.suse.de> References: <200008152007.PAA01650@jen.americas.sgi.com> <200008152007.PAA01650@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I just looked at the nfsfh.c code. It looks like it just calls d_alloc_root if it cannot find a non anonymous indoe in the dcache. Is this what you mean by an anonymous dentry? Why is the nfsfs.c code so carefully to look for a non anonymous dcache entry. Is it just trying to save space in the dcache? Bill Jones From owner-linux-xfs@oss.sgi.com Tue Aug 15 16:30:15 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 16:30:05 -0700 Received: from Cantor.suse.de ([194.112.123.193]:14352 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 15 Aug 2000 16:29:51 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 46D491E28F; Wed, 16 Aug 2000 01:29:49 +0200 (MEST) Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id AEC6510A035; Wed, 16 Aug 2000 01:29:48 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 03D3B2F300; Wed, 16 Aug 2000 01:29:43 +0200 (MEST) Date: Wed, 16 Aug 2000 01:29:43 +0200 From: "Andi Kleen" To: "William L. Jones" Cc: "Andi Kleen" , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Possible bug in open_by_handle Message-ID: <20000816012942.A15731@gruyere.muc.suse.de> References: <200008152007.PAA01650@jen.americas.sgi.com> <200008152007.PAA01650@jen.americas.sgi.com> <20000815222734.A13055@gruyere.muc.suse.de> <4.2.0.58.20000815171608.016a0c20@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.0.58.20000815171608.016a0c20@127.0.0.1>; from jones@tacc.cc.utexas.edu on Tue, Aug 15, 2000 at 05:36:37PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Aug 15, 2000 at 05:36:37PM -0500, William L. Jones wrote: > > > I just looked at the nfsfh.c code. It looks like it just calls > d_alloc_root if it cannot find a non anonymous indoe in the dcache. Is this > what you mean by an anonymous dentry? Yes. > > Why is the nfsfs.c code so carefully to look for a non anonymous dcache entry. > Is it just trying to save space in the dcache? For some access checking the nfsfh code needs to know the full path name of the file. For that it needs to notice when the filehandle is deleted, which is easiest when the dentry is connected to the normal dentry tree (otherwise it has to search the directory) For the "virtual hardlinks" the xfs file handle code uses this is not a problem, because they don't need file names and cannot be deleted. -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 15 16:51:04 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 16:50:55 -0700 Received: from Cantor.suse.de ([194.112.123.193]:60944 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 15 Aug 2000 16:50:34 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 50B1C1E295; Wed, 16 Aug 2000 01:50:32 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id C04F810A035; Wed, 16 Aug 2000 01:50:31 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 829962F300; Wed, 16 Aug 2000 01:50:31 +0200 (MEST) Date: Wed, 16 Aug 2000 01:50:31 +0200 From: "Andi Kleen" Cc: "William L. Jones" , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Possible bug in open_by_handle Message-ID: <20000816015031.A15971@gruyere.muc.suse.de> References: <200008152007.PAA01650@jen.americas.sgi.com> <200008152007.PAA01650@jen.americas.sgi.com> <20000815222734.A13055@gruyere.muc.suse.de> <4.2.0.58.20000815171608.016a0c20@127.0.0.1> <20000816012942.A15731@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000816012942.A15731@gruyere.muc.suse.de>; from ak@suse.de on Wed, Aug 16, 2000 at 01:29:42AM +0200 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Aug 16, 2000 at 01:29:42AM +0200, Andi Kleen wrote: > For some access checking the nfsfh code needs to know the full path name > of the file. For that it needs to notice when the filehandle is deleted, > which is easiest when the dentry is connected to the normal dentry tree > (otherwise it has to search the directory) The other reason I forgot to mention is that there can only be a single dentry/link in the system for various locking reasons. The connection to the tree can be either done by you, or by the dcache via the inode dentry list, but of course you have to check first if it doesn't already exist. (again does not apply to xfs open_by_handle, because it is a new link) -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 15 16:56:04 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 16:55:55 -0700 Received: from smtp4.xs4all.nl ([194.109.6.50]:28611 "EHLO smtp4.xs4all.nl") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 16:55:46 -0700 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by smtp4.xs4all.nl (8.9.3/8.9.3) with ESMTP id BAA26188 for ; Wed, 16 Aug 2000 01:55:44 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id BAA08501 for ; Wed, 16 Aug 2000 01:55:44 +0200 (CEST) Date: Wed, 16 Aug 2000 01:55:44 +0200 (CEST) From: Seth Mos To: linux-xfs@oss.sgi.com Subject: RE: Broken Link on oss.sgi.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 15 Aug 2000, Mostek, Jim wrote: > > http://oss.sgi.com/projects/xfs/papers/ols2000/ols-xfs.htm works for me. > > Jim Crud I'm blaming the nightly mozilla build ;-) Excuse me. From owner-linux-xfs@oss.sgi.com Tue Aug 15 17:49:05 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 17:48:55 -0700 Received: from smtp4.xs4all.nl ([194.109.6.50]:6358 "EHLO smtp4.xs4all.nl") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 17:48:37 -0700 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by smtp4.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA07579 for ; Wed, 16 Aug 2000 02:48:35 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA10749 for ; Wed, 16 Aug 2000 02:48:35 +0200 (CEST) Date: Wed, 16 Aug 2000 02:48:35 +0200 (CEST) From: Seth Mos To: linux-xfs@oss.sgi.com Subject: xfs module size Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi After compiling xfs as a nodule it bloats to 9.7MB. Now who has the largest module on the block ;-) Some reference: Compiled with minimal options for installers and no debugging. - kernel xfs as module is 580K xfs.o module is 9.7M and pagebuf.o is 810K Module loads ok and works. - Kernel xfs compiled in is 889K also works Anyone can explain what happened here? CVS version compiled without debugging on a standard redhat 6.2 machine. I did noticed 2 definitions of CONFIG_PAGE_BUF=m in the CONFIG_XFS_* part of the config. I don't think that is/should be a problem. I could be wrong. Bye Seth From owner-linux-xfs@oss.sgi.com Tue Aug 15 18:03:35 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 18:03:25 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28517 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 18:03:02 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA04113 for ; Tue, 15 Aug 2000 18:09:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA52636; Tue, 15 Aug 2000 20:01:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id UAA23535; Tue, 15 Aug 2000 20:01:44 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id TAA12215; Tue, 15 Aug 2000 19:59:00 -0500 Message-Id: <200008160059.TAA12215@jen.americas.sgi.com> To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: xfs module size In-reply-to: Your message of "Wed, 16 Aug 2000 02:48:35 +0200 Date: Tue, 15 Aug 2000 19:58:59 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing It is the -g3 thrown into the command line, so it is basically all symbol table info. We are doing this at the moment to aid in debugging. You could turn it off in the makefiles in fs/pagebuf fs/xfs and fs/xfs/linux Steve > Hi > > After compiling xfs as a nodule it bloats to 9.7MB. > Now who has the largest module on the block ;-) > > Some reference: > Compiled with minimal options for installers and no debugging. > > - kernel xfs as module is 580K > xfs.o module is 9.7M and pagebuf.o is 810K > Module loads ok and works. > > - Kernel xfs compiled in is 889K > also works > > Anyone can explain what happened here? > CVS version compiled without debugging on a standard redhat 6.2 machine. > > I did noticed 2 definitions of CONFIG_PAGE_BUF=m in the CONFIG_XFS_* part > of the config. I don't think that is/should be a problem. > I could be wrong. > > Bye Seth From owner-linux-xfs@oss.sgi.com Tue Aug 15 18:05:15 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 18:05:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:36716 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 18:04:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA22548 for ; Tue, 15 Aug 2000 17:57:18 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09648 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 11:02:22 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA07749 for ; Wed, 16 Aug 2000 11:02:21 +1000 (EST) Message-Id: <200008160102.LAA07749@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: XFS SMP lockup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 11:02:20 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I just got an SMP lockup running qa 013 with yesterday's t-o-t. Unfortunately I haven't been able to reproduce it. I'm pretty sure the stress being run was: fsstress -v -p 5 -r -n 1000 Here's the kdb info: [1]kdb> cpu 0 Entering kdb (0xf4fe6000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc01f797a stext_lock+0x1a32 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf4fe7dac 0xc0132c1e insert_into_queues+0x5e (0xf750c180, 0xf750c180, 0xc013314c, 0x0) kernel .text 0xc0100000 0xc0132bc0 0xc0132c80 0xf4fe7dd8 0xc013335c getblk+0xa0 (0x100, 0xccf, 0x400) kernel .text 0xc0100000 0xc01332bc 0xc013338c 0xf4fe7df8 0xc016da3d rd_request+0xad (0xc033c128) kernel .text 0xc0100000 0xc016d990 0xc016dac0 0xf4fe7e08 0xc0164ab7 generic_unplug_device+0x2f (0xc033c128) kernel .text 0xc0100000 0xc0164a88 0xc0164ac8 0xf4fe7e18 0xf89049a2 [xfs]xfs_trigger_io+0x5a xfs .text 0xf888e060 0xf8904948 0xf89049b0 0xf4fe7e4c 0xf88d9086 [xfs]xlog_sync+0x2c6 (0xf5eaf8e0, 0xf5390000, 0x0) xfs .text 0xf888e060 0xf88d8dc0 0xf88d92dc 0xf4fe7e80 0xf88da9e9 [xfs]xlog_state_release_iclog+0x121 (0xf5eaf8e0, 0xf5390000) xfs .text 0xf888e060 0xf88da8c8 0xf88da9f4 0xf4fe7eac 0xf88dabd5 [xfs]xlog_state_sync_all+0xf5 (0xf5eaf8e0, 0x2) xfs .text 0xf888e060 0xf88daae0 0xf88dac9c 0xf4fe7ec8 0xf88d7ca7 [xfs]xfs_log_force+0x77 (0xf4699000, 0x0, 0x0, 0x2) xfs .text 0xf888e060 0xf88d7c30 0xf88d7cd4 0xf4fe7f50 0xf88f122f [xfs]xfs_syncsub+0xeb (0xf4699000, 0x31, 0x0, 0x0, 0xf4699000) xfs .text 0xf888e060 0xf88f1144 0xf88f2404 0xf4fe7f70 0xf88f113b [xfs]xfs_sync+0x1b (0xf4699000, 0x31, 0xf8920f80) xfs .text 0xf888e060 0xf88f1120 0xf88f1144 0xf4fe7f88 0xf8906304 [xfs]linvfs_write_super+0x24 (0xf53bde00) xfs .text 0xf888e060 0xf89062e0 0xf8906310 0xf4fe7f9c 0xc0136578 sync_supers+0x6c (0x0) kernel .text 0xc0100000 0xc013650c 0xc01365a0 0xf4fe7fb0 0xc0132844 fsync_dev+0x3c (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf4fe7fbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> [0]kdb> cpu 1 Entering kdb (0xf42ca000) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01fa1ea stext_lock+0x42a2 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf42cbef4 0xc01aa38e sym53c8xx_intr+0x62 (0x39, 0xf7cd6000, 0xf42cbf44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xf42cbf14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xf42cbf44, 0xf7f80b00, 0x632, 0xefd60ae0) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xf42cbf3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xefd60a80 ebx = 0x00000632 ecx = 0xefdf26c0 edx = 0xefdf26c0 esi = 0xefd60ae0 edi = 0x00000000 esp = 0xf42cbf78 eip = 0xc0132653 ebp = 0xf42cbf98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xf6a60018 es = 0xf6a60018 origeax = 0xffffff39 ®s = 0xf42cbf44 0xc0132653 sync_buffers+0x83 (0x0, 0x0) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xf42cbfb0 0xc0132819 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf42cbfbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 [1]more> kernel .text 0xc0100000 0xc010900c 0xc0109044 [1]kdb> [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xf7fb2000 00000001 00000000 0 001 stop 0xf7fb2340 init 0xf7f8c000 00000002 00000001 0 001 stop 0xf7f8c340 kswapd 0xf7f8a000 00000003 00000001 0 001 stop 0xf7f8a340 kflushd 0xf7f88000 00000004 00000001 0 001 stop 0xf7f88340 kupdate 0xf5c60000 00000350 00000001 0 000 stop 0xf5c60340 portmap 0xf6702000 00000429 00000001 0 000 stop 0xf6702340 rpciod 0xf645a000 00000430 00000001 0 000 stop 0xf645a340 lockd 0xf56fa000 00000453 00000001 0 000 stop 0xf56fa340 syslogd 0xf6806000 00000465 00000001 0 000 run 0xf6806340 klogd 0xf68c0000 00000482 00000001 0 001 stop 0xf68c0340 identd 0xf5c0e000 00000484 00000482 0 001 stop 0xf5c0e340 identd 0xf6646000 00000485 00000484 0 001 stop 0xf6646340 identd 0xf5a60000 00000486 00000484 0 001 stop 0xf5a60340 identd 0xf5e94000 00000487 00000484 0 001 stop 0xf5e94340 identd 0xf5dd6000 00000503 00000001 0 001 stop 0xf5dd6340 atd 0xf57c6000 00000520 00000001 0 000 stop 0xf57c6340 crond 0xf65f4000 00000537 00000001 0 000 stop 0xf65f4340 inetd 0xf5a56000 00000648 00000001 0 000 stop 0xf5a56340 pmcd 0xf5ea0000 00000801 00000001 0 000 stop 0xf5ea0340 pmlogger 0xf5ad2000 00000851 00000001 0 000 stop 0xf5ad2340 minilogd 0xf6986000 00000867 00000001 0 000 stop 0xf6986340 mingetty 0xf609e000 00000868 00000001 0 000 stop 0xf609e340 mingetty [1]more> 0xf5952000 00000869 00000001 0 000 stop 0xf5952340 mingetty 0xf574e000 00000870 00000001 0 001 stop 0xf574e340 mingetty 0xf56ca000 00000871 00000001 0 001 stop 0xf56ca340 mingetty 0xf69fc000 00000872 00000001 0 001 stop 0xf69fc340 mingetty 0xf64f8000 00000873 00000001 0 000 stop 0xf64f8340 login 0xf5eb2000 00000898 00000873 0 001 stop 0xf5eb2340 tcsh 0xf556e000 00001497 00000001 0 000 stop 0xf556e340 pagebuf_daemon 0xf55ba000 00001498 00000001 0 000 stop 0xf55ba340 page_daemon 0xf32fa000 00007853 00000898 0 000 stop 0xf32fa340 check 0xf361c000 00008084 00007853 0 000 stop 0xf361c340 sh 0xf2e70000 00008138 00008084 0 000 stop 0xf2e70340 fsstress 0xf42ca000 00008139 00008138 1 001 run 0xf42ca340*fsstress 0xf1e78000 00008140 00008138 0 001 stop 0xf1e78340 fsstress 0xe4092000 00008141 00008138 0 000 stop 0xe4092340 fsstress 0xf4044000 00008142 00008138 0 001 run 0xf4044340 fsstress 0xf4fe6000 00008143 00008138 1 000 run 0xf4fe6340 fsstress [1]kdb> btp 8139 EBP EIP Function(args) 0xc01fa1ea stext_lock+0x42a2 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf7f80b00 0xc01aa38e sym53c8xx_intr+0x62 (0x39, 0xf7cd6000, 0xf42cbf44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xf42cbf14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xf42cbf44, 0xf7f80b00, 0x632, 0xefd60ae0) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xf42cbf3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xefd60a80 ebx = 0x00000632 ecx = 0xefdf26c0 edx = 0xefdf26c0 esi = 0xefd60ae0 edi = 0x00000000 esp = 0xf42cbf78 eip = 0xc0132653 ebp = 0xf42cbf98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xf6a60018 es = 0xf6a60018 origeax = 0xffffff39 ®s = 0xf42cbf44 0xc0132653 sync_buffers+0x83 (0x0, 0x0) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xf42cbfb0 0xc0132819 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf42cbfbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 15 18:11:55 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 18:11:45 -0700 Received: from timmo.dsl.psn.net ([209.63.182.212]:51701 "EHLO fileserver.nimmo.org") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 18:11:33 -0700 Received: from comms (comms.nimmo.org [192.254.254.6]) by fileserver.nimmo.org (8.9.3/8.9.3) with ESMTP id SAA08841 for ; Tue, 15 Aug 2000 18:11:21 -0700 From: "T. Nimmo" To: Subject: RE: xfs module size Date: Tue, 15 Aug 2000 18:11:03 -0700 Message-ID: <000e01c0071e$d9bc8d40$06fefec0@nimmo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Mines bigger than yours" or so goes the car commercial. Built from fresh CVS on 08/14 ~2300MST with no debugging. [root@dbserver /root]# lsmod Module Size Used by nfs 81464 3 (autoclean) lockd 50588 1 (autoclean) [nfs] sunrpc 63268 1 (autoclean) [nfs lockd] 3c59x 23256 1 (autoclean) st 27212 0 (unused) xfs 421728 13 (autoclean) pagebuf 35072 13 (autoclean) [xfs] [root@dbserver /root]# uname -a Linux dbserver.nimmo.org 2.4.0-test5 #1 SMP Mon Aug 14 22:18:04 MST 2000 i586 unknown [root@dbserver /root]# l /lib/modules/2.4.0-test5/fs total 11212 drwxr-xr-x 2 root root 4096 Aug 14 23:07 ./ drwxr-xr-x 10 root root 4096 Aug 14 23:25 ../ -rw-r--r-- 1 root root 18001 Aug 14 23:07 autofs4.o -rw-r--r-- 1 root root 29803 Aug 14 23:07 isofs.o -rw-r--r-- 1 root root 77145 Aug 14 23:07 lockd.o -rw-r--r-- 1 root root 112848 Aug 14 23:07 nfs.o -rw-r--r-- 1 root root 99945 Aug 14 23:07 nfsd.o -rw-r--r-- 1 root root 5856 Aug 14 23:07 nls_cp437.o -rw-r--r-- 1 root root 4148 Aug 14 23:07 nls_iso8859-1.o -rw-r--r-- 1 root root 857189 Aug 14 23:07 pagebuf.o -rw-r--r-- 1 root root 5780 Aug 14 23:07 ramfs.o -rw-r--r-- 1 root root 7256 Aug 14 23:07 romfs.o -rw-r--r-- 1 root root 48003 Aug 14 23:07 smbfs.o -rw-r--r-- 1 root root 10148958 Aug 14 23:07 xfs.o [root@dbserver /root]# -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Seth Mos Sent: Tuesday, August 15, 2000 5:49 PM To: linux-xfs@oss.sgi.com Subject: xfs module size Hi After compiling xfs as a nodule it bloats to 9.7MB. Now who has the largest module on the block ;-) Some reference: Compiled with minimal options for installers and no debugging. - kernel xfs as module is 580K xfs.o module is 9.7M and pagebuf.o is 810K Module loads ok and works. - Kernel xfs compiled in is 889K also works Anyone can explain what happened here? CVS version compiled without debugging on a standard redhat 6.2 machine. I did noticed 2 definitions of CONFIG_PAGE_BUF=m in the CONFIG_XFS_* part of the config. I don't think that is/should be a problem. I could be wrong. Bye Seth From owner-linux-xfs@oss.sgi.com Tue Aug 15 18:58:35 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 18:58:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:25205 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 18:58:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA26912 for ; Tue, 15 Aug 2000 18:50:32 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09964 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 11:56:50 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA28806 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 11:56:50 +1000 (EST) Date: Wed, 16 Aug 2000 11:56:50 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008160156.LAA28806@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_db error check Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing check for errors writing command file, barf on error instead of confusing user later. Modid: 2.4.0-test1-xfs:slinx:72161a Date: Tue Aug 15 18:56:22 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/init.c - 1.26 - check for errors writing command file From owner-linux-xfs@oss.sgi.com Tue Aug 15 21:58:36 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 21:58:26 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26733 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 21:57:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id WAA00312 for ; Tue, 15 Aug 2000 22:04:06 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11054 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 14:56:39 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA61214 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 14:56:39 +1000 (EST) Date: Wed, 16 Aug 2000 14:56:39 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008160456.OAA61214@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libxfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes a couple of bugs in libxfs and paves the way for the new repair to be checked in. Turned out the "bestfree" part of the hdr was being modified in addition to the magic number, so this is slightly different to your recommended fix Steve. Test 019 now works, provided your stat(1) is the same as Daniels. ;) I'll checkin a new 019 stat filter soon too. Modid: 2.4.0-test1-xfs:slinx:72165a Date: Tue Aug 15 21:48:06 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/libxfs/init.c - 1.6 - initialize the xfs_da_state_zone global. cmd/xfs/libxfs/xfs_dir2_block.c - 1.2 - call xfs_dir2_data_log_header after all changes to hdr are made. cmd/xfs/stress/common.rc - 1.15 - troppo has been completely rebuilt & reconfigured after dying yesterday - use the new disk layout for stress. linux/fs/xfs/xfs_dir2_block.c - 1.14 - call xfs_dir2_data_log_header after all changes to hdr are made. From owner-linux-xfs@oss.sgi.com Tue Aug 15 22:08:45 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 22:08:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8208 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 22:08:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA09201 for ; Tue, 15 Aug 2000 22:00:44 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11124 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 15:05:48 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA80568 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 15:05:47 +1000 (EST) Date: Wed, 16 Aug 2000 15:05:47 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008160505.PAA80568@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - sim/repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72166a Date: Tue Aug 15 22:05:17 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/sim/repair/Makefile - 1.1 cmd/xfs/sim/repair/agheader.c - 1.1 cmd/xfs/sim/repair/agheader.h - 1.1 cmd/xfs/sim/repair/attr_repair.c - 1.1 cmd/xfs/sim/repair/attr_repair.h - 1.1 cmd/xfs/sim/repair/avl.c - 1.1 cmd/xfs/sim/repair/avl.h - 1.1 cmd/xfs/sim/repair/avl64.c - 1.1 cmd/xfs/sim/repair/avl64.h - 1.1 cmd/xfs/sim/repair/bmap.c - 1.1 cmd/xfs/sim/repair/bmap.h - 1.1 cmd/xfs/sim/repair/dino_chunks.c - 1.1 cmd/xfs/sim/repair/dinode.c - 1.1 cmd/xfs/sim/repair/dinode.h - 1.1 cmd/xfs/sim/repair/dir.c - 1.1 cmd/xfs/sim/repair/dir.h - 1.1 cmd/xfs/sim/repair/dir2.c - 1.1 cmd/xfs/sim/repair/dir2.h - 1.1 cmd/xfs/sim/repair/dir_stack.c - 1.1 cmd/xfs/sim/repair/dir_stack.h - 1.1 cmd/xfs/sim/repair/err_protos.h - 1.1 cmd/xfs/sim/repair/globals.c - 1.1 cmd/xfs/sim/repair/globals.h - 1.1 cmd/xfs/sim/repair/incore.c - 1.1 cmd/xfs/sim/repair/incore.h - 1.1 cmd/xfs/sim/repair/incore_bmc.c - 1.1 cmd/xfs/sim/repair/incore_ext.c - 1.1 cmd/xfs/sim/repair/incore_ino.c - 1.1 cmd/xfs/sim/repair/init.c - 1.1 cmd/xfs/sim/repair/io.c - 1.1 cmd/xfs/sim/repair/phase1.c - 1.1 cmd/xfs/sim/repair/phase2.c - 1.1 cmd/xfs/sim/repair/phase3.c - 1.1 cmd/xfs/sim/repair/phase4.c - 1.1 cmd/xfs/sim/repair/phase5.c - 1.1 cmd/xfs/sim/repair/phase6.c - 1.1 cmd/xfs/sim/repair/phase7.c - 1.1 cmd/xfs/sim/repair/protos.h - 1.1 cmd/xfs/sim/repair/rt.c - 1.1 cmd/xfs/sim/repair/rt.h - 1.1 cmd/xfs/sim/repair/sb.c - 1.1 cmd/xfs/sim/repair/scan.c - 1.1 cmd/xfs/sim/repair/scan.h - 1.1 cmd/xfs/sim/repair/versions.c - 1.1 cmd/xfs/sim/repair/versions.h - 1.1 cmd/xfs/sim/repair/vsn.h - 1.1 cmd/xfs/sim/repair/xfs_repair.c - 1.1 - snapshot of xfs_repair at point of transition to a non-SIM version. From owner-linux-xfs@oss.sgi.com Tue Aug 15 22:19:45 2000 Received: by oss.sgi.com id ; Tue, 15 Aug 2000 22:19:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20497 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Aug 2000 22:19:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA09890 for ; Tue, 15 Aug 2000 22:11:38 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11223 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 15:17:57 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA24388 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 15:17:56 +1000 (EST) Date: Wed, 16 Aug 2000 15:17:56 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008160517.PAA24388@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is the last part of the user code changes to de-SIM. There are no known problems with this code with my previous libxfs checkin, and it should be easy to port over to other platforms. cheerio. Modid: 2.4.0-test1-xfs:slinx:72167a Date: Tue Aug 15 22:11:39 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/Makefile - 1.28 - remove sim/src - no commands use libsim anymore. cmd/xfs/repair/Makefile - 1.42 cmd/xfs/repair/agheader.c - 1.22 cmd/xfs/repair/agheader.h - 1.8 cmd/xfs/repair/attr_repair.c - 1.20 cmd/xfs/repair/attr_repair.h - 1.4 cmd/xfs/repair/avl.c - 1.19 cmd/xfs/repair/avl.h - 1.7 cmd/xfs/repair/avl64.c - 1.7 cmd/xfs/repair/bmap.c - 1.5 cmd/xfs/repair/bmap.h - 1.3 cmd/xfs/repair/dino_chunks.c - 1.40 cmd/xfs/repair/dinode.c - 1.79 cmd/xfs/repair/dinode.h - 1.23 cmd/xfs/repair/dir.c - 1.58 cmd/xfs/repair/dir.h - 1.13 cmd/xfs/repair/dir2.c - 1.13 cmd/xfs/repair/dir2.h - 1.3 cmd/xfs/repair/dir_stack.c - 1.9 cmd/xfs/repair/dir_stack.h - 1.4 cmd/xfs/repair/err_protos.h - 1.5 cmd/xfs/repair/globals.c - 1.9 cmd/xfs/repair/globals.h - 1.30 cmd/xfs/repair/incore.c - 1.35 cmd/xfs/repair/incore.h - 1.35 cmd/xfs/repair/incore_bmc.c - 1.12 cmd/xfs/repair/incore_ext.c - 1.20 cmd/xfs/repair/incore_ino.c - 1.23 cmd/xfs/repair/init.c - 1.12 cmd/xfs/repair/io.c - 1.17 cmd/xfs/repair/phase1.c - 1.24 cmd/xfs/repair/phase2.c - 1.25 cmd/xfs/repair/phase3.c - 1.30 cmd/xfs/repair/phase4.c - 1.48 cmd/xfs/repair/phase5.c - 1.42 cmd/xfs/repair/phase6.c - 1.56 cmd/xfs/repair/phase7.c - 1.23 cmd/xfs/repair/protos.h - 1.8 cmd/xfs/repair/rt.c - 1.18 cmd/xfs/repair/rt.h - 1.5 cmd/xfs/repair/sb.c - 1.32 cmd/xfs/repair/scan.c - 1.42 cmd/xfs/repair/scan.h - 1.9 cmd/xfs/repair/versions.c - 1.19 cmd/xfs/repair/versions.h - 1.8 cmd/xfs/repair/xfs_repair.c - 1.47 - transition from libsim to libxfs; no longer define _KERNEL, __KERNEL__, SIM, use libxfs.h, etc. From owner-linux-xfs@oss.sgi.com Wed Aug 16 00:07:25 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 00:07:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18033 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 00:07:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA07325 for ; Wed, 16 Aug 2000 00:13:13 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11786 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 16 Aug 2000 17:05:47 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA22274 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 17:05:47 +1000 (EST) Date: Wed, 16 Aug 2000 17:05:47 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008160705.RAA22274@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This moves xfs_fs.h (ioctl stuff) into the userland build, and we can now build without an asm link in the kernel (we can build with a non-XFS kernel now too) - following through on Keiths recommendation from last week. $KERNEL is no longer a configure parameter. Modid: 2.4.0-test1-xfs:slinx:72169a Date: Wed Aug 16 00:01:21 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Makefile - 1.18 - remove the symlink creation nonsense in the ProPack build. cmd/xfs/CHANGELOG - 1.3 - add a list of stuff thats new since last time I updated this. cmd/xfs/Makefile - 1.29 - add a clean target for use when configure hasn't been run before. cmd/xfs/VERSION - 1.4 - roll point release number. cmd/xfs/bmap/xfs_bmap.c - 1.7 - get xfs_fs.h & uuid.h from an alternate location. cmd/xfs/configure.in - 1.11 - remove the KERNEL variable - we no longer need an XFS kernel to build cmds. cmd/xfs/dump/common/drive.c - 1.11 cmd/xfs/dump/common/fs.c - 1.14 cmd/xfs/dump/common/global.c - 1.11 cmd/xfs/dump/common/main.c - 1.17 - get xfs_fs.h & uuid.h from an alternate location. cmd/xfs/dump/common/openutil.c - 1.8 - remove bogus assert & not-available include. cmd/xfs/dump/common/util.c - 1.14 cmd/xfs/handle/handle.c - 1.3 - get xfs_fs.h & uuid.h from an alternate location. cmd/xfs/include/Makefile - 1.8 - add xfs_fs.h. cmd/xfs/include/builddefs.in - 1.9 - remove the KERNEL variable - we no longer need an XFS kernel to build cmds. cmd/xfs/include/libxfs.h - 1.9 cmd/xfs/include/platform_defs.h.in - 1.10 - we know where xfs_fs.h is coming from now. cmd/xfs/logprint/logprint.h - 1.6 - fix XFS_ERROR botch. cmd/xfs/mkfile/xfs_mkfile.c - 1.7 - get xfs_fs.h & uuid.h from an alternate location. cmd/xfs/sim/mkfs/Makefile - 1.2 cmd/xfs/sim/repair/Makefile - 1.2 cmd/xfs/sim/src/Makefile - 1.81 - need to set KERNEL explicitly here now. From owner-linux-xfs@oss.sgi.com Wed Aug 16 02:56:50 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 02:56:40 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32890 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 02:56:28 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id DAA00757 for ; Wed, 16 Aug 2000 03:02:37 -0700 (PDT) mail_from (tes@sherman.melbourne.sgi.com) Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id TAA16839 for linux-xfs@oss.sgi.com; Wed, 16 Aug 2000 19:56:16 +1000 Date: Wed, 16 Aug 2000 19:56:16 +1000 From: Tim Shimmin Message-Id: <200008160956.TAA16839@sherman.melbourne.sgi.com> Subject: TAKE - xfsdump stress test To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 16 02:55:31 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72173a cmd/xfs/stress/027 - 1.1 - Do the xfsdump | xfsrestore test. cmd/xfs/stress/027.out - 1.1 - Diffs of src and dest. cmd/xfs/stress/common.rc - 1.16 - Add sherman to list of hosts and their devices. cmd/xfs/stress/group - 1.22 - Add 027. cmd/xfs/stress/common.dump - 1.7 - Add functions to support "xfsdump|xfsrestore". From owner-linux-xfs@oss.sgi.com Wed Aug 16 07:21:50 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 07:21:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64090 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 07:21:32 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA17572 for ; Wed, 16 Aug 2000 07:13:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA35088 for ; Wed, 16 Aug 2000 09:20:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA33206 for ; Wed, 16 Aug 2000 09:20:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id JAA24298; Wed, 16 Aug 2000 09:17:25 -0500 Message-Id: <200008161417.JAA24298@jen.americas.sgi.com> Date: Wed, 16 Aug 2000 09:17:25 -0500 Subject: TAKE - add instructions on how to build optimized XFS commands To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 16 07:19:35 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72184a cmd/xfs/INSTALL - 1.3 - Add instructions on how to do an optimized build From owner-linux-xfs@oss.sgi.com Wed Aug 16 16:02:55 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 16:02:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:3967 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 16:02:27 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA08916 for ; Wed, 16 Aug 2000 13:20:26 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA32578 for ; Wed, 16 Aug 2000 15:25:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA81386 for ; Wed, 16 Aug 2000 15:25:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id PAA11680; Wed, 16 Aug 2000 15:22:37 -0500 Message-Id: <200008162022.PAA11680@jen.americas.sgi.com> Date: Wed, 16 Aug 2000 15:22:37 -0500 Subject: TAKE - fix kdb module to build without pagebuf tracing To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 16 13:25:04 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72203a linux/kdb/modules/kdbm_pg.c - 1.13 - Fix module to build with pagebuf tracing compiled out of the kernel. From owner-linux-xfs@oss.sgi.com Wed Aug 16 16:24:14 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 16:24:06 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19466 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 16:23:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA29702 for ; Wed, 16 Aug 2000 12:15:03 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA01127 for ; Wed, 16 Aug 2000 14:20:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA72705 for ; Wed, 16 Aug 2000 14:20:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA05852; Wed, 16 Aug 2000 14:17:15 -0500 Message-Id: <200008161917.OAA05852@jen.americas.sgi.com> Date: Wed, 16 Aug 2000 14:17:15 -0500 Subject: TAKE - fix xfs_repair shortcomings - merge of irix fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fix adds more checks to xfs_repair for corruption seen on a filesystem at LANL. The filesystem had an inode whose extent B+Tree was corrupted; the corruption was not detected by xfs_repair, however it prevented the file from being accessed (a 'cp' would report the error "Filesystem is corrupted") or removed (a dirty transaciton would be cancelled causing the filesystem to be shut down). Date: Wed Aug 16 12:19:23 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72201a cmd/xfs/repair/dinode.c - 1.80 - Add a check to process_btinode to verifty that B+Tree forward sibling block numbers are NULL in the rightmost B+Tree block. This check catches only problems in the highest level B+Tree blocks. cmd/xfs/repair/scan.c - 1.43 - Add a B+Tree left sibling check to scanfunc_bmap. The left sibling block number must be NULL in the leftmost B+Tree block. Also add to scanfunc_bmap the same check that was added to process_dinode_int to verifty that B+Tree forward sibling block numbers are NULL in the rightmost B+Tree block. This check catches problems in all but the highest B+Tree level. From owner-linux-xfs@oss.sgi.com Wed Aug 16 16:28:45 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 16:28:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:61195 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 16:28:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA17267 for ; Wed, 16 Aug 2000 10:55:33 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA34347 for ; Wed, 16 Aug 2000 13:00:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA22789 for ; Wed, 16 Aug 2000 13:00:37 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id MAA29256; Wed, 16 Aug 2000 12:57:46 -0500 Message-Id: <200008161757.MAA29256@jen.americas.sgi.com> Date: Wed, 16 Aug 2000 12:57:46 -0500 Subject: TAKE - small kiobuf I/O path tweak To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 16 11:00:03 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72193a linux/drivers/block/ll_rw_blk.c - 1.41 - Add chait's suggested patch for recalling q->request_fn at the end of the kiobuf path. From owner-linux-xfs@oss.sgi.com Wed Aug 16 16:28:45 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 16:28:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:61195 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 16:28:16 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA18859 for ; Wed, 16 Aug 2000 11:06:24 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA15778 for ; Wed, 16 Aug 2000 13:11:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA26435 for ; Wed, 16 Aug 2000 13:11:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA29388; Wed, 16 Aug 2000 13:08:36 -0500 Message-Id: <200008161808.NAA29388@jen.americas.sgi.com> Date: Wed, 16 Aug 2000 13:08:36 -0500 Subject: TAKE - pagebuf tuning To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This adds yet another mount option for XFS, kiocluster, this indicates use kiobufs for all I/O requests, and use write clustering on converting delalloc writes to real disk blocks, the kio flag now means use kiobufs but do not do write clustering. Currently write clustering is giving worse performance turned on rather than off - probably more to do with when it is triggered rather than anything else. This also turns off all the compiled in debug printk code in pagebuf and the pagebuf tracing code being compiled in. These can be turned back on for debugging via editing page_buf.h Date: Wed Aug 16 11:07:38 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72194a linux/include/linux/fs.h - 1.56 - Add MS_KIOCLUSTER super block flag. linux/fs/xfs/linux/xfs_super.c - 1.82 - Add kiocluster mount option to control used of clustered writes for delalloc page cleaning. linux/include/linux/page_buf.h - 1.62 - Remove some prototypes. Also turn off pagebuf tracing code compilation and debugging printks by default. If you want these built into the kernel you NEED to edit page_buf.h now. linux/fs/xfs/linux/xfs_mount_opt.c - 1.11 - Add kiocluster mount option to control used of clustered writes for delalloc page cleaning. linux/fs/pagebuf/page_buf.c - 1.24 - Remove some dead code, add options to allow us to play with page locking more. linux/fs/pagebuf/page_buf_io.c - 1.23 - Separate out the decision to use I/O clustering on delalloc page cleaning from the decision to use kiobufs for I/O. Also do not allow write requests for clustered delalloc requests to linger in the request queue for too long with all the pages locked down. From owner-linux-xfs@oss.sgi.com Wed Aug 16 20:29:55 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 20:29:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:40258 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 20:29:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA03853 for ; Wed, 16 Aug 2000 20:21:32 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18811 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 17 Aug 2000 13:26:35 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA36152 for linux-xfs@oss.sgi.com; Thu, 17 Aug 2000 13:26:34 +1000 (EST) Date: Thu, 17 Aug 2000 13:26:34 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008170326.NAA36152@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72233a Date: Wed Aug 16 20:19:03 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/build/rpm/Makefile - 1.5 cmd/xfs/configure.in - 1.12 - ensure rpm version 4 packages can be correctly generated. cmd/xfs/doc/Makefile - 1.3 - move Porting-Guide over here & ensure its part of src tarball. cmd/xfs/dump/Makefile - 1.3 cmd/xfs/dump/dump/Makefile - 1.15 cmd/xfs/dump/inventory/Makefile - 1.5 cmd/xfs/dump/restore/Makefile - 1.6 - ensure dump and restore can be built from the src tarball. cmd/xfs/include/builddefs.in - 1.10 - ensure rpm version 4 packages can be correctly generated. cmd/xfs/doc/Porting-Guide - 1.1 - fix a couple of typos, move from build subdir. From owner-linux-xfs@oss.sgi.com Wed Aug 16 20:57:25 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 20:57:16 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28255 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 20:56:57 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA03556; Wed, 16 Aug 2000 21:03:07 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA92492; Wed, 16 Aug 2000 20:56:26 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA37705; Wed, 16 Aug 2000 20:55:07 -0700 (PDT) Date: Wed, 16 Aug 2000 20:55:07 -0700 (PDT) Message-Id: <200008170355.UAA37705@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 799238 - SMP lockup between ramdisk & XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 Submitter : dxm Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 mount -t xfs /dev/sdc5 /mnt/scratch_0 dd if=/dev/zero of=/dev/ram1 bs=1024 count=4 mkfs -i 1024 /dev/ram1 4096 mount /dev/ram1 /mnt/ram write a "test" script: #!/bin/sh while true do echo "fish" > /mnt/ram/fish done Run test in bg: test & And then run some stress on the XFS partition: fsstress -z -f sync=1 -f creat=1 -f write=1 -n 1000000 -d /mnt/scratch_0 -p 1 It usually locks up for me within 30sec and drops into kdb via the NMI magic. Why do I care? With a R/O root, all my R/W stuff goes to a ramdisk, including stuff from klogd etc. There seems to be enough traffic to the ramdisk to wipe me out. [1]kdb> cpu 0 Entering kdb (0xf4fe6000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc01f797a stext_lock+0x1a32 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf4fe7dac 0xc0132c1e insert_into_queues+0x5e (0xf750c180, 0xf750c180, 0xc013314c, 0x0) kernel .text 0xc0100000 0xc0132bc0 0xc0132c80 0xf4fe7dd8 0xc013335c getblk+0xa0 (0x100, 0xccf, 0x400) kernel .text 0xc0100000 0xc01332bc 0xc013338c 0xf4fe7df8 0xc016da3d rd_request+0xad (0xc033c128) kernel .text 0xc0100000 0xc016d990 0xc016dac0 0xf4fe7e08 0xc0164ab7 generic_unplug_device+0x2f (0xc033c128) kernel .text 0xc0100000 0xc0164a88 0xc0164ac8 0xf4fe7e18 0xf89049a2 [xfs]xfs_trigger_io+0x5a xfs .text 0xf888e060 0xf8904948 0xf89049b0 0xf4fe7e4c 0xf88d9086 [xfs]xlog_sync+0x2c6 (0xf5eaf8e0, 0xf5390000, 0x0) xfs .text 0xf888e060 0xf88d8dc0 0xf88d92dc 0xf4fe7e80 0xf88da9e9 [xfs]xlog_state_release_iclog+0x121 (0xf5eaf8e0, 0xf5390000) xfs .text 0xf888e060 0xf88da8c8 0xf88da9f4 0xf4fe7eac 0xf88dabd5 [xfs]xlog_state_sync_all+0xf5 (0xf5eaf8e0, 0x2) xfs .text 0xf888e060 0xf88daae0 0xf88dac9c 0xf4fe7ec8 0xf88d7ca7 [xfs]xfs_log_force+0x77 (0xf4699000, 0x0, 0x0, 0x2) xfs .text 0xf888e060 0xf88d7c30 0xf88d7cd4 0xf4fe7f50 0xf88f122f [xfs]xfs_syncsub+0xeb (0xf4699000, 0x31, 0x0, 0x0, 0xf4699000) xfs .text 0xf888e060 0xf88f1144 0xf88f2404 0xf4fe7f70 0xf88f113b [xfs]xfs_sync+0x1b (0xf4699000, 0x31, 0xf8920f80) xfs .text 0xf888e060 0xf88f1120 0xf88f1144 0xf4fe7f88 0xf8906304 [xfs]linvfs_write_super+0x24 (0xf53bde00) xfs .text 0xf888e060 0xf89062e0 0xf8906310 0xf4fe7f9c 0xc0136578 sync_supers+0x6c (0x0) kernel .text 0xc0100000 0xc013650c 0xc01365a0 0xf4fe7fb0 0xc0132844 fsync_dev+0x3c (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf4fe7fbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> [0]kdb> cpu 1 Entering kdb (0xf42ca000) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01fa1ea stext_lock+0x42a2 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf42cbef4 0xc01aa38e sym53c8xx_intr+0x62 (0x39, 0xf7cd6000, 0xf42cbf44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xf42cbf14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xf42cbf44, 0xf7f80b00, 0x632, 0xefd60ae0) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xf42cbf3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xefd60a80 ebx = 0x00000632 ecx = 0xefdf26c0 edx = 0xefdf26c0 esi = 0xefd60ae0 edi = 0x00000000 esp = 0xf42cbf78 eip = 0xc0132653 ebp = 0xf42cbf98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xf6a60018 es = 0xf6a60018 origeax = 0xffffff39 ®s = 0xf42cbf44 0xc0132653 sync_buffers+0x83 (0x0, 0x0) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xf42cbfb0 0xc0132819 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf42cbfbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 [1]more> kernel .text 0xc0100000 0xc010900c 0xc0109044 [1]kdb> [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xf7fb2000 00000001 00000000 0 001 stop 0xf7fb2340 init 0xf7f8c000 00000002 00000001 0 001 stop 0xf7f8c340 kswapd 0xf7f8a000 00000003 00000001 0 001 stop 0xf7f8a340 kflushd 0xf7f88000 00000004 00000001 0 001 stop 0xf7f88340 kupdate 0xf5c60000 00000350 00000001 0 000 stop 0xf5c60340 portmap 0xf6702000 00000429 00000001 0 000 stop 0xf6702340 rpciod 0xf645a000 00000430 00000001 0 000 stop 0xf645a340 lockd 0xf56fa000 00000453 00000001 0 000 stop 0xf56fa340 syslogd 0xf6806000 00000465 00000001 0 000 run 0xf6806340 klogd 0xf68c0000 00000482 00000001 0 001 stop 0xf68c0340 identd 0xf5c0e000 00000484 00000482 0 001 stop 0xf5c0e340 identd 0xf6646000 00000485 00000484 0 001 stop 0xf6646340 identd 0xf5a60000 00000486 00000484 0 001 stop 0xf5a60340 identd 0xf5e94000 00000487 00000484 0 001 stop 0xf5e94340 identd 0xf5dd6000 00000503 00000001 0 001 stop 0xf5dd6340 atd 0xf57c6000 00000520 00000001 0 000 stop 0xf57c6340 crond 0xf65f4000 00000537 00000001 0 000 stop 0xf65f4340 inetd 0xf5a56000 00000648 00000001 0 000 stop 0xf5a56340 pmcd 0xf5ea0000 00000801 00000001 0 000 stop 0xf5ea0340 pmlogger 0xf5ad2000 00000851 00000001 0 000 stop 0xf5ad2340 minilogd 0xf6986000 00000867 00000001 0 000 stop 0xf6986340 mingetty 0xf609e000 00000868 00000001 0 000 stop 0xf609e340 mingetty [1]more> 0xf5952000 00000869 00000001 0 000 stop 0xf5952340 mingetty 0xf574e000 00000870 00000001 0 001 stop 0xf574e340 mingetty 0xf56ca000 00000871 00000001 0 001 stop 0xf56ca340 mingetty 0xf69fc000 00000872 00000001 0 001 stop 0xf69fc340 mingetty 0xf64f8000 00000873 00000001 0 000 stop 0xf64f8340 login 0xf5eb2000 00000898 00000873 0 001 stop 0xf5eb2340 tcsh 0xf556e000 00001497 00000001 0 000 stop 0xf556e340 pagebuf_daemon 0xf55ba000 00001498 00000001 0 000 stop 0xf55ba340 page_daemon 0xf32fa000 00007853 00000898 0 000 stop 0xf32fa340 check 0xf361c000 00008084 00007853 0 000 stop 0xf361c340 sh 0xf2e70000 00008138 00008084 0 000 stop 0xf2e70340 fsstress 0xf42ca000 00008139 00008138 1 001 run 0xf42ca340*fsstress 0xf1e78000 00008140 00008138 0 001 stop 0xf1e78340 fsstress 0xe4092000 00008141 00008138 0 000 stop 0xe4092340 fsstress 0xf4044000 00008142 00008138 0 001 run 0xf4044340 fsstress 0xf4fe6000 00008143 00008138 1 000 run 0xf4fe6340 fsstress [1]kdb> btp 8139 EBP EIP Function(args) 0xc01fa1ea stext_lock+0x42a2 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf7f80b00 0xc01aa38e sym53c8xx_intr+0x62 (0x39, 0xf7cd6000, 0xf42cbf44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xf42cbf14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xf42cbf44, 0xf7f80b00, 0x632, 0xefd60ae0) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xf42cbf3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xefd60a80 ebx = 0x00000632 ecx = 0xefdf26c0 edx = 0xefdf26c0 esi = 0xefd60ae0 edi = 0x00000000 esp = 0xf42cbf78 eip = 0xc0132653 ebp = 0xf42cbf98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000246 ds = 0xf6a60018 es = 0xf6a60018 origeax = 0xffffff39 ®s = 0xf42cbf44 0xc0132653 sync_buffers+0x83 (0x0, 0x0) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xf42cbfb0 0xc0132819 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xf42cbfbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xdd4176f0, 0x22be890f, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 [1]more> kernel .text 0xc0100000 0xc010900c 0xc0109044 Another run: [0]kdb> bt EBP EIP Function(args) 0xc01f797a stext_lock+0x1a32 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xf6c7bcb4 0xc0132c1e insert_into_queues+0x5e (0xf750ba20, 0xf750ba20, 0xc013314c, 0x0) kernel .text 0xc0100000 0xc0132bc0 0xc0132c80 0xf6c7bce0 0xc013335c getblk+0xa0 (0x100, 0x969, 0x400) kernel .text 0xc0100000 0xc01332bc 0xc013338c 0xf6c7bd00 0xc016da3d rd_request+0xad (0xc033c128) kernel .text 0xc0100000 0xc016d990 0xc016dac0 0xf6c7bd10 0xc0164ab7 generic_unplug_device+0x2f (0xc033c128, 0xf7057060, 0xc18e9ce4) kernel .text 0xc0100000 0xc0164a88 0xc0164ac8 0xf6c7bd44 0xc0132599 __wait_on_buffer+0xa9 (0xd3e5e6e0) kernel .text 0xc0100000 0xc01324f0 0xc01325d0 0xf6c7bd98 0xf8885206 [pagebuf]__pb_block_prepare_write_async+0x2ee (0xf7057060, 0xc18e9ce4, 0xe73, 0x1000, 0x0) pagebuf .text 0xf8881060 0xf8884f18 0xf888522c 0xf6c7bde8 0xf888556b [pagebuf]__pagebuf_do_delwri+0x167 (0xf7057060, 0x7b000, 0x0, 0x10000, 0x8053500) pagebuf .text 0xf8881060 0xf8885404 0xf8885664 0xf6c7be64 0xf88857b2 [pagebuf]_pagebuf_file_write+0x14e (0xf69c4180, 0x8053500, 0x141f5, 0xf6c7becc, 0x2) pagebuf .text 0xf8881060 0xf8885664 0xf88857ec 0xf6c7bef0 0xf88859d3 [pagebuf]pagebuf_generic_file_write_Rsmp_f2244478+0x1e7 (0xf69c4180, 0x8053500, 0x141f5, 0xf6c7bf90) pagebuf .text 0xf8881060 0xf88857ec 0xf8885b80 0xf6c7bf14 0xf8900e92 [xfs]xfs_rdwr+0x72 (0xf4d9a058, 0xf69c4180, 0x8053500, 0x141f5, 0xf6c7bf90) xfs .text 0xf888e060 0xf8900e20 0xf8900ea0 0xf6c7bf60 0xf8901ff6 [xfs]xfs_write+0x19a (0xf4d9a058, 0xf69c4180, 0x8053500, 0x141f5, 0xf6c7bf90) xfs .text 0xf888e060 0xf8901e5c 0xf89020a4 0xf6c7bf98 0xf88fd030 [xfs]linvfs_write+0xec (0xf69c4180, 0x8053500, 0x141f5, 0xf69c41a0, 0xf6c7a000) xfs .text 0xf888e060 0xf88fcf44 0xf88fd05c 0xf6c7bfbc 0xc0131698 sys_write+0xa8 (0x3, 0x8053500, 0x141f5, 0x72e7be73, 0x141f5) kernel .text 0xc0100000 0xc01315f0 0xc01316b0 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [1]kdb> bt EBP EIP Function(args) 0xc01fa4af stext_lock+0x4567 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xc4a17dec 0xc01b0139 scsi_queue_next_request+0x11 (0xf7cf4798, 0x0) kernel .text 0xc0100000 0xc01b0128 0xc01b0254 0xc4a17e04 0xc01abdd8 scsi_release_command+0x8c (0xf7c99600, 0x8, 0xf7c996ac) kernel .text 0xc0100000 0xc01abd4c 0xc01abde4 0xc4a17e48 0xc01b052b __scsi_end_request+0x2d7 (0xf7c99600, 0x1, 0x21, 0x1) kernel .text 0xc0100000 0xc01b0254 0xc01b0538 0xc4a17e88 0xc01b077c scsi_io_completion+0x160 (0xf7c99600, 0x21, 0x1) kernel .text 0xc0100000 0xc01b061c 0xc01b0948 0xc4a17ea8 0xc01a2000 rw_intr+0x16c (0xf7c99600) kernel .text 0xc0100000 0xc01a1e94 0xc01a200c 0xc4a17edc 0xc01b37eb scsi_old_done+0x5bb (0xf7c99600) kernel .text 0xc0100000 0xc01b3230 0xc01b380c 0xc4a17ef4 0xc01aa3b1 sym53c8xx_intr+0x85 (0x39, 0xf7cd6000, 0xc4a17f44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xc4a17f14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xc4a17f44, 0xf7f80b00, 0xd5f, 0xcb14a5c0) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xc4a17f3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xcb14a620 ebx = 0x00000d5f ecx = 0xc033c128 edx = 0xf7cf6ec0 esi = 0xcb14a5c0 edi = 0x00000000 esp = 0xc4a17f78 eip = 0xc0132636 ebp = 0xc4a17f98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000206 ds = 0xc0330018 es = 0xc4a10018 origeax = 0xffffff39 ®s = 0xc4a17f44 0xc0132636 sync_buffers+0x66 (0x0, 0x1) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xc4a17fb0 0xc0132890 fsync_dev+0x88 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xc4a17fbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0xad0f0221, 0x52f0fdde, 0x4000ae60, 0xbffff984) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xf7fb2000 00000001 00000000 0 000 stop 0xf7fb2340 init 0xf7f8c000 00000002 00000001 0 001 stop 0xf7f8c340 kswapd 0xf7f8a000 00000003 00000001 0 001 stop 0xf7f8a340 kflushd 0xf7f88000 00000004 00000001 0 001 stop 0xf7f88340 kupdate 0xf5a0a000 00000350 00000001 0 000 stop 0xf5a0a340 portmap 0xf6600000 00000429 00000001 0 000 stop 0xf6600340 rpciod 0xf6604000 00000430 00000001 0 000 stop 0xf6604340 lockd 0xf5d64000 00000453 00000001 0 000 stop 0xf5d64340 syslogd 0xf649c000 00000465 00000001 0 000 run 0xf649c340 klogd 0xf67c4000 00000482 00000001 0 000 stop 0xf67c4340 identd 0xf5aa2000 00000484 00000482 0 001 stop 0xf5aa2340 identd 0xf5ae2000 00000485 00000484 0 000 stop 0xf5ae2340 identd 0xf66c0000 00000486 00000484 0 000 stop 0xf66c0340 identd 0xf5aa0000 00000487 00000484 0 000 stop 0xf5aa0340 identd 0xf6a00000 00000503 00000001 0 001 stop 0xf6a00340 atd 0xf5788000 00000520 00000001 0 000 stop 0xf5788340 crond 0xf5756000 00000537 00000001 0 001 stop 0xf5756340 inetd 0xf59d4000 00000648 00000001 0 001 stop 0xf59d4340 pmcd 0xf5e60000 00000799 00000001 0 001 stop 0xf5e60340 pmlogger 0xf60d4000 00000851 00000001 0 001 stop 0xf60d4340 minilogd 0xf7b68000 00000867 00000001 0 001 stop 0xf7b68340 mingetty 0xf5858000 00000868 00000001 0 001 stop 0xf5858340 mingetty 0xf65ae000 00000869 00000001 0 001 stop 0xf65ae340 mingetty 0xf6ade000 00000870 00000001 0 000 stop 0xf6ade340 mingetty 0xf6870000 00000871 00000001 0 000 stop 0xf6870340 mingetty 0xf6936000 00000872 00000001 0 000 stop 0xf6936340 mingetty 0xf67f4000 00000873 00000001 0 001 stop 0xf67f4340 login 0xf5658000 00000898 00000873 0 001 stop 0xf5658340 tcsh 0xf55bc000 00000981 00000001 0 001 stop 0xf55bc340 pagebuf_daemon 0xf55b2000 00000982 00000001 0 000 stop 0xf55b2340 page_daemon 0xe1f54000 00004432 00000898 0 001 stop 0xe1f54340 check 0xf2c24000 00004473 00004432 0 001 stop 0xf2c24340 sh 0xf3090000 00004603 00004473 0 000 stop 0xf3090340 fsstress 0xccb62000 00004604 00004603 0 001 run 0xccb62340 fsstress 0xc4a16000 00004605 00004603 1 001 run 0xc4a16340*fsstress 0xc59c8000 00004606 00004603 0 001 run 0xc59c8340 fsstress 0xc94f8000 00004607 00004603 0 001 run 0xc94f8340 fsstress 0xf6c7a000 00004608 00004603 1 000 run 0xf6c7a340 fsstress And another for good luck: root@lumpy ~/xfs# fsstress -z -f sync=1 -f creat=1 -f write=1 -n 1000000 -d /mnt/scratch_0 -p 2 seed = 966213390 NMI Watchdog detected LOCKUP on CPU0, registers: CPU: 0 EIP: 0010:[] EFLAGS: 00000086 eax: f7fc0000 ebx: 00008b40 ecx: 0000db40 edx: f7ff6d00 esi: 00000010 edi: 0000000a ebp: eb3b7d74 esp: eb3b7d64 ds: 0018 es: 0018 ss: 0018 Process test (pid: 10138, stackpage=eb3b7000) Stack: f533a5c0 00000008 00000400 0000db40 eb3b7da0 c013335c f533a5c0 f533a5c0 c013314c 00000000 00000000 e9f8d420 eb3b6000 00000100 01007ddc eb3b7dc0 c016da3d 00000100 000008b4 00000400 00000286 e9f8d420 eb3b6000 eb3b7dd0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 80 3d 08 41 2c c0 00 f3 90 7e f5 e9 9d b2 f3 ff 50 8d 05 04 Entering kdb (0xeb3b6000) on processor 0 due to WatchDog Interrupt @ 0xc01f7971 eax = 0xf7fc0000 ebx = 0x00008b40 ecx = 0x0000db40 edx = 0xf7ff6d00 esi = 0x00000010 edi = 0x0000000a esp = 0xeb3b7d64 eip = 0xc01f7971 ebp = 0xeb3b7d74 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000086 ds = 0x00000018 es = 0x00000018 origeax = 0xf7fc0000 ®s = 0xeb3b7d30 [0]kdb> bt EBP EIP Function(args) 0xc01f7971 stext_lock+0x1a29 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xeb3b7d74 0xc0132c1e insert_into_queues+0x5e (0xf533a5c0, 0xf533a5c0, 0xc013314c, 0x0) kernel .text 0xc0100000 0xc0132bc0 0xc0132c80 0xeb3b7da0 0xc013335c getblk+0xa0 (0x100, 0x8b4, 0x400) kernel .text 0xc0100000 0xc01332bc 0xc013338c 0xeb3b7dc0 0xc016da3d rd_request+0xad (0xc033c128) kernel .text 0xc0100000 0xc016d990 0xc016dac0 0xeb3b7dd0 0xc0164ab7 generic_unplug_device+0x2f (0xc033c128, 0xe9f8d420, 0xe9f8d480) kernel .text 0xc0100000 0xc0164a88 0xc0164ac8 0xeb3b7e04 0xc0132599 __wait_on_buffer+0xa9 (0xe9f8d420) kernel .text 0xc0100000 0xc01324f0 0xc01325d0 0xeb3b7e14 0xc0133b4b unmap_buffer+0x33 (0xe9f8d420) kernel .text 0xc0100000 0xc0133b18 0xc0133b78 0xeb3b7e34 0xc0133bfe block_flushpage+0x86 (0xc1b25bf0, 0x0) kernel .text 0xc0100000 0xc0133b78 0xc0133c40 0xeb3b7e64 0xc0125f26 truncate_inode_pages+0xd6 (0xeb3c4edc, 0x0, 0x0, 0x2) kernel .text 0xc0100000 0xc0125e50 0xc01260c0 0xeb3b7ea8 0xc01240b3 vmtruncate+0x57 (0xeb3c4e40, 0x0, 0x0) kernel .text 0xc0100000 0xc012405c 0xc0124228 0xeb3b7ec8 0xc0145f33 inode_setattr+0x37 (0xeb3c4e40, 0xeb3b7f04) kernel .text 0xc0100000 0xc0145efc 0xc0145fb0 0xeb3b7eec 0xc014603f notify_change+0x8f (0xf4e747a0, 0xeb3b7f04) kernel .text 0xc0100000 0xc0145fb0 0xc0146090 0xeb3b7f2c 0xc012fd8b do_truncate+0x4b (0xf4e747a0, 0x0, 0x0) kernel .text 0xc0100000 0xc012fd40 0xc012fda0 0xeb3b7f60 0xc013de12 open_namei+0x472 (0xebc9f000, 0x242, 0x1b6, 0xeb3b7f84) kernel .text 0xc0100000 0xc013d9a0 0xc013df54 0xeb3b7fa0 0xc0130cda filp_open+0x3a (0xebc9f000, 0x241, 0x1b6) kernel .text 0xc0100000 0xc0130ca0 0xc0130cfc 0xeb3b7fbc 0xc0131012 sys_open+0x36 (0x809dff0, 0x241, 0x1b6, 0x809dff0, 0x809d2e0) kernel .text 0xc0100000 0xc0130fdc 0xc01310ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 [0]kdb> [0]kdb> cpu 1 Entering kdb (0xeb344000) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01fa1f1 stext_lock+0x42a9 kernel .text.lock 0xc01f5f48 0xc01f5f48 0xc01fbca0 0xeb345ef4 0xc01aa38e sym53c8xx_intr+0x62 (0x39, 0xf7cd6000, 0xeb345f44, 0x720, 0xc0317f20) kernel .text 0xc0100000 0xc01aa32c 0xc01aa3cc 0xeb345f14 0xc010ab39 handle_IRQ_event+0x4d (0x39, 0xeb345f44, 0xf7f80b00, 0x42c, 0xea0f4c00) kernel .text 0xc0100000 0xc010aaec 0xc010ab68 0xeb345f3c 0xc010ad39 do_IRQ+0x99 kernel .text 0xc0100000 0xc010aca0 0xc010ad8c 0xc0109100 ret_from_intr kernel .text 0xc0100000 0xc0109100 0xc0109120 Interrupt registers: eax = 0xea0f4c60 ebx = 0x0000042c ecx = 0xc033c128 edx = 0xc033c138 esi = 0xea0f4c00 edi = 0x00000000 esp = 0xeb345f78 eip = 0xc0132636 ebp = 0xeb345f98 ss = 0x00000018 cs = 0x00000010 eflags = 0x00000206 ds = 0xc0330018 es = 0xeb340018 origeax = 0xffffff39 ®s = 0xeb345f44 0xc0132636 sync_buffers+0x66 (0x0, 0x0) kernel .text 0xc0100000 0xc01325d0 0xc01327dc 0xeb345fb0 0xc0132819 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc0132808 0xc013289c 0xeb345fbc 0xc01328a6 sys_sync+0xa (0x804ec68, 0x41f349da, 0x41f349da, 0x4000ae60, 0xbffffa74) kernel .text 0xc0100000 0xc013289c 0xc01328ac 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 From owner-linux-xfs@oss.sgi.com Wed Aug 16 21:58:15 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 21:58:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16206 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 21:57:46 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA10058 for ; Wed, 16 Aug 2000 21:50:09 -0700 (PDT) mail_from (ajag@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19231 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 17 Aug 2000 14:56:27 +1000 Received: (from ajag@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA03792 for linux-xfs@oss.sgi.com; Thu, 17 Aug 2000 14:56:27 +1000 (EST) Date: Thu, 17 Aug 2000 14:56:27 +1000 (EST) From: ajag@snort.melbourne.sgi.com (Andrew Gildfind) Message-Id: <200008170456.OAA03792@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72237a Date: Wed Aug 16 21:54:47 PDT 2000 Workarea: snort:/build5/ajag/slinx Author: ajag The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/growfs/Makefile - 1.1 cmd/xfs/growfs/xfs_growfs.c - 1.1 - xfs_growfs command, command is largely complete, however, growfs code in the kernel still has problems (ie. using growfs is dangerous it will probably damage filesystems). From owner-linux-xfs@oss.sgi.com Wed Aug 16 22:16:05 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 22:15:55 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:16306 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 22:15:52 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id AAA20570; Thu, 17 Aug 2000 00:15:49 -0500 (CDT) Date: Thu, 17 Aug 2000 00:15:49 -0500 (CDT) Message-Id: <200008170515.AAA20570@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore problems Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing xfsrestore is complaining that the version number of a xfsdump file: [root@xfs newdump]# xfsrestore -i -f /usr/src/mnt.dump . xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: ERROR: unrecognized media file header version (33554432) xfsrestore: restore complete: 0 seconds elapsed Is xfsdump/xfsrestore still a work in progress? It worked a couple of days ago. Bill Jones From owner-linux-xfs@oss.sgi.com Wed Aug 16 22:26:06 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 22:25:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1378 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 22:25:35 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08045; Wed, 16 Aug 2000 22:31:45 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA21150; Wed, 16 Aug 2000 22:25:33 -0700 (PDT) Date: Wed, 16 Aug 2000 22:25:33 -0700 (PDT) Message-Id: <200008170525.WAA21150@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: UPDATE 799238 - SMP lockup between ramdisk & XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 Status : open Priority : 2 Assigned Engineer : nb Submitter : dxm Opened Date : 08/15/00 *Modified User : dxm *Modified User Domain : engr *Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: dxm@engr (BugWorks) Date: Aug 16 2000 10:25:32PM ========================== CPU A: sys_sync sync_buffers takes lru_list_lock interrupt -> sym53c8xx_intr takes io_request_lock CPU B: sys_open generic_unplug_device takes io_request_lock insert_into_queues takes lru_list_lock equals: race condition (yay!) And I can't see where XFS is involved, which kind of suggests it is, but I haven't been able to repeat this one without using, so go figure. From owner-linux-xfs@oss.sgi.com Wed Aug 16 23:13:27 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 23:13:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:25177 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 23:13:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA16034 for ; Wed, 16 Aug 2000 23:05:32 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) From: ivanr@melbourne.sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19617; Thu, 17 Aug 2000 16:10:36 +1000 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA14997; Thu, 17 Aug 2000 16:10:34 +1000 (EST) Date: Thu, 17 Aug 2000 16:10:34 +1000 To: William L Jones cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore problems In-Reply-To: <200008170515.AAA20570@spica.cc.utexas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, 17 Aug 2000, William L Jones wrote: > xfsrestore is complaining that the version number of a xfsdump file: > > [root@xfs newdump]# xfsrestore -i -f /usr/src/mnt.dump . > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: searching media for dump > xfsrestore: ERROR: unrecognized media file header version (33554432) > xfsrestore: restore complete: 0 seconds elapsed I'll look into it. Can you rerun it using the following option '-v nitty'? This will produce _alot_ of output, so you should redirect it to a file. > Is xfsdump/xfsrestore still a work in progress? It worked a couple of > days ago. It is still a work in progress, in that we are still porting features from IRIX. The dump format should not change, so we'd like people to use xfsdump/xfsrestore now (or rather, as soon as we fix this bug. :) Ivan -- Ivan Rayner ivanr@melbourne.sgi.com From owner-linux-xfs@oss.sgi.com Wed Aug 16 23:46:08 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 23:45:58 -0700 Received: from timmo.dsl.psn.net ([209.63.182.212]:23546 "EHLO fileserver.nimmo.org") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 23:45:38 -0700 Received: from comms (comms.nimmo.org [192.254.254.6]) by fileserver.nimmo.org (8.9.3/8.9.3) with ESMTP id XAA17684; Wed, 16 Aug 2000 23:45:22 -0700 From: "T. Nimmo" To: "'Steve Lord'" Cc: Subject: RE: Feedback: Installing Oracle 8.1.6 on Linux w/xfs Date: Wed, 16 Aug 2000 23:45:19 -0700 Message-ID: <000001c00816$b6a456a0$06fefec0@nimmo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200008141401.JAA12732@jen.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve, I built a new kernel from 'cvs co...' on 8/14/2000 @ ~2300MST and built clean disks shown below from fdisk+mkfs. Installed Oracle 8.1.6 for Linux over NFS and built a new database from scratch. Oracle install and db build executed perfectly. Also, I had prior problems tarring ~600MB tarball to xfs f/s. tar looked good; however 'tar [x|t]vf' cleanly exited ($?=0) 5-10% into the tarball. tar cvf and xvf to/from xfs now works too. Looking like a really nice work folks! Thanks for the 'oss xfs' effort and appreciate the assistance, Tim... Linux dbserver.nimmo.org 2.4.0-test5 #1 SMP Mon Aug 14 22:18:04 MST 2000 i586 unknown /dev/scsi/host3/bus0/target6/lun0/part1 on /app type xfs (rw,kio) /dev/scsi/host3/bus0/target5/lun0/part1 on /app/rdbms/archive type xfs (rw,kio) /dev/ide/host0/bus0/target1/lun0/part2 on /app/rdbms/db1 type xfs (rw,kio) /dev/ide/host0/bus1/target0/lun0/part2 on /app/rdbms/db2 type xfs (rw,kio) /dev/ide/host0/bus1/target1/lun0/part2 on /app/rdbms/db3 type xfs (rw,kio) /dev/scsi/host1/bus0/target0/lun0/part1 on /app/rdbms/db4 type xfs (rw,kio) /dev/scsi/host1/bus0/target4/lun0/part1 on /app/rdbms/db5 type xfs (rw,kio) /dev/scsi/host2/bus0/target4/lun0/part1 on /app/rdbms/db6 type xfs (rw,kio) /dev/scsi/host2/bus0/target0/lun0/part1 on /app/rdbms/db7 type xfs (rw,kio) /dev/scsi/host1/bus0/target2/lun0/part1 on /app/rdbms/log1 type xfs (rw,kio) /dev/scsi/host2/bus0/target2/lun0/part1 on /app/rdbms/log2 type xfs (rw,kio) /dev/scsi/host1/bus0/target5/lun0/part1 on /app/rdbms/rbs type xfs (rw,kio) /dev/scsi/host3/bus0/target4/lun0/part1 on /app/rdbms/tmp type xfs (rw,kio) Filesystem 1k-blocks Used Available Use% Mounted on /dev/scsi/host3/bus0/target6/lun0/part1 2043452 536244 1507208 26% /app /dev/scsi/host3/bus0/target5/lun0/part1 1553472 51348 1502124 3% /app/rdbms/archive /dev/ide/host0/bus0/target1/lun0/part2 2363996 425116 1938880 18% /app/rdbms/db1 /dev/ide/host0/bus1/target0/lun0/part2 1928540 527520 1401020 27% /app/rdbms/db2 /dev/ide/host0/bus1/target1/lun0/part2 1451252 681128 770124 47% /app/rdbms/db3 /dev/scsi/host1/bus0/target0/lun0/part1 1995260 425116 1570144 21% /app/rdbms/db4 /dev/scsi/host1/bus0/target4/lun0/part1 2091648 629928 1461720 30% /app/rdbms/db5 /dev/scsi/host2/bus0/target4/lun0/part1 2091648 629924 1461724 30% /app/rdbms/db6 /dev/scsi/host2/bus0/target0/lun0/part1 2092332 629928 1462404 30% /app/rdbms/db7 /dev/scsi/host1/bus0/target2/lun0/part1 1047424 264200 783224 25% /app/rdbms/log1 /dev/scsi/host2/bus0/target2/lun0/part1 1020204 264200 756004 26% /app/rdbms/log2 /dev/scsi/host1/bus0/target5/lun0/part1 1025324 962268 63056 94% /app/rdbms/rbs /dev/scsi/host3/bus0/target4/lun0/part1 1553472 512464 1041008 33% /app/rdbms/tmp -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Monday, August 14, 2000 7:01 AM To: T. Nimmo Cc: linux-xfs@oss.sgi.com Subject: Re: Feedback: Installing Oracle 8.1.6 on Linux w/xfs If at all possible could you please download the latest version of the source - there are new patches from yesterday (8/13) at ftp://oss.sgi.com/projects/xfs/download/ and the cvs tree should always be upto date. Two fixes went in last week, the second not until Thursday, which could have an effect on this. If this does not help, or you have already done this then we would definitely like to chase this one down. It would also be helpful to know if you have the KIOBUF config option on or off. We think it should now make no difference, prior to these two fixes it was more likely to produce corruption. Thanks Steve > I started building the linux-2.4-xfs kernel on a RedHat 6.2 O/S back on > 8/4-8/7; which wasn't stable and locked up the machine. mount/umount or high > file copy rates to xfs filesystems seemed to lock it quickly. By 8/9 this > problem disappeared and the system no longer locks. Now with the scene > setup... > > I've been building a Oracle 8.1.6 for Linux installation using xfs/scsi for > the data volumes with good results. I have Oracle installed on a ext2/scsi > filesystem. After this test I rebuilt the Oracle installation tree on the > same scsi drive using xfs. I used fdisk/mkfs to create the xfs filesystem. > > Copying to a xfs volume, the Oracle installer runs along doing it's normal > thing, until the end of the installation. At the 98% mark the installer > relinks the Oracle executables as part of it's routine. However the linker > 'ld' isn't able to properly read the Oracle library files to relink the > executables. It's like the file contents are messed up or 'ld' can't read > the Oracle library file contents or something. Really wierd! > > If I scratch the Oracle installation tree and reinstall it back to normal on > ext2 it installs just fine. The Oracle datafiles on xfs seem to read/write > perfectly as I can make Oracle do it's thing with no hiccups. > > All of my Oracle xfs filesystems are single sliced on 9 scsi drives and 3 > atapi drives. Most filesystems have 5-7 ###MB files with ~6GB across 11 > filesystems. The 12th filesystem contains the Oracle installation > (/app/oracle/product/blah-blah). > > Anyone have any thoughts about why the Oracle installer can't read libraries > and relink executables on a xfs filesystem? > > Thanks, Tim... From owner-linux-xfs@oss.sgi.com Wed Aug 16 23:58:28 2000 Received: by oss.sgi.com id ; Wed, 16 Aug 2000 23:58:17 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22111 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 16 Aug 2000 23:58:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA19011 for ; Wed, 16 Aug 2000 23:50:35 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19854 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 17 Aug 2000 16:56:54 +1000 Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA24569 for linux-xfs@oss.sgi.com; Thu, 17 Aug 2000 16:56:53 +1000 (EST) Date: Thu, 17 Aug 2000 16:56:53 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008170656.QAA24569@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - remove (broken) definition of printf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Everything should be (is) using printk anyway Modid: 2.4.0-test1-xfs:slinx:72239a Date: Wed Aug 16 23:56:28 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/linux/xfs_random.c - 1.43 - remove (broken) definition of printf From owner-linux-xfs@oss.sgi.com Thu Aug 17 05:46:50 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 05:46:40 -0700 Received: from hermes.mixx.net ([212.84.196.2]:44045 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 17 Aug 2000 05:46:21 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 682AAF80A for ; Thu, 17 Aug 2000 14:45:37 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B400F2CA71; Thu, 17 Aug 2000 14:43:43 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: [OT] kiobuf on ide ? Date: 17 Aug 2000 12:43:42 GMT Organization: innominate AG, Berlin, Germany Lines: 13 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966516222 19088 10.0.0.69 (17 Aug 2000 12:43:42 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing what is the state of kiobuf on ide drives (and all the other stuff like md etc.) - doeas anyone here has some idea about the current and future state ? a lot of thanks in advance t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 17 05:47:00 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 05:46:50 -0700 Received: from hermes.mixx.net ([212.84.196.2]:43789 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 17 Aug 2000 05:46:21 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4BE0BF808 for ; Thu, 17 Aug 2000 14:45:40 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id BBBB72CA6F; Thu, 17 Aug 2000 14:42:35 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: short xfs_db intro ? Date: 17 Aug 2000 12:42:35 GMT Organization: innominate AG, Berlin, Germany Lines: 25 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966516155 19088 10.0.0.69 (17 Aug 2000 12:42:35 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just a little idea: can anyone of the people very familiar with xfs_db please do a simple xfs_db sesssion and record it with script(1) - maybe showing most of the typical things (super- block i think - other interesting blocks and inodes etc.) i think this will not take much time for someone using xfS_db everyday and knowing the xfs struktures on disk very well and this might be a good intro for a newbie ... if someone would do this and put some simple comments to the steps i may polish it a bit and put it somewhere - i think it might be of use now that xfs gets more widely used a lot of thanks in advance t p.s.: a detailed xfs_db doc would be fine also if that should exist -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 17 06:58:52 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 06:58:42 -0700 Received: from tux.mkp.net ([130.225.60.11]:57349 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 06:58:17 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13PQ6x-00070R-00; Thu, 17 Aug 2000 15:53:35 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id JAA01037; Thu, 17 Aug 2000 09:57:44 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: Thomas Graichen Cc: linux-xfs@oss.sgi.com Subject: Re: [OT] kiobuf on ide ? References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 17 Aug 2000 09:57:43 -0400 In-Reply-To: Thomas Graichen's message of "17 Aug 2000 12:43:42 GMT" Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Thomas" == Thomas Graichen writes: Thomas> what is the state of kiobuf on ide drives (and all the other Thomas> stuff like md etc.) - doeas anyone here has some idea about Thomas> the current and future state ? kiobuf support is in a state of flux right now. The existing scheme didn't work out very well for LVM, MD and other stackable block device drivers. Chait Tumuluri, Jens Axboe and myself are redesigning the Linux block I/O queueing structure to accomodate both buffer_head and kiobuf based I/O. We haven't settled on a final design yet, however (keep running into nasties). Once the API is frozen, the new code will start to appear in the XFS tree. We also want to make sure that this (fairly intrusive) change in the kernel is acknowledged by the powers that be, so that we won't have to rewrite everything when XFS eventually becomes part of the mainstream kernel. -- Martin K. Petersen Principal Linux Consultant, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:02:21 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:02:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46375 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:01:48 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA23611 for ; Thu, 17 Aug 2000 06:53:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA60724; Thu, 17 Aug 2000 08:59:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA85420; Thu, 17 Aug 2000 09:00:00 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA15222; Thu, 17 Aug 2000 08:57:01 -0500 Message-Id: <200008171357.IAA15222@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: [OT] kiobuf on ide ? In-Reply-To: Message from Thomas Graichen of "17 Aug 2000 12:43:42 GMT." Date: Thu, 17 Aug 2000 08:57:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > what is the state of kiobuf on ide drives (and all the other stuff > like md etc.) - doeas anyone here has some idea about the current > and future state ? > > a lot of thanks in advance > > t > These are both works in Progress, Jens Axboe at Suse has been working on the ide kiobuf code, not quite sure where it is at the moment, md is in the hands of Martin Peterson at LinuxCare. There are issues in both code bases - for example md has always worked just by redirecting fixed size requests to the correct devices - introducing kiobufs into its I/O path means it has to cope with variable sized requests and do things like request splitting. If Jens and Martin are reading this perhaps they could comment some more on where things are at. Steve > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:28:22 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:28:11 -0700 Received: from tux.mkp.net ([130.225.60.11]:61957 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:27:45 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 13PQYA-00071G-00; Thu, 17 Aug 2000 16:21:43 +0200 Received: (from mkp@localhost) by tyra.mkp.net (8.9.3/8.9.3) id KAA01078; Thu, 17 Aug 2000 10:25:50 -0400 X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f To: Steve Lord Cc: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: [OT] kiobuf on ide ? References: <200008171357.IAA15222@jen.americas.sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 17 Aug 2000 10:25:50 -0400 In-Reply-To: Steve Lord's message of "Thu, 17 Aug 2000 08:57:00 -0500" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Steve" == Steve Lord writes: Steve> There are issues in both code bases - for example md has always Steve> worked just by redirecting fixed size requests to the correct Steve> devices - introducing kiobufs into its I/O path means it has to Steve> cope with variable sized requests and do things like request Steve> splitting. FWIW, same goes for LVM... -- Martin K. Petersen Principal Linux Consultant, Linuxcare, Inc. http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:32:01 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:31:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22832 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:31:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA27479 for ; Thu, 17 Aug 2000 07:23:29 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA68443; Thu, 17 Aug 2000 09:29:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA68351; Thu, 17 Aug 2000 09:29:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA15295; Thu, 17 Aug 2000 09:26:47 -0500 Message-Id: <200008171426.JAA15295@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Martin K. Petersen" cc: Thomas Graichen , linux-xfs@oss.sgi.com Subject: Re: [OT] kiobuf on ide ? In-Reply-To: Message from "Martin K. Petersen" of "17 Aug 2000 10:25:50 EDT." Date: Thu, 17 Aug 2000 09:26:47 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > >>>>> "Steve" == Steve Lord writes: > > Steve> There are issues in both code bases - for example md has always > Steve> worked just by redirecting fixed size requests to the correct > Steve> devices - introducing kiobufs into its I/O path means it has to > Steve> cope with variable sized requests and do things like request > Steve> splitting. > > FWIW, same goes for LVM... Woops, not enough coffee yet, Martin is looking at LVM, not md (yet) - sorry about that. Steve > > -- > Martin K. Petersen Principal Linux Consultant, Linuxcare, Inc. > http://mkp.net/ SGI XFS, Linux/PA-RISC, GNOME > From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:41:41 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:41:31 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27954 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:41:14 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA28467; Thu, 17 Aug 2000 07:33:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA62411; Thu, 17 Aug 2000 07:40:42 -0700 (PDT) Date: Thu, 17 Aug 2000 07:40:42 -0700 (PDT) Message-Id: <200008171440.HAA62411@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: UPDATE 799238 - RAM disk driver breaks locking hierarchy To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 *Summary : RAM disk driver breaks locking hierarchy Status : open Priority : 2 Assigned Engineer : nb Submitter : dxm Opened Date : 08/15/00 *Modified User : lord *Modified User Domain : sgi.com *Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: lord@sgi.com (BugWorks) Date: Aug 17 2000 07:40:41AM ========================== Changing the title on this one, it is not an XFS problem at all, rather a general linux locking bug. Not sure we should keep a PV on this one or not.... From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:42:31 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:42:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:48946 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:42:08 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA28575 for ; Thu, 17 Aug 2000 07:34:02 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA59336 for ; Thu, 17 Aug 2000 09:40:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA22018; Thu, 17 Aug 2000 09:40:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA15325; Thu, 17 Aug 2000 09:37:21 -0500 Message-Id: <200008171437.JAA15325@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: sgi.bugs.xfs@fido.engr.sgi.com cc: linux-xfs@oss.sgi.com Subject: Re: UPDATE 799238 - SMP lockup between ramdisk & XFS In-Reply-To: Message from pv@odin.corp.sgi.com (dxm@engr.sgi.com) of "Wed, 16 Aug 2000 22:25:33 PDT." <200008170525.WAA21150@info.engr.sgi.com> Date: Thu, 17 Aug 2000 09:37:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS is not really part of the problem here, it is just triggering lots of I/O. There appears to be a deadlock between the lru_list_lock and the io_request_lock. On the one hand the lru_list_lock does not disable interrupts, so in I/O can complete whilst it is held. I/O completion functions tend to grab the io_request_lock. On the other hand there are queue request functions (rd_request from the ram disk driver is the example we hit) which end up grabbing the lru_list_lock. In this case rd_request calls getblk. Since the unplug_device layer holds the io_request_lock around the request_fn call we have a deadlock. So either doing anything which touches the lru_list_lock in a request function is a BUG, or the lru_list_lock should hold off interrupts, or some more complex fix is needed. I am not sure if the ram disk driver is an isolated case or one of many possible culprits. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 17 07:50:22 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 07:50:12 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35380 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 07:49:57 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA29513; Thu, 17 Aug 2000 07:41:51 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA62167; Thu, 17 Aug 2000 07:47:41 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA52309; Thu, 17 Aug 2000 07:45:05 -0700 (PDT) Date: Thu, 17 Aug 2000 07:45:05 -0700 (PDT) Message-Id: <200008171445.HAA52309@feature.engr.sgi.com> X-Pv-Incident: 799238 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: ADD 799238 - RAM disk driver breaks locking hierarchy To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : dxm Status : open Assigned Engineer : nb Priority : 2 *Modified Date : 08/17/00 *Modified User : lord *Modified User Domain : sgi.com *Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 ..... ========================== ADDITIONAL INFORMATION (ADD) From: steve lord Date: Aug 17 2000 07:45:04AM [pvnews version: 1.71] ========================== XFS is not really part of the problem here, it is just triggering lots of I/O. There appears to be a deadlock between the lru_list_lock and the io_request_lock. On the one hand the lru_list_lock does not disable interrupts, so in I/O can complete whilst it is held. I/O completion functions tend to grab the io_request_lock. On the other hand there are queue request functions (rd_request from the ram disk driver is the example we hit) which end up grabbing the lru_list_lock. In this case rd_request calls getblk. Since the unplug_device layer holds the io_request_lock around the request_fn call we have a deadlock. So either doing anything which touches the lru_list_lock in a request function is a BUG, or the lru_list_lock should hold off interrupts, or some more complex fix is needed. I am not sure if the ram disk driver is an isolated case or one of many possible culprits. Steve From owner-linux-xfs@oss.sgi.com Thu Aug 17 12:59:43 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 12:59:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22299 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 12:59:20 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA14351 for ; Thu, 17 Aug 2000 12:51:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA99308 for ; Thu, 17 Aug 2000 14:56:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA94112 for ; Thu, 17 Aug 2000 14:56:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA08698; Thu, 17 Aug 2000 14:53:46 -0500 Message-Id: <200008171953.OAA08698@jen.americas.sgi.com> Date: Thu, 17 Aug 2000 14:53:46 -0500 Subject: TAKE - don't delete kdb commands which were not installed To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 17 12:56:10 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72269a linux/kdb/modules/kdbm_pg.c - 1.14 - A bit more cleanup for the non pagebuf tracing version of the module From owner-linux-xfs@oss.sgi.com Thu Aug 17 13:22:33 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 13:22:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51233 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 13:22:17 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA17419 for ; Thu, 17 Aug 2000 13:14:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA80534; Thu, 17 Aug 2000 15:19:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA27231; Thu, 17 Aug 2000 15:19:44 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA08873; Thu, 17 Aug 2000 15:16:42 -0500 Message-Id: <200008172016.PAA08873@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: short xfs_db intro ? In-Reply-To: Message from Thomas Graichen of "17 Aug 2000 12:42:35 GMT." Date: Thu, 17 Aug 2000 15:16:42 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The first trick is finding people familiar with xfs_db! I personally only use it as a tool of last resort. The only documentation I am aware of for xfs_db is the man page, it does contain information on the different metadata objects in XFS. Steve > just a little idea: can anyone of the people very familiar with > xfs_db please do a simple xfs_db sesssion and record it with > script(1) - maybe showing most of the typical things (super- > block i think - other interesting blocks and inodes etc.) > > i think this will not take much time for someone using xfS_db > everyday and knowing the xfs struktures on disk very well and > this might be a good intro for a newbie ... > > if someone would do this and put some simple comments to the > steps i may polish it a bit and put it somewhere - i think > it might be of use now that xfs gets more widely used > > a lot of thanks in advance > > t > > p.s.: a detailed xfs_db doc would be fine also if that should > exist > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 17 13:36:03 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 13:35:57 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:55250 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 13:35:43 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id PAA00594; Thu, 17 Aug 2000 15:35:29 -0500 (CDT) Message-Id: <4.2.0.58.20000817152620.00be84f0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 17 Aug 2000 15:37:08 -0500 To: Steve Lord , Thomas Graichen , thomas.graichen@innominate.de From: "William L. Jones" Subject: Re: short xfs_db intro ? Cc: linux-xfs@oss.sgi.com In-Reply-To: <200008172016.PAA08873@jen.americas.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing In general I don't think even the most sophisticated sys admin will ever have to use this command unless they were trying debug the xfs file system. xfs_db can be usefully but to a very small number of people. I like to see some work done on xfs_reapair. Just having an example that talks about how it handles lost+found would be usefully. It very confusing the first time you see it relink file the were original in lost+found. I thought it was a bug the first time I saw what it did. Bill Jones At 03:16 PM 8/17/00 -0500, Steve Lord wrote: >The first trick is finding people familiar with xfs_db! I personally >only use it as a tool of last resort. The only documentation I am aware >of for xfs_db is the man page, it does contain information on the different >metadata objects in XFS. > >Steve > > > > > just a little idea: can anyone of the people very familiar with > > xfs_db please do a simple xfs_db sesssion and record it with > > script(1) - maybe showing most of the typical things (super- > > block i think - other interesting blocks and inodes etc.) > > > > i think this will not take much time for someone using xfS_db > > everyday and knowing the xfs struktures on disk very well and > > this might be a good intro for a newbie ... > > > > if someone would do this and put some simple comments to the > > steps i may polish it a bit and put it somewhere - i think > > it might be of use now that xfs gets more widely used > > > > a lot of thanks in advance > > > > t > > > > p.s.: a detailed xfs_db doc would be fine also if that should > > exist > > > > -- > > thomas.graichen@innominate.de > > technical director innominate AG > > clustering & security networking people > > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 17 15:54:14 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 15:54:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56150 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 15:53:44 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA01832; Thu, 17 Aug 2000 15:59:55 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA96755; Thu, 17 Aug 2000 15:53:13 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA71283; Thu, 17 Aug 2000 15:51:55 -0700 (PDT) Date: Thu, 17 Aug 2000 15:51:55 -0700 (PDT) Message-Id: <200008172251.PAA71283@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: REASSIGN 799238 - RAM disk driver breaks locking hierarchy To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 Status : open Priority : 2 *Assigned Engineer : dxm *Assigned Domain : engr Submitter : dxm Project : xfs-linux Assigned Group : xfs-linux Opened Date : 08/15/00 *Modified User : dxm *Modified User Domain : engr *Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: dxm@engr (BugWorks) Date: Aug 17 2000 03:51:54PM ========================== => XFS is not really part of the problem here, it is just triggering lots of => I/O. That's just about where I got to yesterday. At first I was assuming it was at fault, then I thought involved, now I suspect it's just a catalyst. => There appears to be a deadlock between the lru_list_lock and the => io_request_lock. Under the circumstances, it's probably the ramdisk. I'll chase this up with some relevant Linux people... From owner-linux-xfs@oss.sgi.com Thu Aug 17 16:35:55 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 16:35:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:18019 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 16:35:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA15199 for ; Thu, 17 Aug 2000 16:27:58 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25159 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 18 Aug 2000 09:34:17 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA75581 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 09:34:17 +1000 (EST) Date: Fri, 18 Aug 2000 09:34:17 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008172334.JAA75581@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing missed this one in my last checkin... Modid: 2.4.0-test1-xfs:slinx:72291a Date: Thu Aug 17 16:33:13 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/dump/common/Makefile - 1.1 - ensure all dump source makes it into the src tarball. From owner-linux-xfs@oss.sgi.com Thu Aug 17 19:14:45 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 19:14:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39197 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 19:14:10 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA14668 for ; Thu, 17 Aug 2000 19:06:34 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA72987 for ; Thu, 17 Aug 2000 21:11:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id VAA85741 for ; Thu, 17 Aug 2000 21:11:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id VAA30041; Thu, 17 Aug 2000 21:08:33 -0500 Message-Id: <200008180208.VAA30041@jen.americas.sgi.com> Date: Thu, 17 Aug 2000 21:08:33 -0500 Subject: TAKE - fix uuid comparison functions To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Linux uuids do not conform to the OSF definitions - which is no big deal, except the code in XFS to compare them was rejecting uuids which did not conform. This causes panics in debug kernels on unmount. The fix is to remove the conformance tests. Date: Thu Aug 17 19:09:30 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72304a linux/fs/xfs/linux/xfs_uuid.c - 1.19 - Fix uuid comparison functions to work with linux uuids. From owner-linux-xfs@oss.sgi.com Thu Aug 17 23:57:46 2000 Received: by oss.sgi.com id ; Thu, 17 Aug 2000 23:57:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62736 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Aug 2000 23:57:08 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA01879 for ; Fri, 18 Aug 2000 00:03:18 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA02825 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 16:54:22 +1000 (EST) Date: Fri, 18 Aug 2000 16:54:22 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008180654.QAA02825@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - growfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing growfs works! (just in time for ProPack 1.4, with any luck) This is "checkin-by-committee" ... Andrew, Daniel & myself are responsible for getting the last few bugs ironed out. cheers. Modid: 2.4.0-test1-xfs:slinx:72308a Date: Thu Aug 17 23:48:52 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/CHANGELOG - 1.4 cmd/xfs/Makefile - 1.30 - added growfs. cmd/xfs/VERSION - 1.5 - bump point release number. cmd/xfs/growfs/Makefile - 1.2 - install xfs_info also. cmd/xfs/growfs/xfs_growfs.c - 1.2 - remove unneeded headers, go back to IRIX usage (pox off getsubopts), use mtab to figure out any log/rt devs, few other little things. cmd/xfs/man/man8/xfs_growfs.8 - 1.2 - document xfs_info also. linux/fs/xfs/linux/xfs_ioctl.c - 1.17 - return a valid error code from the growfs ioctls. linux/fs/xfs/xfs_fsops.c - 1.57 - fix do_div problem causing growfs to go belly up. cmd/xfs/growfs/xfs_info.sh - 1.1 - wrapper around growfs along the lines of the db wrappers, simply invokes growfs in safe, report-only mode. was requested recently by a number of folk on sgi.csd.sn0 ... & was pretty simple to do. From owner-linux-xfs@oss.sgi.com Fri Aug 18 00:11:46 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 00:11:36 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22033 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 00:11:22 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA01302 for ; Fri, 18 Aug 2000 00:17:32 -0700 (PDT) mail_from (ivanr@sherman.melbourne.sgi.com) Received: (from ivanr@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA04957 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 17:10:19 +1000 Date: Fri, 18 Aug 2000 17:10:19 +1000 From: Ivan Rayner Message-Id: <200008180710.RAA04957@sherman.melbourne.sgi.com> Subject: TAKE - xfsdump endian fix To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes a bug for xfsdump writing to a file. In certain circumstances when the global header was rewritten to the media file, it would not be endian converted. Dumps previous to this fix cannot be restored. Unfortunately I don't have the system to test my fix, so any feedback would be appreciated. xfsdump/xfsrestore continue to pass qa tests, and file dumps continue to be compatible with IRIX. Ivan Date: Fri Aug 18 00:05:36 PDT 2000 Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72309a cmd/xfs/dump/common/drive_minrmt.c - 1.19 cmd/xfs/dump/common/drive_scsitape.c - 1.22 - correct benign endian bug cmd/xfs/dump/common/drive_simple.c - 1.11 - fix global header bug, where the global header was not being translated when a mark was being written on media. From owner-linux-xfs@oss.sgi.com Fri Aug 18 00:43:56 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 00:43:46 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:63303 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 00:43:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA05027 for ; Fri, 18 Aug 2000 00:35:57 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA03197 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 17:42:14 +1000 (EST) Date: Fri, 18 Aug 2000 17:42:14 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008180742.RAA03197@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress/qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72311a Date: Fri Aug 18 00:42:02 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/019 - 1.4 cmd/xfs/stress/019.out - 1.2 - ensure output is the same with different stat(1)s. cmd/xfs/stress/common.rc - 1.17 - fix a buglet in check for mounted testdev. From owner-linux-xfs@oss.sgi.com Fri Aug 18 05:35:12 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 05:35:02 -0700 Received: from fepB.post.tele.dk ([195.41.46.145]:35784 "EHLO fepB.post.tele.dk") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 05:34:48 -0700 Received: from burns.home.kernel.dk ([193.89.189.243]) by fepB.post.tele.dk (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000818123446.VBSX819.fepB.post.tele.dk@burns.home.kernel.dk>; Fri, 18 Aug 2000 14:34:46 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 13PlMu-00009M-00; Fri, 18 Aug 2000 14:35:28 +0200 Date: Fri, 18 Aug 2000 14:35:28 +0200 From: Jens Axboe To: Steve Lord Cc: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: [OT] kiobuf on ide ? Message-ID: <20000818143528.A540@suse.de> References: <200008171357.IAA15222@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008171357.IAA15222@jen.americas.sgi.com>; from lord@sgi.com on Thu, Aug 17, 2000 at 08:57:00AM -0500 X-OS: Linux 2.4.0-test7 i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Aug 17 2000, Steve Lord wrote: > > what is the state of kiobuf on ide drives (and all the other stuff > > like md etc.) - doeas anyone here has some idea about the current > > and future state ? > > These are both works in Progress, Jens Axboe at Suse has been working > on the ide kiobuf code, not quite sure where it is at the moment, md IDE support is working and almost completed, but tied up with the block infrastructure changes we are doing at the moment. A rough estimate on getting the whole thing in working order is some time next week. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Fri Aug 18 08:05:53 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 08:05:42 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:19445 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 08:05:25 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA11526; Fri, 18 Aug 2000 10:05:19 -0500 (CDT) Message-Id: <4.2.0.58.20000818100512.021c8ba0@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 18 Aug 2000 10:07:00 -0500 To: Ivan Rayner From: "William L. Jones" Subject: Re: TAKE - xfsdump endian fix Cc: linux-xfs@oss.sgi.com In-Reply-To: <200008180710.RAA04957@sherman.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 05:10 PM 8/18/00 +1000, Ivan Rayner wrote: >This fixes a bug for xfsdump writing to a file. In certain circumstances >when the global header was rewritten to the media file, it would not be >endian converted. > >Dumps previous to this fix cannot be restored. > >Unfortunately I don't have the system to test my fix, so any feedback >would be appreciated. xfsdump/xfsrestore continue to pass qa tests, >and file dumps continue to be compatible with IRIX. > >Ivan > > > >Date: Fri Aug 18 00:05:36 PDT 2000 >Workarea: sherman.melbourne.sgi.com:/b/ivanr/isms/slinx-xfs > >The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs > > >Modid: 2.4.0-test1-xfs:slinx:72309a >cmd/xfs/dump/common/drive_minrmt.c - 1.19 >cmd/xfs/dump/common/drive_scsitape.c - 1.22 > - correct benign endian bug > >cmd/xfs/dump/common/drive_simple.c - 1.11 > - fix global header bug, where the global header was not being > translated > when a mark was being written on media. I just tried it. It fixed my problem. Bill Jones From owner-linux-xfs@oss.sgi.com Fri Aug 18 12:19:56 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 12:19:47 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59221 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 12:19:32 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA08178 for ; Fri, 18 Aug 2000 12:11:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA57152 for ; Fri, 18 Aug 2000 14:16:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA64847 for ; Fri, 18 Aug 2000 14:16:59 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA06000; Fri, 18 Aug 2000 14:13:48 -0500 Message-Id: <200008181913.OAA06000@jen.americas.sgi.com> Date: Fri, 18 Aug 2000 14:13:48 -0500 Subject: TAKE - cleanup xfs locking code To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is just a cosmetic change - plus a few code and structure size shrinkages. Date: Fri Aug 18 12:16:07 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72588a linux/fs/xfs/linux/xfs_sema.h - 1.26 linux/fs/xfs/linux/xfs_locks.c - 1.20 - Rationalize locking code somewhat - remove old debugging code and unused fields in locks. Replace some empy functions with macros which do nothing. From owner-linux-xfs@oss.sgi.com Fri Aug 18 12:31:47 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 12:31:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32089 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 12:30:58 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09839 for ; Fri, 18 Aug 2000 12:23:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA79929 for ; Fri, 18 Aug 2000 14:28:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA65759 for ; Fri, 18 Aug 2000 14:28:26 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id OAA06312; Fri, 18 Aug 2000 14:25:15 -0500 Message-Id: <200008181925.OAA06312@jen.americas.sgi.com> Date: Fri, 18 Aug 2000 14:25:15 -0500 Subject: TAKE - vnode code and structure size cleanup To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Removes some dead fields from the vnode + code which refered to them. Changes the method xfs uses to catch iput calls from above the vfs layer - more to come here later. Date: Fri Aug 18 12:27:11 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72592a linux/fs/xfs/xfs_vnodeops.c - 1.471 - Remove references to VN_DIRTY - it is gone (and didn't do aything when it was there) linux/fs/xfs/xfs_itable.c - 1.89 - Remove reference to vp->v_rdev it is gone, this breaks xfs_fd_to_mp, but it is already broken since the getf call is uses is an unimplemented irix call. Also this function is only currently used for error injection which we have not used yet. linux/fs/xfs/xfs_vfsops.c - 1.284 - Remove some sync code paths which do not mean aything on Linux linux/fs/xfs/xfs_iget.c - 1.126 - Remove reference to vp->v_rdev it is gone. linux/fs/xfs/xfs_inode.c - 1.300 - Remove references to vp->v_rdev and VN_DIRTY, they are gone linux/fs/xfs/xfs_inode.h - 1.141 - Formatting cleanup linux/fs/xfs/xfs_utils.c - 1.32 - Turn off some more irix code linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.28 - remove unused fields from vmap structure, make VN_RELE call vn_rele linux/fs/xfs/linux/xfs_vnode.c - 1.39 - Remove dead code, user space code, flip the names on vn_put and vn_rele linux/fs/xfs/linux/xfs_super.c - 1.83 - remove put_inode method, replaced by d_iput linux/fs/xfs/linux/xfs_iops.c - 1.64 - Add d_iput method to xfs - lets us intercept iput slightly higher up the call stack. linux/include/linux/vnode.h - 1.3 - Remove some dead vnode fields From owner-linux-xfs@oss.sgi.com Fri Aug 18 12:34:27 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 12:34:16 -0700 Received: from hermes.mixx.net ([212.84.196.2]:34062 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 18 Aug 2000 12:34:00 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 6EE5EF80F for ; Fri, 18 Aug 2000 21:33:58 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 37DCA2CA6F; Fri, 18 Aug 2000 21:33:57 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs trouble Date: 18 Aug 2000 19:33:57 GMT Organization: innominate AG, Berlin, Germany Lines: 43 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966627237 20907 10.0.0.69 (18 Aug 2000 19:33:57 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just built xfs fromm an rsync of the current cvs tree and wanted to move a system to xfs (for some more realy world testing) - but after mkfs.xfs'ing the device (ide, no kiobufs), mounting it, umounting it and again mounting it i got [root@ozon /root]# mkfs -t xfs -f /dev/hda3 meta-data=/dev/hda3 isize=256 agcount=8, agsize=65766 blks data = bsize=4096 blocks=526128, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 [root@ozon /root]# mount -t xfs /dev/hda3 /mnt Start mounting filesystem: ide0(3,3) Ending clean XFS mount for filesystem: ide0(3,3) [root@ozon /root]# umount /mnt [root@ozon /root]# mount -t xfs /dev/hda3 /mnt Start mounting filesystem: ide0(3,3) XFS: xlog_find_verify_log_record: need to backup XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed mount: wrong fs type, bad option, bad superblock on /dev/hda3, or too many mounted file systems [root@ozon /root]# any idea ? is this reproducable for others too ? (it is on redhat 6.2 - thus egcs, 233mmx pentium, also the cmd's fresh rebuild - from real current sources) a lot of thanks in advance t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 18 12:42:17 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 12:41:57 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:47963 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 12:41:47 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA10938 for ; Fri, 18 Aug 2000 12:34:11 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA75586; Fri, 18 Aug 2000 14:39:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA80685; Fri, 18 Aug 2000 14:39:13 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA10783; Fri, 18 Aug 2000 14:36:02 -0500 Message-Id: <200008181936.OAA10783@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs trouble In-Reply-To: Message from Thomas Graichen of "18 Aug 2000 19:33:57 GMT." Date: Fri, 18 Aug 2000 14:36:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yep, this is repeatable here - I will have a look at what is going on. Steve > just built xfs fromm an rsync of the current cvs tree and wanted to > move a system to xfs (for some more realy world testing) - but after > mkfs.xfs'ing the device (ide, no kiobufs), mounting it, umounting it > and again mounting it i got > > [root@ozon /root]# mkfs -t xfs -f /dev/hda3 > meta-data=/dev/hda3 isize=256 agcount=8, agsize=65766 blks > data = bsize=4096 blocks=526128, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > Ending clean XFS mount for filesystem: ide0(3,3) > [root@ozon /root]# umount /mnt > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > XFS: xlog_find_verify_log_record: need to backup > XFS: failed to find log head > > XFS: log mount/recovery failed > > XFS: log mount failed > > mount: wrong fs type, bad option, bad superblock on /dev/hda3, > or too many mounted file systems > [root@ozon /root]# > > any idea ? is this reproducable for others too ? > > (it is on redhat 6.2 - thus egcs, 233mmx pentium, also the cmd's > fresh rebuild - from real current sources) > > a lot of thanks in advance > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 18 13:06:17 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 13:06:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:1122 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 13:05:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA13932 for ; Fri, 18 Aug 2000 12:58:18 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA26552; Fri, 18 Aug 2000 15:03:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA54905; Fri, 18 Aug 2000 15:03:18 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA13563; Fri, 18 Aug 2000 15:00:06 -0500 Message-Id: <200008182000.PAA13563@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Steve Lord cc: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: xfs trouble In-Reply-To: Message from Steve Lord of "Fri, 18 Aug 2000 14:36:01 CDT." <200008181936.OAA10783@jen.americas.sgi.com> Date: Fri, 18 Aug 2000 15:00:05 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is only present in the non-kiobuf case - so IDE is broken right now, and scsi works if you use the correct mount options. More later. Steve > > Yep, this is repeatable here - I will have a look at what is going on. > > Steve > > > > just built xfs fromm an rsync of the current cvs tree and wanted to > > move a system to xfs (for some more realy world testing) - but after > > mkfs.xfs'ing the device (ide, no kiobufs), mounting it, umounting it > > and again mounting it i got > > From owner-linux-xfs@oss.sgi.com Fri Aug 18 14:15:07 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 14:14:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20565 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 14:14:33 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA05104 for ; Fri, 18 Aug 2000 14:20:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA08662; Fri, 18 Aug 2000 16:13:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id QAA75884; Fri, 18 Aug 2000 16:13:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id QAA15754; Fri, 18 Aug 2000 16:10:02 -0500 Message-Id: <200008182110.QAA15754@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs trouble In-Reply-To: Message from Thomas Graichen of "18 Aug 2000 19:33:57 GMT." Date: Fri, 18 Aug 2000 16:10:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing OK, I am not sure why, but this is actually a mkfs problem! My comment about kiobufs was a read herring - that disk had a good log in it previously and the old data in the log was sufficient to make mount happy. In order to trigger this you need to have non valid log data out there to start with, so new disks, or disks which have been stamped on are the only places this will show up. If you use an old mkfs then the second mount proceeds without problems, however, if you use the new mkfs command then ide drives appear to have problems. This probably has more to do with the log zeroing code than anything else. Steve p.s. to build the 'old' mkfs do this: cd cmd/xfs/sim/src make cd ../mkfs make make install # if you want it installed. > just built xfs fromm an rsync of the current cvs tree and wanted to > move a system to xfs (for some more realy world testing) - but after > mkfs.xfs'ing the device (ide, no kiobufs), mounting it, umounting it > and again mounting it i got > > [root@ozon /root]# mkfs -t xfs -f /dev/hda3 > meta-data=/dev/hda3 isize=256 agcount=8, agsize=65766 blks > data = bsize=4096 blocks=526128, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > Ending clean XFS mount for filesystem: ide0(3,3) > [root@ozon /root]# umount /mnt > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > XFS: xlog_find_verify_log_record: need to backup > XFS: failed to find log head > > XFS: log mount/recovery failed > > XFS: log mount failed > > mount: wrong fs type, bad option, bad superblock on /dev/hda3, > or too many mounted file systems > [root@ozon /root]# > > any idea ? is this reproducable for others too ? > > (it is on redhat 6.2 - thus egcs, 233mmx pentium, also the cmd's > fresh rebuild - from real current sources) > > a lot of thanks in advance > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 18 14:52:38 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 14:52:28 -0700 Received: from hermes.mixx.net ([212.84.196.2]:11793 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 18 Aug 2000 14:52:09 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id F105FF80E for ; Fri, 18 Aug 2000 23:52:07 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 6980E2CA6D; Fri, 18 Aug 2000 23:52:07 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs trouble Date: 18 Aug 2000 21:52:07 GMT Organization: innominate AG, Berlin, Germany Lines: 75 Distribution: local Message-ID: References: <200008182110.QAA15754@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966635527 25316 10.0.0.69 (18 Aug 2000 21:52:07 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > OK, I am not sure why, but this is actually a mkfs problem! My > comment about kiobufs was a read herring - that disk had a good > log in it previously and the old data in the log was sufficient > to make mount happy. In order to trigger this you need to have non > valid log data out there to start with, so new disks, or disks which > have been stamped on are the only places this will show up. > If you use an old mkfs then the second mount proceeds without problems, > however, if you use the new mkfs command then ide drives appear > to have problems. This probably has more to do with the log zeroing > code than anything else. > Steve > p.s. to build the 'old' mkfs do this: > cd cmd/xfs/sim/src > make > cd ../mkfs > make > make install # if you want it installed. does not work from current sources - but cd cmd/xfs/sim/src make cd ../maxtrres make cd ../mkfs make make install # if you want it installed. works (in the other case you get problems with the includes) ... but more important - the resulting mkfs does not work :-( [root@chrome /root]# mkfs -t xfs -f /dev/hda3 xfs: using dummy primary network address meta-data=/dev/hda3 isize=256 agcount=8, agsize=65766 blks data = bsize=4096 blocks=526128, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 Segmentation fault (core dumped) [root@chrome /root]# Core was generated by `mkfs.xfs -f /dev/hda3'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x807dafa in xfs_ichgtime (ip=0x812d360, flags=7) at xfs_inode.c:3756 3756 if (XFS_ITOV(ip)->v_vfsp->vfs_flag & VFS_RDONLY) (gdb) where #0 0x807dafa in xfs_ichgtime (ip=0x812d360, flags=7) at xfs_inode.c:3756 #1 0x807b7d6 in xfs_ialloc (tp=0x812d190, pip=0x0, mode=16877, nlink=1, rdev=1048577, cr=0xbffff2c0, prid=0, okalloc=1, ialloc_context=0xbffff274, call_again=0xbffff27c, ipp=0xbffff270) at xfs_inode.c:1181 #2 0x80554d8 in ialloc (tp=0xbffff388, pip=0x0, mode=16877, nlink=1, rdev=1048577, cr=0xbffff2c0, ipp=0xbffff3a8) at xfs_mkfs.c:2267 #3 0x8056630 in parseproto (mp=0x810aa90, pip=0x0, pp=0xbffff660, name=0x0) at xfs_mkfs.c:2696 #4 0x805464b in main (argc=3, argv=0xbffffaf4) at xfs_mkfs.c:2028 (gdb) will go to bed now ... it's already quite late now t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 18 14:57:18 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 14:57:08 -0700 Received: from scaup.prod.itd.earthlink.net ([207.217.121.49]:6885 "EHLO scaup.prod.itd.earthlink.net") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 14:56:54 -0700 Received: from mickey (sdn-ar-006txhousP270.dialsprint.net [158.252.132.200]) by scaup.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id OAA20199 for ; Fri, 18 Aug 2000 14:56:53 -0700 (PDT) Reply-To: From: "Jason Holland" To: Subject: RE: xfs trouble Date: Fri, 18 Aug 2000 16:56:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just in case anyone is wondering, i am experiencing the same problems. everything freshly built from cvs tree. i've been able to reproduce on redhat 6.2, 6.1 and debian 2.2 boxes. all running gcc 2.95 i believe, or egcs, whichever you call it now. after the first unsuccessful mount, i run xfs_repair, and mount/umount work perfectly after that. weirdness... jason > just built xfs fromm an rsync of the current cvs tree and wanted to > move a system to xfs (for some more realy world testing) - but after > mkfs.xfs'ing the device (ide, no kiobufs), mounting it, umounting it > and again mounting it i got > > [root@ozon /root]# mkfs -t xfs -f /dev/hda3 > meta-data=/dev/hda3 isize=256 agcount=8, agsize=65766 blks > data = bsize=4096 blocks=526128, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > Ending clean XFS mount for filesystem: ide0(3,3) > [root@ozon /root]# umount /mnt > [root@ozon /root]# mount -t xfs /dev/hda3 /mnt > Start mounting filesystem: ide0(3,3) > XFS: xlog_find_verify_log_record: need to backup > XFS: failed to find log head > > XFS: log mount/recovery failed > > XFS: log mount failed > > mount: wrong fs type, bad option, bad superblock on /dev/hda3, > or too many mounted file systems > [root@ozon /root]# > > any idea ? is this reproducable for others too ? > > (it is on redhat 6.2 - thus egcs, 233mmx pentium, also the cmd's > fresh rebuild - from real current sources) > > a lot of thanks in advance > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de > From owner-linux-xfs@oss.sgi.com Fri Aug 18 14:59:18 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 14:59:08 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44377 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 14:59:00 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03205 for ; Fri, 18 Aug 2000 15:05:12 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA38123 for ; Fri, 18 Aug 2000 16:57:42 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id QAA25308 for ; Fri, 18 Aug 2000 16:57:43 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7ILvAB32658 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 16:57:10 -0500 Date: Fri, 18 Aug 2000 16:57:10 -0500 From: Russell Cattelan Message-Id: <200008182157.e7ILvAB32658@gibble.americas.sgi.com> Subject: TAKE - Modified mkinitrd; used to build an xfs ramdisk. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Aug 18 14:56:59 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72607a cmd/xfs/misc/mkinitrd.xfs - 1.1 - Modified mkinitrd: make it large enough to fit xfs and pagebuf (15meg) Use static version of bash rather than sash; sash doesn't seem to work. (bash.staic not supplied must build your own). Note default ram disk size in the kernel is 4096k add append="ramdisk_size=15000" to lilo.conf From owner-linux-xfs@oss.sgi.com Fri Aug 18 15:22:38 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 15:22:28 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 15:22:07 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA28775 for ; Fri, 18 Aug 2000 15:14:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA59931; Fri, 18 Aug 2000 17:19:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id RAA21484; Fri, 18 Aug 2000 17:19:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id RAA22352; Fri, 18 Aug 2000 17:16:21 -0500 Message-Id: <200008182216.RAA22352@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: jphollan@earthlink.net cc: linux-xfs@oss.sgi.com Subject: Re: xfs trouble In-Reply-To: Message from "Jason Holland" of "Fri, 18 Aug 2000 16:56:49 CDT." Date: Fri, 18 Aug 2000 17:16:21 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > just in case anyone is wondering, i am experiencing the same problems. > everything freshly built from cvs tree. i've been able to reproduce on > redhat 6.2, 6.1 and debian 2.2 boxes. all running gcc 2.95 i believe, or > egcs, whichever you call it now. after the first unsuccessful mount, i run > xfs_repair, and mount/umount work perfectly after that. weirdness... > > jason > It may be that the zeroing code in repair is working, but that in mkfs is not. Once you have a completely zeroed log everything should be OK. Steve From owner-linux-xfs@oss.sgi.com Fri Aug 18 15:46:58 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 15:46:38 -0700 Received: from hermes.mixx.net ([212.84.196.2]:22802 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 18 Aug 2000 15:46:07 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 41103F812 for ; Sat, 19 Aug 2000 00:46:05 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EDA382CA6D; Sat, 19 Aug 2000 00:46:04 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs trouble Date: 18 Aug 2000 22:46:04 GMT Organization: innominate AG, Berlin, Germany Lines: 25 Distribution: local Message-ID: References: <200008182216.RAA22352@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966638764 20208 10.0.0.69 (18 Aug 2000 22:46:04 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> just in case anyone is wondering, i am experiencing the same problems. >> everything freshly built from cvs tree. i've been able to reproduce on >> redhat 6.2, 6.1 and debian 2.2 boxes. all running gcc 2.95 i believe, or >> egcs, whichever you call it now. after the first unsuccessful mount, i run >> xfs_repair, and mount/umount work perfectly after that. weirdness... > It may be that the zeroing code in repair is working, but that in mkfs is > not. Once you have a completely zeroed log everything should be OK. i have so far put an (old) working copy of mkfs_xfs (and mkfs_xfs.gz) to http://innominate.org/~graichen/projects/xfs/ just if someone wants to play with xfs this weekend - so that there is no showstopper :-) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 18 16:00:28 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 16:00:08 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64267 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 15:59:38 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA02485 for ; Fri, 18 Aug 2000 15:52:02 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA00655 for ; Fri, 18 Aug 2000 17:57:06 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id RAA29772 for ; Fri, 18 Aug 2000 17:57:05 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7IMuX602819 for linux-xfs@oss.sgi.com; Fri, 18 Aug 2000 17:56:33 -0500 Date: Fri, 18 Aug 2000 17:56:33 -0500 From: Russell Cattelan Message-Id: <200008182256.e7IMuX602819@gibble.americas.sgi.com> Subject: TAKE - Better RW -> RO remount code. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This still doesn't work right is all cases. If pounding on file system with a bunch of transactions, the call to remount will probalby hang. This code is mainly for shuting down a system running XFS as the root file system. I haven't had it fail yet on a reboot. This is generally due to the fact that the shutdown process kills just about everything before getting to remount RO. Date: Fri Aug 18 15:54:04 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72612a linux/fs/xfs/xfs_buf.h - 1.59 - changed comment. linux/fs/xfs/xfs_vfsops.c - 1.285 - revert the sync code back to orginal, read only remount handled in XFS_log_write_unmount_ro linux/fs/xfs/linux/xfs_lrw.h - 1.11 - Added prototype. linux/fs/xfs/linux/xfs_lrw.c - 1.52 - Added function to write out superblock and an unmount record, for a READONLY remount. linux/fs/xfs/linux/xfs_super.c - 1.84 - Call XFS_log_write_unmount_ro from remount. linux/include/linux/page_buf.h - 1.63 - Changed prototype. linux/fs/pagebuf/page_buf.c - 1.25 - Added flags to delwri_flush function. If flagged just returned the count of pinned buffer and/or locked buffers. From owner-linux-xfs@oss.sgi.com Fri Aug 18 20:49:52 2000 Received: by oss.sgi.com id ; Fri, 18 Aug 2000 20:49:42 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30824 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 18 Aug 2000 20:49:32 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA06375 for ; Fri, 18 Aug 2000 20:55:44 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA03879 for linux-xfs@oss.sgi.com; Sat, 19 Aug 2000 13:48:13 +1000 (EST) Date: Sat, 19 Aug 2000 13:48:13 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008190348.NAA03879@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This should fix those intermittent mount problems. cheers. Modid: 2.4.0-test1-xfs:slinx:72645a Date: Fri Aug 18 20:44:05 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/libxfs/rdwr.c - 1.8 - use bytes not blocks in device_zero code. From owner-linux-xfs@oss.sgi.com Sat Aug 19 06:27:36 2000 Received: by oss.sgi.com id ; Sat, 19 Aug 2000 06:27:26 -0700 Received: from hermes.mixx.net ([212.84.196.2]:42511 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 19 Aug 2000 06:27:12 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 5245FF826 for ; Sat, 19 Aug 2000 15:27:10 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 78A4F2CA6D; Sat, 19 Aug 2000 15:27:09 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs_repair crash Date: 19 Aug 2000 13:27:09 GMT Organization: innominate AG, Berlin, Germany Lines: 74 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 966691629 26002 10.0.0.69 (19 Aug 2000 13:27:09 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing yet another one :-) ok - with the old mkfs.xfs i was able to build xfs filesystems which were mountable and thus i was able to start running a system here at home completely on xfs (/ & /home) - works fine so far - even the shutdown now works (even with the code before the commit yester- day) ... ok i also have a small ext2 system on the disk too into which i might boot to check the xfs filesystems with xfs_repair ... this is what i got with that: ... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory xfs_repair: xfs_dir2_data.c:147: xfs_dir2_data_check: Assertion `i < ((( 0) == 1) ? (btp->count) : ((sizeof((btp->count)) == 8) ? ((typeof((btp->count)))(__fswab64((__u64)(btp->count)))) : ((sizeof((btp->count)) == 4) ? ((typeof((btp->count)))(__fswab32((__u32)(btp->count)))) : ((sizeof((btp->count)) == 2) ? ((typeof((btp->count)))(__fswab16((__u16)(btp->count)))) : ((btp->count))))) )' failed. Aborted (core dumped) [root@chrome /root]# Core was generated by `xfs_repair /dev/hda3'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x4003ad41 in __kill () from /lib/libc.so.6 (gdb) where #0 0x4003ad41 in __kill () from /lib/libc.so.6 #1 0x4003a9b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4003c0d8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40034bae in __assert_fail () at assert.c:59 #4 0x80f0063 in xfs_dir2_data_check (dp=0x81f2380, bp=0x815d940) at xfs_dir2_data.c:147 #5 0x80e7a43 in xfs_dir2_block_addname (args=0xbffff6b8) at xfs_dir2_block.c:410 #6 0x80e2520 in libxfs_dir2_createname (tp=0x8195a70, dp=0x81f2380, name=0x8103f29 "lost+found", namelen=10, inum=3337, first=0xbffff7c8, flist=0xbffff7b0, total=40) at xfs_dir2.c:133 #7 0x807db46 in dir_createname (mp=0xbffff844, tp=0x8195a70, pip=0x81f2380, name=0x8103f29 "lost+found", namelen=10, inum=3337, first=0xbffff7c8, flist=0xbffff7b0, total=40) at phase6.c:254 #8 0x807f18f in mk_orphanage (mp=0xbffff844) at phase6.c:779 #9 0x8089339 in phase6 (mp=0xbffff844) at phase6.c:3828 #10 0x8093c1e in main (argc=2, argv=0xbffffb14) at xfs_repair.c:487 (gdb) an old xfs_repair works - so looks like also here is a small problem with the non-sim code - a rerun of xfs_repair after such a crash of it resulted in a growing nomber of Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 entry at block 0 offset 352 in directory inode 128 has illegal name "/ost+found": clearing entry entry at block 0 offset 376 in directory inode 128 has illegal name "/ost+found": clearing entry entry at block 0 offset 400 in directory inode 128 has illegal name "/ost+found": clearing entry mismatch between format (2) and size (0) in directory ino 3337 cleared inode 3337 ... one the first time - two the second and three the third - the old binary - as said - worked fine on this filesystem and fixed all the problems - for the meantime i have uploaded a working (old) binary to http://innominate.org/~graichen/projects/xfs/ if anyone needs a working one (both xfs_repair or xfs_repair.gz for whatever bandwidth you have) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Aug 19 14:14:46 2000 Received: by oss.sgi.com id ; Sat, 19 Aug 2000 14:14:37 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:33196 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sat, 19 Aug 2000 14:14:12 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id QAA27879; Sat, 19 Aug 2000 16:14:09 -0500 (CDT) Date: Sat, 19 Aug 2000 16:14:09 -0500 (CDT) Message-Id: <200008192114.QAA27879@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Cleaned up the open_by_handle code in xfs/linux/xfs_ioctl.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The following is a patch to xfs_ioctl.c in fs/xfs/linux. It use anonymous dcache entries like nfssd. It use dentry_open from fs/open.c to do the mundane work of creating a file entry. I hope this will meke the code cleaner and easier to maintain and I think it gets rid of some potentially problems that can come about with the way nfsd use dcache entries. It really needs will formed cache entries for files and directories or for them to be anonymous so it can ignore them. ---------------------- cut here ----------------------------------------------------- *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 --- xfs_ioctl.c Sat Aug 19 14:07:58 2000 *************** *** 295,325 **** vfs_t *vfsp, xfs_mount_t *mp) { - int i; int error; ! int klocked = 0; ! int newfd = -1; int permflag; - char sname[(2 * MAXFIDSZ) + 1]; - char *cpi; - char *cpo; __u32 igen; struct dentry *dentry = NULL; ! struct dentry *pardentry; ! struct file *filp; struct inode *inode = NULL; - struct qstr sqstr; void *hanp; size_t hlen; ! vnode_t *vp = NULL; xfs_fid_t *xfid; xfs_handle_t *handlep; xfs_handle_t handle; - xfs_ino_t ino; - xfs_inode_t *ip = NULL; xfs_fsop_handlereq_t hreq; - #ifndef PERMISSIONS_BY_USER /* * Only allow Sys Admin capable users. --- 295,315 ---- vfs_t *vfsp, xfs_mount_t *mp) { int error; ! int new_fd; int permflag; __u32 igen; struct dentry *dentry = NULL; ! struct file *filp = NULL; struct inode *inode = NULL; void *hanp; size_t hlen; ! ino_t ino; xfs_fid_t *xfid; xfs_handle_t *handlep; xfs_handle_t handle; xfs_fsop_handlereq_t hreq; #ifndef PERMISSIONS_BY_USER /* * Only allow Sys Admin capable users. *************** *** 377,387 **** * Crack the handle, obtain the inode # & generation # */ - /* - * handle_to_vp(&handle) - * VFS_VGET (vfsp, &vp, &handlep->ha_fid, error) - * bdp, **vp, fidp; - */ xfid = (struct xfs_fid *)&handlep->ha_fid; if (xfid->xfs_fid_len == sizeof(*xfid) - sizeof(xfid->xfs_fid_len)) { --- 367,372 ---- *************** *** 395,617 **** return -XFS_ERROR(EINVAL); } - /* ! * Make a unique name for dcache. */ ! cpi = (char *)handlep; ! cpo = sname; ! ! for (i = 0; i < hlen && i < MAXFIDSZ; i++) { ! sprintf(cpo, "%02x", *cpi); ! ! cpi++; ! cpo += 2; } - *cpo = '\0'; /* ! * Obtain/create a 'dentry'. */ ! sqstr.name = sname; ! sqstr.len = 2 * hlen; ! sqstr.hash = full_name_hash(sname, hlen); ! ! pardentry = parfilp->f_dentry; ! ! ! down(&parinode->i_sem); ! ! dentry = d_lookup(pardentry, &sqstr); /* There already? */ ! if (!dentry) { ! dentry = d_alloc(pardentry, &sqstr); ! ! if (! dentry) { ! up(&parinode->i_sem); ! return -ENOMEM; ! } ! } ! ! up(&parinode->i_sem); ! inode = dentry->d_inode; ! /* ! * Get the XFS inode, building a vnode to go with it */ ! error = xfs_iget(mp, NULL, inode?inode->i_ino:ino, XFS_ILOCK_SHARED, &ip, 0); ! ! if (error) { ! error = -error; ! ! goto cleanup_dentry; ! } ! ! if (ip == NULL) { ! error = -XFS_ERROR(EIO); ! ! goto cleanup_dentry; ! } ! ! if (ip->i_d.di_mode == 0 || ip->i_d.di_gen != igen) { ! ! xfs_iput(ip, XFS_ILOCK_SHARED); ! ! error = -XFS_ERROR(ENOENT); ! ! goto cleanup_dentry; ! } ! ! vp = XFS_ITOV(ip); ! ! xfs_iunlock(ip, XFS_ILOCK_SHARED); ! ! if (inode == NULL) { ! inode = igrab(vp->v_inode); ! ! if (! inode) { ! error = -EACCES; ! ! VN_RELE(vp); ! ! goto cleanup_dentry; ! } ! ! /* ! * Set xfs inode ops. ! */ ! linvfs_set_inode_ops(inode); ! d_add(dentry, inode); ! } /* * Restrict handle operations to directories & regular files. ! */ if (! (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) ) { ! ! error = -XFS_ERROR(EINVAL); ! ! goto cleanup_dentry; } ! /* ! * Get a file descriptor # to use. */ ! lock_kernel(); ! ! klocked = 1; ! ! newfd = get_unused_fd(); ! ! if (newfd < 0) { ! error = newfd; ! ! goto cleanup_dentry; } /* ! * Get a file table entry. */ ! filp = get_empty_filp(); ! ! if (! filp) { ! error = -ENFILE; - goto cleanup_fd; - } - - filp->f_flags = hreq.oflags; - - filp->f_mode = (hreq.oflags + 1) & O_ACCMODE; - - #ifdef PERMISSIONS_BY_USER /* ! * Do permission/write checks */ ! permflag = 0; ! ! if (filp->f_mode & FMODE_READ) ! permflag |= MAY_READ; ! ! if (filp->f_mode & FMODE_WRITE) ! permflag |= MAY_WRITE; ! ! if (error = permission(inode, permflag)) ! goto cleanup_file; ! ! #endif /* PERMISSIONS_BY_USER */ ! ! if (filp->f_mode & FMODE_WRITE) { ! ! if (vp->v_type == VDIR) { /* Can't write directories */ ! error = -EISDIR; ! ! goto cleanup_file; ! } ! ! error = get_write_access(inode); ! ! if (error) ! goto cleanup_file; ! } ! /* ! * Stitch it all together. */ ! filp->f_dentry = dentry; ! filp->f_pos = 0; ! filp->f_reada = 0; ! filp->f_op = inode->i_fop; ! ! ! ! if (inode->i_sb) ! file_move(filp, &inode->i_sb->s_files); ! ! if (filp->f_op && filp->f_op->open) { ! ! error = filp->f_op->open(inode, filp); ! if (error) ! goto cleanup_all; } ! filp->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC); ! ! if (klocked) ! unlock_kernel(); ! klocked = 0; ! ! fd_install(newfd, filp); ! ! iput(inode); ! return newfd; ! cleanup_all: ! if (filp->f_mode & FMODE_WRITE) ! put_write_access(inode); ! ! cleanup_file: ! filp->f_dentry = NULL; ! put_filp(filp); ! ! cleanup_fd: ! if (newfd >= 0) ! put_unused_fd(newfd); ! ! cleanup_dentry: ! if (inode) ! iput(inode); ! dput(dentry); ! if (klocked) ! unlock_kernel(); ! return error; } --- 380,501 ---- return -XFS_ERROR(EINVAL); } /* ! * Get the inode. */ ! inode = iget(parfilp->f_dentry->d_inode->i_sb, ino); ! if (is_bad_inode(inode) || ! igen != inode->i_generation) { ! iput(inode); ! return -XFS_ERROR(ENOENT); } /* ! * Why do we need to do this? ! * XFS_IOC_FSBULKSTAT_SINGLE does a xfs_iget on the inode ! * and puts it in the linux inode cache with out ! * calling linvfs_set_inode_ops. The next time ! * the linux iget is called on the inode it will find the inode in the linux ! * cache so read_inode is not called and the inode ops field is never ! * initialized. */ ! linvfs_set_inode_ops(inode); /* ! * Fix the mode flags that linvfs_set_inode_ops bashes. */ ! linvfs_revalidate_core(inode); /* * Restrict handle operations to directories & regular files. ! */ if (! (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) ) { ! iput(inode); ! return -XFS_ERROR(EINVAL); ! } ! ! /* ! * Put open permission in namei format. ! */ ! permflag = hreq.oflags; ! if ((permflag+1) & O_ACCMODE) ! permflag++; ! if (permflag & O_TRUNC) ! permflag |= 2; ! ! /* ! * Can't write directories. ! */ ! if ( S_ISDIR(inode->i_mode) && (permflag & FMODE_WRITE)) { ! iput(inode); ! return -XFS_ERROR(EISDIR); ! } ! ! /* ! * Create new_fd ! */ ! if ((new_fd = get_unused_fd()) < 0) { ! iput(inode); ! return new_fd; } ! /* ! * Create anonymous dcache entry. */ ! dentry = d_alloc_root(inode); ! if (dentry == NULL) { ! iput(inode); ! put_unused_fd(new_fd); ! return -XFS_ERROR(ENOMEM); } /* ! * Keep nfsd happy. */ ! dentry->d_flags |= DCACHE_NFSD_DISCONNECTED; /* ! * Make sure dput can find this dcache entry. */ ! d_rehash(dentry); /* ! * Make sure umount returns an EBUSY on umounts while this file is open. */ ! mntget(parfilp->f_vfsmnt); ! /* ! * Create file pointer. ! */ ! filp = dentry_open(dentry, parfilp->f_vfsmnt, hreq.oflags); ! if (IS_ERR(filp)) { ! put_unused_fd(new_fd); ! return -XFS_ERROR(-PTR_ERR(filp)); } ! #ifdef PERMISSIONS_BY_USER ! /* ! * Do permission/write checks ! */ ! permflag = 0; ! if (filp->f_mode & FMODE_READ) ! permflag |= MAY_READ; ! if (filp->f_mode & FMODE_WRITE) ! permflag |= MAY_WRITE; + if (error = permission(inode, permflag)) { + put_unused_fd(new_fd); + fput(filp); + return -XFS_ERROR(-error); ! } ! #endif /* PERMISSIONS_BY_USER */ ! fd_install(new_fd, filp); ! return new_fd; } From owner-linux-xfs@oss.sgi.com Sat Aug 19 14:49:27 2000 Received: by oss.sgi.com id ; Sat, 19 Aug 2000 14:49:17 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:5293 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Sat, 19 Aug 2000 14:49:02 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id QAA28106; Sat, 19 Aug 2000 16:49:00 -0500 (CDT) Date: Sat, 19 Aug 2000 16:49:00 -0500 (CDT) Message-Id: <200008192149.QAA28106@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: Minor bug with xfs_iget Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing xfs_iget can put indoes in the linux inode cache that do not have the file operations field set in the linux incore inode. This mainly happens on a XFS_IOC_FSBULKSTAT_SINGLE function. This means that a linux iget can get a xfs inode with the out file operations field set. Fortunately linux makes little use of iget function. But nfsd does after a server crash. I think xfs_iget should always make sure that cached linux inode entries should have the correct file/inode/... operatoins initialized in the linux inode. I only stumbled on this do to my work with open_inode_by_handle. It is not something that needs to be fixed quickly. It is very unlikely to cause any problem except with nfsd and only after the server crashes and some one does a XFS_IOC_FSBULKSTAT_SINGLE with out doing a open_by_inode_handle immediately after. open_by_inode_handle will fix the file operation fields. Bill Jones From owner-linux-xfs@oss.sgi.com Sat Aug 19 15:40:56 2000 Received: by oss.sgi.com id ; Sat, 19 Aug 2000 15:40:46 -0700 Received: from Cantor.suse.de ([194.112.123.193]:58125 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sat, 19 Aug 2000 15:40:43 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 556FB1E2B4; Sun, 20 Aug 2000 00:40:41 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id C2D9E10A02A; Sun, 20 Aug 2000 00:40:40 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 4C39D2F300; Sun, 20 Aug 2000 00:40:40 +0200 (MEST) Date: Sun, 20 Aug 2000 00:40:40 +0200 From: "Andi Kleen" To: William L Jones Cc: linux-xfs@oss.sgi.com Subject: Re: Minor bug with xfs_iget Message-ID: <20000820004040.A25039@gruyere.muc.suse.de> References: <200008192149.QAA28106@spica.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008192149.QAA28106@spica.cc.utexas.edu>; from jones@tacc.cc.utexas.edu on Sat, Aug 19, 2000 at 04:49:00PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sat, Aug 19, 2000 at 04:49:00PM -0500, William L Jones wrote: > I think xfs_iget should always make sure that cached linux inode entries should have the > correct file/inode/... operatoins initialized in the linux inode. > > I only stumbled on this do to my work with open_inode_by_handle. It is not something > that needs to be fixed quickly. It is very unlikely to cause any problem except with nfsd > and only after the server crashes and some one does a XFS_IOC_FSBULKSTAT_SINGLE > with out doing a open_by_inode_handle immediately after. open_by_inode_handle will fix > the file operation fields. Actually knfsd does the iget too when its clients overrun the fhcache and it has to reconstruct file handles, so you would likely see it over high load. An easy way to overrun the fhcache is just to do a recursive grep in a big source tree. -Andi From owner-linux-xfs@oss.sgi.com Sat Aug 19 20:21:19 2000 Received: by oss.sgi.com id ; Sat, 19 Aug 2000 20:21:09 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:3883 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 19 Aug 2000 20:20:48 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA19542 for ; Sat, 19 Aug 2000 20:13:10 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07039; Sun, 20 Aug 2000 13:18:15 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA02526; Sun, 20 Aug 2000 13:18:12 +1000 (EST) From: "Nathan Scott" Message-Id: <10008201318.ZM2683@wobbly.melbourne.sgi.com> Date: Sun, 20 Aug 2000 13:18:11 -0500 In-Reply-To: Thomas Graichen "xfs_repair crash" (Aug 19, 11:28pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: xfs_repair crash Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Thomas, On Aug 19, 11:28pm, Thomas Graichen wrote: > Subject: xfs_repair crash > yet another one :-) > > ok - with the old mkfs.xfs i was able to build xfs filesystems which > were mountable and thus i was able to start running a system here at > home completely on xfs (/ & /home) - works fine so far - even the > shutdown now works (even with the code before the commit yester- > day) ... ok i also have a small ext2 system on the disk too into I have made one subsequent change to libxfs - everyone using a recent mkfs should refresh their source tree and rebuild (both libxfs and mkfs subdirs at least). > which i might boot to check the xfs filesystems with xfs_repair > ... this is what i got with that: > > ... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > xfs_repair: xfs_dir2_data.c:147: xfs_dir2_data_check: Assertion `i < ((( 0) == 1) ? (btp->count) : ((sizeof((btp->count)) == 8) ? ((typeof((btp->count)))(__fswab64((__u64)(btp->count)))) : ((sizeof((btp->count)) == 4) ? ((typeof((btp->count)))(__fswab32((__u32)(btp->count)))) : ((sizeof((btp->count)) == 2) ? ((typeof((btp->count)))(__fswab16((__u16)(btp->count)))) : ((btp->count))))) )' failed. > Aborted (core dumped) I have just managed to reproduce this locally ... I'll look into it further once I get in tomorrow. One point to note is that assert's weren't enabled in the old sim/xfs_repair code, and now are (perhaps they shouldn't be, for repair). At the stage where its dying though I wouldn't expect it to, so thats probably not of much interest. > an old xfs_repair works - so looks like also here is a small problem > with the non-sim code - a rerun of xfs_repair after such a crash of > it resulted in a growing nomber of > This isn't surprising considering the initial repair was half-way through creating the lost+found subdir when it died. It would be a good idea to use the -n option to the new xfs_repair until I sort this out. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Aug 20 17:33:36 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 17:33:26 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:65314 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 17:33:19 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09736 for ; Sun, 20 Aug 2000 17:39:32 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA12515 for linux-xfs@oss.sgi.com; Mon, 21 Aug 2000 10:30:44 +1000 (EST) Date: Mon, 21 Aug 2000 10:30:44 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008210030.KAA12515@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - unmount_ro missing include, move prdev Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72662a Date: Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/linux/xfs_super.c - Include xfs_lrw.h for missing prototype (+the 13 other files needed to get it to compile...) Modid: 2.4.0-test1-xfs:slinx:72664a Date: Sun Aug 20 17:28:02 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/pseudo-inc/sys/systm.h - 1.7 - move prdev into xfs_error.h linux/fs/xfs/xfs_buf_item.c - 1.109 - include xfs_error.h for prdev linux/fs/xfs/xfs_error.h - 1.15 - move prdev in linux/fs/xfs/xfs_inode.c - 1.301 - add diag From owner-linux-xfs@oss.sgi.com Sun Aug 20 19:00:27 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 19:00:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34065 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 19:00:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA15202 for ; Sun, 20 Aug 2000 18:52:23 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11918 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 21 Aug 2000 11:57:27 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA64653 for ; Mon, 21 Aug 2000 11:57:26 +1000 (EST) Message-Id: <200008210157.LAA64653@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: xfs_iget... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Aug 2000 11:57:26 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Re: the xfs_iget bug, could the people who've seen it please post some more info. I'd like to post this bug and need some more details on the symptons etc. I'm seeing "bad inode magic/vsn daddr" messages from xfs_itobp and I'm wondering if these are connected. Steve, do you think this is connected to pv 797419? Ta ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Aug 20 19:45:46 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 19:45:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50453 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 19:45:15 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA17469; Sun, 20 Aug 2000 19:37:38 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA03431; Sun, 20 Aug 2000 19:43:28 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA43719; Sun, 20 Aug 2000 19:42:12 -0700 (PDT) Date: Sun, 20 Aug 2000 19:42:12 -0700 (PDT) Message-Id: <200008210242.TAA43719@info.engr.sgi.com> X-Pv-Incident: 799518 webPV: harrier.corp.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nelsond@engr.sgi.com) Subject: BUG 799518 - panic machine when mounting filesystems and xfs_repair core dump To: nb@sgi.com Cc: ananth@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799518 Submitter : nelsond Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : I'm running the 2.4.0-test5-xfs code from bonnie from Aug 20th. I've run into a panic when mounting my filesystems. I have 30x 40GB raid luns. On thursday and friday I was hitting the bug where the filesystems would not mount without doing the xfs_repair on them. I put the new kernel source on, and recreated the xfs user utilities. I ran xfs_repair on my filesystems, and some of them had errors and caused xfs_repair to core dump. Here is the stack trace from the xfs_repair core dump: [root@tigershark 100gb_30_lun_load]# gdb xfs_repair core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_repair /dev/scsi/host3/bus0/target0/lun3/part10'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x4003ad41 in __kill () from /lib/libc.so.6 (gdb) where #0 0x4003ad41 in __kill () from /lib/libc.so.6 #1 0x4003a9b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4003c0d8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40034bae in __assert_fail () at assert.c:59 #4 0x8094bfb in xfs_iflush_fork (ip=0x8151ba8, dip=0x8151c88, whichfork=0, bp=0x8151c70) at util.c:336 #5 0x8095223 in libxfs_iflush_int (ip=0x8151ba8, bp=0x8151c70) at util.c:443 #6 0x80899a0 in libxfs_trans_log_inode (tp=0x814dbb8, ip=0x8151ba8, flags=1) at rdwr.c:456 #7 0x8074e5a in mk_root_dir (mp=0xbffffa44) at phase6.c:703 #8 0x807e11b in phase6 (mp=0xbffffa44) at phase6.c:3780 #9 0x8086c77 in main (argc=2, argv=0xbffffd14) at xfs_repair.c:487 (gdb) quit ====================================================================== After the xfs_repair, I tried to mount the filesystems, and got the following panic. =========================================================================== Start mounting filesystem: sd(8,74) XFS: corrupted root inode 0x84a: Root inode 128 is not a directory Unable to handle kernel NULL pointer dereference at virtual address 0000001c printing eip: c01b7b1c *pde = 00000000 Entering kdb (0xdb594000) on processor 1 Panic: Oops due to panic @ 0xc01b7b1c eax = 0x00000000 ebx = 0xdb94dee0 ecx = 0xc1ef6400 edx = 0xdb94def8 esi = 0xdb94dee0 edi = 0xdb595bb0 esp = 0xdb595b1c eip = 0xc01b7b1c ebp = 0xdb595b30 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0xdb940018 es = 0x00000018 origeax = 0xffffffff ®s = 0xdb595ae8 [1]kdb> bt EBP EIP Function(args) 0xdb595b30 0xc01b7b1c vn_count+0xc (0xe2c085a0, 0xe1f64ce0, 0xdb595eb4, 0x0, 0xc03d87e0) kernel .text 0xc0100000 0xc01b7b10 0xc01b7b20 0xdb595ec8 0xc01b6a2a linvfs_read_super+0x1c2 (0xe2f55400, 0x0, 0x0) kernel .text 0xc0100000 0xc01b6868 0xc01b6b04 0xdb595ee8 0xc01389f5 read_super+0x105 (0x84a, 0xde8b4fa0, 0xc0358768, 0x0, 0x0) kernel .text 0xc0100000 0xc01388f0 0xc0138a54 0xdb595f38 0xc0138c1b get_sb_bdev+0x15b (0xc0358768, 0xdb57a000, 0x0, 0x0) kernel .text 0xc0100000 0xc0138ac0 0xc0138c70 0xdb595f88 0xc0139836 do_mount+0x1a2 (0xdb57a000, 0xf7755000, 0xdce4a000, 0xc0ed0000, 0x0) kernel .text 0xc0100000 0xc0139694 0xc0139940 0xdb595fbc 0xc01399e7 sys_mount+0xa7 (0x8059778, 0x80597a8, 0x80597d8, 0xc0ed0000, 0x0) kernel .text 0xc0100000 0xc0139940 0xc0139a58 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [1]kdb> cpu 0 Entering kdb (0xe2f90000) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc0267b4b stext_lock+0x77f kernel .text.lock 0xc02673cc 0xc02673cc 0xc026d5e00xe2f91ed8 0xc0119ca1 schedule+0x6c9 kernel .text 0xc0100000 0xc01195d8 0xc0119e90 0xc01347c2 __wait_on_buffer+0xb2 (0xe17f7180) kernel .text 0xc0100000 0xc0134710 0xc01347e8 0xe2f91f1c 0xc0128b2d waitfor_one_page+0x1d (0xc18ded50) kernel .text 0xc0100000 0xc0128b10 0xc0128b54 0xe2f91f38 0xc0128bb7 do_buffer_fdatasync+0x63 (0xf79c0640, 0x0, 0xffffffff, 0xc0128b10, 0xf79c0640) kernel .text 0xc0100000 0xc0128b54 0xc0128c04 0xe2f91f6c 0xc0128c32 generic_buffer_fdatasync+0x2e (0xf79c0640, 0x0, 0xffffffff) kernel .text 0xc0100000 0xc0128c04 0xc0128c40 0xe2f91f98 0xc0151212 ext2_sync_file+0x52 (0xf7c0d4e0, 0xf762f0e0, 0x0) kernel .text 0xc0100000 0xc01511c0 0xc01512c0 0xe2f91fbc 0xc0134bb8 sys_fsync+0x54 (0x1, 0xbffff028, 0x0, 0xbffff050, 0x8058b58) kernel .text 0xc0100000 0xc0134b64 0xc0134bdc 0xc010a660 system_call+0x34 kernel .text 0xc0100000 0xc010a62c 0xc010a664 [0]kdb> cpu 2 Entering kdb (0xf7fbc000) on processor 2 due to cpu switch [2]kdb> bt EBP EIP Function(args) 0xf7fbdfa4 0xc0108880 default_idle+0x30 kernel .text 0xc0100000 0xc0108850 0xc0108888 0xc01088f2 cpu_idle+0x42 kernel .text 0xc0100000 0xc01088b0 0xc0108908 0xf7fbdfc0 0xc0377219 start_secondary+0x21 kernel .text.init 0xc0372000 0xc03771f8 0xc0377220[2]kdb> cpu 3 Entering kdb (0xf7fba000) on processor 3 due to cpu switch [3]kdb> bt EBP EIP Function(args) 0xf7fbbfa4 0xc0108880 default_idle+0x30 kernel .text 0xc0100000 0xc0108850 0xc0108888 0xc01088f2 cpu_idle+0x42 kernel .text 0xc0100000 0xc01088b0 0xc0108908 0xf7fbbfc0 0xc0377219 start_secondary+0x21 kernel .text.init 0xc0372000 0xc03771f8 0xc0377220 From owner-linux-xfs@oss.sgi.com Sun Aug 20 19:55:47 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 19:55:27 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1831 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 19:55:10 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02622; Sun, 20 Aug 2000 20:01:24 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA78830; Sun, 20 Aug 2000 19:54:39 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA08202; Sun, 20 Aug 2000 19:53:22 -0700 (PDT) Date: Sun, 20 Aug 2000 19:53:22 -0700 (PDT) Message-Id: <200008210253.TAA08202@info.engr.sgi.com> X-Pv-Incident: 799518 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: REASSIGN 799518 - panic machine when mounting filesystems and xfs_repair core dump To: nathans@engr.sgi.com Cc: ananth@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799518 Status : open Priority : 2 *Assigned Engineer : nathans *Assigned Domain : engr Submitter : nelsond Project : xfs-linux Assigned Group : xfs-linux Opened Date : 08/20/00 *Modified User : nathans *Modified User Domain : engr *Description : I'm running the 2.4.0-test5-xfs code from bonnie from Aug 20th. I've run into a panic when mounting my filesystems. I have 30x 40GB raid luns. On thursday and friday I was hitting the bug where the filesystems would not mount without doing the xfs_repair on them. I put the new kernel source on, and recreated the xfs user utilities. I ran xfs_repair on my filesystems, and some of them had errors and caused xfs_repair to core dump. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: nathans@engr (BugWorks) Date: Aug 20 2000 07:53:22PM ========================== From owner-linux-xfs@oss.sgi.com Sun Aug 20 20:02:47 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 20:02:27 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5399 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 20:02:15 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA18257; Sun, 20 Aug 2000 19:54:39 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA07142; Sun, 20 Aug 2000 20:01:44 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA67043; Sun, 20 Aug 2000 20:00:28 -0700 (PDT) Date: Sun, 20 Aug 2000 20:00:28 -0700 (PDT) Message-Id: <200008210300.UAA67043@info.engr.sgi.com> X-Pv-Incident: 799518 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 799518 - panic machine when mounting filesystems and xfs_repair core dump To: nathans@engr.sgi.com Cc: ananth@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799518 Status : open Priority : 2 Assigned Engineer : nathans Submitter : nelsond *Modified User : nathans *Modified User Domain : engr *Description : I'm running the 2.4.0-test5-xfs code from bonnie from Aug 20th. I've run into a panic when mounting my filesystems. I have 30x 40GB raid luns. On thursday and friday I was hitting the bug where the filesystems would not mount without doing the xfs_repair on them. I put the new kernel source on, and recreated the xfs user utilities. I ran xfs_repair on my filesystems, and some of them had errors and caused xfs_repair to core dump. ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 20 2000 08:00:27PM ========================== hi Doug, Looks like you've been bitten by a couple of bugs here. Firstly, the mkfs log zeroing problem has been fixed now, so there is no longer a need to run repair to rectify this. There are also some issues on the write path in xfs_repair, so running repair can currently be a destructive operation. I am about to checkin a change which will switch off the write path in repair for a little while (till I fix this). thanks. From owner-linux-xfs@oss.sgi.com Sun Aug 20 20:14:56 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 20:14:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39463 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 20:14:40 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA01972 for ; Sun, 20 Aug 2000 20:20:54 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA20267; Mon, 21 Aug 2000 13:13:15 +1000 (EST) Date: Mon, 21 Aug 2000 13:13:15 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008210313.NAA20267@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com, nelsond@corp.sgi.com Subject: PARTIAL TAKE 799518 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing To build the known-working version of xfs_repair: - run "make config" in $WORKAREA/linux directory (libsim requires this in order to build). - cd $WORKAREA/cmd/xfs/sim - run "make" - the new repair binary is in $WORKAREA/cmd/xfs/sim/repair/ cheers. Modid: 2.4.0-test1-xfs:slinx:72670a Date: Sun Aug 20 20:08:08 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/repair/xfs_repair.c - 1.48 - switch off write path (force nomodify), until corruption-via-repair fixed. cmd/xfs/sim/Makefile - 1.56 - Makefile to build known-working libsim-based tools. From owner-linux-xfs@oss.sgi.com Sun Aug 20 20:18:26 2000 Received: by oss.sgi.com id ; Sun, 20 Aug 2000 20:18:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38168 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 20 Aug 2000 20:18:11 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA19083; Sun, 20 Aug 2000 20:10:34 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA98979; Sun, 20 Aug 2000 20:17:40 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA67703; Sun, 20 Aug 2000 20:15:04 -0700 (PDT) Date: Sun, 20 Aug 2000 20:15:04 -0700 (PDT) Message-Id: <200008210315.UAA67703@feature.engr.sgi.com> X-Pv-Incident: 799518 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: PARTIAL TAKE 799518 - panic machine when mounting filesystems and xfs_repair core dump To: nathans@cthulhu.engr.sgi.com Cc: ananth@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : nelsond Status : open Assigned Engineer : nathans Priority : 2 *Modified Date : 08/20/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathans@snort.melbourne.sgi.com (nathan scott) (PARTIAL) Date: Aug 20 2000 08:15:03PM [pvnews version: 1.71] ---------------------------- To build the known-working version of xfs_repair: - run "make config" in $WORKAREA/linux directory (libsim requires this in order to build). - cd $WORKAREA/cmd/xfs/sim - run "make" - the new repair binary is in $WORKAREA/cmd/xfs/sim/repair/ cheers. Modid: 2.4.0-test1-xfs:slinx:72670a Date: Sun Aug 20 20:08:08 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/repair/xfs_repair.c - 1.48 - switch off write path (force nomodify), until corruption-via-repair fixed. cmd/xfs/sim/Makefile - 1.56 - Makefile to build known-working libsim-based tools. Description : I'm running the 2.4.0-test5-xfs code from bonnie from Aug 20th. I've run into a panic when mounting my filesystems. I have 30x 40GB raid luns. On thursday and friday I was hitting the bug where the filesystems would not mount without doing the xfs_repair on them. I put the new kernel source on, and recreated the xfs user utilities. I ran xfs_repair on my filesystems, and some of them had errors and caused xfs_repair to core dump. ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 20 2000 08:00:27PM ========================== hi Doug, Looks like you've been bitten by a couple of bugs here. Firstly, the mkfs log zeroing problem has been fixed now, so there is no longer a need to run repair to rectify this. There are also some issues on the write path in xfs_repair, so running repair can currently be a destructive operation. I am about to checkin a change which will switch off the write path in repair for a little while (till I fix this). thanks. From owner-linux-xfs@oss.sgi.com Mon Aug 21 00:13:58 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 00:13:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18223 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 00:13:38 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA02426; Mon, 21 Aug 2000 00:19:52 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id AAA26924; Mon, 21 Aug 2000 00:13:36 -0700 (PDT) Date: Mon, 21 Aug 2000 00:13:36 -0700 (PDT) Message-Id: <200008210713.AAA26924@info.engr.sgi.com> X-Pv-Incident: 798910 webPV: boing.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tes@engr.sgi.com) Subject: ADD 798910 - xfsdump -I can't find mnt= mount point To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=798910 Status : open Priority : 2 Assigned Engineer : nb Submitter : pma *Modified User : tes *Modified User Domain : engr *Description : An xfs filesystem was backed up daily via xfsdump. The mount point of the filesystem was changed, and xfsdump was called to back up the filesystem with the new mount point. When xfsdump -I was called using the NEW filesystem mount point, it failed to retrieve any information, and in fact gave this: xfsdump:INV:open failed on mount point "efs:/groups/ulib" If you run xfsdump -I with mnt= the ORIGINAL mount point, you can see the entry for the NEW mount point. ========================== ..... ========================== ADDITIONAL INFORMATION (ADD) From: tes@engr (BugWorks) Date: Aug 21 2000 12:13:34AM ========================== Can you please run as root: # xfsdump -I fstab Can you please tell me what version of IRIX xfsdump is coming from ? [As a reminder to me: - may have something to do with extra test for mount pt match when adding to inv-fstab. Added in inv_fstab.c rev#1.3 and commented out in inv_fstab.c rev#1.11. ] From owner-linux-xfs@oss.sgi.com Mon Aug 21 00:17:18 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 00:17:08 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:29229 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 00:17:03 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA00934 for ; Mon, 21 Aug 2000 00:09:26 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13712; Mon, 21 Aug 2000 17:14:28 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA04252; Mon, 21 Aug 2000 17:14:27 +1000 (EST) From: "Nathan Scott" Message-Id: <10008211714.ZM4254@wobbly.melbourne.sgi.com> Date: Mon, 21 Aug 2000 17:14:27 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-xfs@oss.sgi.com Subject: libxfs/mkfs/repair status Cc: nelsond@engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, Just thought I'd send a note regarding the current state of mkfs and repair, in light of recent changes & problems with those changes, so that everyone knows where things stand... - mkfs and repair both link with a static library which knows alot about the internals of XFS, in particular how to manipulate most of the on-disk data structures in a manner very similar to the kernel XFS code (much of the code is exactly the same in the kernel); - this is either libsim (previously) or libxfs (currently) - libxfs is very new (days) and has had some teething problems with both mkfs and repair... o first major problem was that the device zeroing code was buggy - this was corrected over the weekend. this code is used by both mkfs and repair (phase 2) to initialize the log to a known state (all zeros); o the bug caused only parts of the log to be zeroed such that the head was OK initially, but after passing a few records through the log, we'd eventually read a not-zero'd part at a bad time (e.g. mount); o became more confusing because the same buggy zeroing code could be called from repair to partly-initialise the log once more... seemingly "fixing" mkfs' mistake, but not really (resetting it the same way mkfs did); o *these log zeroing problems seem to be resolved now* o the second problem is only evident in repair, since it uses alot more of the library functionality than mkfs; o this problem is going to be more difficult to correct - it seems I've made a bad "optimisation" in the new code which now does not play well with the transaction mechanism in certain situations; o I will have to pull in alot more transaction code in order to resolve this one, and its gonna take a bit of time (several days I imagine, & I'll clearly need to do a bunch more testing too); o as a result of this, I have switched off the code which performs any writes in xfs_repair, so that filesystems will not be further damaged by using it in the interim. So, current state is: there are no known issues with mkfs, and I'm working on fixing the write code in repair. Note that it should still be possible to use the known-working libsim mkfs/repair using the instructions I sent out earlier (I have no idea what caused the core dump you saw, Thomas - the sim code hasn't changed for a long time now & it works fine for me... very strange). cheers for now. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Aug 21 01:48:29 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 01:48:19 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64054 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 01:48:03 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA06341; Mon, 21 Aug 2000 01:40:26 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id BAA34323; Mon, 21 Aug 2000 01:47:31 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id BAA11396; Mon, 21 Aug 2000 01:46:14 -0700 (PDT) Date: Mon, 21 Aug 2000 01:46:14 -0700 (PDT) Message-Id: <200008210846.BAA11396@info.engr.sgi.com> X-Pv-Incident: 798910 webPV: boing.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (tes@engr.sgi.com) Subject: ADD 798910 - xfsdump -I can't find mnt= mount point To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=798910 Status : open Priority : 2 Assigned Engineer : nb Submitter : pma *Modified User : tes *Modified User Domain : engr *Description : An xfs filesystem was backed up daily via xfsdump. The mount point of the filesystem was changed, and xfsdump was called to back up the filesystem with the new mount point. When xfsdump -I was called using the NEW filesystem mount point, it failed to retrieve any information, and in fact gave this: xfsdump:INV:open failed on mount point "efs:/groups/ulib" If you run xfsdump -I with mnt= the ORIGINAL mount point, you can see the entry for the NEW mount point. ========================== ..... ========================== ADDITIONAL INFORMATION (ADD) From: tes@engr (BugWorks) Date: Aug 21 2000 01:46:11AM ========================== Reproduced this locally using TOT xfsdump. "xfsdump -I fstab" showed that the newly mounted filesystem with different name but on same partition with old fsid was not added. I remounted /dev/sda10 as /mnt/tmp3 and it didn't show up in the inventory fstab. [root@sherman stress]# xfsdump -I fstab xfsdump: --------- fstab ------------ Mount sherman.melbourne.sgi.com:/mnt/tmp1 Dev sherman.melbourne.sgi.com:/dev/sda9 FSid 0f80a92f-4766-4029-803a-bf9b5e55345c Mount sherman.melbourne.sgi.com:/mnt/tmp Dev sherman.melbourne.sgi.com:/dev/sda10 FSid 61fedff9-e7d9-2310-0080-79736d6d6a69 xfsdump: ---------========------------ I will need to work out reason for inv_fstab.c rev#1.3. From owner-linux-xfs@oss.sgi.com Mon Aug 21 08:24:12 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 08:24:02 -0700 Received: from Cantor.suse.de ([194.112.123.193]:36876 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 21 Aug 2000 08:23:48 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id C34921E1B8 for ; Mon, 21 Aug 2000 17:23:44 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 6E77F10A028 for ; Mon, 21 Aug 2000 17:23:44 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 79B612F300; Mon, 21 Aug 2000 17:23:41 +0200 (MEST) Date: Mon, 21 Aug 2000 17:23:41 +0200 From: "Andi Kleen" To: linux-xfs@oss.sgi.com Subject: Locking bmap mappings Message-ID: <20000821172341.A31808@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing In ext2 and most other file systems it is enough to hold the inode semaphore to pin blocks returned by bmap (because truncate and unlink are the only functions that could steal blocks from under you). This seems to be mostly true for XFS too because it is enforced in the VFS above XFS, but it has some loopholes with the space management ioctls and the fsr (swapext). The following patch plugs them by grabbing the respective linux inode semaphores. Did I forget any case where bmap could be invalidated? -Andi --- ./fs/xfs/linux/xfs_ioctl.c-o Wed Aug 9 02:18:40 2000 +++ ./fs/xfs/linux/xfs_ioctl.c Sun Aug 20 20:55:00 2000 @@ -751,7 +751,8 @@ xfs_flock64_t bf; xfs_inode_t *ip; xfs_mount_t *mp; - + int need_isem; + vp = LINVFS_GET_VP(inode); ASSERT(vp); @@ -769,15 +770,24 @@ return (EIO); + /* + * Linux code relies on i_sem protecing bmap mappings, so grab it + * for all operations that may shrink the file or free space. + * XXX: is this correct for inode mapped files? + */ + need_isem = 0; switch (cmd) { - case XFS_IOC_ALLOCSP: case XFS_IOC_FREESP: + case XFS_IOC_FREESP64: + need_isem = 1; + /*FALL THROUGH*/ + + case XFS_IOC_ALLOCSP: case XFS_IOC_RESVSP: case XFS_IOC_UNRESVSP: case XFS_IOC_ALLOCSP64: - case XFS_IOC_FREESP64: case XFS_IOC_RESVSP64: case XFS_IOC_UNRESVSP64: { @@ -798,13 +808,15 @@ /* if (filp->f_flags & FINVIS) XXXjtk - need O_INVISIBLE? */ attr_flags |= ATTR_DMI; - + + if (need_isem) + down(&inode->i_sem); error = xfs_change_file_space(bdp, cmd, &bf, filp->f_pos, - &cred, attr_flags); - if (error) - return -error; + &cred, attr_flags); + if (need_isem) + up(&inode->i_sem); - return 0; + return -error; } case XFS_IOC_DIOINFO: --- ./fs/xfs/xfs_dfrag.c-o Wed Aug 9 02:18:50 2000 +++ ./fs/xfs/xfs_dfrag.c Sun Aug 20 19:57:16 2000 @@ -293,6 +293,9 @@ xfs_trans_cancel(tp, 0); return error; } + + double_down(fp->f_dentry->d_inode, tfp->f_dentry->d_inode); + xfs_lock_inodes(ips, 2, 0, XFS_ILOCK_EXCL); /* @@ -304,6 +307,8 @@ if (error) { xfs_iunlock(ip, lock_flags); xfs_iunlock(tip, lock_flags); + up(&fp->f_dentry->d_inode); + up(&tfp->f_dentry->d_inode); xfs_trans_cancel(tp, 0); return error; } @@ -396,6 +401,9 @@ error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT, NULL); CELL_ONLY(cfs_end_defrag(vp, cxfs_val)); + + up(fp->f_dentry->d_inode); + up(tfp->f_dentry->d_inode); fput(fp); fput(tfp); From owner-linux-xfs@oss.sgi.com Mon Aug 21 08:24:22 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 08:24:12 -0700 Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:50695 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 08:24:06 -0700 Received: from thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e7LFO0a37785 for ; Mon, 21 Aug 2000 10:24:00 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <39A14990.3DE667D1@thebarn.com> Date: Mon, 21 Aug 2000 10:24:00 -0500 From: Russell Cattelan Reply-To: cattelan@thebarn.com X-Mailer: Mozilla 4.73 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [Fwd: Performance: test6, 7-5, 7-5 Multiqueue, history] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing -------- Original Message -------- Subject: Performance: test6, 7-5, 7-5 Multiqueue, history Date: Sun, 20 Aug 2000 11:56:43 -0700 From: Rajagopal Ananthanarayanan To: slinx-xfs@cthulhu.engr.sgi.com Just sent this message out to linux-mm list. In case anyone is tempted to move XFS to newer linux versions, test5 seems to be the best w.r.t the performance domain. Another performance update using various benchmarks. In the following, TEST7-5 is test7-pre5 patch. TEST7-5MQ has in addition the Multiqueue VM patch (the MQ patch is 2.4.0-t7p4-vmpatch2b, dated circa Tue Aug 15 14:27:14 2000). Observations ------------ o test5 continues to yield the best performance. o test5 -> test6 (and in test7-5) block I/O performance degraded about 10%. o test6 -> test7-5 non-streaming dbench performance stabilized. o considering best results in each kernel version, both test6 & test7-5 are worse than test5 by about 30% o MQ patch yields bad performance in most cases; perhaps changes between test7-pre4 and test7-pre5 don't sit well with MQ changes, since I used the t7p4 MQ patch. All numbers on a 2P 64MB X86 box using a dedicated scsi disk for the tests containing an EXT2 filesystem. All tests were run 3 times, in some cases individual results from 3 runs are reported; in others a range is given. ------ Bonnie ------ -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU TEST7-5MQ 256 3507 97.1 9021 14.3 3715 6.6 2985 88.6 16494 17.7 170.8 2.4 TEST7-5MQ 256 3572 98.9 9153 14.1 3757 7.1 2984 88.1 15749 17.7 170.0 2.5 TEST7-5MQ 256 3566 98.3 9086 13.7 3776 6.8 2975 88.5 16469 16.7 171.4 2.8 TEST7-5 256 3651 100.1 10041 14.4 5916 11.1 3038 89.9 18153 17.5 187.0 3.4 TEST7-5 256 3649 100.0 10105 14.1 5931 10.6 3034 89.8 18155 18.4 187.7 2.5 TEST7-5 256 3651 99.9 10077 14.7 5923 10.7 3041 89.9 18184 17.6 187.9 2.6 TEST6 256 3624 99.2 10057 14.3 5917 10.3 3031 90.1 18159 18.4 180.6 2.3 TEST6 256 3650 99.9 10096 14.6 5917 10.7 3032 89.9 18143 17.9 185.2 2.3 TEST6 256 3649 100.0 10036 14.2 5894 10.2 3038 90.0 18188 17.4 184.6 2.8 TEST5 256 3618 99.2 11135 16.0 5981 10.8 3005 88.8 18268 17.8 185.4 2.9 TEST5 256 3652 100.0 11066 15.6 6014 10.6 2999 89.1 18276 17.4 185.5 2.8 TEST5 256 3647 99.8 11055 15.8 5924 10.3 3003 88.8 18270 18.5 183.5 3.1 TEST4 256 3630 99.5 9915 14.7 6013 11.3 2894 86.0 18502 19.1 181.4 3.1 TEST4 256 3110 85.5 9884 14.7 6098 11.1 1831 54.3 18554 17.6 183.8 3.0 TEST4 256 3301 89.7 9857 15.3 6034 10.2 2772 82.7 18570 17.6 180.8 2.5 TEST3 256 3628 99.5 10693 15.3 6084 10.7 3014 89.5 18533 17.7 182.6 3.2 TEST3 256 3648 100.2 10456 15.2 6044 11.1 3031 89.7 18511 18.6 183.6 2.5 TEST3 256 3650 99.9 10545 15.6 6046 10.8 3020 89.9 18518 19.8 181.6 2.6 TEST1 256 3434 94.8 6858 12.0 2949 6.1 3110 93.0 18713 21.3 174.9 3.3 TEST1 256 3421 95.0 6933 11.2 2628 6.0 3052 91.2 18569 22.0 176.0 2.5 TEST1 256 3474 96.5 6900 11.5 2824 6.1 3023 90.6 18103 24.4 173.5 2.9 ----------------------------------- lmdd (across blocksizes 1K to 1024K) ------------------------------------ Write Read --------- -------- TEST7-5+MQ 9.4-10.4 MB/s 15.5-17 MB/sec TEST7-5 10.8 MB/s ~19 MB/s TEST6 10.8 MB/s ~19 MB/s TEST5 11.5 MB/s ~19 MB/s TEST4 10 MB/s [ Didn't run this ] TEST3 10-11 MB/s ~19 MB/s TEST1 6-7 MB/s ~18.5 MB/s ------------------- DBENCH (48 clients) ------------------- TEST7-5+MQ 2.7, 2.7, 1.9 MB/sec TEST7-5 8.4, 8.6, 8.8 MB/sec TEST6 8.6, 8.1, 7.1 MB/sec TEST5 11.5 - 12.4 MB/sec TEST4 10.X - 11.X MB/sec TEST3 10.X - 11.X MB/sec TEST1 1.5 - 2.X MB/sec -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Aug 21 18:10:25 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 18:10:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30470 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 18:09:59 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05376 for ; Mon, 21 Aug 2000 18:16:13 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA22207 for ; Mon, 21 Aug 2000 20:08:40 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id UAA23761 for ; Mon, 21 Aug 2000 20:08:39 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7M17xS11258; Mon, 21 Aug 2000 20:07:59 -0500 Date: Mon, 21 Aug 2000 20:07:59 -0500 From: Russell Cattelan Message-Id: <200008220107.e7M17xS11258@gibble.americas.sgi.com> Subject: TAKE - mkinitrd -> 2.5 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Aug 21 18:06:17 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72705a cmd/xfs/misc/mkinitrd.xfs - 1.2 - Bring up to mkinitrd 2.5 From owner-linux-xfs@oss.sgi.com Mon Aug 21 18:50:05 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 18:49:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:52492 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 18:49:32 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA19047 for ; Mon, 21 Aug 2000 18:41:53 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA76850 for linux-xfs@oss.sgi.com; Tue, 22 Aug 2000 11:48:11 +1000 (EST) Date: Tue, 22 Aug 2000 11:48:11 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008220148.LAA76850@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE missing include, remove xfs_itable Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72706a Date: Mon Aug 21 18:41:18 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-bruce Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/linux/xfs_lrw.c - 1.53 - add missing include Modid: 2.4.0-test1-xfs:slinx:72707a Date: Mon Aug 21 18:46:01 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-bruce Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_itable.c - 1.90 linux/fs/xfs/xfs_itable.h - 1.31 - remove unused xfs_itable From owner-linux-xfs@oss.sgi.com Mon Aug 21 22:46:16 2000 Received: by oss.sgi.com id ; Mon, 21 Aug 2000 22:46:06 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56338 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 21 Aug 2000 22:46:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA05935; Mon, 21 Aug 2000 22:52:19 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA18449; Mon, 21 Aug 2000 22:46:01 -0700 (PDT) Date: Mon, 21 Aug 2000 22:46:01 -0700 (PDT) Message-Id: <200008220546.WAA18449@info.engr.sgi.com> X-Pv-Incident: 799616 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 799616 - ASSERT fail imap.br_startblock != DELAYSTARTBLOCK To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799616 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : when running the xfscrash corrupt test, an ASSERT can get tripped: XFS assertion failed: imap.br_startblock != DELAYSTARTBLOCK, file: xfs_vnodeops.c, line: 5803 kernel BUG at xfs_debug.c:50! Entering kdb (0xedeb6000) on processor 1 Panic: invalid operand due to panic @ 0xf89028a9 eax = 0x0000001e ebx = 0x000f8fff ecx = 0xc02b6f2c edx = 0x00000000 esi = 0x00000000 edi = 0x00000000 esp = 0xedeb79b4 eip = 0xf89028a9 ebp = 0xedeb79c0 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xedeb7980 EBP EIP Function(args) 0xedeb79c0 0xf89028a9 [xfs]assfail+0x2d (0xf8921160, 0xf892095b, 0x16ab) xfs .text 0xf8894060 0xf890287c 0xf89028b0 0xedeb7a38 0xf88ffa99 [xfs]xfs_zero_remaining_bytes+0x1c1 (0xf3676040, 0xf8f45, 0x0, 0xf8fff, 0x0) xfs .text 0xf8894060 0xf88ff8d8 0xf88ffbc4 0xedeb7b1c 0xf8900156 [xfs]xfs_free_file_space+0x592 (0xf3676040, 0xf8f45, 0x0, 0x5102a, 0x0) xfs .text 0xf8894060 0xf88ffbc4 0xf89003b0 0xedeb7be0 0xf89005de [xfs]xfs_change_file_space+0x22e (0xf3676058, 0x402c582b, 0xedeb7d34, 0x0, 0x0) xfs .text 0xf8894060 0xf89003b0 0xf89007b8 0xedeb7f34 0xf890414c [xfs]xfs_ioctl+0x33c (0xf3676058, 0xf705bb40, 0xf7c79480, 0x402c582b, 0xbffff91c) xfs .text 0xf8894060 0xf8903e10 0xf8904d00 0xedeb7f58 0xf8902ec2 [xfs]linvfs_ioctl+0x56 (0xf705bb40, 0xf7c79480, 0x402c582b, 0xbffff91c) xfs .text 0xf8894060 0xf8902e6c 0xf8902ecc 0xedeb7f84 0xc014084b file_ioctl+0x14b (0xf7c79480, 0x402c582b, 0xbffff91c, 0xedeb6000) kernel .text 0xc0100000 0xc0140700 0xc0140860 0xedeb7fbc 0xc01409cd sys_ioctl+0x16d (0x3, 0x402c582b, 0xbffff91c, 0x5102a, 0x0) kernel .text 0xc0100000 0xc0140860 0xc0140a50 0xc0109040 system_call+0x34 kernel .text 0xc0100000 0xc010900c 0xc0109044 The bug is related to the "resvsp" & "unresvsp" operations in fsstress. (fsstress -d /mnt/arch0/stress -n 1000 -p 1 -f sync=0 allocsp=0 freesp=0) From owner-linux-xfs@oss.sgi.com Tue Aug 22 11:43:40 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 11:43:30 -0700 Received: from fepB.post.tele.dk ([195.41.46.145]:5025 "EHLO fepB.post.tele.dk") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 11:43:23 -0700 Received: from burns.home.kernel.dk ([193.89.189.243]) by fepB.post.tele.dk (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000822184320.SPTB819.fepB.post.tele.dk@burns.home.kernel.dk> for ; Tue, 22 Aug 2000 20:43:20 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 13RJ1u-0001D2-00 for ; Tue, 22 Aug 2000 20:44:10 +0200 Date: Tue, 22 Aug 2000 20:44:10 +0200 From: Jens Axboe To: linux-xfs@oss.sgi.com Subject: stuck in sv_wait Message-ID: <20000822204410.L2336@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Linux 2.2.16-2GB-SMP i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, Doing any kind of work on an xfs mounted partition, results in processes stuck in sv_wait... This occurs on both IDE and SCSI, with and without kio (cluster or plain) enabled. Although rm or cp will be uninterruptibly stuck in sv_wait, they do come to life ocassionally and perform some I/O. But most of the time is spent sleeping, without any I/O getting done. Here's a backtrace of rm: 0xc33a2000 00000696 00000368 0 001 stop 0xc33a2340 rm [1]kdb> btp 696 EBP EIP Function(args) 0xc33a3e2c 0xc01166d2 schedule+0x3ca kernel .text 0xc0100000 0xc0116308 0xc0116bc0 0xc01abcea _sv_wait+0xd6 (0xc2559d48, 0xc3df4714, 0x292, 0x0, 0x0) kernel .text 0xc0100000 0xc01abc14 0xc01abd08 0xc0191b1f xlog_grant_log_space+0x127 (0xc3df4680, 0xc2559d48, 0xc6c49c00, 0x58b70, 0xc3df4680) kernel .text 0xc0100000 0xc01919f8 0xc0191c38 0xc0190109 xfs_log_reserve+0x81 (0xc6c49c00, 0x2abb8, 0x2, 0xc5559e94, 0x69) kernel .text 0xc0100000 0xc0190088 0xc0190114 0xc019c1bf xfs_trans_reserve+0x7f (0xc5559e60, 0x0, 0x2abb8, 0x0, 0x4) kernel .text 0xc0100000 0xc019c140 0xc019c274 0xc01a2758 xfs_inactive+0x1a8 (0xc4093968, 0x0) kernel .text 0xc0100000 0xc01a25b0 0xc01a29cc 0xc01b0a99 vn_put+0x45 (0xc66c6940) kernel .text 0xc0100000 0xc01b0a54 0xc01b0ad8 0xc01ab774 linvfs_d_iput+0x18 (0xc7061760, 0xc66c6860) kernel .text 0xc0100000 0xc01ab75c 0xc01ab790 0xc0141ecd d_delete+0x55 (0xc7061760) kernel .text 0xc0100000 0xc0141e78 0xc0141f14 0xc013c6e0 vfs_unlink+0x168 (0xc66c69e0, 0xc7061760) kernel .text 0xc0100000 0xc013c578 0xc013c6f8 0xc33a3fa4 0xc013c79f sys_unlink+0xa7 (0x80522f7, 0xbffff3ac, 0xbffff44c, 0x80522f7, 0x0) kernel .text 0xc0100000 0xc013c6f8 0xc013c818 [1]more> 0xc010a690 system_call+0x34 kernel .text 0xc0100000 0xc010a65c 0xc010a694 This is pretty much preventing me from doing a final beat up of IDE kiobuf support, since it's impossible to trash the disk. Any clues? -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Tue Aug 22 13:00:20 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 13:00:10 -0700 Received: from [216.206.117.2] ([216.206.117.2]:10506 "EHLO disco.typeset.net") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 13:00:01 -0700 Received: from xnote.com ([209.180.88.127]) by disco.typeset.net (8.8.7/8.8.8) with ESMTP id NAA28554 for ; Tue, 22 Aug 2000 13:59:53 -0600 Message-ID: <39A2DB4D.585E4605@xnote.com> Date: Tue, 22 Aug 2000 13:58:05 -0600 From: Vernon McPherron Reply-To: vernon@xnote.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-test1-ac16 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: stuck in sv_wait References: <20000822204410.L2336@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > > Hi, > > Doing any kind of work on an xfs mounted partition, results in processes > stuck in sv_wait... This occurs on both IDE and SCSI, with and without > kio (cluster or plain) enabled. > > Although rm or cp will be uninterruptibly stuck in sv_wait, they do come > to life ocassionally and perform some I/O. But most of the time is spent > sleeping, without any I/O getting done. Here's a backtrace of rm: > > This is pretty much preventing me from doing a final beat up of IDE > kiobuf support, since it's impossible to trash the disk. Any clues? Ah, so I'm not the only one that saw this. I was using the Aug 17th cvs. Haven't tried since then, is there something I'm doing or not doing? -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Tue Aug 22 13:19:40 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 13:19:30 -0700 Received: from fepF.post.tele.dk ([195.41.46.135]:22780 "EHLO fepF.post.tele.dk") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 13:19:06 -0700 Received: from burns.home.kernel.dk ([193.89.189.243]) by fepF.post.tele.dk (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000822201904.KAQW5020.fepF.post.tele.dk@burns.home.kernel.dk>; Tue, 22 Aug 2000 22:19:04 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 13RKWY-0002lA-00; Tue, 22 Aug 2000 22:19:54 +0200 Date: Tue, 22 Aug 2000 22:19:54 +0200 From: Jens Axboe To: Vernon McPherron Cc: linux-xfs@oss.sgi.com Subject: Re: stuck in sv_wait Message-ID: <20000822221954.B10355@suse.de> References: <20000822204410.L2336@suse.de> <39A2DB4D.585E4605@xnote.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39A2DB4D.585E4605@xnote.com>; from vernon@xnote.com on Tue, Aug 22, 2000 at 01:58:05PM -0600 X-OS: Linux 2.2.16-2GB-SMP i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Aug 22 2000, Vernon McPherron wrote: > > Doing any kind of work on an xfs mounted partition, results in processes > > stuck in sv_wait... This occurs on both IDE and SCSI, with and without > > kio (cluster or plain) enabled. > > Ah, so I'm not the only one that saw this. I was using the Aug 17th > cvs. > > Haven't tried since then, is there something I'm doing or not doing? On a hunch, I tried using egcs-1.1.2 instead of gcc-2.95 (I didn't think I had that on my devel system, but I guess I did...). This has cured the problem for me, so you may want to try that. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Tue Aug 22 15:14:40 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 15:14:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:56944 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 15:14:27 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08600; Tue, 22 Aug 2000 15:06:50 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA72504; Tue, 22 Aug 2000 15:14:26 -0700 (PDT) Date: Tue, 22 Aug 2000 15:14:26 -0700 (PDT) Message-Id: <200008222214.PAA72504@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: sgigate.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: BUG 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com, slinx-xfs@cthulhu.engr.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Submitter : ananth Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. From owner-linux-xfs@oss.sgi.com Tue Aug 22 16:06:00 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 16:05:51 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35687 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 16:05:37 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06025; Tue, 22 Aug 2000 16:11:53 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA38808; Tue, 22 Aug 2000 16:05:36 -0700 (PDT) Date: Tue, 22 Aug 2000 16:05:36 -0700 (PDT) Message-Id: <200008222305.QAA38808@info.engr.sgi.com> X-Pv-Incident: 799711 webPV: gibble.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: BUG 799711 - LINUX XFS reports wrong permissions. To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799711 Submitter : cattelan Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : nt8[5:33pm]-=>ls -l total 121 drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 Chicane_FarFromTheMaddeni ngCrowds/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_Interpretatio nsByJerryBonham/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_ d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_ d2/ drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d1/ d--------- 2 cattelan sdivmisc 4096 Jul 28 1999 PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulOakenfold_Tranceport/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_SevenWays_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_SevenWays_d2/ drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ gibble[5:34pm]-=>ls -l total 60 drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 Chicane_FarFromTheMaddeningCrowds/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOakenfold-NewYork_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOakenfold-NewYork_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_InterpretationsByJerryBonham/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_d2/ drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d1/ drwxrwxr-x 2 cattelan sdivmisc 4096 Aug 22 17:32 PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulOakenfold_Tranceport/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_SevenWays_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_SevenWays_d2/ drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ From owner-linux-xfs@oss.sgi.com Tue Aug 22 16:59:31 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 16:59:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23659 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 16:59:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA08431 for ; Tue, 22 Aug 2000 17:05:19 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA84871 for linux-xfs@oss.sgi.com; Wed, 23 Aug 2000 09:56:28 +1000 (EST) Date: Wed, 23 Aug 2000 09:56:28 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008222356.JAA84871@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix broken sim build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This should do it, Nathan. Modid: 2.4.0-test1-xfs:slinx:72793a Date: Tue Aug 22 16:56:10 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/sim/src/sim.lock.c - 1.37 - - remove freesema & spinlock_destroy - they're now macros From owner-linux-xfs@oss.sgi.com Tue Aug 22 17:00:41 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 17:00:31 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30827 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 17:00:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA03957 for ; Tue, 22 Aug 2000 17:06:38 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27103; Wed, 23 Aug 2000 09:59:05 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA44847; Wed, 23 Aug 2000 09:59:04 +1000 (EST) Message-Id: <200008222359.JAA44847@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jens Axboe cc: linux-xfs@oss.sgi.com Subject: Re: stuck in sv_wait In-reply-to: Your message of "Tue, 22 Aug 2000 22:19:54 +0200." <20000822221954.B10355@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Aug 2000 09:59:03 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe writes: => On a hunch, I tried using egcs-1.1.2 instead of gcc-2.95 (I didn't think => I had that on my devel system, but I guess I did...). This has cured => the problem for me, so you may want to try that. This is probably a FAQ now. I gather XFS and/or the kernel have issues with gcc-2.95. We build with egcs-2.91.66 here with no problems. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 22 17:19:21 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 17:19:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16398 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 17:18:58 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA21879; Tue, 22 Aug 2000 17:11:21 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA12818; Tue, 22 Aug 2000 17:18:57 -0700 (PDT) Date: Tue, 22 Aug 2000 17:18:57 -0700 (PDT) Message-Id: <200008230018.RAA12818@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : chait *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Aug 22 2000 05:18:56PM ========================== I'm seeing this problem intermittently as well. These are the kinds of messages that dbench spits out when it hits the problem: (47235) nb_close: handle 4294 was not open Any ideas on whats going on? Cheers, -Chait. From owner-linux-xfs@oss.sgi.com Tue Aug 22 17:23:21 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 17:23:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45164 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 17:23:05 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04697; Tue, 22 Aug 2000 17:29:21 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA28433; Tue, 22 Aug 2000 17:23:04 -0700 (PDT) Date: Tue, 22 Aug 2000 17:23:04 -0700 (PDT) Message-Id: <200008230023.RAA28433@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Aug 22 2000 05:23:03PM ========================== Here's Nathan's suggestion: -------- when you do a fresh mkfs, then run xfs_logprint, does it just say: # /usr/sbin/xfs_logprint /dev/hda7 xfs_logprint: data device: 0x307 log device: 0x307 daddr: 1020128 length: 9600 xfs_logprint: skipped 9600 zeroed blocks xfs_logprint: totally zeroed log xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ # (thats what it should say, anyway). -------------- Chait, can you try this on your system? ananth. From owner-linux-xfs@oss.sgi.com Tue Aug 22 17:33:11 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 17:33:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34832 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 17:32:45 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA23018; Tue, 22 Aug 2000 17:25:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA14692; Tue, 22 Aug 2000 17:30:59 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA66256; Tue, 22 Aug 2000 17:29:41 -0700 (PDT) Date: Tue, 22 Aug 2000 17:29:41 -0700 (PDT) Message-Id: <200008230029.RAA66256@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : nathans *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 22 2000 05:29:41PM ========================== The other things I thought might be useful to try would be: - make sim versions of commands & verify they don't see the problem also; - ensure mkfs really is linked to top of tree libxfs; otherwise I'm fresh out of ideas... baffled as to how my changes might cause these errors (which isn't to say they haven't caused them, just that I can't imagine how). thanks. From owner-linux-xfs@oss.sgi.com Tue Aug 22 19:38:43 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 19:38:33 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42355 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 19:38:13 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA02079; Tue, 22 Aug 2000 19:44:29 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA23309; Tue, 22 Aug 2000 19:37:42 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA42034; Tue, 22 Aug 2000 19:36:24 -0700 (PDT) Date: Tue, 22 Aug 2000 19:36:24 -0700 (PDT) Message-Id: <200008230236.TAA42034@info.engr.sgi.com> X-Pv-Incident: 799747 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 799747 - xfs_logprint doesn't grok external log footer To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799747 Submitter : nathans Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 4 Project : xfs-linux Status : open Description : So, I thought it would be a good idea to make absolutely sure that the log zeroing code is working again - and it is. However, it seems that with an external log device, logprint thinks the log footer which mkfs writes at the end of the log is bad-looking "data" and prints an error message. This problem exists in both the libsim (mkfs_xfs below) and libxfs (/sbin/mkfs.xfs below) versions of mkfs. In write_log_footer() the log footer seems to start with: 0x70, 0x68, 0x69, 0x6c as magic... ### external log, libxfs ### 11:32 nathans@troppo ~ 19> sudo ./devzero /dev/hda8 -1 Wrote 38146 x 4K blocks (value 0xffffffff) 11:34 nathans@troppo ~ 21> sudo /sbin/mkfs.xfs -f -l logdev=/dev/hda8,size=32000b -d name=/dev/hda7 meta-data=/dev/hda7 isize=256 agcount=8, agsize=31878 blks data = bsize=4096 blocks=255023, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =/dev/hda8 bsize=4096 blocks=32000 realtime =none extsz=65536 blocks=0, rtextents=0 11:35 nathans@troppo ~ 23> sudo /usr/sbin/xfs_logprint /dev/hda7 -l /dev/hda8 xfs_logprint: data device: 0x307 log file: "/dev/hda8" daddr: 0 length: 256000 Header 0x7068696c wanted 0xfeedbabe xfs_logprint: after 255999 zeroed blocks ********************************************************************** * ERROR: found data after zeroed blocks block=255999 * ********************************************************************** ********************************************************************** * ERROR: header cycle=1885890924 block=255999 * ********************************************************************** xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ ### external log, libsim ### 11:41 nathans@troppo ~ 37> sudo ./devzero /dev/hda8 -1 Wrote 38146 x 4K blocks (value 0xffffffff) 11:42 nathans@troppo ~ 38> sudo ./mkfs_xfs -f -l logdev=/dev/hda8,size=32000b -d name=/dev/hda7 xfs: using dummy primary network address meta-data=/dev/hda7 isize=256 agcount=8, agsize=31878 blks data = bsize=4096 blocks=255023, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =/dev/hda8 bsize=4096 blocks=32000 realtime =none extsz=65536 blocks=0, rtextents=0 11:42 nathans@troppo ~ 39> sudo /usr/sbin/xfs_logprint /dev/hda7 -l /dev/hda8 xfs_logprint: data device: 0x307 log file: "/dev/hda8" daddr: 0 length: 256000 Header 0x7068696c wanted 0xfeedbabe xfs_logprint: after 255999 zeroed blocks ********************************************************************** * ERROR: found data after zeroed blocks block=255999 * ********************************************************************** ********************************************************************** * ERROR: header cycle=1885890924 block=255999 * ********************************************************************** xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ 11:43 nathans@troppo ~ 40> ### internal log, libsim ### (this looks good) 12:07 nathans@troppo ~ 41> sudo ./devzero /dev/hda8 -1 Wrote 38146 x 4K blocks (value 0xffffffff) 12:08 nathans@troppo ~ 42> sudo ./mkfs_xfs -f /dev/hda8 xfs: using dummy primary network address meta-data=/dev/hda8 isize=256 agcount=8, agsize=4769 blks data = bsize=4096 blocks=38146, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 12:10 nathans@troppo ~ 43> sudo /usr/sbin/xfs_logprint /dev/hda8 xfs_logprint: data device: 0x308 log device: 0x308 daddr: 152640 length: 9600 xfs_logprint: skipped 9600 zeroed blocks xfs_logprint: totally zeroed log xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ ### internal log, libxfs ### (this looks good too) 12:10 nathans@troppo ~ 44> sudo ./devzero /dev/hda8 -1 Wrote 38146 x 4K blocks (value 0xffffffff) 12:11 nathans@troppo ~ 45> sudo /sbin/mkfs.xfs /dev/hda8 meta-data=/dev/hda8 isize=256 agcount=8, agsize=4769 blks data = bsize=4096 blocks=38146, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 12:11 nathans@troppo ~ 46> sudo /usr/sbin/xfs_logprint /dev/hda8 xfs_logprint: data device: 0x308 log device: 0x308 daddr: 152640 length: 9600 xfs_logprint: skipped 9600 zeroed blocks xfs_logprint: totally zeroed log xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ 12:11 nathans@troppo ~ 47> From owner-linux-xfs@oss.sgi.com Tue Aug 22 21:56:03 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 21:55:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49528 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 21:55:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA05040 for ; Tue, 22 Aug 2000 22:01:50 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA68960 for linux-xfs@oss.sgi.com; Wed, 23 Aug 2000 14:52:59 +1000 (EST) Date: Wed, 23 Aug 2000 14:52:59 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008230452.OAA68960@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 799747 xfs_logprint doesn't grok external logs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:72818a Date: Tue Aug 22 21:52:01 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_log_recover.c - 1.184 cmd/xfs/logprint/kernel.c - 1.4 - remove surplus \ns, tidy up footer check, make xlog_test_footer non-static cmd/xfs/logprint/log_misc.c - 1.68 cmd/xfs/logprint/log_print_trans.c - 1.33 cmd/xfs/logprint/logprint.c - 1.44 cmd/xfs/logprint/logprint.h - 1.7 - tidy From owner-linux-xfs@oss.sgi.com Tue Aug 22 22:02:33 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 22:02:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1913 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 22:02:13 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA00386; Tue, 22 Aug 2000 22:08:30 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA27990; Tue, 22 Aug 2000 22:02:11 -0700 (PDT) Date: Tue, 22 Aug 2000 22:02:11 -0700 (PDT) Message-Id: <200008230502.WAA27990@info.engr.sgi.com> X-Pv-Incident: 799752 webPV: clouds.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: BUG 799752 - failed mount leaves entry in uuid table To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799752 Submitter : dxm Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : a failed mount (ie because log mount failed) will leave an entry in the uuid table. If the mount is retried, the uuid will be recreated due to the "already mounted" FS with the same uuid. Also, if the uuid is recreated for a FS with an external log, the log mount will fail since the uuid in the footer does not match the new uuid created. From owner-linux-xfs@oss.sgi.com Tue Aug 22 22:26:13 2000 Received: by oss.sgi.com id ; Tue, 22 Aug 2000 22:26:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:47413 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 22 Aug 2000 22:25:52 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA12891 for ; Tue, 22 Aug 2000 22:18:14 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA38646 for linux-xfs@oss.sgi.com; Wed, 23 Aug 2000 15:24:32 +1000 (EST) Date: Wed, 23 Aug 2000 15:24:32 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008230524.PAA38646@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - randomize stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing sigh Modid: 2.4.0-test1-xfs:slinx:72820a Date: Tue Aug 22 22:24:13 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/src/fsstress.c - 1.6 - wild idea: lets do _different_ stress each time! From owner-linux-xfs@oss.sgi.com Wed Aug 23 00:16:24 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 00:16:04 -0700 Received: from hermes.mixx.net ([212.84.196.2]:9735 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Wed, 23 Aug 2000 00:15:53 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id BC5E9F806 for ; Wed, 23 Aug 2000 09:15:51 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 8CDC02CA6B; Wed, 23 Aug 2000 09:15:51 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: stuck in sv_wait Date: 23 Aug 2000 07:15:51 GMT Organization: innominate AG, Berlin, Germany Lines: 44 Distribution: local Message-ID: References: <20000822221954.B10355@suse.de> <200008222359.JAA44847@clouds.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967014951 6635 10.0.0.69 (23 Aug 2000 07:15:51 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > Jens Axboe writes: > => On a hunch, I tried using egcs-1.1.2 instead of gcc-2.95 (I didn't think > => I had that on my devel system, but I guess I did...). This has cured > => the problem for me, so you may want to try that. > This is probably a FAQ now. I gather XFS and/or the kernel have issues > with gcc-2.95. > We build with egcs-2.91.66 here with no problems. just added it to the faq ... btw. what kind of problems are that - are they in the gcc 2.95 optimizer or in the i386 backend (because maybe this is also the reson for the problems on the other arches i tried: ppc and alpha - i used 2.95 on both - because it's the standard there ... maybe i should build and try egcs there too) t p.s.: i very often get the following whenever i want to check something into the web tree - anyone from the sgi people an idea what this is ? ... Checking in faq.html; /cvs/xfs-website/faq.html,v <-- faq.html new revision: 1.13; previous revision: 1.12 done cvs [server aborted]: received broken pipe signal cvs commit: saving log message in /tmp/cvstJJmJa graichen@h2o ~/xfs-faq/xfs-website % i am cvs login'ed here and sometimes it also works ... -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Aug 23 08:26:26 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 08:26:16 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:56771 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 08:26:07 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id KAA16986; Wed, 23 Aug 2000 10:26:01 -0500 (CDT) Message-Id: <4.2.0.58.20000823095720.02202e00@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 10:27:49 -0500 To: sgi.bugs.xfs@fido.engr.sgi.com, nb@sgi.com From: "William L. Jones" Subject: Re: BUG 799711 - LINUX XFS reports wrong permissions. Cc: linux-xfs@oss.sgi.com In-Reply-To: <200008222305.QAA38808@info.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing open_by_handle can cause this, where you doning a xfsdump? The problem in open_by_handle in xfs_ioctl.c. It is doing a linvfs_set_inode_ops with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears the perm bits in the mode field. The following patch will fix the current oepn_by_handle: *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 *************** *** 481,486 **** --- 481,492 ---- * Set xfs inode ops. */ linvfs_set_inode_ops(inode); + + /* + * Fix the perm mode flags that linvfs_set_inode_ops bashes. + */ + linvfs_revalidate_core(inode); + d_add(dentry, inode); } --------------------- end ------------------------------------------------- If this doesn't fix the problem then there may be some other place were linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops call right after. At 04:05 PM 8/22/00 -0700, cattelan@engr.sgi.com wrote: >View Incident: >http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1& >view_type=Bug&wi=799711 > >Submitter : cattelan Submitter Domain : engr >Assigned Engineer : nb Assigned Domain : sgi.com >Assigned Group : xfs-linux Category : software >Customer Reported : F Priority : 3 >Project : xfs-linux Status : open >Description : >nt8[5:33pm]-=>ls -l >total 121 >drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ >drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 >Chicane_FarFromTheMaddeni ngCrowds/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOak enfold-NewYork_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOak enfold-NewYork_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_Interpretatio nsByJerryBonham/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_ d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_ d2/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d1/ >d--------- 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulOakenfold_Tranceport/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d2/ >drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ > >gibble[5:34pm]-=>ls -l >total 60 >drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ >drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 >Chicane_FarFromTheMaddeningCrowds/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOakenfold-NewYork_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOakenfold-NewYork_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_InterpretationsByJerryBonham/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_d2/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d1/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Aug 22 17:32 >PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulOakenfold_Tranceport/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d2/ >drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ From owner-linux-xfs@oss.sgi.com Wed Aug 23 08:33:45 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 08:33:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27919 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 08:33:12 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25227; Wed, 23 Aug 2000 08:25:35 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA20459; Wed, 23 Aug 2000 08:32:41 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA62533; Wed, 23 Aug 2000 08:30:04 -0700 (PDT) Date: Wed, 23 Aug 2000 08:30:04 -0700 (PDT) Message-Id: <200008231530.IAA62533@feature.engr.sgi.com> X-Pv-Incident: 799711 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (jones@tacc.cc.utexas.edu.sgi.com) Subject: ADD 799711 - LINUX XFS reports wrong permissions. To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : cattelan Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 08/23/00 *Modified User : jones *Modified User Domain : tacc.cc.utexas.edu *Description : nt8[5:33pm]-=>ls -l total 121 drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 Chicane_FarFromTheMaddeni ngCrowds/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_Interpretatio nsByJerryBonham/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_ d1/ ..... ========================== ADDITIONAL INFORMATION (ADD) From: "william l. jones" Date: Aug 23 2000 08:30:03AM [pvnews version: 1.71] ========================== open_by_handle can cause this, where you doning a xfsdump? The problem in open_by_handle in xfs_ioctl.c. It is doing a linvfs_set_inode_ops with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears the perm bits in the mode field. The following patch will fix the current oepn_by_handle: *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 *************** *** 481,486 **** --- 481,492 ---- * Set xfs inode ops. */ linvfs_set_inode_ops(inode); + + /* + * Fix the perm mode flags that linvfs_set_inode_ops bashes. + */ + linvfs_revalidate_core(inode); + d_add(dentry, inode); } --------------------- end ------------------------------------------------- If this doesn't fix the problem then there may be some other place were linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops call right after. At 04:05 PM 8/22/00 -0700, cattelan@engr.sgi.com wrote: >View Incident: >http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1& >view_type=Bug&wi=799711 > >Submitter : cattelan Submitter Domain : engr >Assigned Engineer : nb Assigned Domain : sgi.com >Assigned Group : xfs-linux Category : software >Customer Reported : F Priority : 3 >Project : xfs-linux Status : open >Description : >nt8[5:33pm]-=>ls -l >total 121 >drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ >drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 >Chicane_FarFromTheMaddeni ngCrowds/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOak enfold-NewYork_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOak enfold-NewYork_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_Interpretatio nsByJerryBonham/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_ d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_ d2/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d1/ >d--------- 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:Tw oYearsOfOakenfoldAtCream_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulOakenfold_Tranceport/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d2/ >drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ > >gibble[5:34pm]-=>ls -l >total 60 >drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ >drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 >Chicane_FarFromTheMaddeningCrowds/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOakenfold-NewYork_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >GlobalUnderground_PaulOakenfold-NewYork_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_InterpretationsByJerryBonham/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >JerryBonham_SoundEscapes_d2/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Jul 28 1999 >PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d1/ >drwxrwxr-x 2 cattelan sdivmisc 4096 Aug 22 17:32 >PaulOakenfold_Resident:TwoYearsOfOakenfoldAtCream_d2/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulOakenfold_Tranceport/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 PaulVanDyk_45RPM/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d1/ >drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 >PaulVanDyk_SevenWays_d2/ >drwxr-xr-x 13 cattelan sdivmisc 146 Oct 9 1998 cddb/ From owner-linux-xfs@oss.sgi.com Wed Aug 23 09:50:46 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 09:50:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:37411 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 09:50:04 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA05119 for ; Wed, 23 Aug 2000 09:41:57 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.mw.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA47935; Wed, 23 Aug 2000 11:46:52 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id LAA24162; Wed, 23 Aug 2000 11:46:51 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e7NGkFr16749; Wed, 23 Aug 2000 11:46:15 -0500 Message-ID: <39A3FFD7.C3A2625F@thebarn.com> Date: Wed, 23 Aug 2000 11:46:15 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "William L. Jones" CC: sgi.bugs.xfs@fido.engr.sgi.com, nb@sgi.com, linux-xfs@oss.sgi.com Subject: Re: BUG 799711 - LINUX XFS reports wrong permissions. References: <4.2.0.58.20000823095720.02202e00@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "William L. Jones" wrote: > open_by_handle can cause this, where you doning a xfsdump? No, basically the only activity on the file system was serving up some nfs traffic. This does give me something to go on, I'll dig around and see if anything looks suspicious. BTW I have your latest ioctl patch in my tree, ran fsr a few times... seems to work just fine. I'll commit it shortly. > > > The problem in open_by_handle in xfs_ioctl.c. It is doing a > linvfs_set_inode_ops > with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears > the perm bits in the mode field. The following patch > will fix the current oepn_by_handle: > > *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 > --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 > *************** > *** 481,486 **** > --- 481,492 ---- > * Set xfs inode ops. > */ > linvfs_set_inode_ops(inode); > + > + /* > + * Fix the perm mode flags that linvfs_set_inode_ops bashes. > + */ > + linvfs_revalidate_core(inode); > + > d_add(dentry, inode); > } > --------------------- end ------------------------------------------------- > > If this doesn't fix the problem then there may be some other place were > linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops > call right after. > > From owner-linux-xfs@oss.sgi.com Wed Aug 23 09:52:35 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 09:52:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:6948 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 09:51:54 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA05407; Wed, 23 Aug 2000 09:43:47 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA65193; Wed, 23 Aug 2000 09:50:04 -0700 (PDT) Date: Wed, 23 Aug 2000 09:50:04 -0700 (PDT) Message-Id: <200008231650.JAA65193@feature.engr.sgi.com> X-Pv-Incident: 799711 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com) Subject: ADD 799711 - LINUX XFS reports wrong permissions. To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : cattelan Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 08/23/00 *Modified User : cattelan *Modified User Domain : thebarn.com *Description : nt8[5:33pm]-=>ls -l total 121 drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 Chicane_FarFromTheMaddeni ngCrowds/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_Interpretatio nsByJerryBonham/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_ d1/ ..... ========================== ADDITIONAL INFORMATION (ADD) From: russell cattelan Date: Aug 23 2000 09:50:04AM [pvnews version: 1.71] ========================== "William L. Jones" wrote: > open_by_handle can cause this, where you doning a xfsdump? No, basically the only activity on the file system was serving up some nfs traffic. This does give me something to go on, I'll dig around and see if anything looks suspicious. BTW I have your latest ioctl patch in my tree, ran fsr a few times... seems to work just fine. I'll commit it shortly. > > > The problem in open_by_handle in xfs_ioctl.c. It is doing a > linvfs_set_inode_ops > with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears > the perm bits in the mode field. The following patch > will fix the current oepn_by_handle: > > *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 > --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 > *************** > *** 481,486 **** > --- 481,492 ---- > * Set xfs inode ops. > */ > linvfs_set_inode_ops(inode); > + > + /* > + * Fix the perm mode flags that linvfs_set_inode_ops bashes. > + */ > + linvfs_revalidate_core(inode); > + > d_add(dentry, inode); > } > --------------------- end ------------------------------------------------- > > If this doesn't fix the problem then there may be some other place were > linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops > call right after. > > From owner-linux-xfs@oss.sgi.com Wed Aug 23 10:41:45 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 10:41:35 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:54984 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 10:41:09 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA18557; Wed, 23 Aug 2000 12:40:26 -0500 (CDT) Message-Id: <4.2.0.58.20000823123945.021cd180@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 12:42:16 -0500 To: Russell Cattelan , "William L. Jones" From: "William L. Jones" Subject: Re: BUG 799711 - LINUX XFS reports wrong permissions. Cc: sgi.bugs.xfs@fido.engr.sgi.com, nb@sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <39A3FFD7.C3A2625F@thebarn.com> References: <4.2.0.58.20000823095720.02202e00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing If you are using nfds then the problems is in vn_initialize it should call linvfs_revalidate_core after the linvfs_set_inode_ops. At 11:46 AM 8/23/00 -0500, Russell Cattelan wrote: >"William L. Jones" wrote: > > > > open_by_handle can cause this, where you doning a xfsdump? > >No, basically the only activity on the file system was serving up some >nfs traffic. > >This does give me something to go on, I'll dig around and see if >anything looks suspicious. > > >BTW I have your latest ioctl patch in my tree, >ran fsr a few times... seems to work just fine. >I'll commit it shortly. > > > > > > > The problem in open_by_handle in xfs_ioctl.c. It is doing a > > linvfs_set_inode_ops > > with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears > > the perm bits in the mode field. The following patch > > will fix the current oepn_by_handle: > > > > *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 > > --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 > > *************** > > *** 481,486 **** > > --- 481,492 ---- > > * Set xfs inode ops. > > */ > > linvfs_set_inode_ops(inode); > > + > > + /* > > + * Fix the perm mode flags that linvfs_set_inode_ops > bashes. > > + */ > > + linvfs_revalidate_core(inode); > > + > > d_add(dentry, inode); > > } > > --------------------- end ------------------------------------------------- > > > > If this doesn't fix the problem then there may be some other place were > > linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops > > call right after. > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 23 10:47:26 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 10:47:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10038 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 10:46:55 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01279; Wed, 23 Aug 2000 10:52:42 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA67156; Wed, 23 Aug 2000 10:45:05 -0700 (PDT) Date: Wed, 23 Aug 2000 10:45:05 -0700 (PDT) Message-Id: <200008231745.KAA67156@feature.engr.sgi.com> X-Pv-Incident: 799711 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (jones@tacc.cc.utexas.edu.sgi.com) Subject: ADD 799711 - LINUX XFS reports wrong permissions. To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : cattelan Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 08/23/00 *Modified User : jones *Modified User Domain : tacc.cc.utexas.edu *Description : nt8[5:33pm]-=>ls -l total 121 drwxr-xrwx 16 cattelan sdivmisc 4096 Mar 6 18:37 ./ drwxrwxr-x 42 cattelan sdivmisc 4096 Apr 14 13:04 ../ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 BT_ESCM/ drwxr-xr-x 2 cattelan sdivmisc 4096 Aug 9 17:21 Chicane_FarFromTheMaddeni ngCrowds/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d1/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 GlobalUnderground_PaulOak enfold-NewYork_d2/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_Interpretatio nsByJerryBonham/ drwxr-xr-x 2 cattelan sdivmisc 4096 Feb 17 1999 JerryBonham_SoundEscapes_ d1/ ..... ========================== ADDITIONAL INFORMATION (ADD) From: "william l. jones" Date: Aug 23 2000 10:45:04AM [pvnews version: 1.71] ========================== If you are using nfds then the problems is in vn_initialize it should call linvfs_revalidate_core after the linvfs_set_inode_ops. At 11:46 AM 8/23/00 -0500, Russell Cattelan wrote: >"William L. Jones" wrote: > > > > open_by_handle can cause this, where you doning a xfsdump? > >No, basically the only activity on the file system was serving up some >nfs traffic. > >This does give me something to go on, I'll dig around and see if >anything looks suspicious. > > >BTW I have your latest ioctl patch in my tree, >ran fsr a few times... seems to work just fine. >I'll commit it shortly. > > > > > > > The problem in open_by_handle in xfs_ioctl.c. It is doing a > > linvfs_set_inode_ops > > with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears > > the perm bits in the mode field. The following patch > > will fix the current oepn_by_handle: > > > > *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 > > --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 > > *************** > > *** 481,486 **** > > --- 481,492 ---- > > * Set xfs inode ops. > > */ > > linvfs_set_inode_ops(inode); > > + > > + /* > > + * Fix the perm mode flags that linvfs_set_inode_ops > bashes. > > + */ > > + linvfs_revalidate_core(inode); > > + > > d_add(dentry, inode); > > } > > --------------------- end ------------------------------------------------- > > > > If this doesn't fix the problem then there may be some other place were > > linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops > > call right after. > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 23 10:56:26 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 10:56:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:40757 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 10:55:56 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14264 for ; Wed, 23 Aug 2000 10:47:49 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA12136 for ; Wed, 23 Aug 2000 12:52:53 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id MAA26798 for ; Wed, 23 Aug 2000 12:52:52 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7NHqGI17905 for linux-xfs@oss.sgi.com; Wed, 23 Aug 2000 12:52:16 -0500 Date: Wed, 23 Aug 2000 12:52:16 -0500 From: Russell Cattelan Message-Id: <200008231752.e7NHqGI17905@gibble.americas.sgi.com> Subject: TAKE - xfs_open_by_handle patch To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Aug 23 10:50:17 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:72847a linux/fs/xfs/linux/xfs_ioctl.c - 1.18 - Patch from: William L Jones It use anonymous dcache entries like nfssd. It use dentry_open from fs/open.c to do the mundane work of creating a file entry. I hope this will meke the code cleaner and easier to maintain and I think it gets rid of some potentially problems that can come about with the way nfsd use dcache entries. It really needs will formed cache entries for files and directories or for them to be anonymous so it can ignore them. From owner-linux-xfs@oss.sgi.com Wed Aug 23 11:35:05 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 11:35:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:13120 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 11:34:42 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA19410 for ; Wed, 23 Aug 2000 11:26:35 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA17100; Wed, 23 Aug 2000 13:31:39 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA28549; Wed, 23 Aug 2000 13:31:38 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e7NIV2r19429; Wed, 23 Aug 2000 13:31:02 -0500 Message-ID: <39A41863.F5243C5@thebarn.com> Date: Wed, 23 Aug 2000 13:31:00 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "William L. Jones" CC: linux-xfs@oss.sgi.com Subject: Re: BUG 799711 - LINUX XFS reports wrong permissions. References: <4.2.0.58.20000823095720.02202e00@127.0.0.1> <4.2.0.58.20000823123945.021cd180@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "William L. Jones" wrote: > If you are using nfds then the problems is in vn_initialize it should call > linvfs_revalidate_core after the linvfs_set_inode_ops. I was just looking at that. Ofcourse it can't be that simple. :-) > > > At 11:46 AM 8/23/00 -0500, Russell Cattelan wrote: > >"William L. Jones" wrote: > > > > > > > open_by_handle can cause this, where you doning a xfsdump? > > > >No, basically the only activity on the file system was serving up some > >nfs traffic. > > > >This does give me something to go on, I'll dig around and see if > >anything looks suspicious. > > > > > >BTW I have your latest ioctl patch in my tree, > >ran fsr a few times... seems to work just fine. > >I'll commit it shortly. > > > > > > > > > > > The problem in open_by_handle in xfs_ioctl.c. It is doing a > > > linvfs_set_inode_ops > > > with out doing a linvfs_revalidate_core after, linvfs_set_inode_op clears > > > the perm bits in the mode field. The following patch > > > will fix the current oepn_by_handle: > > > > > > *** xfs_ioctl.c.orig Sat Aug 19 14:03:21 2000 > > > --- xfs_ioctl.c Wed Aug 23 10:01:58 2000 > > > *************** > > > *** 481,486 **** > > > --- 481,492 ---- > > > * Set xfs inode ops. > > > */ > > > linvfs_set_inode_ops(inode); > > > + > > > + /* > > > + * Fix the perm mode flags that linvfs_set_inode_ops > > bashes. > > > + */ > > > + linvfs_revalidate_core(inode); > > > + > > > d_add(dentry, inode); > > > } > > > --------------------- end ------------------------------------------------- > > > > > > If this doesn't fix the problem then there may be some other place were > > > linvfs_set_inode_ops gets called with out a linvfs_set_inode_ops > > > call right after. > > > > > > From owner-linux-xfs@oss.sgi.com Wed Aug 23 17:22:58 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 17:22:48 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:47133 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 17:22:34 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA03520; Wed, 23 Aug 2000 17:14:17 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA12341; Wed, 23 Aug 2000 17:21:23 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA51201; Wed, 23 Aug 2000 17:20:05 -0700 (PDT) Date: Wed, 23 Aug 2000 17:20:05 -0700 (PDT) Message-Id: <200008240020.RAA51201@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: OBSERVE 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 *Status : observe Priority : 2 Assigned Engineer : nb Submitter : ananth Opened Date : 08/22/00 *Closed Date : 08/23/00 *Fixed By : nathans *Fixed By Domain : engr *Modified Date : 08/23/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (OBSERVE) From: nathans@engr (BugWorks) Date: Aug 23 2000 05:20:05PM ========================== >From the mail exchange Ananth, Chait and I had yesterday, my current understanding is that this was an old mkfs and a full recompile fixed the problem, so I'll move status to observe. Ananth/Chait please close/reject when you're confident dbench is no longer acting up. thanks. From owner-linux-xfs@oss.sgi.com Wed Aug 23 17:56:57 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 17:56:47 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41254 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 17:56:33 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA07605; Wed, 23 Aug 2000 17:48:26 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA47877; Wed, 23 Aug 2000 17:56:01 -0700 (PDT) Date: Wed, 23 Aug 2000 17:56:01 -0700 (PDT) Message-Id: <200008240056.RAA47877@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : observe Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Aug 23 2000 05:56:01PM ========================== Actually, the problem still exists. I was just saying that something makes the symptoms go away. In fact, chait & I were running some reasonably heavy dbench tests (at 96 clients) and the random failures started happening ... this is on Chait's test system with lots of memory ("sierra"). Earlier today dbench had completed several runs successfully. ananth. From owner-linux-xfs@oss.sgi.com Wed Aug 23 18:09:57 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 18:09:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38759 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 18:09:30 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05940; Wed, 23 Aug 2000 18:15:17 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA04643; Wed, 23 Aug 2000 18:08:58 -0700 (PDT) Date: Wed, 23 Aug 2000 18:08:58 -0700 (PDT) Message-Id: <200008240108.SAA04643@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: ADD 799238 - RAM disk driver breaks locking hierarchy To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 Status : open Priority : 2 Assigned Engineer : dxm Submitter : dxm *Modified User : dxm *Modified User Domain : engr *Description : OK, so this one is repeatable now, and it looks like an interraction between the ramdisk driver and XFS. 2 way SMP 1400 with 1Gb memory, SCSI disk. t-o-t kernel, kio _not_ enabled. setup: mkfs -t xfs -f /dev/sdc5 ..... ========================== ADDITIONAL INFORMATION (ADD) From: dxm@engr (BugWorks) Date: Aug 23 2000 06:08:57PM ========================== Modid: 2.4.0-test1-xfs:slinx:72912a Date: Wed Aug 23 18:06:56 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs-bruce Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/drivers/block/rd.c - 1.22 - SMP deadlock fix from Neil Brown (to be submitted for inclusion in kernel) This fixes the problem, but I'll close this once it gets posted to the kernel list. From owner-linux-xfs@oss.sgi.com Wed Aug 23 18:16:27 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 18:16:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:41770 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 18:15:37 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA09654; Wed, 23 Aug 2000 18:07:30 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA04623; Wed, 23 Aug 2000 18:15:06 -0700 (PDT) Date: Wed, 23 Aug 2000 18:15:06 -0700 (PDT) Message-Id: <200008240115.SAA04623@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : observe Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : nathans *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 23 2000 06:15:05PM ========================== hi Ananth, have you been able to narrow it down to sim vs non-sim mkfs? (could you try sim/mkfs/mkfs_xfs for some dbench runs & see if the problem persists?) thanks. From owner-linux-xfs@oss.sgi.com Wed Aug 23 22:01:48 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 22:01:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:56664 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 22:01:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA00524 for ; Wed, 23 Aug 2000 21:52:21 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07897 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 24 Aug 2000 14:57:26 +1000 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id OAA96883 for ; Thu, 24 Aug 2000 14:57:23 +1000 (EST) Message-Id: <200008240457.OAA96883@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com Subject: XFS_IOC_RESVSP & XFS_IOC_UNRESVSP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Aug 2000 14:57:23 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Still banging my head against this one (pv 799616). Can anyone tell me how xfs_zero_remaining_bytes in xfs_vnodeops.c can assert that xfs_bmapi doesn't return a delayed allocation extent? ASSERT(imap.br_startblock != DELAYSTARTBLOCK); I've got a completely repeatable test case where this ASSERT fails because xfs_bmapi returns a delayed extent. Amusing this is, if you sleep for a tiny bit before doing the unreserve that trips the assert, the pagebuf page_cleaner_daemon comes along and converts it to a real extent and everything goes fine. The extent in question is written with dd, so there's no reason why it _shouldn't_ be delayed. But when the unreserve happens, there's the assertion that it isn't. Anyone got any ideas? There's an example fsstress invocation in the pv, or this: #!/bin/sh make iprobe _t() { echo "$*" | isms/slinx-xfs/cmd/xfs/stress/src/alloc \ -n -f /mnt/arch0/fish } mkfs -t xfs -f /dev/hda6 || exit 1 mount -t xfs /dev/hda6 /mnt/arch0 || exit 1 _t r 552894 105778 _t u 359577 318758 dd if=/dev/zero of=/mnt/arch0/fish bs=1 seek=592400 count=10466 # sleep 1 here and it'll work, otherwise the next line trips the ASSERT _t u 634008 225946 umount /dev/hda6 ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Aug 23 22:21:49 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 22:21:39 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36479 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 22:21:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA02585 for ; Wed, 23 Aug 2000 22:26:13 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from root@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA38551 for linux-xfs@oss.sgi.com; Thu, 24 Aug 2000 15:17:21 +1000 (EST) Date: Thu, 24 Aug 2000 15:17:21 +1000 (EST) From: dxm@snort.melbourne.sgi.com (Daniel Moore) Message-Id: <200008240517.PAA38551@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - uuid command for xfs_db Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing get/set/create uuid for a FS. gets/sets uuids in every AG. Doesn't handle uuid in external log. Modid: 2.4.0-test1-xfs:slinx:72921a Date: Wed Aug 23 22:16:12 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/Makefile - 1.51 - Add uuid cmd/xfs/db/command.c - 1.29 - add uuid cmd/xfs/db/uuid.c - 1.1 cmd/xfs/db/uuid.h - 1.1 - uuid command - get/set FS uuid From owner-linux-xfs@oss.sgi.com Wed Aug 23 22:48:08 2000 Received: by oss.sgi.com id ; Wed, 23 Aug 2000 22:47:58 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:53854 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 23 Aug 2000 22:47:20 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA03491; Wed, 23 Aug 2000 22:39:03 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA34061; Wed, 23 Aug 2000 22:44:55 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA76546; Wed, 23 Aug 2000 22:43:36 -0700 (PDT) Date: Wed, 23 Aug 2000 22:43:36 -0700 (PDT) Message-Id: <200008240543.WAA76546@info.engr.sgi.com> X-Pv-Incident: 799752 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 799752 - failed mount leaves entry in uuid table To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799752 *Status : closed Priority : 3 Assigned Engineer : dxm Submitter : dxm Opened Date : 08/22/00 *Closed Date : 08/23/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 08/23/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Aug 23 2000 10:43:36PM ========================== Modid: 2.4.0-test1-xfs:slinx:72923a Date: Wed Aug 23 22:43:08 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_log_recover.c - 1.185 - compare footer against original uuid not potentially new one linux/fs/xfs/xfs_mount.c - 1.233 - save original uuid for log footer check linux/fs/xfs/xfs_mount.h - 1.116 - add field for original uuid From owner-linux-xfs@oss.sgi.com Thu Aug 24 03:34:29 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 03:34:20 -0700 Received: from hermes.mixx.net ([212.84.196.2]:18187 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 24 Aug 2000 03:34:01 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 06D47F803 for ; Thu, 24 Aug 2000 12:33:17 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id B1E262CA6B; Thu, 24 Aug 2000 12:33:16 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: XFS sources lxr xrefed available Date: 24 Aug 2000 10:33:16 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967113196 8905 10.0.0.69 (24 Aug 2000 10:33:16 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > i have just set up an lxr indexed xfs source tree at > http://innominate.org/~graichen/projects/lxr/source/?v=xfs > which will be keeped up to date to the SGI cvs tree daily starting > in the next days and should make the navigation through the code > much easier for everyone interesed ... just as an info: just found a free minute and wrote the script - so that this lxr tree is now daily updated automatically to the current SGI XFS sources (was done by hand before on irregular basis) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Thu Aug 24 10:45:31 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 10:45:22 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25923 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 10:44:57 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01657; Thu, 24 Aug 2000 10:50:46 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA89505; Thu, 24 Aug 2000 10:43:57 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA31437; Thu, 24 Aug 2000 10:42:39 -0700 (PDT) Date: Thu, 24 Aug 2000 10:42:39 -0700 (PDT) Message-Id: <200008241742.KAA31437@info.engr.sgi.com> X-Pv-Incident: 799692 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 799692 - dbench problems relating to xfs-cmds To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799692 Status : observe Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : I don't know how exactly to descibe this problem, but dbench starts reporting errors under some circumstances. AFAIK, this is related to the xfs-cmds version used to mkfs/mount/repair (etc.) the file system. Using the same kernel, dbench would run fine when 1.0.2 version of the xfs-cmds is used, but reports errors when 1.0.4 version (as of today) of xfs-cmds is used. ananth. ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Aug 24 2000 10:42:39AM ========================== Right now my machine is not showing the problem ... so I want to do some more benchmark runs while the going is good. As mentioned already, the issue is to get a setup that will consistently fail. When I get the system in a failure-mode, I'll try sim/src ... Sorry that I'm not able to provide much data in resolving the problem. regards, ananth. From owner-linux-xfs@oss.sgi.com Thu Aug 24 10:58:31 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 10:58:11 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23663 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 10:57:39 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA06284; Thu, 24 Aug 2000 10:49:32 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA98385; Thu, 24 Aug 2000 10:56:38 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA74637; Thu, 24 Aug 2000 10:55:21 -0700 (PDT) Date: Thu, 24 Aug 2000 10:55:21 -0700 (PDT) Message-Id: <200008241755.KAA74637@info.engr.sgi.com> X-Pv-Incident: 800061 webPV: sgigate.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: BUG 800061 - HIGHMEM support is broken To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800061 Submitter : ananth Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : There are two problems in handling highmem with XFS: 1. consistent use of kmap/kunmap to get at the address of a page. 2. supporting highmem with kiobufs. I'll check-in a short fix that will check, issue warning, etc. if highmem is turned on. ananth. From owner-linux-xfs@oss.sgi.com Thu Aug 24 11:14:11 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 11:13:51 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44870 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 11:13:29 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02629; Thu, 24 Aug 2000 11:19:17 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA94334; Thu, 24 Aug 2000 11:12:58 -0700 (PDT) Date: Thu, 24 Aug 2000 11:12:58 -0700 (PDT) Message-Id: <200008241812.LAA94334@info.engr.sgi.com> X-Pv-Incident: 800061 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 800061 - HIGHMEM support is broken To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800061 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : chait *Modified User Domain : engr *Description : There are two problems in handling highmem with XFS: 1. consistent use of kmap/kunmap to get at the address of a page. 2. supporting highmem with kiobufs. I'll check-in a short fix that will check, issue warning, etc. if highmem is turned on. ..... ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Aug 24 2000 11:12:57AM ========================== FYI: With respect to kiobuf and highmem, the only available solution is to use bounce buffering. However, there are heated debates going on about where exactly this bouncing should be done: - I/O queuing layer - scsi/ide/lvm/... midlayers - device driver layers - pci-dma mapping layers I'm working on a quick'n'dirty fix which should work at the I/O queuing layer __for now__. This is to conform with the existing fix for highmem boucing done for buffer-head based I/Os. This quick'n'dirty fix is just a forward port of sct's original patch for kiobufs in the 2.2 series of kernels. -Chait. From owner-linux-xfs@oss.sgi.com Thu Aug 24 11:59:01 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 11:58:41 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22605 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 11:58:20 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09641; Thu, 24 Aug 2000 12:04:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA58946; Thu, 24 Aug 2000 11:57:48 -0700 (PDT) Date: Thu, 24 Aug 2000 11:57:48 -0700 (PDT) Message-Id: <200008241857.LAA58946@info.engr.sgi.com> X-Pv-Incident: 800074 webPV: sgigate.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: BUG 800074 - Non-page-sized block sizes don't work To: ananth@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800074 Submitter : ananth Submitter Domain : engr Assigned Engineer : ananth Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : Currently only page-sized blocks are supported. From owner-linux-xfs@oss.sgi.com Thu Aug 24 16:26:25 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 16:26:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3185 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 16:25:48 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA04037; Thu, 24 Aug 2000 16:31:26 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA57488; Thu, 24 Aug 2000 16:25:06 -0700 (PDT) Date: Thu, 24 Aug 2000 16:25:06 -0700 (PDT) Message-Id: <200008242325.QAA57488@info.engr.sgi.com> X-Pv-Incident: 799238 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 799238 - RAM disk driver breaks locking hierarchy To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238 *Status : closed Priority : 2 Assigned Engineer : dxm Submitter : dxm Opened Date : 08/15/00 *Closed Date : 08/24/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 08/24/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Aug 24 2000 04:25:05PM ========================== Subject: TAKE - Modid: 2.4.0-test1-xfs:slinx:73011a Date: Thu Aug 24 16:23:59 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/drivers/block/rd.c - 1.23 - "more correct" parameters to getblk pv 799238 This supplies "more correct" parameters to getblk. Neil is looking after submitting the patch to Linus. From owner-linux-xfs@oss.sgi.com Thu Aug 24 21:37:05 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 21:36:55 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:22677 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 21:36:26 -0700 Received: (from jones@localhost) by spica.cc.utexas.edu (8.9.1/8.9.1) id XAA08893; Thu, 24 Aug 2000 23:35:54 -0500 (CDT) Date: Thu, 24 Aug 2000 23:35:54 -0500 (CDT) Message-Id: <200008250435.XAA08893@spica.cc.utexas.edu> From: William L Jones To: linux-xfs@oss.sgi.com Subject: I think mkfs.xfs and the kernel code are not constant Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I created a file system with mkfs.xfs heres the output: meta-data=/dev/vg/xfs isize=256 agcount=8, agsize=5120 blks data = bsize=4096 blocks=40959, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs reports agcount of 8 with 5120 blks in an ag. df reports that that I have 159036 indoes. This implies that the ag size is 163776*256/8 bytes are 1280 4096 byte blocks per ag ,round up, which is not 5120 blks its 1/4 of this value. Which implies that mkfs.xfs is using 1024 byes per block when computing ag sizes in block. I dug a little deeper and printed sbp->sb_inopblog in xfs_mount.c using printk. It value of is 4 which would be correct if a block size was 1024, 1024/256 == 4. This is set by mkfs.xfs I filled up the file system and I know it filled up the ag's with 81855 inodes which is slitly less then the 81920 inodes that I would expect if an ag was 5120 4096 byte bocks in size. The kernel is is using 4096 for the size of a ag block which is not the 1024 that mkfs.xfs uses. The kernel and mkfs.xfs need to agree on the size of block. Bill Jones From owner-linux-xfs@oss.sgi.com Thu Aug 24 21:41:05 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 21:40:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46597 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 21:40:36 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA13117 for ; Thu, 24 Aug 2000 21:32:13 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA75202 for linux-xfs@oss.sgi.com; Fri, 25 Aug 2000 14:38:31 +1000 (EST) Date: Fri, 25 Aug 2000 14:38:31 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008250438.OAA75202@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73033a Date: Thu Aug 24 21:38:04 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/mkfs/xfs_mkfs.c - 1.172 - fix use-after-free issue found with libefence.a From owner-linux-xfs@oss.sgi.com Thu Aug 24 23:10:56 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 23:10:46 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24075 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Aug 2000 23:10:17 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA03328 for ; Thu, 24 Aug 2000 23:16:05 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA93857 for linux-xfs@oss.sgi.com; Fri, 25 Aug 2000 16:07:12 +1000 (EST) Date: Fri, 25 Aug 2000 16:07:12 +1000 (EST) From: nathans@snort.melbourne.sgi.com (Nathan Scott) Message-Id: <200008250607.QAA93857@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73034a Date: Thu Aug 24 23:06:49 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/src/Makefile - 1.12 - bring devzero.c into the fold. cmd/xfs/stress/src/devzero.c - 1.2 - add a bunch of useful options for testing. From owner-linux-xfs@oss.sgi.com Thu Aug 24 23:33:56 2000 Received: by oss.sgi.com id ; Thu, 24 Aug 2000 23:33:46 -0700 Received: from hermes.mixx.net ([212.84.196.2]:11528 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Thu, 24 Aug 2000 23:33:32 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8FEB4F803 for ; Fri, 25 Aug 2000 08:32:59 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 7514D2CA6B; Fri, 25 Aug 2000 08:32:59 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: maybe xfs problem Date: 25 Aug 2000 06:32:59 GMT Organization: innominate AG, Berlin, Germany Lines: 23 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967185179 23974 10.0.0.69 (25 Aug 2000 06:32:59 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i am not 100% shure that this is really an XFS problem but i will at least write it down here - maybe someone else sees something similar: i this morning had a problem at that small xfs testmachine i am using here - it is now running a used squid and an innd for two weeks (so two weeks old xfs code) - the squid did not react anymore and also the news server did not (both of them have their files on the same filesystem) - i did not find any- thing special in any logfile etc. ... restarting the squid fixed the problem (also innd was running then fine again) ... but as said - this does not really have to be xfs related in any way ... will update the xfs code tomorrow and will keep an eye on it ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 08:00:07 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 07:59:52 -0700 Received: from spica.cc.utexas.edu ([129.116.206.20]:60330 "EHLO spica.cc.utexas.edu") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 07:59:28 -0700 Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194]) by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id JAA14884; Fri, 25 Aug 2000 09:58:54 -0500 (CDT) Message-Id: <4.2.0.58.20000825095909.02269420@127.0.0.1> X-Sender: jones@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Aug 2000 10:00:48 -0500 To: William L Jones , linux-xfs@oss.sgi.com From: "William L. Jones" Subject: Re: I think mkfs.xfs and the kernel code are not constant <-- wrong In-Reply-To: <200008250435.XAA08893@spica.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Never mid. It was late and I was getting shift mixed up with counts. Sigh At 11:35 PM 8/24/00 -0500, William L Jones wrote: >I created a file system with mkfs.xfs heres the output: > >meta-data=/dev/vg/xfs isize=256 agcount=8, agsize=5120 blks >data = bsize=4096 blocks=40959, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 >naming =version 2 bsize=4096 >log =internal log bsize=4096 blocks=1200 >realtime =none extsz=65536 blocks=0, rtextents=0 > > >mkfs.xfs reports agcount of 8 with 5120 blks in an ag. >df reports that that I have 159036 indoes. This implies that >the ag size is 163776*256/8 bytes are 1280 4096 byte blocks per ag >,round up, which is not 5120 blks its 1/4 of this value. Which >implies that mkfs.xfs is using 1024 byes per block when computing >ag sizes in block. > >I dug a little deeper and printed sbp->sb_inopblog in xfs_mount.c >using printk. It value of is 4 which would be correct if a block >size was 1024, 1024/256 == 4. This is set by mkfs.xfs > > >I filled up the file system and I know it filled up the ag's with >81855 inodes which is slitly less then the 81920 inodes that I would >expect if an ag was 5120 4096 byte bocks in size. The kernel >is is using 4096 for the size of a ag block which is not the >1024 that mkfs.xfs uses. > >The kernel and mkfs.xfs need to agree on the size of block. > >Bill Jones > > > > > > From owner-linux-xfs@oss.sgi.com Fri Aug 25 09:03:48 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 09:03:38 -0700 Received: from hermes.mixx.net ([212.84.196.2]:41481 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 25 Aug 2000 09:03:14 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4F8F7F809 for ; Fri, 25 Aug 2000 18:02:32 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 19FDD2CA6B; Fri, 25 Aug 2000 18:02:32 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: smp and xfs / crash Date: 25 Aug 2000 16:02:32 GMT Organization: innominate AG, Berlin, Germany Lines: 211 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967219352 24688 10.0.0.69 (25 Aug 2000 16:02:32 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i have a small problem here now - just tried to set up another xfs test machine with all xfs filesystems - this time an smp one ... basic system is redhat 6.2 with the current sgi xfs cvs tree kernel on an dual pII 300 ... everything worked so far fine until i tried to boot from the xfs filesystem - it always crashes in the early stages with no real useful backtrace (no xfs stuff - but i can provide it anyway if there is interest) - after the crash and booting into an ext2 disk a xfs_repair gives me the output from the end of the mail - the thing is: after that xfs_repair i can successfully boot it - but after the next boot then it crashes again - so i assume it has to do with the umount code somehow some more facts: xfs_repair and mkfs.xfs are the old - sim-based ones, the system runs fine with the same kernel with ext2 root and i can mount the xfs filesystem from there fine too will try to compile an up kernel now and see what happens ... t p.s.: the xfs_repair output ... [root@qed /root]# xfs_repair /dev/hda3 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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 data fork in ino 2816323 claims free block 179711 - agno = 2 data fork in ino 4194437 claims free block 262165 - agno = 3 - agno = 4 - agno = 5 - agno = 6 imap claims a free inode 12949352 is in use, correcting imap and clearing inode - agno = 7 data fork in ino 14680196 claims free block 945617 data fork in ino 14680196 claims free block 945618 data fork in ino 14680196 claims free block 945619 data fork in ino 14680196 claims free block 945620 data fork in ino 14680196 claims free block 945621 data fork in ino 14680196 claims free block 945622 data fork in ino 14680196 claims free block 945623 data fork in ino 14680196 claims free block 945624 data fork in ino 14680196 claims free block 945625 data fork in ino 14680198 claims free block 945580 data fork in ino 14680198 claims free block 945581 data fork in ino 14680198 claims free block 945582 data fork in ino 14680198 claims free block 945583 data fork in ino 14680198 claims free block 945584 data fork in ino 14680198 claims free block 945585 data fork in ino 14680198 claims free block 945586 data fork in ino 14680198 claims free block 945587 data fork in ino 14680198 claims free block 945588 data fork in ino 14680198 claims free block 945589 data fork in ino 14680198 claims free block 945590 data fork in ino 14680198 claims free block 945591 data fork in ino 14680198 claims free block 945592 data fork in ino 14680198 claims free block 945593 data fork in ino 14680198 claims free block 945594 data fork in ino 14680198 claims free block 945595 data fork in ino 14680198 claims free block 945596 data fork in ino 14680198 claims free block 945597 data fork in ino 14680198 claims free block 945598 data fork in ino 14680198 claims free block 945599 data fork in ino 14680198 claims free block 945600 data fork in ino 14680198 claims free block 945601 data fork in ino 14680198 claims free block 945602 data fork in ino 14680198 claims free block 945603 data fork in ino 14680198 claims free block 945604 data fork in ino 14680198 claims free block 945605 data fork in ino 14680198 claims free block 945606 data fork in ino 14680198 claims free block 945607 data fork in ino 14680198 claims free block 945608 data fork in ino 14680198 claims free block 945609 correcting nblocks for inode 14680200, was 91 - counted 92 data fork in ino 14680205 claims free block 944377 data fork in ino 14680205 claims free block 944378 data fork in ino 14680205 claims free block 944379 data fork in ino 14680205 claims free block 944380 data fork in ino 14680205 claims free block 944381 data fork in ino 14680205 claims free block 944382 data fork in ino 14680205 claims free block 944383 data fork in ino 14680205 claims free block 944384 data fork in ino 14680205 claims free block 944385 data fork in ino 14680205 claims free block 944386 data fork in ino 14680205 claims free block 944387 data fork in ino 14680205 claims free block 944388 data fork in ino 14680205 claims free block 944389 - 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 - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 entry "network" at block 0 offset 48 in directory inode 2816323 references free inode 2816315 clearing inode number in entry at offset 48... entry "portmap" at block 0 offset 72 in directory inode 2816323 references free inode 2816317 clearing inode number in entry at offset 72... entry "nfslock" at block 0 offset 96 in directory inode 2816323 references free inode 2816319 clearing inode number in entry at offset 96... entry "ypbind" at block 0 offset 120 in directory inode 2816323 references free inode 2816321 clearing inode number in entry at offset 120... entry "autofs" at block 0 offset 144 in directory inode 2816323 references free inode 2816325 clearing inode number in entry at offset 144... entry "random" at block 0 offset 168 in directory inode 2816323 references free inode 2816327 clearing inode number in entry at offset 168... entry "netfs" at block 0 offset 192 in directory inode 2816323 references free inode 2816329 clearing inode number in entry at offset 192... entry "syslog" at block 0 offset 208 in directory inode 2816323 references free inode 2816333 clearing inode number in entry at offset 208... entry "identd" at block 0 offset 232 in directory inode 2816323 references free inode 2816335 clearing inode number in entry at offset 232... entry "atd" at block 0 offset 256 in directory inode 2816323 references free inode 2816337 clearing inode number in entry at offset 256... entry "crond" at block 0 offset 272 in directory inode 2816323 references free inode 2816339 clearing inode number in entry at offset 272... entry "inet" at block 0 offset 288 in directory inode 2816323 references free inode 2816341 clearing inode number in entry at offset 288... entry "sshd" at block 0 offset 304 in directory inode 2816323 references free inode 2816343 clearing inode number in entry at offset 304... entry "xntpd" at block 0 offset 320 in directory inode 2816323 references free inode 2816345 clearing inode number in entry at offset 320... entry "lpd" at block 0 offset 336 in directory inode 2816323 references free inode 2816347 clearing inode number in entry at offset 336... entry "nfs" at block 0 offset 352 in directory inode 2816323 references free inode 2816351 clearing inode number in entry at offset 352... entry "keytable" at block 0 offset 368 in directory inode 2816323 references free inode 2816594 clearing inode number in entry at offset 368... entry "postfix" at block 0 offset 392 in directory inode 2816323 references free inode 2816595 clearing inode number in entry at offset 392... entry "gpm" at block 0 offset 416 in directory inode 2816323 references free ino de 2901637 clearing inode number in entry at offset 416... entry "xfs" at block 0 offset 448 in directory inode 2816323 references free ino de 2901639 clearing inode number in entry at offset 448... - agno = 2 entry "ypbind.pid" at block 0 offset 112 in directory inode 4194437 references f ree inode 4194440 clearing inode number in entry at offset 112... entry "syslogd.pid" at block 0 offset 160 in directory inode 4194437 references free inode 4194721 clearing inode number in entry at offset 160... entry "klogd.pid" at block 0 offset 184 in directory inode 4194437 references fr ee inode 4194722 clearing inode number in entry at offset 184... entry "identd.pid" at block 0 offset 208 in directory inode 4194437 references f ree inode 4194723 clearing inode number in entry at offset 208... entry "atd.pid" at block 0 offset 232 in directory inode 4194437 references free inode 4194724 clearing inode number in entry at offset 232... entry "crond.pid" at block 0 offset 256 in directory inode 4194437 references fr ee inode 4194725 clearing inode number in entry at offset 256... entry "inetd.pid" at block 0 offset 280 in directory inode 4194437 references fr ee inode 4194726 clearing inode number in entry at offset 280... entry "sshd.pid" at block 0 offset 304 in directory inode 4194437 references fre e inode 4194727 clearing inode number in entry at offset 304... entry "gpm.pid" at block 0 offset 352 in directory inode 4194437 references free inode 4194728 clearing inode number in entry at offset 352... entry "httpd.pid" at block 0 offset 376 in directory inode 4194437 references fr ee inode 4194729 clearing inode number in entry at offset 376... entry "gdm.pid" at block 0 offset 400 in directory inode 4194437 references free inode 4194730 clearing inode number in entry at offset 400... - agno = 3 - agno = 4 - agno = 5 - agno = 6 entry "mtab" at block 0 offset 3536 in directory inode 12941653 references free inode 12949352 clearing inode number in entry at offset 3536... - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 rebuilding directory inode 12941653 rebuilding directory inode 4194437 rebuilding directory inode 2816323 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... resetting inode 2770866 nlinks from 1 to 2 done -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 09:09:38 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 09:09:28 -0700 Received: from hermes.mixx.net ([212.84.196.2]:58889 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 25 Aug 2000 09:09:16 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B512FF808 for ; Fri, 25 Aug 2000 18:08:44 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 789812CA6B; Fri, 25 Aug 2000 18:08:44 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: smp and xfs / crash Date: 25 Aug 2000 16:08:44 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967219724 24688 10.0.0.69 (25 Aug 2000 16:08:44 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > i have a small problem here now - just tried to set up another xfs > test machine with all xfs filesystems - this time an smp one ... > basic system is redhat 6.2 with the current sgi xfs cvs tree kernel > on an dual pII 300 ... everything worked so far fine until i tried > to boot from the xfs filesystem - it always crashes in the early > stages with no real useful backtrace (no xfs stuff - but i can just a small addition: early stages means: the kernel has fully booted and in the early stages of init - i think while remounting / rw - will look as soon as the machine has it's up kernel built and i can test it and reproduce the bug again with the smp kernel too ... t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 09:22:47 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 09:22:37 -0700 Received: from hermes.mixx.net ([212.84.196.2]:20746 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 25 Aug 2000 09:22:07 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 1878EF809 for ; Fri, 25 Aug 2000 18:21:22 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id EF2882CA6B; Fri, 25 Aug 2000 18:21:21 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: smp and xfs / crash Date: 25 Aug 2000 16:21:21 GMT Organization: innominate AG, Berlin, Germany Lines: 28 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967220481 7769 10.0.0.69 (25 Aug 2000 16:21:21 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > Thomas Graichen wrote: >> i have a small problem here now - just tried to set up another xfs >> test machine with all xfs filesystems - this time an smp one ... >> basic system is redhat 6.2 with the current sgi xfs cvs tree kernel >> on an dual pII 300 ... everything worked so far fine until i tried >> to boot from the xfs filesystem - it always crashes in the early >> stages with no real useful backtrace (no xfs stuff - but i can > just a small addition: early stages means: the kernel has fully > booted and in the early stages of init - i think while remounting > / rw - will look as soon as the machine has it's up kernel built > and i can test it and reproduce the bug again with the smp kernel > too ... ok - all back - looks like the mkfs was not old enough - it was one of those buggy non sim mkfs ... will remake the fs with the real old and working one now ... so don't care for this until i tested this (btw. it happend on up too - so i looked again better at the mkfs.xfs used ...) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 11:00:17 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 11:00:07 -0700 Received: from hermes.mixx.net ([212.84.196.2]:49164 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 25 Aug 2000 10:59:36 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 4CAF4F805 for ; Fri, 25 Aug 2000 19:59:04 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id D559F2CA6B; Fri, 25 Aug 2000 19:59:03 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: smp and xfs / crash Date: 25 Aug 2000 17:59:03 GMT Organization: innominate AG, Berlin, Germany Lines: 20 Distribution: local Message-ID: References: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967226343 19280 10.0.0.69 (25 Aug 2000 17:59:03 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: > ok - all back - looks like the mkfs was not old enough - it was > one of those buggy non sim mkfs ... will remake the fs with the > real old and working one now ... so don't care for this until > i tested this (btw. it happend on up too - so i looked again > better at the mkfs.xfs used ...) ok - it was the mkfs.xfs - re-mkfs'ed it and it now works fine ... sorry for the false alarm have a nice weekend t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 11:17:17 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 11:17:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:28170 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 11:16:42 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA14105 for ; Fri, 25 Aug 2000 11:08:34 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA5300797; Fri, 25 Aug 2000 13:14:54 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id NAA02056; Fri, 25 Aug 2000 13:14:53 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e7PI2xK01284; Fri, 25 Aug 2000 13:02:59 -0500 Message-ID: <39A69CB9.52A9A7FE@thebarn.com> Date: Fri, 25 Aug 2000 11:20:09 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: smp and xfs / crash References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: does the crash give something that looks like this? Remounting root filesystem in read-write mode [ OK ] Entering kdb (0xc6e2e000) on processor 1 Panic: Oops due to panic @ 0xc0131281 eax = 0xc1235c40 ebx = 0x00000007 ecx = 0xfffffc0e edx = 0xc1235ba0 esi = 0xfffffc0e edi = 0x080f8fcc esp = 0xc6e2ff88 eip = 0xc0131281 ebp = 0xc6e2ff94 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010206 ds = 0xc1230018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc6e2ff54 [1]kdb> bt EBP EIP Function(args) 0xc6e2ff94 0xc0131281 filp_close+0x9 (0xfffffc0e, 0xc1235ba0, 0xc6e2e000, 0x1) kernel .text 0xc0100000 0xc0131278 0xc0131330 0xc6e2ffac 0xc0131394 do_close+0x64 (0x7, 0x1) kernel .text 0xc0100000 0xc0131330 0xc01313bc 0xc6e2ffbc 0xc01313ca sys_close+0xe (0x7, 0xffffffff, 0x7, 0x1, 0x80f8fcc) kernel .text 0xc0100000 0xc01313bc 0xc01313d0 0xc010a870 system_call+0x34 kernel .text 0xc0100000 0xc010a83c 0xc010a874 > i have a small problem here now - just tried to set up another xfs > test machine with all xfs filesystems - this time an smp one ... > basic system is redhat 6.2 with the current sgi xfs cvs tree kernel > on an dual pII 300 ... everything worked so far fine until i tried > to boot from the xfs filesystem - it always crashes in the early > stages with no real useful backtrace (no xfs stuff - but i can > provide it anyway if there is interest) - after the crash and > booting into an ext2 disk a xfs_repair gives me the output from > the end of the mail - the thing is: after that xfs_repair i can > successfully boot it - but after the next boot then it crashes > again - so i assume it has to do with the umount code somehow > > some more facts: xfs_repair and mkfs.xfs are the old - sim-based > ones, the system runs fine with the same kernel with ext2 root > and i can mount the xfs filesystem from there fine too > > will try to compile an up kernel now and see what happens ... > > t > > p.s.: the xfs_repair output ... > > [root@qed /root]# xfs_repair /dev/hda3 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - 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 > data fork in ino 2816323 claims free block 179711 > - agno = 2 > data fork in ino 4194437 claims free block 262165 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > imap claims a free inode 12949352 is in use, correcting imap and clearing inode > - agno = 7 > data fork in ino 14680196 claims free block 945617 > data fork in ino 14680196 claims free block 945618 > data fork in ino 14680196 claims free block 945619 > data fork in ino 14680196 claims free block 945620 > data fork in ino 14680196 claims free block 945621 > data fork in ino 14680196 claims free block 945622 > data fork in ino 14680196 claims free block 945623 > data fork in ino 14680196 claims free block 945624 > data fork in ino 14680196 claims free block 945625 > data fork in ino 14680198 claims free block 945580 > data fork in ino 14680198 claims free block 945581 > data fork in ino 14680198 claims free block 945582 > data fork in ino 14680198 claims free block 945583 > data fork in ino 14680198 claims free block 945584 > data fork in ino 14680198 claims free block 945585 > data fork in ino 14680198 claims free block 945586 > data fork in ino 14680198 claims free block 945587 > data fork in ino 14680198 claims free block 945588 > data fork in ino 14680198 claims free block 945589 > data fork in ino 14680198 claims free block 945590 > data fork in ino 14680198 claims free block 945591 > data fork in ino 14680198 claims free block 945592 > data fork in ino 14680198 claims free block 945593 > data fork in ino 14680198 claims free block 945594 > data fork in ino 14680198 claims free block 945595 > data fork in ino 14680198 claims free block 945596 > data fork in ino 14680198 claims free block 945597 > data fork in ino 14680198 claims free block 945598 > data fork in ino 14680198 claims free block 945599 > data fork in ino 14680198 claims free block 945600 > data fork in ino 14680198 claims free block 945601 > data fork in ino 14680198 claims free block 945602 > data fork in ino 14680198 claims free block 945603 > data fork in ino 14680198 claims free block 945604 > data fork in ino 14680198 claims free block 945605 > data fork in ino 14680198 claims free block 945606 > data fork in ino 14680198 claims free block 945607 > data fork in ino 14680198 claims free block 945608 > data fork in ino 14680198 claims free block 945609 > correcting nblocks for inode 14680200, was 91 - counted 92 > data fork in ino 14680205 claims free block 944377 > data fork in ino 14680205 claims free block 944378 > data fork in ino 14680205 claims free block 944379 > data fork in ino 14680205 claims free block 944380 > data fork in ino 14680205 claims free block 944381 > data fork in ino 14680205 claims free block 944382 > data fork in ino 14680205 claims free block 944383 > data fork in ino 14680205 claims free block 944384 > data fork in ino 14680205 claims free block 944385 > data fork in ino 14680205 claims free block 944386 > data fork in ino 14680205 claims free block 944387 > data fork in ino 14680205 claims free block 944388 > data fork in ino 14680205 claims free block 944389 > - 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 > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > entry "network" at block 0 offset 48 in directory inode 2816323 references free inode 2816315 > clearing inode number in entry at offset 48... > entry "portmap" at block 0 offset 72 in directory inode 2816323 references free inode 2816317 > clearing inode number in entry at offset 72... > entry "nfslock" at block 0 offset 96 in directory inode 2816323 references free inode 2816319 > clearing inode number in entry at offset 96... > entry "ypbind" at block 0 offset 120 in directory inode 2816323 references free inode 2816321 > clearing inode number in entry at offset 120... > entry "autofs" at block 0 offset 144 in directory inode 2816323 references free inode 2816325 > clearing inode number in entry at offset 144... > entry "random" at block 0 offset 168 in directory inode 2816323 references free inode 2816327 > clearing inode number in entry at offset 168... > entry "netfs" at block 0 offset 192 in directory inode 2816323 references free inode 2816329 > clearing inode number in entry at offset 192... > entry "syslog" at block 0 offset 208 in directory inode 2816323 references free inode 2816333 > clearing inode number in entry at offset 208... > entry "identd" at block 0 offset 232 in directory inode 2816323 references free inode 2816335 > clearing inode number in entry at offset 232... > entry "atd" at block 0 offset 256 in directory inode 2816323 references free inode 2816337 > clearing inode number in entry at offset 256... > entry "crond" at block 0 offset 272 in directory inode 2816323 references free inode 2816339 > clearing inode number in entry at offset 272... > entry "inet" at block 0 offset 288 in directory inode 2816323 references free inode 2816341 > clearing inode number in entry at offset 288... > entry "sshd" at block 0 offset 304 in directory inode 2816323 references free inode 2816343 > clearing inode number in entry at offset 304... > entry "xntpd" at block 0 offset 320 in directory inode 2816323 references free inode 2816345 > clearing inode number in entry at offset 320... > entry "lpd" at block 0 offset 336 in directory inode 2816323 references free inode 2816347 > clearing inode number in entry at offset 336... > entry "nfs" at block 0 offset 352 in directory inode 2816323 references free inode 2816351 > clearing inode number in entry at offset 352... > entry "keytable" at block 0 offset 368 in directory inode 2816323 references free inode 2816594 > clearing inode number in entry at offset 368... > entry "postfix" at block 0 offset 392 in directory inode 2816323 references free inode 2816595 > clearing inode number in entry at offset 392... > entry "gpm" at block 0 offset 416 in directory inode 2816323 references free ino > de 2901637 > clearing inode number in entry at offset 416... > entry "xfs" at block 0 offset 448 in directory inode 2816323 references free ino > de 2901639 > clearing inode number in entry at offset 448... > - agno = 2 > entry "ypbind.pid" at block 0 offset 112 in directory inode 4194437 references f > ree inode 4194440 > clearing inode number in entry at offset 112... > entry "syslogd.pid" at block 0 offset 160 in directory inode 4194437 references > free inode 4194721 > clearing inode number in entry at offset 160... > entry "klogd.pid" at block 0 offset 184 in directory inode 4194437 references fr > ee inode 4194722 > clearing inode number in entry at offset 184... > entry "identd.pid" at block 0 offset 208 in directory inode 4194437 references f > ree inode 4194723 > clearing inode number in entry at offset 208... > entry "atd.pid" at block 0 offset 232 in directory inode 4194437 references free > inode 4194724 > clearing inode number in entry at offset 232... > entry "crond.pid" at block 0 offset 256 in directory inode 4194437 references fr > ee inode 4194725 > clearing inode number in entry at offset 256... > entry "inetd.pid" at block 0 offset 280 in directory inode 4194437 references fr > ee inode 4194726 > clearing inode number in entry at offset 280... > entry "sshd.pid" at block 0 offset 304 in directory inode 4194437 references fre > e inode 4194727 > clearing inode number in entry at offset 304... > entry "gpm.pid" at block 0 offset 352 in directory inode 4194437 references free > inode 4194728 > clearing inode number in entry at offset 352... > entry "httpd.pid" at block 0 offset 376 in directory inode 4194437 references fr > ee inode 4194729 > clearing inode number in entry at offset 376... > entry "gdm.pid" at block 0 offset 400 in directory inode 4194437 references free > inode 4194730 > clearing inode number in entry at offset 400... > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > entry "mtab" at block 0 offset 3536 in directory inode 12941653 references free > inode 12949352 > clearing inode number in entry at offset 3536... > - agno = 7 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > rebuilding directory inode 12941653 > rebuilding directory inode 4194437 > rebuilding directory inode 2816323 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > resetting inode 2770866 nlinks from 1 to 2 > done > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Fri Aug 25 12:40:38 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 12:40:17 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41035 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 12:39:50 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA04817 for ; Fri, 25 Aug 2000 12:45:39 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA94567 for ; Fri, 25 Aug 2000 14:38:03 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id OAA04178 for ; Fri, 25 Aug 2000 14:38:02 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7PJQ7T12096 for linux-xfs@oss.sgi.com; Fri, 25 Aug 2000 14:26:07 -0500 Date: Fri, 25 Aug 2000 14:26:07 -0500 From: Russell Cattelan Message-Id: <200008251926.e7PJQ7T12096@gibble.americas.sgi.com> Subject: TAKE - fixed sim build, some minor clean up. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Aug 25 12:37:15 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73067a cmd/xfs/sim/src/sim.random.c - 1.112 - Moved some #define's from xfs_linux to here. They were only used here. linux/fs/xfs/xfs_dir.c - 1.128 - changed irix5_off_t to xfs32_off_t more consistent linux/fs/xfs/xfs_mount.c - 1.236 - Fixed sim build linux/fs/xfs/xfs_dir2.c - 1.22 - changed irix5_off_t to xfs32_off_t more consistent linux/fs/xfs/pseudo-inc/mountinfo.h - 1.6 - changed irix5_off_t to xfs32_off_t more consistent moved define from xfs_linux.h linux/fs/xfs/pseudo-inc/sys/dirent.h - 1.4 - changed irix5_off_t to xfs32_off_t more consistent linux/fs/xfs/linux/xfs_linux.h - 1.27 - Removed un-used define's and typedefs. linux/fs/xfs/xfs_os_defs.h - 1.12 - Moved stuff from xfs_linux.h From owner-linux-xfs@oss.sgi.com Fri Aug 25 14:58:40 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 14:58:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48735 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 14:57:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00873 for ; Fri, 25 Aug 2000 15:03:44 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA48748 for ; Fri, 25 Aug 2000 16:56:08 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id QAA06892 for ; Fri, 25 Aug 2000 16:56:07 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7PLiCG12392 for linux-xfs@oss.sgi.com; Fri, 25 Aug 2000 16:44:12 -0500 Date: Fri, 25 Aug 2000 16:44:12 -0500 From: Russell Cattelan Message-Id: <200008252144.e7PLiCG12392@gibble.americas.sgi.com> Subject: TAKE - nfs permission fix. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This seems to fix the case where nfsd call's read inode directly, and the permissions come out wrong. Date: Fri Aug 25 14:53:10 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73084a linux/fs/xfs/linux/xfs_vnode.c - 1.40 - Make sure the linux inode is up to date when called directly from nfsd. From owner-linux-xfs@oss.sgi.com Fri Aug 25 17:20:02 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 17:19:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14436 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 17:19:29 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA27553; Fri, 25 Aug 2000 17:11:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA55733; Fri, 25 Aug 2000 17:18:58 -0700 (PDT) Date: Fri, 25 Aug 2000 17:18:58 -0700 (PDT) Message-Id: <200008260018.RAA55733@info.engr.sgi.com> X-Pv-Incident: 800273 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800273 - repair & db need to write external log footer To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800273 Submitter : nathans Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : xfs_repair (and now xfs_db with Daniel's recent change) need to be able to write the footer in an external log. I've just pushed write_log_footer into libxfs (was only used by mkfs previously), to facilitate this. repair does a device_zero on the log device in phase2, but doesn't do a log footer write. Daniel's new uuid command in db sets the new filesystem uuid everywhere except for in the (external) log. I'm not sure about the current procedural interface, however. We currently pass in the log file name and in mkfs there's a comment saying... /* Now that the device has been closed (which this function * depends on), mark the last block with the magic number and * uuid of this fs */ Seems to me we could do the log footer write before closing the log device a few lines earlier in mkfs (just seek+write+close, rather than the close+open+seek+write+close which we do currently - I think so anyway - maybe I'm missing some subtelty here though?). To do this, we could just pass in the libxfs/sim dev_t associated with the log device rather than the device name. In fact, it'd probably simplify things further (and make the code more consistent) to do a libxfs_getbuf, then a libxfs_writebuf to the log device (wraps up the buffer alloc, memset, seek & write). cheers. From owner-linux-xfs@oss.sgi.com Fri Aug 25 17:27:52 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 17:27:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16997 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 17:27:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA28072 for ; Fri, 25 Aug 2000 17:19:21 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA68634 for linux-xfs@oss.sgi.com; Sat, 26 Aug 2000 10:25:40 +1000 (EST) Date: Sat, 26 Aug 2000 10:25:40 +1000 (EST) From: Nathan Scott Message-Id: <200008260025.KAA68634@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73098a Date: Fri Aug 25 17:24:47 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/libxfs.h - 1.10 cmd/xfs/libxfs/rdwr.c - 1.10 - export write_log_footer routine. cmd/xfs/mkfs/xfs_mkfs.c - 1.173 - move write_log_footer routine into libxfs - others need it too. cmd/xfs/repair/phase2.c - 1.26 - tidy some code, add comment & TODO note in log zeroing code. From owner-linux-xfs@oss.sgi.com Sat Aug 26 08:06:38 2000 Received: by oss.sgi.com id ; Sat, 26 Aug 2000 08:06:29 -0700 Received: from hermes.mixx.net ([212.84.196.2]:47889 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sat, 26 Aug 2000 08:06:02 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id DBCACF82E for ; Sat, 26 Aug 2000 17:05:19 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 1C0922CA6B; Sat, 26 Aug 2000 17:05:19 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: smp and xfs / crash Date: 26 Aug 2000 15:05:19 GMT Organization: innominate AG, Berlin, Germany Lines: 32 Distribution: local Message-ID: References: <39A69CB9.52A9A7FE@thebarn.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967302319 21195 10.0.0.69 (26 Aug 2000 15:05:19 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > Thomas Graichen wrote: > does the crash give something that looks like this? > Remounting root filesystem in read-write mode [ OK ] > Entering kdb (0xc6e2e000) on processor 1 Panic: Oops > due to panic @ 0xc0131281 > eax = 0xc1235c40 ebx = 0x00000007 ecx = 0xfffffc0e edx = 0xc1235ba0 > esi = 0xfffffc0e edi = 0x080f8fcc esp = 0xc6e2ff88 eip = 0xc0131281 > ebp = 0xc6e2ff94 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010206 > ds = 0xc1230018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc6e2ff54 > [1]kdb> bt > EBP EIP Function(args) > 0xc6e2ff94 0xc0131281 filp_close+0x9 (0xfffffc0e, 0xc1235ba0, 0xc6e2e000, 0x1) > kernel .text 0xc0100000 0xc0131278 0xc0131330 > 0xc6e2ffac 0xc0131394 do_close+0x64 (0x7, 0x1) > kernel .text 0xc0100000 0xc0131330 0xc01313bc > 0xc6e2ffbc 0xc01313ca sys_close+0xe (0x7, 0xffffffff, 0x7, 0x1, 0x80f8fcc) > kernel .text 0xc0100000 0xc01313bc 0xc01313d0 > 0xc010a870 system_call+0x34 > kernel .text 0xc0100000 0xc010a83c 0xc010a874 ecactly - yes - this is what i got t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sat Aug 26 17:21:52 2000 Received: by oss.sgi.com id ; Sat, 26 Aug 2000 17:21:42 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27916 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 26 Aug 2000 17:21:21 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA06490; Sat, 26 Aug 2000 17:27:12 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA02955; Sat, 26 Aug 2000 17:20:50 -0700 (PDT) Date: Sat, 26 Aug 2000 17:20:50 -0700 (PDT) Message-Id: <200008270020.RAA02955@info.engr.sgi.com> X-Pv-Incident: 797419 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 797419 - xfs_iget goes recursive and dies a horrible death To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797419 Status : open Priority : 1 Assigned Engineer : lord Submitter : lord *Modified User : ananth *Modified User Domain : engr *Description : xfs_iget has some conditions where it can end up recalling itself, this is allowed for, but there are cases in there where two threads are looking up the same inode which it does not cope with, the end result is usually this: xfs_iget_core: ambiguous vns: vp/0xc3012b00, invp/0xc22c1800 Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c889c115 *pde = 00000000 ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Aug 26 2000 05:20:48PM ========================== It doesn't appear that the xfs_iget call has to be recursive for this bug to happen. On my 2P 64MB box with kiocluster option on mount, and running dbench 48 clients, I can get the system to panic fairly often. Here's one of the instances: ------------------- .Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c01b7ddb *pde = 00000000 Entering kdb (0xc2124000) on processor 1 Panic: Oops due to panic @ 0xc01b7ddb eax = 0x00000080 ebx = 0x00a08701 ecx = 0x00a08701 edx = 0x00000000 esi = 0xc206eac0 edi = 0xc2f505d0 esp = 0xc2125ce0 eip = 0xc01b7ddb ebp = 0x00000000 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010282 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc2125cac [1]kdb> bt EBP EIP Function(args) 0xc01b7ddb vn_revalidate+0x1f (0xc206eac0, 0x80) kernel .text 0xc0100000 0xc01b7dbc 0xc01b7e74 0xc018d8f0 xfs_iget_core+0x77c (0x0, 0xc38b6400, 0x0, 0xa08701, 0x0) kernel .text 0xc0100000 0xc018d174 0xc018d918 0xc018d94a xfs_iget+0x32 (0xc38b6400, 0x0, 0xa08701, 0x0, 0x0) kernel .text 0xc0100000 0xc018d918 0xc018d954 0xc01a40ac xfs_dir_lookup_int+0x154 (0x0, 0xc2262078, 0x5, 0xc09fefa0, 0xc2125ed0) kernel .text 0xc0100000 0xc01a3f58 0xc01a4240 0xc01a89d7 xfs_lookup+0x97 (0xc2262078, 0xc09fefa0, 0xc2125ecc, 0xc2125ed0, 0x0) kernel .text 0xc0100000 0xc01a8940 0xc01a8a40 0xc01b1540 linvfs_lookup+0x84 (0xc09c6040, 0xc09fef40) kernel .text 0xc0100000 0xc01b14bc 0xc01b1594 0xc013aad7 real_lookup+0x77 (0xc0dbc3e0, 0xc2125f30, 0x4) kernel .text 0xc0100000 0xc013aa60 0xc013ab80 0xc013af6b path_walk+0x27b (0xc087401e, 0xc2125f8c) kernel .text 0xc0100000 0xc013acf0 0xc013b590 0xc013bc6f open_namei+0xcb (0xc0874000, 0x243, 0x180, 0xc2125f8c) kernel .text 0xc0100000 0xc013bba4 0xc013c150 0xc012f1a7 filp_open+0x3b (0xc0874000, 0x242, 0x180) kernel .text 0xc0100000 0xc012f16c 0xc012f1c8 0xc012f4e2 sys_open+0x36 (0xbffffc74, 0x242, 0x180, 0x242, 0x804a085) kernel .text 0xc0100000 0xc012f4ac 0xc012f574 [1]more> 0xc0108f90 system_call+0x34 kernel .text 0xc0100000 0xc0108f5c 0xc0108f94 ------------------ ananth. From owner-linux-xfs@oss.sgi.com Sun Aug 27 02:08:25 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 02:08:15 -0700 Received: from hermes.mixx.net ([212.84.196.2]:52754 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 27 Aug 2000 02:07:45 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A69BDF844 for ; Sun, 27 Aug 2000 11:07:02 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 2B4842CA6B; Sun, 27 Aug 2000 11:07:02 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs & ppc & egcs Date: 27 Aug 2000 09:07:02 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967367222 24330 10.0.0.69 (27 Aug 2000 09:07:02 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing just installed an egcs on the ppc machine and rebuilt the xfs kernel with it (4 files did not compile due to assembler problems - maybe i need to downgrade the binutils too for which i don't have the diskspace right now - but lets hope those 4 files are not that important ... they are btw.: xfs_log.c, xfs_trans_buf.c, page_buf.c, page_buf_io.c - i recompiled those 4 files with gcc 2.95 then) the final result of this little experiment was: i get the same problems on the ppc as with gcc 2.95 - so it looks like the problems are more generic and not directly related to gcc vs. egcs ... will try to investigate all this again deeper in the next days (i think i will have a closer look at xfs_db and how it works - to see how exactly the on disk structure looks like - is this a good idea ?) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 02:50:25 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 02:50:15 -0700 Received: from hermes.mixx.net ([212.84.196.2]:21267 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 27 Aug 2000 02:49:46 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 3960DF847 for ; Sun, 27 Aug 2000 11:49:04 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id F00762CA6B; Sun, 27 Aug 2000 11:49:03 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: more xfs on ppc Date: 27 Aug 2000 09:49:03 GMT Organization: innominate AG, Berlin, Germany Lines: 47 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967369743 12276 10.0.0.69 (27 Aug 2000 09:49:03 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - just did the following on the linux/ppc machine: - dumped the diskimage from http://innominate.org/~graichen/projects/xfs/xfs.dd.gz which is a gzip'ed 32mb fresh xfs filesystem on an before zeroed blockdevice with one file on it: XFS containing "i am here" - did the following (all behind the % is comment): [root@aqua linux]# modprobe xfs [root@aqua linux]# mount -t xfs /dev/hda8 /mnt/floppy [root@aqua linux]# cd /mnt/floppy [root@aqua floppy]# ls XFS % looks fine so far [root@aqua floppy]# cat XFS i am here % dito [root@aqua floppy]# cp XFS test [root@aqua floppy]# ls XFS % does not show the new file [root@aqua floppy]# cat test i am here % but it is somehow there [root@aqua floppy]# cd [root@aqua /root]# umount /mnt/floppy [root@aqua /root]# - dumped that filesystem back into a file - which you may now get from http://innominate.org/~graichen/projects/xfs/xfs-ppc-bug.dd.gz maybe someone might have a short look at it - it should be simple enough so that someone who knows the xfs on disk structures might get an idea of what exactly goes wrong here (so that i know in which direction to look further) ... maybe a good warmup for a day :-) a lot of thanks in advance t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 07:15:07 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 07:14:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35353 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 07:14:30 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02756 for ; Sun, 27 Aug 2000 07:20:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA82717; Sun, 27 Aug 2000 09:12:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA48212; Sun, 27 Aug 2000 09:12:42 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA19490; Sun, 27 Aug 2000 09:08:04 -0500 Message-Id: <200008271408.JAA19490@jen.americas.sgi.com> To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-reply-to: Your message of "27 Aug 2000 09:49:03 GMT Date: Sun, 27 Aug 2000 09:08:03 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I will try and take a look at this tomorrow - I am currently on the other side of a very slow network link. However, I would suspect this problem is not an on disk issue in particular, but a getdents output problem. Since for the cat of test to work the directory entry must be there for it to work. You could use strace to look at the system call output from ls. try something like strace -o /tmp/strace.out -v ls You should see one or more getdents calls in the output, entries in the getdents output should look like this: {d_ino=43042, d_off=64, d_reclen=24, d_name=".bash_logout"} You should see . .. XFS and test as d_name values. Let us know what you see as before and after output for the getdents calls in ls. Steve > ok - just did the following on the linux/ppc machine: > > - dumped the diskimage from > > http://innominate.org/~graichen/projects/xfs/xfs.dd.gz > > which is a gzip'ed 32mb fresh xfs filesystem on an before zeroed > blockdevice with one file on it: XFS containing "i am here" > > - did the following (all behind the % is comment): > > [root@aqua linux]# modprobe xfs > [root@aqua linux]# mount -t xfs /dev/hda8 /mnt/floppy > [root@aqua linux]# cd /mnt/floppy > [root@aqua floppy]# ls > XFS % looks fine so far > [root@aqua floppy]# cat XFS > i am here % dito > [root@aqua floppy]# cp XFS test > [root@aqua floppy]# ls > XFS % does not show the new file > [root@aqua floppy]# cat test > i am here % but it is somehow there > [root@aqua floppy]# cd > [root@aqua /root]# umount /mnt/floppy > [root@aqua /root]# > > - dumped that filesystem back into a file - which you may now > get from > > http://innominate.org/~graichen/projects/xfs/xfs-ppc-bug.dd.gz > > maybe someone might have a short look at it - it should be simple > enough so that someone who knows the xfs on disk structures might > get an idea of what exactly goes wrong here (so that i know in > which direction to look further) ... maybe a good warmup for > a day :-) > > a lot of thanks in advance > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 07:21:27 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 07:21:17 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44057 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 07:20:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA09793 for ; Sun, 27 Aug 2000 07:26:36 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA84196; Sun, 27 Aug 2000 09:18:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA33641; Sun, 27 Aug 2000 09:18:54 -0500 (CDT) From: Steve Lord Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA19505; Sun, 27 Aug 2000 09:14:15 -0500 Message-Id: <200008271414.JAA19505@jen.americas.sgi.com> To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs & ppc & egcs In-reply-to: Your message of "27 Aug 2000 09:07:02 GMT Date: Sun, 27 Aug 2000 09:14:15 -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We do know that there are problems in the generated code for gcc 2.95 on ia32. We do not know if it is the compiler back end or front end which causes them, and hence will the problems propogate across architectures. We had isolated a specific problem (I cannot off the top of my head remember it - apart from being shift related). We could probably modify the XFS code which was affected by this problem, but finding all instances would not be easy. I will try and dig out the failure case and see if fixing that makes things better. Steve p.s. those files could not be more important, that is a fair percentage of the journalling code, and all of the buffering code in XFS! > just installed an egcs on the ppc machine and rebuilt the xfs kernel > with it (4 files did not compile due to assembler problems - maybe > i need to downgrade the binutils too for which i don't have the > diskspace right now - but lets hope those 4 files are not that > important ... they are btw.: xfs_log.c, xfs_trans_buf.c, page_buf.c, > page_buf_io.c - i recompiled those 4 files with gcc 2.95 then) > > the final result of this little experiment was: i get the same > problems on the ppc as with gcc 2.95 - so it looks like the problems > are more generic and not directly related to gcc vs. egcs ... will > try to investigate all this again deeper in the next days (i think > i will have a closer look at xfs_db and how it works - to see how > exactly the on disk structure looks like - is this a good idea ?) > > t > > -- > thomas.graichen@innominate.de > technical director innominate AG > clustering & security networking people > tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 15:39:09 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 15:38:59 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7203 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 15:38:38 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02028; Sun, 27 Aug 2000 15:44:20 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA23502; Sun, 27 Aug 2000 15:37:57 -0700 (PDT) Date: Sun, 27 Aug 2000 15:37:57 -0700 (PDT) Message-Id: <200008272237.PAA23502@info.engr.sgi.com> X-Pv-Incident: 800293 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800293 - repair can corrupt directories To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800293 Submitter : nathans Submitter Domain : engr Assigned Engineer : nathans Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : Test 031 reproduces this one - it runs mkfs and then repairs numerous different combinations of directory version and directory size ... repair seems to get itself into trouble without even mounting these filesystems (created using mkfs prototype files). To exercise this bug (use the sim mkfs/repair binaries, cos we seem to trip an assert in libxfs-mkfs before completing): $ cd cmd/xfs/sim $ make # make install then running "./check 031" produces output along the lines... QA output created by 031 === version 1, one entry [ snip, output looks fine ] === version 2, one entry (shortform) [ snip, output looks fine ] === version 1, twenty entries [ snip, output looks fine ] === version 2, twenty entries (block form) Repairing, iteration 1 Phase 1 - find and verify superblock... Phase 2 - using internal log Phase 3 - for each AG... Phase 4 - check for duplicate blocks... Phase 5 - rebuild AG headers and trees... Phase 6 - check inode connectivity... rebuilding directory inode 128 Phase 7 - verify and correct link counts... done [ this repeats for each repair iteration ] === version 1, thousand entries Repairing, iteration 1 Phase 1 - find and verify superblock... Phase 2 - using internal log Phase 3 - for each AG... Phase 4 - check for duplicate blocks... # of bmap records in inode 128 greater than max (4096, max - 254) bmap of block #0 of inode 128 failed fatal error -- couldn't map first leaf block of directory inode 128 [ this repeats for each repair iteration ] === version 2, thousand entries (leaf form) Repairing, iteration 1 Phase 1 - find and verify superblock... Phase 2 - using internal log Phase 3 - for each AG... Phase 4 - check for duplicate blocks... # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) Phase 5 - rebuild AG headers and trees... Phase 6 - check inode connectivity... Phase 7 - verify and correct link counts... done [ this repeats for each repair iteration ] From owner-linux-xfs@oss.sgi.com Sun Aug 27 15:42:09 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 15:41:59 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14666 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 15:41:47 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21985; Sun, 27 Aug 2000 15:33:29 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA54232; Sun, 27 Aug 2000 15:41:06 -0700 (PDT) Date: Sun, 27 Aug 2000 15:41:06 -0700 (PDT) Message-Id: <200008272241.PAA54232@info.engr.sgi.com> X-Pv-Incident: 800293 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 800293 - repair can corrupt directories To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800293 Status : open Priority : 2 Assigned Engineer : nathans Submitter : nathans *Modified User : nathans *Modified User Domain : engr *Description : Test 031 reproduces this one - it runs mkfs and then repairs numerous different combinations of directory version and directory size ... repair seems to get itself into trouble without even mounting these filesystems (created using mkfs prototype files). To exercise this bug (use the sim mkfs/repair binaries, cos we seem to trip an assert in libxfs-mkfs before completing): $ cd cmd/xfs/sim $ make ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 27 2000 03:41:05PM ========================== Oh, should've mentioned - its not clear yet whether its mkfs thats writing bad stuff to disk or whether its repair fixing stuff in a bad way. Either way, somethings broken (in both libsim & libxfs). cheers. From owner-linux-xfs@oss.sgi.com Sun Aug 27 15:57:39 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 15:57:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35619 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 15:56:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05561 for ; Sun, 27 Aug 2000 16:02:31 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA28437 for linux-xfs@oss.sgi.com; Mon, 28 Aug 2000 08:54:51 +1000 (EST) Date: Mon, 28 Aug 2000 08:54:51 +1000 (EST) From: Nathan Scott Message-Id: <200008272254.IAA28437@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - qa/stress tests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73133a Date: Sun Aug 27 15:53:09 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/Makefile - 1.2 - descend subdirs. cmd/xfs/stress/common.filter - 1.4 - add a filter for mkfs which produces filtered output on stdout, and useful values on stderr (suitable for use with eval). cmd/xfs/stress/common.rc - 1.19 - add optional scratch log/rt devices for external log testing. cmd/xfs/stress/group - 1.24 - add four new qa tests, rework notional assignments to be meaningful, add some new groups. cmd/xfs/stress/new - 1.3 - correct use of "status" in default script. cmd/xfs/stress/src/devzero.c - 1.3 - use 512 as basic block size, not 1024. cmd/xfs/stress/029 - 1.1 cmd/xfs/stress/029.out - 1.1 - exercise mkfs log (internal/external) zeroing cmd/xfs/stress/030 - 1.1 cmd/xfs/stress/030.out - 1.1 - mkfs protofile test (version 1) cmd/xfs/stress/031 - 1.1 cmd/xfs/stress/031.out - 1.1 - exercise xfs_repair - ensure repeated use doesn't corrupt cmd/xfs/stress/032 - 1.1 cmd/xfs/stress/032.out - 1.1 - cross check mkfs detection of other filesystem types. From owner-linux-xfs@oss.sgi.com Sun Aug 27 22:57:31 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 22:57:11 -0700 Received: from hermes.mixx.net ([212.84.196.2]:53512 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 27 Aug 2000 22:56:47 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id A238DF84A for ; Mon, 28 Aug 2000 07:56:14 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 007182CA6B; Mon, 28 Aug 2000 07:56:13 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: xfs & ppc & egcs Date: 28 Aug 2000 05:56:13 GMT Organization: innominate AG, Berlin, Germany Lines: 27 Distribution: local Message-ID: References: <200008271414.JAA19505@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967442173 24676 10.0.0.69 (28 Aug 2000 05:56:13 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > We do know that there are problems in the generated code for gcc 2.95 > on ia32. We do not know if it is the compiler back end or front end > which causes them, and hence will the problems propogate across > architectures. > We had isolated a specific problem (I cannot off the top of my head > remember it - apart from being shift related). We could probably modify the > XFS code which was affected by this problem, but finding all instances > would not be easy. I will try and dig out the failure case and see if > fixing that makes things better. > Steve > p.s. those files could not be more important, that is a fair percentage > of the journalling code, and all of the buffering code in XFS! ok ... why must real world always be that way? :-) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 23:01:00 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 23:00:50 -0700 Received: from hermes.mixx.net ([212.84.196.2]:64008 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Sun, 27 Aug 2000 23:00:33 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 5107AF84B for ; Mon, 28 Aug 2000 07:59:42 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 139B82CA6B; Mon, 28 Aug 2000 07:59:42 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 28 Aug 2000 05:59:42 GMT Organization: innominate AG, Berlin, Germany Lines: 38 Distribution: local Message-ID: References: <200008271408.JAA19490@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967442382 24676 10.0.0.69 (28 Aug 2000 05:59:42 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > I will try and take a look at this tomorrow - I am currently on > the other side of a very slow network link. However, I would suspect this > problem is not an on disk issue in particular, but a getdents output > problem. Since for the cat of test to work the directory entry > must be there for it to work. my idea was - that this problem will most probably also manifest itself on the disk too (if something goes wrong somewhere before it goes to disk it will most probably not go clean to the disk and the disk pattern may give an idea of what goes wrong) ... but maybe i am wrong here > You could use strace to look at the system call output from ls. try > something like > strace -o /tmp/strace.out -v ls > You should see one or more getdents calls in the output, entries in > the getdents output should look like this: > {d_ino=43042, d_off=64, d_reclen=24, d_name=".bash_logout"} > You should see . .. XFS and test as d_name values. > Let us know what you see as before and after output for the getdents > calls in ls. will do so tonight - thanks so far t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Sun Aug 27 23:54:11 2000 Received: by oss.sgi.com id ; Sun, 27 Aug 2000 23:54:01 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62515 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Aug 2000 23:53:29 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA07108; Sun, 27 Aug 2000 23:59:21 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA34489; Sun, 27 Aug 2000 23:52:58 -0700 (PDT) Date: Sun, 27 Aug 2000 23:52:58 -0700 (PDT) Message-Id: <200008280652.XAA34489@info.engr.sgi.com> X-Pv-Incident: 800297 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800297 - repair doesn't recover if primary sb is trashed To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800297 Submitter : nathans Submitter Domain : engr Assigned Engineer : nathans Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : In writing some verification tests for xfs_repair, I've found that a the corrupted primary superblock is not currently recoverable on Linux. e.g. sim/mkfs/mkfs_xfs /dev/foo stress/src/devzero -b 1 -n 1 /dev/foo sim/repair/xfs_repair /dev/foo Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .....................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... .....................................................................................................................................................................................................................................................................................................found candidate secondary superblock... unable to verify superblock, continuing... ....................................................................Sorry, could not find valid secondary superblock Exiting now. >From the brief analysis I've done I suspect there may be an endian issue remaining here ... I haven't traced it back to its source as yet though. From owner-linux-xfs@oss.sgi.com Mon Aug 28 08:54:31 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 08:54:21 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22346 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 08:54:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA27114 for ; Mon, 28 Aug 2000 08:45:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA70676 for ; Mon, 28 Aug 2000 10:52:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA60493 for ; Mon, 28 Aug 2000 10:52:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id KAA22324; Mon, 28 Aug 2000 10:47:30 -0500 Message-Id: <200008281547.KAA22324@jen.americas.sgi.com> Date: Mon, 28 Aug 2000 10:47:30 -0500 Subject: TAKE - improve xfs allocator performance on extending a file To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This leads to less fragmentation of a file. Date: Mon Aug 28 08:51:37 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73146a linux/fs/xfs/xfs_bmap.c - 1.259 - Merge irix fix for 797199 - this improves the XFS allocator behavior for extending an existing file, fragmentation is reduced. From owner-linux-xfs@oss.sgi.com Mon Aug 28 09:49:02 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 09:48:51 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23128 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 09:48:23 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04260 for ; Mon, 28 Aug 2000 09:40:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA80388; Mon, 28 Aug 2000 11:45:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA94538; Mon, 28 Aug 2000 11:45:10 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id LAA22679; Mon, 28 Aug 2000 11:40:20 -0500 Message-Id: <200008281640.LAA22679@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-Reply-To: Message from Thomas Graichen of "27 Aug 2000 09:49:03 GMT." Date: Mon, 28 Aug 2000 11:40:20 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I took a quick look at the filesystem image, and the second file (test) is there: xfs_db -f xfs-ppc-bug.dd xfs_db: inode 128 xfs_db: print core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 2 core.uid = 0 core.gid = 0 core.atime.sec = Sun Aug 27 07:42:08 2000 core.atime.nsec = 360000000 core.mtime.sec = Sun Aug 27 07:42:04 2000 core.mtime.nsec = 440000000 core.ctime.sec = Sun Aug 27 07:42:04 2000 core.ctime.nsec = 440000000 core.size = 27 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 0 next_unlinked = null u.sfdir2.hdr.count = 2 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 128 u.sfdir2.list[0].namelen = 3 u.sfdir2.list[0].offset = 0x30 u.sfdir2.list[0].name = "XFS" u.sfdir2.list[0].inumber.i4 = 131 u.sfdir2.list[1].namelen = 4 u.sfdir2.list[1].offset = 0x40 u.sfdir2.list[1].name = "test" u.sfdir2.list[1].inumber.i4 = 0 However, the inode number is bad it should be 132, the cat command must be using a dcache entry setup by the create call. Repair seems to confirm this: 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 entry "test" in shortform directory 128 references invalid inode 0 would have junked entry "test" in directory inode 128 - agno = 1 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 entry "test" in shortform directory 128 references invalid inode 0 would have junked entry "test" in directory inode 128 - agno = 1 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 ... disconnected inode 132, would move to lost+found Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. So somehow the wrong inode number got pushed down to the disk. I will do some more digging. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 11:27:02 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 11:26:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23161 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 11:26:31 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA18097; Mon, 28 Aug 2000 11:18:23 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA39296; Mon, 28 Aug 2000 11:25:30 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA41827; Mon, 28 Aug 2000 11:24:13 -0700 (PDT) Date: Mon, 28 Aug 2000 11:24:13 -0700 (PDT) Message-Id: <200008281824.LAA41827@info.engr.sgi.com> X-Pv-Incident: 799711 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 799711 - LINUX XFS reports wrong permissions. To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799711 *Status : closed Priority : 3 Assigned Engineer : nb Submitter : cattelan Opened Date : 08/22/00 *Closed Date : 08/28/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/28/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 28 2000 11:24:12AM ========================== Fixed 2.4.0-test1-xfs:slinx:73084a From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:01:02 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:00:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24584 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:00:27 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA23640 for ; Mon, 28 Aug 2000 11:52:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA99747; Mon, 28 Aug 2000 13:58:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA19488; Mon, 28 Aug 2000 13:58:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id NAA23993; Mon, 28 Aug 2000 13:53:33 -0500 Message-Id: <200008281853.NAA23993@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de, linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-Reply-To: Message from Steve Lord of "Mon, 28 Aug 2000 11:40:20 CDT." <200008281640.LAA22679@jen.americas.sgi.com> Date: Mon, 28 Aug 2000 13:53:33 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Here is some more xfs_db output, we are in agi 0 (inode allocation group 0) xfs_db: agi 0 xfs_db: print magicnum = 0x58414749 versionnum = 1 seqno = 0 length = 4222 count = 64 root = 3 level = 1 freecount = 59 newino = 128 dirino = null unlinked[0-63] = which tells us there are 59 free inodes left out of 64 if we go to the root block of the inode free space tree: xfs_db: addr root # follows the root field of the previous structure xfs_db: print magic = 0x49414254 level = 0 numrecs = 1 leftsib = null rightsib = null recs[1] = [startino,freecount,free] 1:[128,59,0xffffffffffffffe0] We see a bit map with 1s representing free inodes. If we compare this with the good image: xfs_db: agi 0 xfs_db: addr root xfs_db: print magic = 0x49414254 level = 0 numrecs = 1 leftsib = null rightsib = null recs[1] = [startino,freecount,free] 1:[128,60,0xfffffffffffffff0] We see that we have used one more inode in the block, and that the bitmap has been correctly adjusted to represent the inode being in use. The inode number is calculated based on this free space map, everything is telling us we should have used inode number 132, but we lost it somewhere between allocating the inode number and placing it in the directory, the trick is to find out where it goes missing. Can you repeat the same experiment, but use a three letter name for the second inode. One aspect of the directory format is that it is tightly packed, and in the test case the second inode number is getting stored starting on an odd byte boundary. This will at least tell me if this is the problem, or if we are losing it somewhere earlier. Here is a hex dump of a directory inode with two entries in it: 00: 494e41ed 01010002 00000000 00000000 00000002 00000000 00000000 00000000 20: 39aab75f 07439e80 39aaaccc 2f330200 39aaaccc 2f330200 00000000 0000001b 40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 00000061 60: ffffffff 02000000 00800300 30584653 00011d20 04004074 65737400 011d2305 1122 22333333 44444444 11222233 33333344 444444 The numbers represent the following: 1 - name length 2 - an offset field 3 - the name 4 - the inode number Notice that the inode numbers are immediately following the name field, so the second one starts on an odd boundary. This example is a little different from yours since the inode numbers are different. To get this information out of xfs_db I did this inode 128 # the root type data # tell it to format as raw hex print # print it >From the ppc disk image I got this: 00: 494e41ed 01010002 00000000 00000000 00000002 00000000 00000000 00000000 20: 39a90ca0 15752a00 39a90c9c 1a39de00 39a90c9c 1a39de00 00000000 0000001b 40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 00000000 60: ffffffff 02000000 00800300 30584653 00000083 04004074 65737400 00000000 ^^ ^^^^^^ inode num = 0 If a three letter name does not work then we are losing the inode number somewhere earlier and we will have to start instrumenting the code to find out where. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:02:52 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:02:42 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32009 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:02:25 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24165 for ; Mon, 28 Aug 2000 11:54:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA04005 for ; Mon, 28 Aug 2000 14:00:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA96325 for ; Mon, 28 Aug 2000 14:00:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA24173; Mon, 28 Aug 2000 13:55:47 -0500 Message-Id: <200008281855.NAA24173@jen.americas.sgi.com> Date: Mon, 28 Aug 2000 13:55:47 -0500 Subject: TAKE - allow xfs_repair and logprint to work on regular files To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Aug 28 12:00:14 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73190a cmd/xfs/libxfs/init.c - 1.7 - Make findsize work with regular files as well as block devices. From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:25:32 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:25:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59920 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:24:51 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA27173 for ; Mon, 28 Aug 2000 12:16:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA02936; Mon, 28 Aug 2000 14:22:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA26359; Mon, 28 Aug 2000 14:22:58 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24273; Mon, 28 Aug 2000 14:18:08 -0500 Message-Id: <200008281918.OAA24273@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: xfs_iget... In-Reply-To: Message from Daniel Moore of "Mon, 21 Aug 2000 11:57:26 +1000." <200008210157.LAA64653@clouds.melbourne.sgi.com> Date: Mon, 28 Aug 2000 14:18:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Re: the xfs_iget bug, could the people who've seen it please > post some more info. I'd like to post this bug and need some more > details on the symptons etc. > > I'm seeing "bad inode magic/vsn daddr" messages from xfs_itobp > and I'm wondering if these are connected. > > Steve, do you think this is connected to pv 797419? > > Ta > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- I suspect what you are seeing is due to running fsstress - it exercises the bulkstat interface asking for random inode numbers - which in all probability do not exist. It calculates a disk location based on the inode number and reads the block into memory - it fails these checks if it is not a real inode block and you get the error message. Irix exhibits exactly the same behavior with fsstress, this one is not a bug it is a feature of the test program. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:28:32 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:28:13 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38161 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:27:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA27513 for ; Mon, 28 Aug 2000 12:19:35 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA05312; Mon, 28 Aug 2000 14:25:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA23323; Mon, 28 Aug 2000 14:25:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24286; Mon, 28 Aug 2000 14:21:04 -0500 Message-Id: <200008281921.OAA24286@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings In-Reply-To: Message from "Andi Kleen" of "Mon, 21 Aug 2000 17:23:41 +0200." <20000821172341.A31808@gruyere.muc.suse.de> Date: Mon, 28 Aug 2000 14:21:04 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > In ext2 and most other file systems it is enough to hold the inode semaphore to pin > blocks returned by bmap (because truncate and unlink are the only functions t hat > could steal blocks from under you). This seems to be mostly true for XFS too because it is > enforced in the VFS above XFS, but it has some loopholes with the space manag ement > ioctls and the fsr (swapext). The following patch plugs them by grabbing the > respective linux inode semaphores. Did I forget any case where bmap could be invalidated? You are correct, except for the fact that xfs is doing its own locking under the covers internally. These should be protecting XFS from stamping on itself. Steve > > -Andi > > --- ./fs/xfs/linux/xfs_ioctl.c-o Wed Aug 9 02:18:40 2000 > +++ ./fs/xfs/linux/xfs_ioctl.c Sun Aug 20 20:55:00 2000 > @@ -751,7 +751,8 @@ > xfs_flock64_t bf; > xfs_inode_t *ip; > xfs_mount_t *mp; > - > + int need_isem; > + > vp = LINVFS_GET_VP(inode); > > ASSERT(vp); > @@ -769,15 +770,24 @@ > return (EIO); > > > + /* > + * Linux code relies on i_sem protecing bmap mappings, so grab it > + * for all operations that may shrink the file or free space. > + * XXX: is this correct for inode mapped files? > + */ > + need_isem = 0; > switch (cmd) { > - case XFS_IOC_ALLOCSP: > case XFS_IOC_FREESP: > + case XFS_IOC_FREESP64: > + need_isem = 1; > + /*FALL THROUGH*/ > + > + case XFS_IOC_ALLOCSP: > > case XFS_IOC_RESVSP: > case XFS_IOC_UNRESVSP: > > case XFS_IOC_ALLOCSP64: > - case XFS_IOC_FREESP64: > > case XFS_IOC_RESVSP64: > case XFS_IOC_UNRESVSP64: { > @@ -798,13 +808,15 @@ > > /* if (filp->f_flags & FINVIS) XXXjtk - need O_INVISIBLE? */ > attr_flags |= ATTR_DMI; > - > + > + if (need_isem) > + down(&inode->i_sem); > error = xfs_change_file_space(bdp, cmd, &bf, filp->f_pos, > - &cred, attr_flags); > - if (error) > - return -error; > + &cred, attr_flags); > + if (need_isem) > + up(&inode->i_sem); > > - return 0; > + return -error; > } > > case XFS_IOC_DIOINFO: > --- ./fs/xfs/xfs_dfrag.c-o Wed Aug 9 02:18:50 2000 > +++ ./fs/xfs/xfs_dfrag.c Sun Aug 20 19:57:16 2000 > @@ -293,6 +293,9 @@ > xfs_trans_cancel(tp, 0); > return error; > } > + > + double_down(fp->f_dentry->d_inode, tfp->f_dentry->d_inode); > + > xfs_lock_inodes(ips, 2, 0, XFS_ILOCK_EXCL); > > /* > @@ -304,6 +307,8 @@ > if (error) { > xfs_iunlock(ip, lock_flags); > xfs_iunlock(tip, lock_flags); > + up(&fp->f_dentry->d_inode); > + up(&tfp->f_dentry->d_inode); > xfs_trans_cancel(tp, 0); > return error; > } > @@ -396,6 +401,9 @@ > error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT, NULL); > > CELL_ONLY(cfs_end_defrag(vp, cxfs_val)); > + > + up(fp->f_dentry->d_inode); > + up(tfp->f_dentry->d_inode); > > fput(fp); > fput(tfp); From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:35:12 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:35:02 -0700 Received: from hermes.mixx.net ([212.84.196.2]:4368 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 28 Aug 2000 12:34:40 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 3F520F808 for ; Mon, 28 Aug 2000 21:34:07 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id AF6602CA6D; Mon, 28 Aug 2000 21:34:06 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 28 Aug 2000 19:34:06 GMT Organization: innominate AG, Berlin, Germany Lines: 33 Distribution: local Message-ID: References: <200008281853.NAA23993@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967491246 19654 10.0.0.69 (28 Aug 2000 19:34:06 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Here is some more xfs_db output, we are in agi 0 (inode allocation group 0) > xfs_db: agi 0 > xfs_db: print > magicnum = 0x58414749 ... > Can you repeat the same experiment, but use a three letter name > for the second inode. ... you may find it at http://innominate.org/~graichen/projects/xfs/xfs-ppc-bug-3.dd.gz also there are the files xfs-i386-ok.dd.gz and xfs-i386-ok-3.dd.gz which is the same done on i386 - maybe useful for an easy a/b comparision ... ok - now i'll have a closer look at your xfs_db and other things so that i hopefully start learning a bit more about all this myself now ... a lot of thanks for your patience - i hope to help with all this in a growing own productivity over time ... but this will take quite some time (and this is short somehow :-) t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:36:22 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:36:13 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33811 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:35:53 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA28469 for ; Mon, 28 Aug 2000 12:27:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA07338; Mon, 28 Aug 2000 14:34:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA30150; Mon, 28 Aug 2000 14:34:05 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24310; Mon, 28 Aug 2000 14:29:14 -0500 Message-Id: <200008281929.OAA24310@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jens Axboe cc: linux-xfs@oss.sgi.com Subject: Re: stuck in sv_wait In-Reply-To: Message from Jens Axboe of "Tue, 22 Aug 2000 20:44:10 +0200." <20000822204410.L2336@suse.de> Date: Mon, 28 Aug 2000 14:29:14 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hi, > > Doing any kind of work on an xfs mounted partition, results in processes > stuck in sv_wait... This occurs on both IDE and SCSI, with and without > kio (cluster or plain) enabled. > > Although rm or cp will be uninterruptibly stuck in sv_wait, they do come > to life ocassionally and perform some I/O. But most of the time is spent > sleeping, without any I/O getting done. Here's a backtrace of rm: > OK, so this one was tracked down to the issues XFS has with the gcc 2.95 compiler (really must deal with that sometime). However, a thread stuck at this point and not moving will generally be because we are waiting for log space. This is a legitimate place to block, but not for long. If there is a long term sleep in the xlog_grant_log_space then something has usually gone wrong in another thread and we are failing to flush old metadata which would free logspace for reuse. Using the xfsidbg module from kdb we can find a few things out: Feeding the first parameter of xlog_grant_log_space into the xlog command gives us the log structure: [1]kdb> xlog 0xc231f3e0 xlog at 0xc231f3e0 &flushsm: 0xc231f3e0 tic_cnt: 101 tic_tcnt: 102 freelist: 0xc3ddfc58 tail: 0xc3ddfc08 ICLOG: 0xc52f0000 &icloglock: 0xc231f414 tail_lsn: 0x4e00003d98 last_sync_lsn: 0x4e00004018 mp: 0xc42dc800 xbuf: 0xc6ef6280 roundoff: 376 l_covered_state: need flags: log 0x0 <> dev: 0x804 logBBstart: 4771360 logsize: 65536000 logBBsize: 128000 curr_cycle: 78 prev_cycle: 78 curr_block: 16455 prev_block: 16408 iclog_bak: 0xc231f464 iclog_size: 0x8000 (32768) num iclogs: 4 &grant_lock: 0xc231f474 resHeadQ: 0x00000000 wrHeadQ: 0x00000000 GResCycle: 78 GResBytes: 8424584 GWrCycle: 78 GWrBytes: 8424584 GResBlocks: 16455 GResRemain: 0 GWrBlocks: 16455 GWrRemain: 0 Taking the mp field from this structure we can look at the active item list - which is the dirty metadata in memory which has been written out into the log (writing this would free logspace) [1]kdb> xail 0xc42dc800 AIL for mp 0xc42dc800, oldest first [0] type inode flags: 0x1 lsn [4e:3d98] inode 0xc68fca9c logged 1 flags: 0x0 <> format: 0x5 lastfield: 0x5 [1] type inode flags: 0x1 lsn [4e:3d98] inode 0xc68fc684 logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x5 [2] type inode flags: 0x1 lsn [4e:3d98] inode 0xc3edd28c logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x3 [3] type inode flags: 0x1 lsn [4e:3ed8] inode 0xc4cc20a0 logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x3 [4] type inode flags: 0x1 lsn [4e:4018] inode 0xc68fc478 logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x1 [5] type inode flags: 0x1 lsn [4e:4018] inode 0xc68fc890 logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x5 [6] type inode flags: 0x1 lsn [4e:4018] inode 0xc3ffed28 logged 1 flags: 0x0 <> format: 0x0 <> lastfield: 0x1 [7] type inode flags: 0x1 lsn [4e:4018] inode 0xc68fcca8 logged 1 flags: 0x0 <> format: 0x3 lastfield: 0x3 So if this had been a hang, one possibility would be that a thead was blocked holding a lock on one of these inodes. This concludes XFS debugging 101. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:37:42 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:37:32 -0700 Received: from hermes.mixx.net ([212.84.196.2]:10256 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 28 Aug 2000 12:37:12 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 83DF9F808 for ; Mon, 28 Aug 2000 21:36:40 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 3F7BF2CA6D; Mon, 28 Aug 2000 21:36:40 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 28 Aug 2000 19:36:40 GMT Organization: innominate AG, Berlin, Germany Lines: 19 Distribution: local Message-ID: References: <200008281640.LAA22679@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967491400 19654 10.0.0.69 (28 Aug 2000 19:36:40 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > I took a quick look at the filesystem image, and the second file (test) is > there: > xfs_db -f xfs-ppc-bug.dd ^^^^^^^^^^^^^^^^^ this looks cool (working directly on the image) - was it possible before or is this the last commit you did some hours ago? t p.s.: btw. what are you using for your version control (TAKE etc.)? -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:42:52 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:42:42 -0700 Received: from hermes.mixx.net ([212.84.196.2]:16144 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 28 Aug 2000 12:42:21 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B3635F80E for ; Mon, 28 Aug 2000 21:41:37 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 50C652CA6E; Mon, 28 Aug 2000 21:41:37 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 28 Aug 2000 19:41:37 GMT Organization: innominate AG, Berlin, Germany Lines: 30 Distribution: local Message-ID: References: <200008271408.JAA19490@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967491697 19654 10.0.0.69 (28 Aug 2000 19:41:37 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > I will try and take a look at this tomorrow - I am currently on > the other side of a very slow network link. However, I would suspect this > problem is not an on disk issue in particular, but a getdents output > problem. Since for the cat of test to work the directory entry > must be there for it to work. > You could use strace to look at the system call output from ls. try > something like > strace -o /tmp/strace.out -v ls if that is still interesting at all [root@aqua floppy]# strace -v ls execve("/bin/ls", ["ls"], [/* 27 vars */]) = 0 XFS [root@aqua floppy]# ... looks like strace is not that much of a help on the ppc :-( t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:44:23 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:44:12 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:2582 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:43:58 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA29574 for ; Mon, 28 Aug 2000 12:35:50 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA08556; Mon, 28 Aug 2000 14:42:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA99123; Mon, 28 Aug 2000 14:42:10 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24345; Mon, 28 Aug 2000 14:37:19 -0500 Message-Id: <200008281937.OAA24345@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-Reply-To: Message from Thomas Graichen of "28 Aug 2000 19:36:40 GMT." Date: Mon, 28 Aug 2000 14:37:19 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > I took a quick look at the filesystem image, and the second file (test) is > > there: > > > xfs_db -f xfs-ppc-bug.dd > ^^^^^^^^^^^^^^^^^ > this looks cool (working directly on the image) - was it possible > before or is this the last commit you did some hours ago? I think this one worked before the mod to libxfs/init.c, but xfs_repair and xfs_logprint did not work. > > t > > p.s.: btw. what are you using for your version control (TAKE etc.)? The source code control is SGI's own internal beast known as ptools - it is actually a layer on top of rcs, but it is tied into a bug tracking system, and also groups together changes to a group of files into a 'mod' this lets you go back and see a change as a whole rather than as a group of changes to individual files. Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:49:43 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:49:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:6423 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:49:12 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00133 for ; Mon, 28 Aug 2000 12:41:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA11185; Mon, 28 Aug 2000 14:47:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA16031; Mon, 28 Aug 2000 14:47:21 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24380; Mon, 28 Aug 2000 14:42:30 -0500 Message-Id: <200008281942.OAA24380@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: XFS_IOC_RESVSP & XFS_IOC_UNRESVSP In-Reply-To: Message from Daniel Moore of "Thu, 24 Aug 2000 14:57:23 +1000." <200008240457.OAA96883@clouds.melbourne.sgi.com> Date: Mon, 28 Aug 2000 14:42:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Still banging my head against this one (pv 799616). > > Can anyone tell me how xfs_zero_remaining_bytes in xfs_vnodeops.c > can assert that xfs_bmapi doesn't return a delayed allocation > extent? > > ASSERT(imap.br_startblock != DELAYSTARTBLOCK); > > I've got a completely repeatable test case where this ASSERT > fails because xfs_bmapi returns a delayed extent. In theory it should be real data at this point, xfs_free_file_space calls xfs_inval_cached_pages before it calls xfs_zero_remaining_bytes, this will end up in pagebuf_flushinval which should convert all extents in the range specified to real disk space..... Maybe we are not doing this correctly. Steve > > Amusing this is, if you sleep for a tiny bit before doing the > unreserve that trips the assert, the pagebuf page_cleaner_daemon > comes along and converts it to a real extent and everything goes > fine. > > The extent in question is written with dd, so there's no reason > why it _shouldn't_ be delayed. But when the unreserve happens, > there's the assertion that it isn't. > > Anyone got any ideas? > > > There's an example fsstress invocation in the pv, or this: > > #!/bin/sh > > make iprobe > > _t() > { > echo "$*" | isms/slinx-xfs/cmd/xfs/stress/src/alloc \ > -n -f /mnt/arch0/fish > } > > mkfs -t xfs -f /dev/hda6 || exit 1 > mount -t xfs /dev/hda6 /mnt/arch0 || exit 1 > > _t r 552894 105778 > _t u 359577 318758 > dd if=/dev/zero of=/mnt/arch0/fish bs=1 seek=592400 count=10466 > # sleep 1 here and it'll work, otherwise the next line trips the ASSERT > _t u 634008 225946 > > umount /dev/hda6 > > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Aug 28 12:54:53 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 12:54:42 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:28184 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 12:54:18 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00817 for ; Mon, 28 Aug 2000 12:46:10 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA12516; Mon, 28 Aug 2000 14:52:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id OAA00478; Mon, 28 Aug 2000 14:52:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id OAA24425; Mon, 28 Aug 2000 14:47:39 -0500 Message-Id: <200008281947.OAA24425@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-Reply-To: Message from Thomas Graichen of "28 Aug 2000 19:34:06 GMT." Date: Mon, 28 Aug 2000 14:47:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing OK, this still has zeros, time to start instrumenting code - I have a meeting in a few minutes, so it will be a while (tomorrow maybe) before I get something back to you. Here is the directory part of the inode: u.sfdir2.hdr.count = 2 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 128 u.sfdir2.list[0].namelen = 3 u.sfdir2.list[0].offset = 0x30 u.sfdir2.list[0].name = "XFS" u.sfdir2.list[0].inumber.i4 = 131 u.sfdir2.list[1].namelen = 3 u.sfdir2.list[1].offset = 0x40 u.sfdir2.list[1].name = "abc" u.sfdir2.list[1].inumber.i4 = 0 Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 13:30:02 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 13:29:52 -0700 Received: from Cantor.suse.de ([194.112.123.193]:48656 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 28 Aug 2000 13:29:26 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id C32001E2F2; Mon, 28 Aug 2000 22:28:53 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 3AA1610A026; Mon, 28 Aug 2000 22:28:53 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 01B9C2F300; Mon, 28 Aug 2000 22:28:51 +0200 (MEST) Date: Mon, 28 Aug 2000 22:28:50 +0200 From: "Andi Kleen" To: Steve Lord Cc: "Andi Kleen" , linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings Message-ID: <20000828222850.A12769@gruyere.muc.suse.de> References: <200008281921.OAA24286@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008281921.OAA24286@jen.americas.sgi.com>; from lord@sgi.com on Mon, Aug 28, 2000 at 02:21:04PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Aug 28, 2000 at 02:21:04PM -0500, Steve Lord wrote: > > > > In ext2 and most other file systems it is enough to hold the inode semaphore > to pin > > blocks returned by bmap (because truncate and unlink are the only functions t > hat > > could steal blocks from under you). This seems to be mostly true for XFS too > because it is > > enforced in the VFS above XFS, but it has some loopholes with the space manag > ement > > ioctls and the fsr (swapext). The following patch plugs them by grabbing the > > respective linux inode semaphores. Did I forget any case where bmap could be > invalidated? > > > You are correct, except for the fact that xfs is doing its own locking under > the covers internally. These should be protecting XFS from stamping on itself. Sorry, I should have been more clear. The locking is required for external users, e.g. the loop device (the current version doesn't do it, but it will be fixed to do so). loop device cannot access any internal XFS locks. -Andi From owner-linux-xfs@oss.sgi.com Mon Aug 28 13:38:52 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 13:38:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1142 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 13:38:26 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA09864 for ; Mon, 28 Aug 2000 13:44:19 -0700 (PDT) mail_from (cattelan@cray.com) Received: from ironwood-e185.americas.sgi.com (ironwood.americas.sgi.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA19905 for ; Mon, 28 Aug 2000 15:36:39 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id PAA18078 for ; Mon, 28 Aug 2000 15:36:39 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.10.1/8.10.1) id e7SKOfw19018 for linux-xfs@oss.sgi.com; Mon, 28 Aug 2000 15:24:41 -0500 Date: Mon, 28 Aug 2000 15:24:41 -0500 From: Russell Cattelan Message-Id: <200008282024.e7SKOfw19018@gibble.americas.sgi.com> Subject: TAKE - Fix root fs remount! this time for sure ;-) To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Aug 28 13:34:04 PDT 2000 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73197a linux/fs/xfs/linux/xfs_random.c - 1.44 - Remove kmem_malloc... simple wrapper for kmem_alloc, was only in one spot linux/fs/xfs/linux/xfs_super.c - 1.86 - Fix flags to PVFS_SYNC on read only remount. Need to "WAIT" for everything to synced out. From owner-linux-xfs@oss.sgi.com Mon Aug 28 14:30:53 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 14:30:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63611 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 14:30:12 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA01724 for ; Mon, 28 Aug 2000 14:36:04 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA26680; Mon, 28 Aug 2000 16:28:24 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id QAA50738; Mon, 28 Aug 2000 16:28:24 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id QAA24574; Mon, 28 Aug 2000 16:23:32 -0500 Message-Id: <200008282123.QAA24574@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings In-Reply-To: Message from "Andi Kleen" of "Mon, 28 Aug 2000 22:28:50 +0200." <20000828222850.A12769@gruyere.muc.suse.de> Date: Mon, 28 Aug 2000 16:23:32 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Sorry, I should have been more clear. The locking is required for external > users, e.g. the loop device (the current version doesn't do it, but it will > be fixed to do so). loop device cannot access any internal XFS locks. > > > -Andi OK, that's a different kettle of fish.... Steve From owner-linux-xfs@oss.sgi.com Mon Aug 28 14:37:13 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 14:37:03 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44668 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 14:36:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03515 for ; Mon, 28 Aug 2000 14:42:27 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA77864 for linux-xfs@oss.sgi.com; Tue, 29 Aug 2000 08:33:29 +1100 (EST) Date: Tue, 29 Aug 2000 08:33:29 +1100 (EST) From: Nathan Scott Message-Id: <200008282133.IAA77864@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - doc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Aug 28, 6:15pm, Timothy Shimmin wrote: > Subject: SCRATCH_LOGDEV > You might like to add SCRATCH_LOGDEV & SCRATCH_RTDEV to the README. > --Tim ok, done - thanks Tim. Modid: 2.4.0-test1-xfs:slinx:73201a Date: Mon Aug 28 14:32:11 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/README - 1.4 - document optional SCRATCH devices and their use. From owner-linux-xfs@oss.sgi.com Mon Aug 28 15:29:43 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 15:29:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:15167 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 15:29:11 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA20730 for ; Mon, 28 Aug 2000 15:20:52 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA79333; Tue, 29 Aug 2000 09:27:12 +1100 (EST) Date: Tue, 29 Aug 2000 09:27:12 +1100 (EST) From: Nathan Scott Message-Id: <200008282227.JAA79333@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, markgw@sgi.com Subject: TAKE - xfsstats Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Aug 29, 9:12am, Mark Goodwin wrote: > Subject: icy running pp1.4, with xfs cmds installed > ... > Regarding the xfs cmds stuff, I'm not running the experimental kernel > and thought the following was not as friendly as it could have been: > > icy 46% /usr/sbin/xfsstats > /proc/fs/xfs/stat: No such file or directory at /usr/sbin/xfsstats line 15. > thanks, Mark - I've added a more useful diagnostic here now. cheers. Modid: 2.4.0-test1-xfs:slinx:73206a Date: Mon Aug 28 15:25:12 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/misc/xfsstats - 1.2 - print a more meaningful message if the XFS stats file isn't available. From owner-linux-xfs@oss.sgi.com Mon Aug 28 15:30:13 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 15:29:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19519 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 15:29:14 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA20765; Mon, 28 Aug 2000 15:21:06 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA61155; Mon, 28 Aug 2000 15:28:43 -0700 (PDT) Date: Mon, 28 Aug 2000 15:28:43 -0700 (PDT) Message-Id: <200008282228.PAA61155@info.engr.sgi.com> X-Pv-Incident: 800297 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 800297 - repair doesn't recover if primary sb is trashed To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800297 Status : open Priority : 3 Assigned Engineer : nathans Submitter : nathans *Modified User : nathans *Modified User Domain : engr *Description : In writing some verification tests for xfs_repair, I've found that a the corrupted primary superblock is not currently recoverable on Linux. e.g. sim/mkfs/mkfs_xfs /dev/foo stress/src/devzero -b 1 -n 1 /dev/foo sim/repair/xfs_repair /dev/foo Phase 1 - find and verify superblock... ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 28 2000 03:28:42PM ========================== Looks like mkfs is writing out secondary superblocks without endian converting (or perhaps endian converting twice by mistake? - not 100% sure yet - its not immediately obvious). this after a fresh mkfs - ag 0 & ag 1... $ sudo od -c -N 20 /dev/hda6 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \v ´ w 0000020 \0 \0 \0 \0 0000024 $ sudo od -c -j 307200000 -N 20 /dev/hda6 2223700000 B S F X \0 020 \0 \0 w ´ \v \0 \0 \0 \0 \0 2223700020 \0 \0 \0 \0 2223700024 From owner-linux-xfs@oss.sgi.com Mon Aug 28 15:38:13 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 15:38:03 -0700 Received: from Cantor.suse.de ([194.112.123.193]:29193 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 28 Aug 2000 15:37:44 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 6D1D61E316; Tue, 29 Aug 2000 00:37:02 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 3008010A026; Tue, 29 Aug 2000 00:37:02 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 02D242F300; Tue, 29 Aug 2000 00:37:00 +0200 (MEST) Date: Tue, 29 Aug 2000 00:36:59 +0200 From: "Andi Kleen" To: Steve Lord Cc: "Andi Kleen" , linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings Message-ID: <20000829003659.A16062@gruyere.muc.suse.de> References: <200008282123.QAA24574@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008282123.QAA24574@jen.americas.sgi.com>; from lord@sgi.com on Mon, Aug 28, 2000 at 04:23:32PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Aug 28, 2000 at 04:23:32PM -0500, Steve Lord wrote: > > > > > Sorry, I should have been more clear. The locking is required for external > > users, e.g. the loop device (the current version doesn't do it, but it will > > be fixed to do so). loop device cannot access any internal XFS locks. > > > > > > -Andi > > OK, that's a different kettle of fish.... It would be nice if you could commit (or whatever ptools calls that) it. Thanks, -Andi From owner-linux-xfs@oss.sgi.com Mon Aug 28 16:18:44 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 16:18:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56073 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 16:17:57 -0700 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01397 for ; Mon, 28 Aug 2000 16:23:40 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id QAA27684 for linux-xfs@oss.sgi.com; Mon, 28 Aug 2000 16:16:06 -0700 Date: Mon, 28 Aug 2000 16:16:06 -0700 From: Ananth Ananthanarayanan Message-Id: <200008282316.QAA27684@waco.engr.sgi.com> Subject: TAKE - write performance improvement To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing With this change streaming writes perform almost at the speed of streaming read, as measured with lmdd and bonnie even when 1K & 2K chunks are used for write. Date: Mon Aug 28 16:12:45 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/slinx-xfs-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73209a linux/fs/pagebuf/page_buf_io.c - 1.24 - Fix a long-standing problem where write performance was sub-standard when < 4K chunk-sizes were used. From owner-linux-xfs@oss.sgi.com Mon Aug 28 17:15:13 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 17:15:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:30807 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 17:14:31 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA02137; Mon, 28 Aug 2000 17:06:24 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA24517; Mon, 28 Aug 2000 17:14:00 -0700 (PDT) Date: Mon, 28 Aug 2000 17:14:00 -0700 (PDT) Message-Id: <200008290014.RAA24517@info.engr.sgi.com> X-Pv-Incident: 800297 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: ADD 800297 - repair doesn't recover if primary sb is trashed To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800297 Status : open Priority : 3 Assigned Engineer : nathans Submitter : nathans *Modified User : nathans *Modified User Domain : engr *Description : In writing some verification tests for xfs_repair, I've found that a the corrupted primary superblock is not currently recoverable on Linux. e.g. sim/mkfs/mkfs_xfs /dev/foo stress/src/devzero -b 1 -n 1 /dev/foo sim/repair/xfs_repair /dev/foo Phase 1 - find and verify superblock... ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 28 2000 05:14:00PM ========================== OK, I'm close to having this sorted out, just need some input from the gurus... The situation at the moment is: - libsim mkfs writes bad secondary superblocks - libxfs mkfs writes good secondary superblocks (as to why? - i don't know - I can only guess that the bflush at the end of the old mkfs has the buffers marked as dirty but not endian converted and flushes them out thus overwriting the good stuff ... seems very odd though). - repair does have an endian issue here after all... with a fix, I get a nicely recovered fs with xfs_repair output like this... (in gdb...) run /dev/hda8 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...found candidate secondary superblock... verified secondary superblock... writing modified primary superblock Breakpoint 1, write_primary_sb (sbp=0x40209080, size=512) at sb.c:481 481 if (no_modify) (gdb) p *sbp $1 = {sb_magicnum = 1481003842, sb_blocksize = 4096, sb_dblocks = 38146, sb_rblocks = 0, sb_rextents = 0, sb_uuid = { __u_bits = "x]o·´\205AÄ\231âK]ùòÀw"}, sb_logstart = 32772, sb_rootino = 18446744073709551615, sb_rbmino = 18446744073709551615, sb_rsumino = 18446744073709551615, sb_rextsize = 16, sb_agblocks = 4769, sb_agcount = 8, sb_rbmblocks = 0, sb_logblocks = 1200, sb_versionnum = 8324, sb_sectsize = 512, sb_inodesize = 256, sb_inopblock = 16, sb_fname = "\000\000\000\000\000", sb_fpack = "\000\000\000\000\000", sb_blocklog = 12 '\f', sb_sectlog = 9 '\t', sb_inodelog = 8 '\b', sb_inopblog = 4 '\004', sb_agblklog = 13 '\r', sb_rextslog = 0 '\000', sb_inprogress = 0 '\000', sb_imax_pct = 25 '\031', sb_icount = 0, sb_ifree = 0, sb_fdblocks = 36914, sb_frextents = 0, sb_uquotino = 0, sb_pquotino = 0, sb_qflags = 0, sb_flags = 0 '\000', sb_shared_vn = 0 '\000', sb_inoalignmt = 2, sb_unit = 0, sb_width = 0, sb_dirblklog = 0 '\000', sb_dummy = "\000\000\000\000\000\000"} (gdb) c Continuing. sb root inode value 18446744073709551615 inconsistent with calculated value 137438953600 resetting superblock root inode pointer to 137438953600 sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 137438953601 resetting superblock realtime bitmap ino pointer to 137438953601 sb realtime summary inode 18446744073709551615 inconsistent with calculated value 137438953602 resetting superblock realtime summary ino pointer to 137438953602 Phase 2 - using internal log - zero log... - 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) ... - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Note - stripe unit (0) and width (0) fields have been reset. Please set with mount -o sunit=,swidth= done So, my question is - I know there's code in mkfs to go through and sprinkle the known-good root inode into some AGs (looks like we use the last AG and one in the middle - below the comment "write out multiple copies of superblocks with the rootinode field set" in mkfs). At this point we know what the root inode (+rt inodes) are, and we have all the AGs setup, so why do we not write these inode numbers in _all_ of the AG superblocks rather than just a couple? (would it be worthwhile changing mkfs to do this?) Looks like repair doesn't find the good one at the moment, or doesn't keep looking for long enough (I suspect its picked the SB in AG 1), so we get those "resetting" messages at the end of phase1. many thanks. From owner-linux-xfs@oss.sgi.com Mon Aug 28 17:54:24 2000 Received: by oss.sgi.com id ; Mon, 28 Aug 2000 17:54:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45586 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 28 Aug 2000 17:53:43 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09427; Mon, 28 Aug 2000 17:59:34 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA43954; Mon, 28 Aug 2000 17:52:40 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA50337; Mon, 28 Aug 2000 17:50:04 -0700 (PDT) Date: Mon, 28 Aug 2000 17:50:04 -0700 (PDT) Message-Id: <200008290050.RAA50337@feature.engr.sgi.com> X-Pv-Incident: 800297 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: TAKE 800297 - repair doesn't recover if primary sb is trashed To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : nathans *Status : closed Assigned Engineer : nathans *Fixed By : nathans *Fixed By Domain : engr *Closed Date : 08/28/00 Priority : 3 *Modified Date : 08/28/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (TAKE) Date: Aug 28 2000 05:50:03PM [pvnews version: 1.71] ---------------------------- Modid: 2.4.0-test1-xfs:slinx:73216a Date: Mon Aug 28 17:41:05 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/repair/sb.c - 1.33 - fix endian issue when searching for secondary superblocks. cmd/xfs/stress/src/devzero.c - 1.4 - correct handling of single block writes, tidy final summary printf. Description : In writing some verification tests for xfs_repair, I've found that a the corrupted primary superblock is not currently recoverable on Linux. e.g. sim/mkfs/mkfs_xfs /dev/foo stress/src/devzero -b 1 -n 1 /dev/foo sim/repair/xfs_repair /dev/foo Phase 1 - find and verify superblock... ..... ========================== ADDITIONAL INFORMATION (ADD) From: nathans@engr (BugWorks) Date: Aug 28 2000 05:14:00PM ========================== OK, I'm close to having this sorted out, just need some input from the gurus... The situation at the moment is: - libsim mkfs writes bad secondary superblocks - libxfs mkfs writes good secondary superblocks (as to why? - i don't know - I can only guess that the bflush at the end of the old mkfs has the buffers marked as dirty but not endian converted and flushes them out thus overwriting the good stuff ... seems very odd though). - repair does have an endian issue here after all... with a fix, I get a nicely recovered fs with xfs_repair output like this... (in gdb...) run /dev/hda8 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...found candidate secondary superblock... verified secondary superblock... writing modified primary superblock Breakpoint 1, write_primary_sb (sbp=0x40209080, size=512) at sb.c:481 481 if (no_modify) (gdb) p *sbp $1 = {sb_magicnum = 1481003842, sb_blocksize = 4096, sb_dblocks = 38146, sb_rblocks = 0, sb_rextents = 0, sb_uuid = { __u_bits = "x]o·´\205AÄ\231âK]ùòÀw"}, sb_logstart = 32772, sb_rootino = 18446744073709551615, sb_rbmino = 18446744073709551615, sb_rsumino = 18446744073709551615, sb_rextsize = 16, sb_agblocks = 4769, sb_agcount = 8, sb_rbmblocks = 0, sb_logblocks = 1200, sb_versionnum = 8324, sb_sectsize = 512, sb_inodesize = 256, sb_inopblock = 16, sb_fname = "\000\000\000\000\000", sb_fpack = "\000\000\000\000\000", sb_blocklog = 12 '\f', sb_sectlog = 9 '\t', sb_inodelog = 8 '\b', sb_inopblog = 4 '\004', sb_agblklog = 13 '\r', sb_rextslog = 0 '\000', sb_inprogress = 0 '\000', sb_imax_pct = 25 '\031', sb_icount = 0, sb_ifree = 0, sb_fdblocks = 36914, sb_frextents = 0, sb_uquotino = 0, sb_pquotino = 0, sb_qflags = 0, sb_flags = 0 '\000', sb_shared_vn = 0 '\000', sb_inoalignmt = 2, sb_unit = 0, sb_width = 0, sb_dirblklog = 0 '\000', sb_dummy = "\000\000\000\000\000\000"} (gdb) c Continuing. sb root inode value 18446744073709551615 inconsistent with calculated value 137438953600 resetting superblock root inode pointer to 137438953600 sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 137438953601 resetting superblock realtime bitmap ino pointer to 137438953601 sb realtime summary inode 18446744073709551615 inconsistent with calculated value 137438953602 resetting superblock realtime summary ino pointer to 137438953602 Phase 2 - using internal log - zero log... - 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) ... - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Note - stripe unit (0) and width (0) fields have been reset. Please set with mount -o sunit=,swidth= done So, my question is - I know there's code in mkfs to go through and sprinkle the known-good root inode into some AGs (looks like we use the last AG and one in the middle - below the comment "write out multiple copies of superblocks with the rootinode field set" in mkfs). At this point we know what the root inode (+rt inodes) are, and we have all the AGs setup, so why do we not write these inode numbers in _all_ of the AG superblocks rather than just a couple? (would it be worthwhile changing mkfs to do this?) Looks like repair doesn't find the good one at the moment, or doesn't keep looking for long enough (I suspect its picked the SB in AG 1), so we get those "resetting" messages at the end of phase1. many thanks. From owner-linux-xfs@oss.sgi.com Tue Aug 29 07:04:12 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 07:04:02 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:63317 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 07:03:35 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA02473 for ; Tue, 29 Aug 2000 06:55:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA01509 for ; Tue, 29 Aug 2000 09:01:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA42039 for ; Tue, 29 Aug 2000 09:01:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id IAA29332; Tue, 29 Aug 2000 08:56:50 -0500 Message-Id: <200008291356.IAA29332@jen.americas.sgi.com> Date: Tue, 29 Aug 2000 08:56:50 -0500 Subject: TAKE - backing out previous change to page_buf_io.c To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Backing out mod 2.4.0-test1-xfs:slinx:73209a, it causes data corruption. Date: Tue Aug 29 07:00:29 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-clean Undoes mod: 2.4.0-test1-xfs:slinx:73209a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73228a linux/fs/pagebuf/page_buf_io.c - 1.25 From owner-linux-xfs@oss.sgi.com Tue Aug 29 07:04:22 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 07:04:12 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59989 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 07:03:43 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA02425 for ; Tue, 29 Aug 2000 06:55:25 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA04646; Tue, 29 Aug 2000 09:01:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA82641; Tue, 29 Aug 2000 09:01:43 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id IAA29324; Tue, 29 Aug 2000 08:56:44 -0500 Message-Id: <200008291356.IAA29324@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ananth Ananthanarayanan cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement In-Reply-To: Message from Ananth Ananthanarayanan of "Mon, 28 Aug 2000 16:16:06 PDT." <200008282316.QAA27684@waco.engr.sgi.com> Date: Tue, 29 Aug 2000 08:56:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I am backing out this change, it breaks doio, and probably anything else which fills holes in files. I think we had a similar test condition in this code path before, and it was removed to fix corruption. There has got to be another variant of this which we can use. Steve > With this change streaming writes perform almost > at the speed of streaming read, as measured > with lmdd and bonnie even when 1K & 2K chunks > are used for write. > > Date: Mon Aug 28 16:12:45 PDT 2000 > Workarea: waco.engr.sgi.com:/build1/ananth/slinx-xfs-new > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs > > > Modid: 2.4.0-test1-xfs:slinx:73209a > linux/fs/pagebuf/page_buf_io.c - 1.24 > - Fix a long-standing problem where write performance > was sub-standard when < 4K chunk-sizes were used. > From owner-linux-xfs@oss.sgi.com Tue Aug 29 07:21:42 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 07:21:32 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22624 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 07:20:59 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA07837 for ; Tue, 29 Aug 2000 07:12:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA07860; Tue, 29 Aug 2000 09:19:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA91338; Tue, 29 Aug 2000 09:19:01 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA31227; Tue, 29 Aug 2000 09:14:03 -0500 Message-Id: <200008291414.JAA31227@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Steve Lord cc: Ananth Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement In-Reply-To: Message from Steve Lord of "Tue, 29 Aug 2000 08:56:44 CDT." <200008291356.IAA29324@jen.americas.sgi.com> Date: Tue, 29 Aug 2000 09:14:02 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > I am backing out this change, it breaks doio, and probably anything else > which fills holes in files. I think we had a similar test condition in > this code path before, and it was removed to fix corruption. There has > got to be another variant of this which we can use. > > Steve > OK, now I am puzzled, I still got corruption after I backed out the mod, I removed the old doio output file and the corruption went away on subsequent runs and I have not been able to reproduce it with or without the mod again. I will run some more tests and probably be putting the mod back in again shortly. Sorry for the confusion. Steve From owner-linux-xfs@oss.sgi.com Tue Aug 29 07:48:43 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 07:48:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:106 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 07:48:05 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13451 for ; Tue, 29 Aug 2000 07:39:57 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA14365; Tue, 29 Aug 2000 09:46:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA83896; Tue, 29 Aug 2000 09:46:17 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA31979; Tue, 29 Aug 2000 09:41:18 -0500 Message-Id: <200008291441.JAA31979@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andi Kleen" cc: linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings In-Reply-To: Message from "Andi Kleen" of "Tue, 29 Aug 2000 00:36:59 +0200." <20000829003659.A16062@gruyere.muc.suse.de> Date: Tue, 29 Aug 2000 09:41:18 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Mon, Aug 28, 2000 at 04:23:32PM -0500, Steve Lord wrote: > > > > > > > > Sorry, I should have been more clear. The locking is required for externa l > > > users, e.g. the loop device (the current version doesn't do it, but it wi ll > > > be fixed to do so). loop device cannot access any internal XFS locks. > > > > > > > > > -Andi > > > > OK, that's a different kettle of fish.... > > It would be nice if you could commit (or whatever ptools calls that) it. > > Thanks, > > -Andi Actually, things are somewhat more broken that this, XFS does not provide prepare_write or commit_write address space operations, so I presume this means under loopback we would be at best a readonly device. At worst totally non-functional. Steve From owner-linux-xfs@oss.sgi.com Tue Aug 29 08:16:33 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 08:16:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14910 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 08:15:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05905 for ; Tue, 29 Aug 2000 08:21:38 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA18462; Tue, 29 Aug 2000 10:13:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id KAA15972; Tue, 29 Aug 2000 10:13:57 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id KAA32284; Tue, 29 Aug 2000 10:08:58 -0500 Message-Id: <200008291508.KAA32284@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc Date: Tue, 29 Aug 2000 10:08:57 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing OK, here is a patch which might start to narrow down where the inode number is getting lost. I seem to remember there being issues with printing 64 bit numbers on the ppc, so you may have to mess with this somewhat to get it to function there. Steve =========================================================================== Index: linux/fs/xfs/xfs_dir2.c =========================================================================== --- /usr/tmp/TmpDir.32182-0/linux/fs/xfs/xfs_dir2.c_1.22 Tue Aug 29 10:11:31 2000 +++ linux/fs/xfs/xfs_dir2.c Tue Aug 29 10:06:05 2000 @@ -274,6 +274,7 @@ int rval; /* return value */ int v; /* type-checking value */ + printk("xfs_dir2_createname: inum = %Ld\n", inum); ASSERT((dp->i_d.di_mode & IFMT) == IFDIR); if (rval = xfs_dir_ino_validate(tp->t_mountp, inum)) { #pragma mips_frequency_hint NEVER =========================================================================== Index: linux/fs/xfs/xfs_ialloc.c =========================================================================== --- /usr/tmp/TmpDir.32182-0/linux/fs/xfs/xfs_ialloc.c_1.139 Tue Aug 29 10:11:31 2000 +++ linux/fs/xfs/xfs_ialloc.c Tue Aug 29 10:05:44 2000 @@ -935,6 +935,9 @@ ASSERT((XFS_AGINO_TO_OFFSET(mp, INT_GET(rec.ir_startino, ARCH_CONVERT)) % XFS_INODES_PER_CHUNK) == 0); ino = XFS_AGINO_TO_INO(mp, agno, INT_GET(rec.ir_startino, ARCH_CONVERT) + offset); + + printk("inum set to %Ld from ir_startino of %d\n", ino, rec.ir_startino); + XFS_INOBT_CLR_FREE(&rec, offset, ARCH_CONVERT); INT_MOD(rec.ir_freecount, ARCH_CONVERT, -1); if (error = xfs_inobt_update(cur, INT_GET(rec.ir_startino, ARCH_CONVERT), INT_GET(rec.ir_freecount, ARCH_CONVERT), =========================================================================== Index: linux/fs/xfs/xfs_inode.c =========================================================================== --- /usr/tmp/TmpDir.32182-0/linux/fs/xfs/xfs_inode.c_1.301 Tue Aug 29 10:11:32 2000 +++ linux/fs/xfs/xfs_inode.c Tue Aug 29 10:06:23 2000 @@ -1097,6 +1097,7 @@ #endif error = xfs_dialloc(tp, pip ? pip->i_ino : 0, mode, okalloc, ialloc_context, call_again, &ino); + printk("xfs_dialloc returned inum %Ld\n", ino); if (error != 0) { return error; } From owner-linux-xfs@oss.sgi.com Tue Aug 29 08:25:53 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 08:25:43 -0700 Received: from Cantor.suse.de ([194.112.123.193]:22803 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 08:25:18 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 5B78F1E0E6; Tue, 29 Aug 2000 17:24:43 +0200 (MEST) Received: from gruyere.muc.suse.de (unknown [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id C0F1F10A026; Tue, 29 Aug 2000 17:24:42 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 499E02F300; Tue, 29 Aug 2000 17:24:40 +0200 (MEST) Date: Tue, 29 Aug 2000 17:24:40 +0200 From: "Andi Kleen" To: Steve Lord Cc: "Andi Kleen" , linux-xfs@oss.sgi.com Subject: Re: Locking bmap mappings Message-ID: <20000829172440.A29377@gruyere.muc.suse.de> References: <200008291441.JAA31979@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008291441.JAA31979@jen.americas.sgi.com>; from lord@sgi.com on Tue, Aug 29, 2000 at 09:41:18AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Aug 29, 2000 at 09:41:18AM -0500, Steve Lord wrote: > > On Mon, Aug 28, 2000 at 04:23:32PM -0500, Steve Lord wrote: > > > > > > > > > > > Sorry, I should have been more clear. The locking is required for externa > l > > > > users, e.g. the loop device (the current version doesn't do it, but it wi > ll > > > > be fixed to do so). loop device cannot access any internal XFS locks. > > > > > > > > > > > > -Andi > > > > > > OK, that's a different kettle of fish.... > > > > It would be nice if you could commit (or whatever ptools calls that) it. > > > > Thanks, > > > > -Andi > > > Actually, things are somewhat more broken that this, XFS does not provide > prepare_write or commit_write address space operations, so I presume this > means under loopback we would be at best a readonly device. At worst > totally non-functional. That's currently the case yes. The plan however is to turn loopback into a block remapper similar to LVM. It would do direct IO on bmap'ed mappings then (with some special hacks to fill holes -- loopback never extents files) The first step for that is a usable bmap interface for direct IO, which requires a generic way to pin bmap mappings. -Andi From owner-linux-xfs@oss.sgi.com Tue Aug 29 09:53:13 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 09:53:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22798 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 09:52:40 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA00134 for ; Tue, 29 Aug 2000 09:44:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA33189; Tue, 29 Aug 2000 11:49:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA11564; Tue, 29 Aug 2000 11:49:36 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id LAA04616; Tue, 29 Aug 2000 11:44:37 -0500 Message-Id: <200008291644.LAA04616@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ananth Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement In-Reply-To: Message from Steve Lord of "Tue, 29 Aug 2000 09:14:02 CDT." <200008291414.JAA31227@jen.americas.sgi.com> Date: Tue, 29 Aug 2000 11:44:37 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > > I am backing out this change, it breaks doio, and probably anything else > > which fills holes in files. I think we had a similar test condition in > > this code path before, and it was removed to fix corruption. There has > > got to be another variant of this which we can use. > > > > Steve > > > > OK, now I am puzzled, I still got corruption after I backed out the mod, > I removed the old doio output file and the corruption went away on subsequent > runs and I have not been able to reproduce it with or without the mod again. I > will run some more tests and probably be putting the mod back in again shortl y. > > Sorry for the confusion. > > Steve > Looks like the corruption is once again coming out of the clustering write code in pagebuf, I would recommend not using the kiocluster mount option at the moment. I am doing a glibc build with Ananth's change back in again and put it back into the tree if the build works OK. Steve From owner-linux-xfs@oss.sgi.com Tue Aug 29 11:30:24 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 11:30:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:59690 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 11:29:49 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA13975 for ; Tue, 29 Aug 2000 11:21:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA50005 for ; Tue, 29 Aug 2000 13:28:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id NAA35785 for ; Tue, 29 Aug 2000 13:28:01 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id NAA04858; Tue, 29 Aug 2000 13:23:01 -0500 Message-Id: <200008291823.NAA04858@jen.americas.sgi.com> Date: Tue, 29 Aug 2000 13:23:01 -0500 Subject: TAKE - re-insert pagebuf mod, corruption is not caused by this To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Aug 29 11:27:29 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73239a linux/fs/pagebuf/page_buf_io.c - 1.26 - Put Ananth's mod back in - it is not the cause if corruption being seen. From owner-linux-xfs@oss.sgi.com Tue Aug 29 12:02:04 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 12:01:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34868 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 12:01:23 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA18382 for ; Tue, 29 Aug 2000 11:53:05 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA30922; Tue, 29 Aug 2000 11:54:17 -0700 (PDT) Message-ID: <39AC0831.33D7D845@sgi.com> Date: Tue, 29 Aug 2000 12:00:01 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15-3SGI_31 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement References: <200008291644.LAA04616@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > > > > > > I am backing out this change, it breaks doio, and probably anything else > > > which fills holes in files. I think we had a similar test condition in > > > this code path before, and it was removed to fix corruption. There has > > > got to be another variant of this which we can use. > > > > > > Steve > > > > > > > OK, now I am puzzled, I still got corruption after I backed out the mod, > > I removed the old doio output file and the corruption went away on subsequent > > runs and I have not been able to reproduce it with or without the mod again. > I > > will run some more tests and probably be putting the mod back in again shortl > y. > > > > Sorry for the confusion. > > > > Steve > > > > Looks like the corruption is once again coming out of the clustering write > code in pagebuf, I would recommend not using the kiocluster mount option > at the moment. I am doing a glibc build with Ananth's change back in again > and put it back into the tree if the build works OK. > Yikes! Sorry if my change caused this problem. But I ran rpmbuild, kernel build and doio (1,2 threads) before checking-in the change ... -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 29 13:09:03 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 13:08:53 -0700 Received: from hermes.mixx.net ([212.84.196.2]:5906 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 13:08:30 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B1681F80F for ; Tue, 29 Aug 2000 22:07:48 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 6C7902CA6D; Tue, 29 Aug 2000 22:07:48 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 29 Aug 2000 20:07:48 GMT Organization: innominate AG, Berlin, Germany Lines: 61 Distribution: local Message-ID: References: <200008291508.KAA32284@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967579668 8164 10.0.0.69 (29 Aug 2000 20:07:48 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > OK, here is a patch which might start to narrow down where the inode number > is getting lost. I seem to remember there being issues with printing 64 > bit numbers on the ppc, so you may have to mess with this somewhat to get > it to function there. ok - did it (btw. the 64bit problem seems to be only happening with printing in hex which can be easily worked around by shifts and printing two longs - %Ld looks like being working) inum set to 132 from ir_startino of 128 xfs_dialloc returned inum 132 xfs_dir2_createname: inum = 132 this is the output of your patch for my typical test: "cp XFS test" just tell me what else you are interested in ... t > +++ linux/fs/xfs/xfs_dir2.c Tue Aug 29 10:06:05 2000 > @@ -274,6 +274,7 @@ > int rval; /* return value */ > int v; /* type-checking value */ > > + printk("xfs_dir2_createname: inum = %Ld\n", inum); > ASSERT((dp->i_d.di_mode & IFMT) == IFDIR); > if (rval = xfs_dir_ino_validate(tp->t_mountp, inum)) { > #pragma mips_frequency_hint NEVER > +++ linux/fs/xfs/xfs_ialloc.c Tue Aug 29 10:05:44 2000 > @@ -935,6 +935,9 @@ > ASSERT((XFS_AGINO_TO_OFFSET(mp, INT_GET(rec.ir_startino, ARCH_CONVERT)) % > XFS_INODES_PER_CHUNK) == 0); > ino = XFS_AGINO_TO_INO(mp, agno, INT_GET(rec.ir_startino, ARCH_CONVERT) + > offset); > + > + printk("inum set to %Ld from ir_startino of %d\n", ino, rec.ir_startino); > + > XFS_INOBT_CLR_FREE(&rec, offset, ARCH_CONVERT); > INT_MOD(rec.ir_freecount, ARCH_CONVERT, -1); > if (error = xfs_inobt_update(cur, INT_GET(rec.ir_startino, ARCH_CONVERT), > INT_GET(rec.ir_freecount, ARCH_CONVERT), > +++ linux/fs/xfs/xfs_inode.c Tue Aug 29 10:06:23 2000 > @@ -1097,6 +1097,7 @@ > #endif > error = xfs_dialloc(tp, pip ? pip->i_ino : 0, mode, okalloc, > ialloc_context, call_again, &ino); > + printk("xfs_dialloc returned inum %Ld\n", ino); > if (error != 0) { > return error; > } -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 29 13:31:43 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 13:31:33 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57708 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 13:31:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05860 for ; Tue, 29 Aug 2000 13:37:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id PAA69311; Tue, 29 Aug 2000 15:29:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id PAA50813; Tue, 29 Aug 2000 15:29:18 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id PAA19696; Tue, 29 Aug 2000 15:24:17 -0500 Message-Id: <200008292024.PAA19696@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: more xfs on ppc In-Reply-To: Message from Thomas Graichen of "29 Aug 2000 20:07:48 GMT." Date: Tue, 29 Aug 2000 15:24:17 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Steve Lord wrote: > > > OK, here is a patch which might start to narrow down where the inode number > > is getting lost. I seem to remember there being issues with printing 64 > > bit numbers on the ppc, so you may have to mess with this somewhat to get > > it to function there. > > ok - did it (btw. the 64bit problem seems to be only happening with > printing in hex which can be easily worked around by shifts and > printing two longs - %Ld looks like being working) > > inum set to 132 from ir_startino of 128 > xfs_dialloc returned inum 132 > xfs_dir2_createname: inum = 132 > > this is the output of your patch for my typical test: "cp XFS test" > > just tell me what else you are interested in ... > Which says that the problem is in getting the inode number into the directory entry itself, not in creating the inode number. Hmmm, try this patch, we are taking an 8 byte inode number and placing it in a 4 byte field, I think on a big endian machine we are copying the wrong half of the word over. Steve =========================================================================== Index: linux/fs/xfs/xfs_arch.h =========================================================================== --- /usr/tmp/TmpDir.19679-0/linux/fs/xfs/xfs_arch.h_1.27 Tue Aug 29 15:28:27 2000 +++ linux/fs/xfs/xfs_arch.h Tue Aug 29 15:23:21 2000 @@ -226,7 +226,7 @@ } #define DIRINO4_COPY_ARCH(from,to,arch) \ if ((arch) == ARCH_NOCONVERT) { \ - bcopy(from,to,sizeof(xfs_dir2_ino4_t)); \ + bcopy((((__u8*)from+4)),to,sizeof(xfs_dir2_ino4_t)); \ } else { \ INT_SWAP_UNALIGNED_32(from,to); \ } From owner-linux-xfs@oss.sgi.com Tue Aug 29 13:50:53 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 13:50:43 -0700 Received: from hermes.mixx.net ([212.84.196.2]:58386 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 13:50:20 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id AFCE0F80F for ; Tue, 29 Aug 2000 22:49:46 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 6E7382CA6D; Tue, 29 Aug 2000 22:49:46 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: more xfs on ppc Date: 29 Aug 2000 20:49:46 GMT Organization: innominate AG, Berlin, Germany Lines: 63 Distribution: local Message-ID: References: <200008292024.PAA19696@jen.americas.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967582186 8164 10.0.0.69 (29 Aug 2000 20:49:46 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: >> Steve Lord wrote: >> >> > OK, here is a patch which might start to narrow down where the inode number >> > is getting lost. I seem to remember there being issues with printing 64 >> > bit numbers on the ppc, so you may have to mess with this somewhat to get >> > it to function there. >> >> ok - did it (btw. the 64bit problem seems to be only happening with >> printing in hex which can be easily worked around by shifts and >> printing two longs - %Ld looks like being working) >> >> inum set to 132 from ir_startino of 128 >> xfs_dialloc returned inum 132 >> xfs_dir2_createname: inum = 132 >> >> this is the output of your patch for my typical test: "cp XFS test" >> >> just tell me what else you are interested in ... > Which says that the problem is in getting the inode number into the directory > entry itself, not in creating the inode number. Hmmm, > try this patch, we are taking an 8 byte inode number and placing it in a > 4 byte field, I think on a big endian machine we are copying the wrong half > of the word over. > +++ linux/fs/xfs/xfs_arch.h Tue Aug 29 15:23:21 2000 > @@ -226,7 +226,7 @@ ... > - bcopy(from,to,sizeof(xfs_dir2_ino4_t)); \ > + bcopy((((__u8*)from+4)),to,sizeof(xfs_dir2_ino4_t)); \ [root@aqua linux]# modprobe xfs [root@aqua linux]# mount -t xfs /dev/hda8 /mnt/floppy/ [root@aqua linux]# cd /mnt/floppy/ [root@aqua floppy]# ls XFS [root@aqua floppy]# cat XFS i am here [root@aqua floppy]# cp XFS test [root@aqua floppy]# ls XFS test [root@aqua floppy]# cat test i am here [root@aqua floppy]# you know what this means? :-) it _works_ now ... i just copied the full /etc onto the filesystem and the result was perfect (diffed the copied one against /etc) also not crash or assert so far ... will try some more stresstesting now - but it looks fine so far ... congrats and a _lot_ of thanks for your help t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 29 14:04:53 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 14:04:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32881 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 14:04:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07080 for ; Tue, 29 Aug 2000 14:10:08 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA75873 for ; Tue, 29 Aug 2000 16:02:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id QAA11173 for ; Tue, 29 Aug 2000 16:02:23 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id PAA23694; Tue, 29 Aug 2000 15:57:21 -0500 Message-Id: <200008292057.PAA23694@jen.americas.sgi.com> Date: Tue, 29 Aug 2000 15:57:21 -0500 Subject: TAKE - fix for big endian versions of XFS To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This makes the power pc port get a lot further. Date: Tue Aug 29 14:01:45 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73252a linux/fs/xfs/xfs_arch.h - 1.28 cmd/xfs/include/xfs_arch.h - 1.2 - Fix for big endian version of byte swapping macros in XFS, fixes code which inserts inode number into a directory, it was using the wrong half of the inode number. From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:37:33 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:37:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13435 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:36:55 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05729; Tue, 29 Aug 2000 15:42:49 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA93922; Tue, 29 Aug 2000 15:35:54 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA06969; Tue, 29 Aug 2000 15:34:37 -0700 (PDT) Date: Tue, 29 Aug 2000 15:34:37 -0700 (PDT) Message-Id: <200008292234.PAA06969@info.engr.sgi.com> X-Pv-Incident: 768229 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 768229 - Remove compile warnings and general code clean-up. To: cattelan@engr.sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768229 *Status : closed Priority : 1 Assigned Engineer : cattelan Submitter : mostek Opened Date : 09/23/99 *Closed Date : 08/29/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:34:36PM ========================== Closed as per discusion at XFS meeting on 8/29/2000 From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:39:44 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:39:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27003 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:39:16 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03953; Tue, 29 Aug 2000 15:45:09 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA14432; Tue, 29 Aug 2000 15:38:14 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA42241; Tue, 29 Aug 2000 15:36:57 -0700 (PDT) Date: Tue, 29 Aug 2000 15:36:57 -0700 (PDT) Message-Id: <200008292236.PAA42241@info.engr.sgi.com> X-Pv-Incident: 768238 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: ADD 768238 - Volume Manager work for XFS on Linux To: n8992@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768238 Status : open Priority : 1 Assigned Engineer : n8992 Submitter : mostek *Modified User : cattelan *Modified User Domain : engr *Description : The interactions between XFS and volume managers on Linux need to be investigated, designed, and implemented. This includes enhancing slinx-xfs/cmd/xfs/sim/src/libdisk.c to also deal with volume managers. i. Install LVM on a machine and integrate with XFS. ii. Install/configure md on a machine and integrate with XFS. iii. port xlv_get_subvolumes() to a more generic routine and implement to handle multiple Linux volume managers. iv. libdisk needs to: ..... ========================== ADDITIONAL INFORMATION (ADD) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:36:56PM ========================== More testing is needed for BETA release of linux-xfs. (9/22/2000) From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:40:14 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:40:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26477 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:39:41 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16353; Tue, 29 Aug 2000 15:31:33 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA83935; Tue, 29 Aug 2000 15:39:10 -0700 (PDT) Date: Tue, 29 Aug 2000 15:39:10 -0700 (PDT) Message-Id: <200008292239.PAA83935@info.engr.sgi.com> X-Pv-Incident: 768250 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 768250 - XFS should use standard Linux UUID code To: btg@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768250 *Status : closed Priority : 2 Assigned Engineer : btg Submitter : mostek Opened Date : 09/23/99 *Closed Date : 08/29/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:39:09PM ========================== Fixed: XFS meeting (8/29/2000) From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:42:34 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:42:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:2414 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:42:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16689; Tue, 29 Aug 2000 15:33:45 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA53594; Tue, 29 Aug 2000 15:41:22 -0700 (PDT) Date: Tue, 29 Aug 2000 15:41:22 -0700 (PDT) Message-Id: <200008292241.PAA53594@info.engr.sgi.com> X-Pv-Incident: 768261 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 768261 - Implement xfs syssgi() calls and mechanim. To: btg@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768261 *Status : closed Priority : 2 Assigned Engineer : btg Submitter : mostek Opened Date : 09/23/99 *Closed Date : 08/29/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:41:22PM ========================== Most of the major syssgi calls have be reimplemented using ioctl. Any additional ones should have new PV's From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:47:04 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:46:59 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5999 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:46:36 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA17257; Tue, 29 Aug 2000 15:38:28 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA60429; Tue, 29 Aug 2000 15:44:20 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA85025; Tue, 29 Aug 2000 15:43:03 -0700 (PDT) Date: Tue, 29 Aug 2000 15:43:03 -0700 (PDT) Message-Id: <200008292243.PAA85025@info.engr.sgi.com> X-Pv-Incident: 768683 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 768683 - XFS' performance must be better than or equal to EXT2 To: btg@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=768683 *Status : closed Priority : 1 Assigned Engineer : btg Submitter : mostek Opened Date : 09/28/99 *Closed Date : 08/29/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:43:03PM ========================== Permormance is on par with ext2 at this point. From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:48:44 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:48:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31087 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:48:15 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA17438; Tue, 29 Aug 2000 15:39:57 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA05259; Tue, 29 Aug 2000 15:47:33 -0700 (PDT) Date: Tue, 29 Aug 2000 15:47:33 -0700 (PDT) Message-Id: <200008292247.PAA05259@info.engr.sgi.com> X-Pv-Incident: 795642 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: ADD 795642 - remount -o remount,ro doesn't leave FS consistent To: btg@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=795642 Status : open Priority : 3 Assigned Engineer : btg Submitter : dxm *Modified User : cattelan *Modified User Domain : engr *Description : Remounting an XFS filesystem R/O can leave the FS in an inconsistent state. (Playing with this for long enough can hang mount up...) Reproduce with QA 013 or: #!/bin/sh DEV=/dev/hda6 MNT=/mnt/arch0 ..... ========================== ADDITIONAL INFORMATION (ADD) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:47:33PM ========================== This is partially working, rw->ro at shutdown works. rw->ro on a running active file system will most likely hang the system. It is unclear this can ever be made to work correctly, since it is hard to determine if the active vnodes are open for reading or for read/write. Some additional work in the linux vfs layers may be nessesary. From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:49:54 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:49:44 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:56431 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:49:28 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA17636; Tue, 29 Aug 2000 15:41:20 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA39837; Tue, 29 Aug 2000 15:48:57 -0700 (PDT) Date: Tue, 29 Aug 2000 15:48:57 -0700 (PDT) Message-Id: <200008292248.PAA39837@info.engr.sgi.com> X-Pv-Incident: 796140 webPV: gibble.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: CLOSE 796140 - deadlock on unmount To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=796140 *Status : closed Priority : 4 Assigned Engineer : lord Submitter : dxm Opened Date : 07/12/00 *Closed Date : 08/29/00 *Fixed By : cattelan *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : cattelan *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: cattelan@engr (BugWorks) Date: Aug 29 2000 03:48:57PM ========================== Assumed to be fixed. XFS meeting (8/29/2000) From owner-linux-xfs@oss.sgi.com Tue Aug 29 15:59:14 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:59:04 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56700 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 15:58:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05230 for ; Tue, 29 Aug 2000 16:04:37 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA42417 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 09:56:56 +1100 (EST) Date: Wed, 30 Aug 2000 09:56:56 +1100 (EST) From: Daniel Moore Message-Id: <200008292256.JAA42417@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 800273 external log footer in user tools Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73260a Date: Tue Aug 29 15:56:17 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/init.c - 1.27 - add "-l logdev" option cmd/xfs/db/uuid.c - 1.2 - handle external logs - check/set footer cmd/xfs/growfs/Makefile - 1.3 - need uuid lib cmd/xfs/include/libxfs.h - 1.11 - add proto for libxfs_check_log_footer cmd/xfs/libxfs/rdwr.c - 1.11 - add libxfs_check_log_footer cmd/xfs/logprint/kernel.c - 1.5 - match kernel change - don't check footer from xlog_find_tail cmd/xfs/logprint/logprint.c - 1.45 - use libxfs_check_log_footer cmd/xfs/logprint/logprint.h - 1.8 - fix log macro definitions cmd/xfs/mkfs/Makefile - 1.44 - need uuid lib cmd/xfs/mkfs/xfs_mkfs.c - 1.174 - use libxfs_write_log_footer cmd/xfs/repair/Makefile - 1.43 - need uuid lib cmd/xfs/repair/err_protos.h - 1.6 - change log macro definitions cmd/xfs/repair/phase2.c - 1.27 - check/rewrite external log footer cmd/xfs/repair/xfs_repair.c - 1.49 - change log macro definitions linux/fs/xfs/xfs_log_recover.c - 1.186 - call xlog_test_footer from xlog_recover not xlog_find_tail From owner-linux-xfs@oss.sgi.com Tue Aug 29 16:02:14 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 16:02:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35698 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 16:01:49 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA19048; Tue, 29 Aug 2000 15:53:11 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA42321; Tue, 29 Aug 2000 16:00:47 -0700 (PDT) Date: Tue, 29 Aug 2000 16:00:47 -0700 (PDT) Message-Id: <200008292300.QAA42321@info.engr.sgi.com> X-Pv-Incident: 800273 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 800273 - repair & db need to write external log footer To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800273 *Status : closed Priority : 2 Assigned Engineer : dxm Submitter : nathans Opened Date : 08/25/00 *Closed Date : 08/29/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 08/29/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Aug 29 2000 04:00:46PM ========================== Modid: 2.4.0-test1-xfs:slinx:73260a Date: Tue Aug 29 15:56:17 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm From owner-linux-xfs@oss.sgi.com Tue Aug 29 16:12:34 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 16:12:24 -0700 Received: from fepE.post.tele.dk ([195.41.46.137]:15331 "EHLO fepE.post.tele.dk") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 16:11:55 -0700 Received: from burns.home.kernel.dk ([193.89.190.47]) by fepE.post.tele.dk (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000829231123.HGRP341.fepE.post.tele.dk@burns.home.kernel.dk>; Wed, 30 Aug 2000 01:11:23 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 13TuWm-0002n2-00; Wed, 30 Aug 2000 01:10:48 +0200 Date: Wed, 30 Aug 2000 01:10:48 +0200 From: Jens Axboe To: Steve Lord Cc: Ananth Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement Message-ID: <20000830011048.B6674@suse.de> References: <200008291644.LAA04616@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008291644.LAA04616@jen.americas.sgi.com>; from lord@sgi.com on Tue, Aug 29, 2000 at 11:44:37AM -0500 X-OS: Linux 2.4.0-test8 i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Aug 29 2000, Steve Lord wrote: > Looks like the corruption is once again coming out of the clustering write > code in pagebuf, I would recommend not using the kiocluster mount option > at the moment. I am doing a glibc build with Ananth's change back in again > and put it back into the tree if the build works OK. Aughr, this could explain some weirdness that I'm seeing on IDE kiobuf atm. Basically, kio and "plain" xfs works just fine and I can't crash it. No corruption either. But kiocluster corrupts data here too... And currently I don't see why. For IDE, the kio clustering just means that the same request will be started more than one time. I'll try and look closer at this tomorrow. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Tue Aug 29 16:36:44 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 16:36:34 -0700 Received: from hermes.mixx.net ([212.84.196.2]:61446 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 16:36:16 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 8BEE2F805 for ; Wed, 30 Aug 2000 01:35:44 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 46CC02CA6D; Wed, 30 Aug 2000 01:35:44 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: xfs on ppc status Date: 29 Aug 2000 23:35:44 GMT Organization: innominate AG, Berlin, Germany Lines: 49 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967592144 351 10.0.0.69 (29 Aug 2000 23:35:44 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ok - with the last fix from steve xfs on ppc starts to be useable (but it definitely has bugs) ... for instance the following is possible: [root@aqua /root]# uname -a Linux aqua 2.4.0-test5 #5 Wed Aug 30 04:08:43 CEST 2000 ppc unknown [root@aqua /root]# mount ^^^ /dev/hda8 on / type xfs (rw) <--- none on /proc type proc (rw) /dev/hda5 on /boot type hfs (ro) /dev/hda9 on /home type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) [root@aqua /root]# so it works quite well (i at least got a 2gb filesystem copied over to xfs and was able to boot from it :-) ... also the journal replay code seems to work somehow (got it mounted clean after an unclean umount) ... but the system did not survive a reboot after the xfs root experiment ... also i still get invalid inode numbers (it started at the end of copying the disk over which is close to completely full) at aqua kernel: XFS assertion failed: xfs_dir_ino_validate(mp, INT_GET(dep->inumber, ARCH_CONVERT)) == 0, file: xfs_dir2_data.c, line: 175 which is: ASSERT(xfs_dir_ino_validate(mp, INT_GET(dep->inumber, ARCH_CONVERT)) == 0); in xfs_dir2_data.c (btw. i have changed asserts to not result in a BUG() ) one thing related to this seems to be that the root-dir of the xfs filesystem does not have a ".." entry visible (but like with the test entry in the last weeks it's there) also now it would be really good to have a working non-sim xfs_repair ... ok - enough for now - it's late night already t -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Tue Aug 29 16:51:24 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 16:51:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:49277 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 16:50:55 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA24507 for ; Tue, 29 Aug 2000 16:42:37 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id SAA89946; Tue, 29 Aug 2000 18:47:40 -0500 (CDT) Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/Cray-ironwood-e1.6) with ESMTP id SAA23399; Tue, 29 Aug 2000 18:47:39 -0500 (CDT) Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80]) by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e7TNZfe01852; Tue, 29 Aug 2000 18:35:41 -0500 Message-ID: <39AC48CC.F4549E08@thebarn.com> Date: Tue, 29 Aug 2000 18:35:40 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-whipme5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jens Axboe CC: Steve Lord , Ananth Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: TAKE - write performance improvement References: <200008291644.LAA04616@jen.americas.sgi.com> <20000830011048.B6674@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > On Tue, Aug 29 2000, Steve Lord wrote: > > Looks like the corruption is once again coming out of the clustering write > > code in pagebuf, I would recommend not using the kiocluster mount option > > at the moment. I am doing a glibc build with Ananth's change back in again > > and put it back into the tree if the build works OK. > > Aughr, this could explain some weirdness that I'm seeing on IDE kiobuf > atm. Basically, kio and "plain" xfs works just fine and I can't crash > it. No corruption either. But kiocluster corrupts data here too... > > And currently I don't see why. For IDE, the kio clustering just means > that the same request will be started more than one time. I'll try and look > closer at this tomorrow. It is unclear at this point where the corruption is coming from there is evidence that it has nothing to do with kiobuf's/ clustering. LVM testing is also showing corruption... it doesn't use kio bufs. -Russell. From owner-linux-xfs@oss.sgi.com Tue Aug 29 17:08:04 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 17:07:54 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10758 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 17:07:29 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01317 for ; Tue, 29 Aug 2000 17:13:23 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA37514 for ; Tue, 29 Aug 2000 17:02:04 -0700 (PDT) Message-ID: <39AC5053.91DA1D4F@sgi.com> Date: Tue, 29 Aug 2000 17:07:47 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15-3SGI_31 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Corruption status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The original hypothesis that the write performance improvements cause the corruption is not correct. Nor is it kiocluster option; just kio option can cause corruption as well. And with Russell's mail it appears that kiobufs may not be the source of the problem either. So, I think we are dealing with something more fundamental, most likely in the I/O paths (prepare/commit write, readpage, writepage, etc.). It would be helpful if we can find a small testcase that shows corruption. Rightnow all we have is an rpm build that fails; this is too complex to track corruption directly. If anyone has a small(er) testcase, please let us know. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 29 17:17:35 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 17:17:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:34310 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 17:17:13 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA26872; Tue, 29 Aug 2000 17:09:01 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA18807; Tue, 29 Aug 2000 17:14:53 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA10858; Tue, 29 Aug 2000 17:13:36 -0700 (PDT) Date: Tue, 29 Aug 2000 17:13:36 -0700 (PDT) Message-Id: <200008300013.RAA10858@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: sgigate.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: BUG 800480 - xlog_grant_log_space can wait indefinitely To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Submitter : ananth Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 xfs_inactive+0x1ca vn_put+0x47 linvfs_d_iput+0x1a d_delete+0x57 vfs_unlink+0x18b sys_unlink+0x9b system_call+0x34 ----------- and wait for ever. Both the page_cleaner and pagebuf daemon had a normal backtrace (ie. both waiting on their respective timer/semaphore). No other suspicious looking backtraces in other processes. The machine was mostly alive except for commands that would touch the xfs filesystem. ananth. From owner-linux-xfs@oss.sgi.com Tue Aug 29 18:07:05 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 18:06:55 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:7951 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 18:06:26 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA01214 for ; Tue, 29 Aug 2000 17:58:17 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA67859 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 12:04:37 +1100 (EST) Date: Wed, 30 Aug 2000 12:04:37 +1100 (EST) From: Daniel Moore Message-Id: <200008300104.MAA67859@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_db "uuid rewrite" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Add "uuid rewrite" to copy uuid from SB 0 to toerh SBs and the external log footer. Modid: 2.4.0-test1-xfs:slinx:73277a Date: Tue Aug 29 18:04:00 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/uuid.c - 1.3 - add "uuid rewrite" to copy uuid from SB 0. From owner-linux-xfs@oss.sgi.com Tue Aug 29 18:08:15 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 18:08:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19215 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 18:07:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA01289 for ; Tue, 29 Aug 2000 17:59:42 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA85525 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 12:06:02 +1100 (EST) Date: Wed, 30 Aug 2000 12:06:02 +1100 (EST) From: Daniel Moore Message-Id: <200008300106.MAA85525@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - External log Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing NOTE: Existing XFS FSes with external logs won't mount after this change. This is due to the version number being made endian safe (ie big-endian) and the magic number changing. It's easy to transition old external logs to the new format - just unmount the FS and use xfs_db: ie for a FS on /dev/foo with log on /dev/foo_log: xfs_db -r /dev/foo -l /dev/foo_log -c "uuid rewrite" This will rewrite the log footer in the new format. You'll need an up-to-date xfs_db for this to work. Modid: 2.4.0-test1-xfs:slinx:73272a Date: Tue Aug 29 17:37:21 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/xfs_log_priv.h - 1.2 linux/fs/xfs/xfs_log_priv.h - 1.74 - Define XFS_EXTERNAL_LOG_VERSION & XFS_EXTERNAL_LOG_MAGIC cmd/xfs/libxfs/rdwr.c - 1.12 cmd/xfs/sim/src/libdisk.c - 1.14 linux/fs/xfs/xfs_log_recover.c - 1.187 - use new XFS_EXTERNAL_LOG_* defines & make version endian safe cmd/xfs/logprint/logprint.c - 1.46 - fix error messages From owner-linux-xfs@oss.sgi.com Tue Aug 29 18:21:25 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 18:21:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:15889 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 18:20:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA02395 for ; Tue, 29 Aug 2000 18:12:38 -0700 (PDT) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24844; Wed, 30 Aug 2000 12:17:44 +1100 Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA44351; Wed, 30 Aug 2000 11:17:43 +1000 (EST) Message-Id: <200008300117.LAA44351@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: xfs_iget... In-reply-to: Your message of "Mon, 28 Aug 2000 14:18:08 EST." <200008281918.OAA24273@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Aug 2000 11:17:43 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord writes: => I suspect what you are seeing is due to running fsstress - it exercises => the bulkstat interface asking for random inode numbers - which in all => probability do not exist. It calculates a disk location based on the inode => number and reads the block into memory - it fails these checks if it is => not a real inode block and you get the error message. => => Irix exhibits exactly the same behavior with fsstress, this one is not a => bug it is a feature of the test program. This confirms what I eventually worked out. I'll document this somewhere useful and cross it off my list. Thanks. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 29 20:11:06 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 20:10:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14096 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 20:10:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA08693 for ; Tue, 29 Aug 2000 20:16:39 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA43758 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 14:07:41 +1100 (EST) Date: Wed, 30 Aug 2000 14:07:41 +1100 (EST) From: Nathan Scott Message-Id: <200008300307.OAA43758@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73279a Date: Tue Aug 29 20:05:44 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/configure.in - 1.13 cmd/xfs/include/builddefs.in - 1.11 - allow an alternate malloc library to be used in all tools. cmd/xfs/stress/030 - 1.2 cmd/xfs/stress/030.out - 1.2 - old 030 now all within 019, so this is a new test which exercises repair handling deliberately corrupted filesystems. this could be extended quite a bit in addition to whats there now. From owner-linux-xfs@oss.sgi.com Tue Aug 29 20:12:36 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 20:12:26 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43551 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 20:12:09 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA09825; Tue, 29 Aug 2000 20:04:01 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id UAA43818; Tue, 29 Aug 2000 20:11:38 -0700 (PDT) Date: Tue, 29 Aug 2000 20:11:38 -0700 (PDT) Message-Id: <200008300311.UAA43818@info.engr.sgi.com> X-Pv-Incident: 800489 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800489 - panic in umount after repair To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800489 Submitter : nathans Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : After deliberate corruption followed by repair, we seem to trip an assert in the unmount code. I've just checked in a QA test which can reproduce this (030), but it doesn't reliably reproduce it (I've seen it only twice out of six/seven iterations). My current test environment is using top-of-tree libxfs-mkfs and a libsim-repair installed to / (I'm trying to verify the old repair before checking in a bunch of changes to it). The kernel I'm using is a bit dated too (built 18 August) - might be part of the problem. I'll update that later today & see if this still happens. Start mounting filesystem: ide0(3,6) Ending clean XFS mount for filesystem: ide0(3,6) XFS assertion failed: i < xfs_uuidtab_size, file: xfs_mount.c, line: 1766 kernel BUG at xfs_debug.c:50! Entering kdb (0xc1a00000) Panic: invalid operand due to panic @ 0xc01d7349 eax = 0x0000001e ebx = 0x00000010 ecx = 0xc034de2c edx = 0x00000000 esi = 0x00000002 edi = 0xc1a01e98 esp = 0xc1a01e6c eip = 0xc01d7349 ebp = 0xc1a01e78 ss = 0x00000018 cs = 0x00000010 eflags = 0x00010246 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc1a01e38 kdb> bt EBP EIP Function(args) 0xc1a01e78 0xc01d7349 assfail+0x2d (0xc02a1dff, 0xc02a16b6, 0x6e6) kernel .text 0xc0100000 0xc01d731c 0xc01d7350 0xc1a01e9c 0xc01bfece xfs_uuid_unmount+0xa6 (0xc5d6fc00) kernel .text 0xc0100000 0xc01bfe28 0xc01bfee8 0xc1a01eb8 0xc01bf3be xfs_unmountfs+0xbe (0xc5d6fc00, 0x3, 0xc03b1f60) kernel .text 0xc0100000 0xc01bf300 0xc01bf404 0xc1a01ee8 0xc01cb324 xfs_unmount+0x1fc (0xc5d6fc00, 0x0, 0xc03b1f60) kernel .text 0xc0100000 0xc01cb128 0xc01cb338 0xc1a01f08 0xc01d79e8 fs_dounmount+0x7c (0xc5d6fc00, 0x0, 0x0, 0xc03b1f60, 0xc345e340) kernel .text 0xc0100000 0xc01d796c 0xc01d7a04 0xc1a01f38 0xc01dffe1 linvfs_put_super+0x59 (0xc503ea00) kernel .text 0xc0100000 0xc01dff88 0xc01e0054 0xc1a01f50 0xc012e28a kill_super+0x7a (0xc503ea00, 0x0, 0xc5858f20, 0xffffffff, 0xc47884c0) kernel .text 0xc0100000 0xc012e210 0xc012e31c 0xc1a01f70 0xc012e641 do_umount+0x1ad (0xc5858f20, 0x0, 0x0) kernel .text 0xc0100000 0xc012e494 0xc012e650 0xc1a01fac 0xc012e707 sys_umount+0xb7 (0x8052fd0, 0x0) kernel .text 0xc0100000 0xc012e650 0xc012e72c 0xc1a01fbc 0xc012e73a sys_oldumount+0xe (0x8052fd0, 0x78, 0x8053008, 0x8052fd1, 0x804d3e0) kernel .text 0xc0100000 0xc012e72c 0xc012e740 0xc0108e28 system_call+0x34 From owner-linux-xfs@oss.sgi.com Tue Aug 29 20:27:46 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 20:27:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22049 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 20:27:02 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA10769; Tue, 29 Aug 2000 20:18:44 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA89947; Tue, 29 Aug 2000 20:25:03 -0700 (PDT) Date: Tue, 29 Aug 2000 20:25:03 -0700 (PDT) Message-Id: <200008300325.UAA89947@feature.engr.sgi.com> X-Pv-Incident: 800489 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (dxm@melbourne.sgi.com) Subject: ADD 800489 - panic in umount after repair To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : nathans Status : open Assigned Engineer : nb Priority : 1 *Modified Date : 08/29/00 *Modified User : dxm *Modified User Domain : melbourne *Description : After deliberate corruption followed by repair, we seem to trip an assert in the unmount code. I've just checked in a QA test which can reproduce this (030), but it doesn't reliably reproduce it (I've seen it only twice out of six/seven iterations). My current test environment is using top-of-tree libxfs-mkfs and a libsim-repair installed to / (I'm trying to verify the old repair before checking in a bunch of changes to it). The kernel I'm using is a bit dated too (built 18 August) - might be part of the problem. I'll update that later today & see if this still happens. ..... ========================== ADDITIONAL INFORMATION (ADD) From: daniel moore Date: Aug 29 2000 08:25:03PM [pvnews version: 1.71] ========================== => After deliberate corruption followed by repair, we seem to trip => an assert in the unmount code. I've just checked in a QA test => which can reproduce this (030), but it doesn't reliably reproduce => it (I've seen it only twice out of six/seven iterations). => => My current test environment is using top-of-tree libxfs-mkfs and a => libsim-repair installed to / (I'm trying to verify the old repair => before checking in a bunch of changes to it). The kernel I'm using => is a bit dated too (built 18 August) - might be part of the problem. => I'll update that later today & see if this still happens. => XFS assertion failed: i < xfs_uuidtab_size, file: xfs_mount.c, line: 1766 => kernel BUG at xfs_debug.c:50! That assertion would be tripped if you filled the uuid table up. XFS used to leave behind entries in the uuid table on failed mounts (pv 799752) but my TAKE on 23 August should have fixed this. Try it out with that change and let me know if you still have problems. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Aug 29 22:52:08 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 22:51:58 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10517 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 22:51:28 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA02635; Tue, 29 Aug 2000 22:57:22 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA35202; Tue, 29 Aug 2000 22:50:56 -0700 (PDT) Date: Tue, 29 Aug 2000 22:50:56 -0700 (PDT) Message-Id: <200008300550.WAA35202@info.engr.sgi.com> X-Pv-Incident: 800493 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800493 - xfs_db suspect memory allocation To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800493 Submitter : nathans Submitter Domain : engr Assigned Engineer : dxm Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : Linking tools with libefence.a, qa test 004 fails due to xfs_db attempting to malloc zero bytes... 003 - output mismatch (see 003.out.bad) 4a5,7 > > ElectricFence Aborting: Allocating 0 bytes, probably a bug. > FAILED - core file 5a9,11 > > ElectricFence Aborting: Allocating 0 bytes, probably a bug. > FAILED - core file (gdb) r -c "push sb" /dev/hda5 Starting program: /home/nathans/isms/linux-xfs/cmd/xfs/db/./xfs_db -c "push sb" /dev/hda5 Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. ElectricFence Aborting: Allocating 0 bytes, probably a bug. Program received signal SIGILL, Illegal instruction. 0x40037d41 in __kill () from /lib/libc.so.6 (gdb) where #0 0x40037d41 in __kill () from /lib/libc.so.6 #1 0x80d21ab in EF_Abort () #2 0x80d196e in memalign () #3 0x80d1ed7 in malloc () #4 0x806a9c7 in xmalloc (size=0) at malloc.c:74 #5 0x806a3b5 in read_bbs (bbno=0, count=0, bufp=0x4011dbd0, bbmap=0x0) at io.c:487 #6 0x806a78a in set_cur (t=0x0, d=0, c=0, ring_flag=0, bbmap=0x0) at io.c:575 #7 0x8069ba7 in push_f (argc=2, argv=0x4011bff4) at io.c:256 #8 0x805e48a in command (argc=2, argv=0x4011bff4) at command.c:113 #9 0x806e568 in main (argc=4, argv=0xbffffaf4) at main.c:57 (gdb) q From owner-linux-xfs@oss.sgi.com Tue Aug 29 22:53:58 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 22:53:48 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18197 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Aug 2000 22:53:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01303 for ; Tue, 29 Aug 2000 22:59:18 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA82302 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 16:50:18 +1100 (EST) Date: Wed, 30 Aug 2000 16:50:18 +1100 (EST) From: Nathan Scott Message-Id: <200008300550.QAA82302@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73283a Date: Tue Aug 29 22:49:48 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/004 - 1.5 - ensure scrath device is initialized. cmd/xfs/stress/013.out - 1.3 - remove extra -v options from output, consistent with test. cmd/xfs/stress/check - 1.4 cmd/xfs/stress/common.rc - 1.21 - filter out libefence notice so diff's can be performed. From owner-linux-xfs@oss.sgi.com Tue Aug 29 23:44:48 2000 Received: by oss.sgi.com id ; Tue, 29 Aug 2000 23:44:38 -0700 Received: from hermes.mixx.net ([212.84.196.2]:35597 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 23:44:08 -0700 Received: from mate.bln.innominate.de (cerberus.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id CA7C4F808 for ; Wed, 30 Aug 2000 08:43:26 +0200 (CEST) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 89A382CA6D; Wed, 30 Aug 2000 08:43:26 +0200 (CEST) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: BUG 800480 - xlog_grant_log_space can wait indefinitely Date: 30 Aug 2000 06:43:26 GMT Organization: innominate AG, Berlin, Germany Lines: 49 Distribution: local Message-ID: References: <200008300013.RAA10858@info.engr.sgi.com> Reply-To: thomas.graichen@innominate.de X-Trace: mate.bln.innominate.de 967617806 7859 10.0.0.31 (30 Aug 2000 06:43:26 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test5 (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing i might be completely wrong - but the sv_wait thing was once observed as an gcc 2.95 problem - maybe this is the reason? (just an idea) t ananth@engr.sgi.com wrote: > View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 > Submitter: ananth Submitter Domain : engr > Assigned Engineer : nb Assigned Domain : sgi.com > Assigned Group : xfs-linux Category : software > Customer Reported : F Priority : 2 > Project: xfs-linux Status : open > Description: > We have a semi-production build machine that is > running XFS bits as of 8/23/00. I have seen > things like "rm" getting into the following backtrace: > --------- > schedule+0x415 > _sv_wait+0xcd > xlog_grant_log_space+0x139 > xfs_log_reserve+0x7b > xfs_trans_reserve+0x76 > xfs_inactive+0x1ca > vn_put+0x47 > linvfs_d_iput+0x1a > d_delete+0x57 > vfs_unlink+0x18b > sys_unlink+0x9b > system_call+0x34 > ----------- > and wait for ever. Both the page_cleaner and pagebuf > daemon had a normal backtrace (ie. both waiting on > their respective timer/semaphore). No other > suspicious looking backtraces in other processes. > The machine was mostly alive except for commands > that would touch the xfs filesystem. > ananth. -- thomas.graichen@innominate.de technical director innominate AG clustering & security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de From owner-linux-xfs@oss.sgi.com Wed Aug 30 03:23:28 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 03:23:19 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63260 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 03:22:50 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id DAA08613 for ; Wed, 30 Aug 2000 03:28:32 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA98649 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 21:19:34 +1100 (EST) Date: Wed, 30 Aug 2000 21:19:34 +1100 (EST) From: Nathan Scott Message-Id: <200008301019.VAA98649@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - stress Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.0-test1-xfs:slinx:73289a Date: Wed Aug 30 03:18:46 PDT 2000 Workarea: snort:/build4/nathans/base-linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/030 - 1.3 cmd/xfs/stress/common.repair - 1.1 - pull out common code for sharing between repair tests. cmd/xfs/stress/group - 1.26 - add test 033. cmd/xfs/stress/033 - 1.1 cmd/xfs/stress/033.out - 1.1 - exercise repair stitching together destroyed root, rt bitamp & summary inodes. From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:15:51 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:15:41 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17959 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:15:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08912; Wed, 30 Aug 2000 07:20:58 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA84609; Wed, 30 Aug 2000 07:14:31 -0700 (PDT) Date: Wed, 30 Aug 2000 07:14:31 -0700 (PDT) Message-Id: <200008301414.HAA84609@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 07:14:30AM ========================== First off lets confirm the right compiler was used - we really need to fix that issue. Secondly, in order to diagnose this problem we are going to need to be able to run a kernel with kdb turned on and go look at things if this happens again. A thread stuck in this location is prefectly normal in the short term, the trick is to find who in the system is really wedged which is stopping log space from being freed up. From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:17:40 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:17:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29479 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:17:03 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA06093; Wed, 30 Aug 2000 07:22:58 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA93258; Wed, 30 Aug 2000 07:16:32 -0700 (PDT) Date: Wed, 30 Aug 2000 07:16:32 -0700 (PDT) Message-Id: <200008301416.HAA93258@info.engr.sgi.com> X-Pv-Incident: 797457 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 797457 - Swap deadlock bug To: ananth@engr.sgi.com Cc: linux-xfs@oss.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797457 Status : open Priority : 2 *Assigned Engineer : ananth *Assigned Domain : engr Submitter : ananth Project : xfs-linux Assigned Group : xfs-linux Opened Date : 07/27/00 *Modified User : lord *Modified User Domain : sgi.com *Description : In general, the kernel shouldn't be swapping a page from a file on which a write is in progress ... following is a old backtrace but doio-2threads can reproduce the problem at will on a 64MB system. ------------- [1]kdb> btp 569 EBP EIP Function(args) ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 07:16:31AM ========================== Ananth is going to check in a work around for beta. From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:19:40 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:19:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33390 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:19:14 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03478; Wed, 30 Aug 2000 07:11:05 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA18417; Wed, 30 Aug 2000 07:16:57 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA10042; Wed, 30 Aug 2000 07:15:40 -0700 (PDT) Date: Wed, 30 Aug 2000 07:15:40 -0700 (PDT) Message-Id: <200008301415.HAA10042@info.engr.sgi.com> X-Pv-Incident: 800061 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 800061 - HIGHMEM support is broken To: chait@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800061 Status : open Priority : 2 *Assigned Engineer : chait *Assigned Domain : engr Submitter : ananth Project : xfs-linux Assigned Group : xfs-linux Opened Date : 08/24/00 *Modified User : lord *Modified User Domain : sgi.com *Description : There are two problems in handling highmem with XFS: 1. consistent use of kmap/kunmap to get at the address of a page. 2. supporting highmem with kiobufs. I'll check-in a short fix that will check, issue warning, etc. if highmem is turned on. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 07:15:40AM ========================== From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:24:10 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:24:01 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:45935 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:23:45 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA04086 for ; Wed, 30 Aug 2000 07:15:27 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA50805; Wed, 30 Aug 2000 09:21:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA38765; Wed, 30 Aug 2000 09:21:47 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id JAA26400; Wed, 30 Aug 2000 09:16:39 -0500 Message-Id: <200008301416.JAA26400@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: BUG 800480 - xlog_grant_log_space can wait indefinitely In-Reply-To: Message from Thomas Graichen of "30 Aug 2000 06:43:26 GMT." Date: Wed, 30 Aug 2000 09:16:39 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > i might be completely wrong - but the sv_wait thing was once observed > as an gcc 2.95 problem - maybe this is the reason? (just an idea) > > t > This is possible and we will check into it, however, a system built with that compiler tends to do things a lot worse than hang some threads. Other possibilities are that some chunk of metadata at the end of the log is not getting written out for some reason, or we missed a wakeup - although that would not be a permanent hang. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:27:00 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:26:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13608 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:26:33 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04811; Wed, 30 Aug 2000 07:32:27 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA74850; Wed, 30 Aug 2000 07:26:01 -0700 (PDT) Date: Wed, 30 Aug 2000 07:26:01 -0700 (PDT) Message-Id: <200008301426.HAA74850@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 07:26:01AM ========================== So can you confirm that the filesystem is really hung out there, anyone else who touches it gets to block as well? From owner-linux-xfs@oss.sgi.com Wed Aug 30 07:49:11 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 07:49:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17270 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 07:48:40 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA07390; Wed, 30 Aug 2000 07:40:31 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA66596; Wed, 30 Aug 2000 07:46:23 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA35895; Wed, 30 Aug 2000 07:45:06 -0700 (PDT) Date: Wed, 30 Aug 2000 07:45:06 -0700 (PDT) Message-Id: <200008301445.HAA35895@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 *Assigned Engineer : lord Submitter : ananth Project : xfs-linux Assigned Group : xfs-linux Opened Date : 08/29/00 *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 07:45:06AM ========================== From owner-linux-xfs@oss.sgi.com Wed Aug 30 08:08:10 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 08:07:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24620 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 08:07:17 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04928; Wed, 30 Aug 2000 08:13:12 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA59357; Wed, 30 Aug 2000 08:06:16 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA34619; Wed, 30 Aug 2000 08:04:58 -0700 (PDT) Date: Wed, 30 Aug 2000 08:04:58 -0700 (PDT) Message-Id: <200008301504.IAA34619@info.engr.sgi.com> X-Pv-Incident: 800505 webPV: jen.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: BUG 800505 - glibc RPM build failing in XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800505 Submitter : lord Submitter Domain : sgi.com Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 1 Project : xfs-linux Status : open Description : The glibc RPM build is once again failing in an XFS filesystem, not much more information than this is available at the moment, The location of the failure appears to be semi-random. From owner-linux-xfs@oss.sgi.com Wed Aug 30 09:42:13 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 09:42:03 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6454 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 09:41:38 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08947 for ; Wed, 30 Aug 2000 09:47:22 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA73718; Wed, 30 Aug 2000 11:39:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA80184; Wed, 30 Aug 2000 11:39:40 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) via ESMTP id LAA28143; Wed, 30 Aug 2000 11:34:30 -0500 Message-Id: <200008301634.LAA28143@jen.americas.sgi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Graichen , thomas.graichen@innominate.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs on ppc status In-Reply-To: Message from Thomas Graichen of "29 Aug 2000 23:35:44 GMT." Date: Wed, 30 Aug 2000 11:34:30 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > ok - with the last fix from steve xfs on ppc starts to be useable > (but it definitely has bugs) ... for instance the following is > possible: > > [root@aqua /root]# uname -a > Linux aqua 2.4.0-test5 #5 Wed Aug 30 04:08:43 CEST 2000 ppc unknown > [root@aqua /root]# mount ^^^ > /dev/hda8 on / type xfs (rw) <--- > none on /proc type proc (rw) > /dev/hda5 on /boot type hfs (ro) > /dev/hda9 on /home type ext2 (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > [root@aqua /root]# > > so it works quite well (i at least got a 2gb filesystem copied over > to xfs and was able to boot from it :-) ... also the journal replay > code seems to work somehow (got it mounted clean after an unclean > umount) ... but the system did not survive a reboot after the > xfs root experiment ... also i still get invalid inode numbers > (it started at the end of copying the disk over which is close > to completely full) at > > aqua kernel: XFS assertion failed: xfs_dir_ino_validate(mp, > INT_GET(dep->inumber, ARCH_CONVERT)) == 0, file: xfs_dir2_data.c, > line: 175 > > which is: > > ASSERT(xfs_dir_ino_validate(mp, INT_GET(dep->inumber, ARCH_CONVERT)) == 0); > > in xfs_dir2_data.c (btw. i have changed asserts to not result in > a BUG() ) All I can say here is that with debug turned on this function is called all over the place to scan all the entries in a directory and validate their consistency. The xfs_dir_ino_validate function will print out the offending inode number (as a 64 bit hex number), could you possibly modify this to be just a printk and capture the offending number. > > one thing related to this seems to be that the root-dir of the > xfs filesystem does not have a ".." entry visible (but like with > the test entry in the last weeks it's there) Are you saying not visible from user space, or not visible from xfs_db? I would not be surprised if there is not another endian conversion macro where the wrong half of a 64 bit value is being copied around in the big endian case. > > also now it would be really good to have a working non-sim > xfs_repair ... Does the non-sim version build on the ppc? If it does then xfs_repair -n output would be a good thing to see. Steve From owner-linux-xfs@oss.sgi.com Wed Aug 30 09:50:13 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 09:50:03 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21278 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 09:49:49 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA25084; Wed, 30 Aug 2000 09:41:41 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA06192; Wed, 30 Aug 2000 09:49:18 -0700 (PDT) Date: Wed, 30 Aug 2000 09:49:18 -0700 (PDT) Message-Id: <200008301649.JAA06192@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: sgigate.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (ananth@engr.sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : ananth *Modified User Domain : engr *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: ananth@engr (BugWorks) Date: Aug 30 2000 09:49:17AM ========================== Here's the mail from Jalal who builds the images: ---------- > > An issue came about just a little while back > regarding the c compiler used for > the experimental builds. Can you please > tell me what version is being used? > > thanks! > > ananth. usr/bin/cc is from RedHat-6.2 egcs-1.1.2-30.i386.rpm. mkchrootdir-6.2 scripts sets the chroot env. It is located under /hosts/bonnie.engr/proj/sgilinux/1.4/isms/linuxmeister/dev1.4. Jalal --------------- kdb is installed on the system; that's the source of the backtrace. I didn't have serial console at that time, so the backtrace was written down "by hand". Finally, I attempted a "du" on a workarea on the filesystem when the "rm" was hung. The du hung as well; sorry the backtrace of du was not noted. Neither were short-term hangs. The rm, in particular, was hung for more than 10 minutes (perhaps even 1/2 hour). ananth. From owner-linux-xfs@oss.sgi.com Wed Aug 30 09:58:23 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 09:58:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 09:57:52 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02503; Wed, 30 Aug 2000 10:03:46 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA33295; Wed, 30 Aug 2000 09:57:20 -0700 (PDT) Date: Wed, 30 Aug 2000 09:57:20 -0700 (PDT) Message-Id: <200008301657.JAA33295@info.engr.sgi.com> X-Pv-Incident: 800480 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: ADD 800480 - xlog_grant_log_space can wait indefinitely To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480 Status : open Priority : 2 Assigned Engineer : lord Submitter : ananth *Modified User : lord *Modified User Domain : sgi.com *Description : We have a semi-production build machine that is running XFS bits as of 8/23/00. I have seen things like "rm" getting into the following backtrace: --------- schedule+0x415 _sv_wait+0xcd xlog_grant_log_space+0x139 xfs_log_reserve+0x7b xfs_trans_reserve+0x76 ..... ========================== ADDITIONAL INFORMATION (ADD) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 09:57:20AM ========================== So is there a serial console now? and if so how can I get to it should we have a reoccurance? From owner-linux-xfs@oss.sgi.com Wed Aug 30 12:48:33 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 12:48:22 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37200 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 12:47:55 -0700 Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA00458 for ; Wed, 30 Aug 2000 12:53:45 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id OAA20871 for linux-xfs@oss.sgi.com; Wed, 30 Aug 2000 14:46:00 -0500 (CDT) Date: Wed, 30 Aug 2000 14:46:00 -0500 (CDT) From: Dean Roehrich Message-Id: <200008301946.OAA20871@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 799138 - dmapi fix for pv 799138 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing apply fix from irix Modid: 2.4.0-test1-xfs:slinx:73307a Date: Wed Aug 30 12:45:42 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs2 SPRs closed: Severity: Minor Modtype: Bugfix Test Description: blah Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/xfs_dmapi.c - 1.22 - fix for pv 799138 From owner-linux-xfs@oss.sgi.com Wed Aug 30 13:26:03 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 13:25:53 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10069 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 13:25:24 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA06077; Wed, 30 Aug 2000 13:31:08 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA55304; Wed, 30 Aug 2000 13:24:43 -0700 (PDT) Date: Wed, 30 Aug 2000 13:24:43 -0700 (PDT) Message-Id: <200008302024.NAA55304@info.engr.sgi.com> X-Pv-Incident: 800505 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: UPDATE 800505 - Data corruption seen in XFS To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800505 *Summary : Data corruption seen in XFS Status : open Priority : 1 Assigned Engineer : nb Submitter : lord Opened Date : 08/30/00 *Modified User : lord *Modified User Domain : sgi.com *Description : The glibc RPM build is once again failing in an XFS filesystem, not much more information than this is available at the moment, The location of the failure appears to be semi-random. ========================== ADDITIONAL INFORMATION (UPDATE) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 01:24:42PM ========================== Changing title to indicate the fact that this is a data corruption issue. Also, I have reproduced the problem a couple of times via doio, a mmaped write always seems to be involved in this case. From owner-linux-xfs@oss.sgi.com Wed Aug 30 14:48:43 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 14:48:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17268 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 14:48:18 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA10736; Wed, 30 Aug 2000 14:40:39 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA16192; Wed, 30 Aug 2000 14:47:46 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA66463; Wed, 30 Aug 2000 14:46:30 -0700 (PDT) Date: Wed, 30 Aug 2000 14:46:30 -0700 (PDT) Message-Id: <200008302146.OAA66463@info.engr.sgi.com> X-Pv-Incident: 800505 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 800505 - Data corruption seen in XFS To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800505 Status : open Priority : 1 *Assigned Engineer : lord Submitter : lord Project : xfs-linux Assigned Group : xfs-linux Opened Date : 08/30/00 *Modified User : lord *Modified User Domain : sgi.com *Description : The glibc RPM build is once again failing in an XFS filesystem, not much more information than this is available at the moment, The location of the failure appears to be semi-random. ========================== ADDITIONAL INFORMATION (UPDATE) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 01:24:42PM ========================== ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 02:46:29PM ========================== Reassign, managers don't do PV's. Also, we appear to be making some progress, first there is more than one bug here. The write full page function is broken, so dirty data is not always swapped out correctly. A fix for this will be along shortly. Secondly, a copy of a file several times bigger than system memory can generate corruption within the file which appears consistent with some data being discarded before being written to disk. In this case kiocluster appears to be necessary to cause corruption. From owner-linux-xfs@oss.sgi.com Wed Aug 30 20:06:15 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 20:06:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39732 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 20:05:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA12417 for ; Wed, 30 Aug 2000 19:58:07 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA21277 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 14:04:27 +1100 (EST) Date: Thu, 31 Aug 2000 14:04:27 +1100 (EST) From: Daniel Moore Message-Id: <200008310304.OAA21277@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing various qa bits Modid: 2.4.0-test1-xfs:slinx:73355a Date: Wed Aug 30 20:04:15 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/016 - 1.3 - use devzero cmd/xfs/stress/016.out - 1.2 - output from 016 cmd/xfs/stress/common.rc - 1.22 - change bruce partitions cmd/xfs/stress/crash/xfscrash - 1.4 - fixups cmd/xfs/stress/group - 1.27 - add "auto" group for auto-qa cmd/xfs/tools/auto-qa - 1.1 - automatic qa script. From owner-linux-xfs@oss.sgi.com Wed Aug 30 20:32:34 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 20:32:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:37431 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 20:32:05 -0700 Received: from bruce.melbourne.sgi.com (root@bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA14065 for ; Wed, 30 Aug 2000 20:24:25 -0700 (PDT) mail_from (dxm@bruce.melbourne.sgi.com) Received: (from dxm@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id OAA20314 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 14:30:16 +1100 Date: Thu, 31 Aug 2000 14:30:16 +1100 From: Daniel Moore Message-Id: <200008310330.OAA20314@bruce.melbourne.sgi.com> Subject: TAKE - xfs qa bits To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing more bits Date: Wed Aug 30 20:29:03 PDT 2000 Workarea: bruce.melbourne.sgi.com:/home/dxm/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73357a cmd/xfs/stress/018.out - 1.3 cmd/xfs/stress/019.out - 1.4 cmd/xfs/stress/019 - 1.7 - No Message Supplied cmd/xfs/stress/src/devzero.c - 1.5 - add -c (create) and -t (truncate) options and make a little less specific to devices. From owner-linux-xfs@oss.sgi.com Wed Aug 30 21:46:36 2000 Received: by oss.sgi.com id ; Wed, 30 Aug 2000 21:46:26 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24435 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 30 Aug 2000 21:46:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA07933 for ; Wed, 30 Aug 2000 21:52:30 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA47263 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 15:44:39 +1100 (EST) Date: Thu, 31 Aug 2000 15:44:39 +1100 (EST) From: Daniel Moore Message-Id: <200008310444.PAA47263@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing yet more qa bits Modid: 2.4.0-test1-xfs:slinx:73360a Date: Wed Aug 30 21:44:23 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/stress/017 - 1.3 - avoid RESVSP and UNRESVSP. they tickle another bug and we're not testing them anyway. cmd/xfs/stress/017.out - 1.2 cmd/xfs/stress/019.out - 1.5 cmd/xfs/stress/group - 1.28 - . cmd/xfs/tools/auto-qa - 1.2 - various mods From owner-linux-xfs@oss.sgi.com Thu Aug 31 07:04:31 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 07:04:21 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50951 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 07:04:06 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA24149 for ; Thu, 31 Aug 2000 06:56:28 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA95458 for ; Thu, 31 Aug 2000 09:02:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id JAA31008 for ; Thu, 31 Aug 2000 09:02:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.6c) id IAA04838; Thu, 31 Aug 2000 08:57:29 -0500 Message-Id: <200008311357.IAA04838@jen.americas.sgi.com> Date: Thu, 31 Aug 2000 08:57:29 -0500 Subject: TAKE - kernel uuid code cleanup To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Aug 31 07:02:32 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73370a linux/fs/xfs/linux/xfs_uuid.c - 1.20 - Kill some dead uuid code, and remove the JIMJIM string from the kernel generated uuids, if it cannot get an ethernet address to take content from it will use random data. From owner-linux-xfs@oss.sgi.com Thu Aug 31 11:18:41 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 11:18:32 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:53846 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 11:18:08 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA00976; Thu, 31 Aug 2000 11:10:30 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA46468; Thu, 31 Aug 2000 11:16:49 -0700 (PDT) Date: Thu, 31 Aug 2000 11:16:49 -0700 (PDT) Message-Id: <200008311816.LAA46468@feature.engr.sgi.com> X-Pv-Incident: 800505 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: PARTIAL TAKE 800505 - Data corruption seen in XFS To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord Status : open Assigned Engineer : lord Priority : 1 *Modified Date : 08/31/00 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : From: steve lord (PARTIAL) Date: Aug 31 2000 11:16:49AM [pvnews version: 1.71] ---------------------------- At least one more to go - which may be restricted to the kiocluster mount option. Date: Wed Aug 30 14:54:03 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73324a linux/fs/xfs/linux/xfs_iops.c - 1.65 - linvfs_write_full_page had a case where it did not write data and returned success. This appears to be a result of cutting and pasting too much code from the read_full_page case. This could only happen if we tried to swap pages out from the file whilst another thread was doing file I/O. Description : The glibc RPM build is once again failing in an XFS filesystem, not much more information than this is available at the moment, The location of the failure appears to be semi-random. ========================== ADDITIONAL INFORMATION (UPDATE) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 01:24:42PM ========================== ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 02:46:29PM ========================== Reassign, managers don't do PV's. Also, we appear to be making some progress, first there is more than one bug here. The write full page function is broken, so dirty data is not always swapped out correctly. A fix for this will be along shortly. Secondly, a copy of a file several times bigger than system memory can generate corruption within the file which appears consistent with some data being discarded before being written to disk. In this case kiocluster appears to be necessary to cause corruption. From owner-linux-xfs@oss.sgi.com Thu Aug 31 12:12:42 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 12:12:22 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:35689 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 12:11:58 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA08917 for ; Thu, 31 Aug 2000 12:04:20 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA29134 for ; Thu, 31 Aug 2000 12:11:27 -0700 (PDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id OAA01290 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 14:08:48 -0500 (CDT) Date: Thu, 31 Aug 2000 14:08:48 -0500 (CDT) From: Dean Roehrich Message-Id: <200008311908.OAA01290@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix unresolved symbol in dmapi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing fix unresolved symbol in dmapi, around a switch on an loff_t. I dunno, but going with 'if' instead makes it go away. Modid: 2.4.0-test1-xfs:slinx:73408a Date: Thu Aug 31 12:08:39 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs2 SPRs closed: NONE Severity: Minor Modtype: Bugfix Test Description: built and loaded the module Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/dmapi/dmapi_sysent.c - 1.3 - get around a runtime link error From owner-linux-xfs@oss.sgi.com Thu Aug 31 12:13:52 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 12:13:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:3434 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 12:13:28 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09141 for ; Thu, 31 Aug 2000 12:05:50 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA55645 for ; Thu, 31 Aug 2000 12:12:57 -0700 (PDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id OAA11682 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 14:10:19 -0500 (CDT) Date: Thu, 31 Aug 2000 14:10:19 -0500 (CDT) From: Dean Roehrich Message-Id: <200008311910.OAA11682@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - supress some compiler warnings in dmapi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing supress some compiler warnings in dmapi Modid: 2.4.0-test1-xfs:slinx:73410a Date: Thu Aug 31 12:10:13 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs2 SPRs closed: NONE Severity: Minor Modtype: Bugfix Test Description: built, loaded. Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs linux/fs/xfs/dmapi/dmapi_private.h - 1.3 - move an include, to suppress a compiler warning From owner-linux-xfs@oss.sgi.com Thu Aug 31 14:32:32 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 14:32:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33872 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 14:31:47 -0700 Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.84.70]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06562 for ; Thu, 31 Aug 2000 14:38:12 -0700 (PDT) mail_from (roehrich@clink.americas.sgi.com) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3) id QAA08454 for linux-xfs@oss.sgi.com; Thu, 31 Aug 2000 16:30:28 -0500 (CDT) Date: Thu, 31 Aug 2000 16:30:28 -0500 (CDT) From: Dean Roehrich Message-Id: <200008312130.QAA08454@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - switch libdm to cmd includes rather than kernel includes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Switch libdm to cmd includes rather than kernel includes. This also cleans up pages of compiler warnings. Modid: 2.4.0-test1-xfs:slinx:73450a Date: Thu Aug 31 14:30:03 PDT 2000 Workarea: clink.americas.sgi.com:/data/clink/a/roehrich/2.4.0-test1-xfs2 SPRs closed: NONE Severity: Minor Modtype: Bugfix Test Description: built Keywords: NONE Requested reviewer(s): Author: roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/libdm/Construct - 1.2 - use cmd/xfs/include instead of going to the kernel includes cmd/xfs/libdm/dm_attr.c - 1.3 cmd/xfs/libdm/dm_bulkattr.c - 1.3 cmd/xfs/libdm/dm_config.c - 1.3 cmd/xfs/libdm/dm_dmattr.c - 1.3 cmd/xfs/libdm/dm_event.c - 1.3 cmd/xfs/libdm/dm_handle.c - 1.3 - add cmd/xfs/libdm/dm_handle2path.c - 1.3 - - add - use getdents rather than ngetdents64 cmd/xfs/libdm/dm_hole.c - 1.3 cmd/xfs/libdm/dm_mountinfo.c - 1.3 cmd/xfs/libdm/dm_rdwr.c - 1.3 cmd/xfs/libdm/dm_region.c - 1.3 cmd/xfs/libdm/dm_right.c - 1.3 cmd/xfs/libdm/dm_session.c - 1.3 cmd/xfs/libdm/linux/dmapi_lib.c - 1.3 cmd/xfs/libdm/tests/dm_create_session.c - 1.3 cmd/xfs/libdm/tests/dm_destroy_session.c - 1.3 cmd/xfs/libdm/tests/dm_find_eventmsg.c - 1.3 cmd/xfs/libdm/tests/dm_getall_sessions.c - 1.3 cmd/xfs/libdm/tests/dm_getall_tokens.c - 1.3 cmd/xfs/libdm/tests/dm_query_session.c - 1.3 - add From owner-linux-xfs@oss.sgi.com Thu Aug 31 14:46:53 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 14:46:43 -0700 Received: from [134.6.67.21] ([134.6.67.21]:34316 "EHLO mcoexc03.mlm.maxtor.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 14:46:14 -0700 Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 15:44:21 -0600 Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C02536F84@mcaexc01.msj.maxtor.com> From: "Davida, Joe" To: "'linux-xfs@oss.sgi.com'" Subject: 2 Terabyte File System Size Limitation Date: Thu, 31 Aug 2000 15:44:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Is there any information on the 2 TBytes file system limitation in Linux which is also inherited by the linux port of xfs? What imposes this limitation? Are the current efforts aimed at removing this limitation? I hear ReiserFS has a 16 Terabyte file system size. Cheers, Joe From owner-linux-xfs@oss.sgi.com Thu Aug 31 16:49:34 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 16:49:24 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29276 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 16:49:02 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06844; Thu, 31 Aug 2000 16:55:28 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA78494; Thu, 31 Aug 2000 16:49:01 -0700 (PDT) Date: Thu, 31 Aug 2000 16:49:01 -0700 (PDT) Message-Id: <200008312349.QAA78494@info.engr.sgi.com> X-Pv-Incident: 800728 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800728 - repair makes bad memory access in dir2 checks To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800728 Submitter : nathans Submitter Domain : engr Assigned Engineer : nathans Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : I've been hunting this bug down for a couple of days now, and have finally reproduced it reliably. The problem exists in all versions of repair. libefence was critical in finding this... an access past the end of some malloc'd memory. first - populate a prototype file with 1000 root ino entries, as in QA test 030, then... stress$ sudo ../sim/mkfs/mkfs_xfs -f -p /tmp/proto1000 /dev/hda7 xfs: using dummy primary network address meta-data=/dev/hda7 isize=256 agcount=8, agsize=31878 blks data = bsize=4096 blocks=255023, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 stress$ sudo gdb ../sim/repair/xfs_repair GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run /dev/hda7 Starting program: /home/nathans/isms/linux-xfs/cmd/xfs/stress/../sim/repair/xfs_repair /dev/hda7 Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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) ... # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... Program received signal SIGSEGV, Segmentation fault. 0x807e368 in longform_dir2_entry_check_data (mp=0x4015acac, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, current_irec=0x40365fcc, current_ino_offset=0, bpp=0xbffff534, hashtab=0x404b4ffc, freetabp=0xbffff528, da_bno=0, isblock=0) at phase6.c:1879 1879 if (ptr + XFS_DIR2_DATA_ENTSIZE(dep->namelen) > endptr) (gdb) where #0 0x807e368 in longform_dir2_entry_check_data (mp=0x4015acac, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, current_irec=0x40365fcc, current_ino_offset=0, bpp=0xbffff534, hashtab=0x404b4ffc, freetabp=0xbffff528, da_bno=0, isblock=0) at phase6.c:1879 #1 0x80820c3 in longform_dir2_entry_check (mp=0x4015acac, ino=128, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, irec=0x40365fcc, ino_offset=0) at phase6.c:2712 #2 0x80841d3 in process_dirstack (mp=0x4015acac, stack=0xbffff688) at phase6.c:3546 #3 0x808559d in phase6 (mp=0x4015acac) at phase6.c:3974 #4 0x808f90c in main (argc=2, argv=0xbffffad4) at xfs_repair.c:604 (gdb) l 1874 (char *)dup - (char *)d) 1875 break; 1876 ptr += INT_GET(dup->length, ARCH_CONVERT); 1877 } 1878 dep = (xfs_dir2_data_entry_t *)ptr; 1879 if (ptr + XFS_DIR2_DATA_ENTSIZE(dep->namelen) > endptr) 1880 break; 1881 if (INT_GET(*XFS_DIR2_DATA_ENTRY_TAG_P(dep), ARCH_CONVERT) != (char *)dep - (char *)d) 1882 break; 1883 ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); (gdb) p ptr $1 = 0x403cf000
(gdb) call __fswab16(dup->length) $3 = 32 (gdb) p dup $4 = (xfs_dir2_data_unused_t *) 0x403cefe0 (gdb) p *dup $5 = {freetag = 65535, length = 8192, tag = 0} (gdb) The "+=" on 1876 puts us right at the start of the memory _after_ the end of our malloc'd region (i.e. endptr), which is OK as long as we don't dereference it (but on 1879 we do). From owner-linux-xfs@oss.sgi.com Thu Aug 31 17:14:53 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 17:14:44 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43319 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 17:14:26 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA15723; Thu, 31 Aug 2000 17:06:48 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: from feature.engr.sgi.com ([130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA99987; Thu, 31 Aug 2000 17:12:40 -0700 (PDT) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA58427; Thu, 31 Aug 2000 17:10:04 -0700 (PDT) Date: Thu, 31 Aug 2000 17:10:04 -0700 (PDT) Message-Id: <200009010010.RAA58427@feature.engr.sgi.com> X-Pv-Incident: 800728 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com) Subject: TAKE 800728 - repair makes bad memory access in dir2 checks To: nathans@cthulhu.engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : nathans *Status : closed Assigned Engineer : nathans *Fixed By : nathans *Fixed By Domain : engr *Closed Date : 08/31/00 Priority : 2 *Modified Date : 08/31/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathan scott (TAKE) Date: Aug 31 2000 05:10:03PM [pvnews version: 1.71] ---------------------------- Modid: 2.4.0-test1-xfs:slinx:73464a Date: Thu Aug 31 17:07:32 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/repair/phase2.c - 1.28 - for internal logs, use data device fd for zeroing. revert spaces back to tabs (cosmetic). cmd/xfs/repair/phase6.c - 1.57 - fix bad memory access - see bug 800728. Description : I've been hunting this bug down for a couple of days now, and have finally reproduced it reliably. The problem exists in all versions of repair. libefence was critical in finding this... an access past the end of some malloc'd memory. first - populate a prototype file with 1000 root ino entries, as in QA test 030, then... stress$ sudo ../sim/mkfs/mkfs_xfs -f -p /tmp/proto1000 /dev/hda7 xfs: using dummy primary network address meta-data=/dev/hda7 isize=256 agcount=8, agsize=31878 blks data = bsize=4096 blocks=255023, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 stress$ sudo gdb ../sim/repair/xfs_repair GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run /dev/hda7 Starting program: /home/nathans/isms/linux-xfs/cmd/xfs/stress/../sim/repair/xfs_repair /dev/hda7 Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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) ... # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) # of bmap records in inode 128 greater than max (4096, max - 254) - 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... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... Program received signal SIGSEGV, Segmentation fault. 0x807e368 in longform_dir2_entry_check_data (mp=0x4015acac, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, current_irec=0x40365fcc, current_ino_offset=0, bpp=0xbffff534, hashtab=0x404b4ffc, freetabp=0xbffff528, da_bno=0, isblock=0) at phase6.c:1879 1879 if (ptr + XFS_DIR2_DATA_ENTSIZE(dep->namelen) > endptr) (gdb) where #0 0x807e368 in longform_dir2_entry_check_data (mp=0x4015acac, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, current_irec=0x40365fcc, current_ino_offset=0, bpp=0xbffff534, hashtab=0x404b4ffc, freetabp=0xbffff528, da_bno=0, isblock=0) at phase6.c:1879 #1 0x80820c3 in longform_dir2_entry_check (mp=0x4015acac, ino=128, ip=0x4034fe5c, num_illegal=0xbffff60c, need_dot=0xbffff618, stack=0xbffff688, irec=0x40365fcc, ino_offset=0) at phase6.c:2712 #2 0x80841d3 in process_dirstack (mp=0x4015acac, stack=0xbffff688) at phase6.c:3546 #3 0x808559d in phase6 (mp=0x4015acac) at phase6.c:3974 #4 0x808f90c in main (argc=2, argv=0xbffffad4) at xfs_repair.c:604 (gdb) l 1874 (char *)dup - (char *)d) 1875 break; 1876 ptr += INT_GET(dup->length, ARCH_CONVERT); 1877 } 1878 dep = (xfs_dir2_data_entry_t *)ptr; 1879 if (ptr + XFS_DIR2_DATA_ENTSIZE(dep->namelen) > endptr) 1880 break; 1881 if (INT_GET(*XFS_DIR2_DATA_ENTRY_TAG_P(dep), ARCH_CONVERT) != (char *)dep - (char *)d) 1882 break; 1883 ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); (gdb) p ptr $1 = 0x403cf000
(gdb) call __fswab16(dup->length) $3 = 32 (gdb) p dup $4 = (xfs_dir2_data_unused_t *) 0x403cefe0 (gdb) p *dup $5 = {freetag = 65535, length = 8192, tag = 0} (gdb) The "+=" on 1876 puts us right at the start of the memory _after_ the end of our malloc'd region (i.e. endptr), which is OK as long as we don't dereference it (but on 1879 we do). From owner-linux-xfs@oss.sgi.com Thu Aug 31 17:34:04 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 17:33:54 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24635 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 17:33:40 -0700 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA17663 for ; Thu, 31 Aug 2000 17:26:02 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.9.3/8.9.3) id RAA13245; Thu, 31 Aug 2000 17:33:32 -0700 Date: Thu, 31 Aug 2000 17:33:32 -0700 From: Ananth Ananthanarayanan Message-Id: <200009010033.RAA13245@waco.engr.sgi.com> Subject: TAKE 800505 - fix corruption To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes known corruption problems with respect to large cp's and rpm builds. Also tested with doio 1- and 2-threads. Date: Thu Aug 31 17:28:57 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73466a linux/fs/pagebuf/page_buf.c - 1.26 - Fix a problem where kiobuf I/O assumptions were being violated; that is, a READ with some valid pages will erase recent data contained only in the in-memory version of the valid pages. Also support clustered pages which are locked on lookup. linux/fs/pagebuf/page_buf_io.c - 1.27 - Fix a bug where if the clustering was stopped because of reaching the tuneable count, the last selected pages was left out of the I/O. Also, support lock pages to be clustered on lookup, closing holes between lookup and start of I/O. From owner-linux-xfs@oss.sgi.com Thu Aug 31 17:36:53 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 17:36:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51259 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 17:36:22 -0700 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA17885; Thu, 31 Aug 2000 17:28:44 -0700 (PDT) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA59081; Thu, 31 Aug 2000 17:35:03 -0700 (PDT) Date: Thu, 31 Aug 2000 17:35:03 -0700 (PDT) Message-Id: <200009010035.RAA59081@feature.engr.sgi.com> X-Pv-Incident: 800505 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ananth@engr.sgi.com) Subject: TAKE 800505 - Data corruption seen in XFS To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : lord *Status : closed Assigned Engineer : lord *Fixed By : ananth *Fixed By Domain : engr *Closed Date : 08/31/00 Priority : 1 *Modified Date : 08/31/00 *Modified User : ananth *Modified User Domain : engr *Fix Description : From: steve lord (PARTIAL) Date: Aug 31 2000 11:16:49AM [pvnews version: 1.71] ---------------------------- At least one more to go - which may be restricted to the kiocluster mount option. Date: Wed Aug 30 14:54:03 PDT 2000 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4.0-test5 ..... ========================== ADDITIONAL INFORMATION (TAKE) From: ananth ananthanarayanan Date: Aug 31 2000 05:35:03PM [pvnews version: 1.71] ========================== This fixes known corruption problems with respect to large cp's and rpm builds. Also tested with doio 1- and 2-threads. Date: Thu Aug 31 17:28:57 PDT 2000 Workarea: waco.engr.sgi.com:/build1/ananth/xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs Modid: 2.4.0-test1-xfs:slinx:73466a linux/fs/pagebuf/page_buf.c - 1.26 - Fix a problem where kiobuf I/O assumptions were being violated; that is, a READ with some valid pages will erase recent data contained only in the in-memory version of the valid pages. Also support clustered pages which are locked on lookup. linux/fs/pagebuf/page_buf_io.c - 1.27 - Fix a bug where if the clustering was stopped because of reaching the tuneable count, the last selected pages was left out of the I/O. Also, support lock pages to be clustered on lookup, closing holes between lookup and start of I/O. Description : The glibc RPM build is once again failing in an XFS filesystem, not much more information than this is available at the moment, The location of the failure appears to be semi-random. ========================== ADDITIONAL INFORMATION (UPDATE) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 01:24:42PM ========================== ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Aug 30 2000 02:46:29PM ========================== Reassign, managers don't do PV's. Also, we appear to be making some progress, first there is more than one bug here. The write full page function is broken, so dirty data is not always swapped out correctly. A fix for this will be along shortly. Secondly, a copy of a file several times bigger than system memory can generate corruption within the file which appears consistent with some data being discarded before being written to disk. In this case kiocluster appears to be necessary to cause corruption. From owner-linux-xfs@oss.sgi.com Thu Aug 31 17:45:54 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 17:45:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21856 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 17:45:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA06198 for ; Thu, 31 Aug 2000 17:52:08 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA51478 for linux-xfs@oss.sgi.com; Fri, 1 Sep 2000 11:43:08 +1100 (EST) Date: Fri, 1 Sep 2000 11:43:08 +1100 (EST) From: Daniel Moore Message-Id: <200009010043.LAA51478@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - db 0 sized mem alloc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing keep efence happy. Any more Nathan? my QA runs ok with efence... Modid: 2.4.0-test1-xfs:slinx:73468a Date: Thu Aug 31 17:42:15 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/io.c - 1.27 - remove malloc(0) From owner-linux-xfs@oss.sgi.com Thu Aug 31 17:53:24 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 17:53:04 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:19262 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 17:52:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA19160 for ; Thu, 31 Aug 2000 17:45:15 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07027 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 1 Sep 2000 11:51:36 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA20850; Fri, 1 Sep 2000 11:51:32 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009011151.ZM20876@wobbly.melbourne.sgi.com> Date: Fri, 1 Sep 2000 11:51:30 -0400 In-Reply-To: Daniel Moore "TAKE - db 0 sized mem alloc" (Sep 1, 11:46am) References: <200009010043.LAA51478@snort.melbourne.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: TAKE - db 0 sized mem alloc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sep 1, 11:46am, Daniel Moore wrote: > Subject: TAKE - db 0 sized mem alloc > keep efence happy. > > Any more Nathan? my QA runs ok with efence... > I've seen logprint die too - QA 018... $ gdb `which xfs_logprint` 018.core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_logprint /dev/hda6'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x400790cd in bcopy (src=0x40116fd8, dest=0xbffff698, len=52) at ../sysdeps/generic/memmove.c:72 72 ../sysdeps/generic/memmove.c: No such file or directory. (gdb) where #0 0x400790cd in bcopy (src=0x40116fd8, dest=0xbffff698, len=52) at ../sysdeps/generic/memmove.c:72 #1 0x804e292 in xlog_print_trans_inode (ptr=0xbffff794, len=40, i=0xbffff780, num_ops=234) at log_misc.c:562 #2 0x804eea9 in xlog_print_record (fd=3, num_ops=234, len=32256, read_type=0xbffff7e0, partial_buf=0xbffff7dc, rhead=0xbffff80c) at log_misc.c:820 #3 0x804f59c in xfs_log_print (log=0xbffffa2c, fd=3, print_block_start=-1, flags=0) at log_misc.c:995 #4 0x80504a5 in main (argc=2, argv=0xbffffae4) at logprint.c:241 (gdb) q cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 31 18:17:44 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 18:17:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24130 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 18:17:27 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA21325; Thu, 31 Aug 2000 18:09:49 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA62621; Thu, 31 Aug 2000 18:15:41 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA79282; Thu, 31 Aug 2000 18:14:22 -0700 (PDT) Date: Thu, 31 Aug 2000 18:14:22 -0700 (PDT) Message-Id: <200009010114.SAA79282@info.engr.sgi.com> X-Pv-Incident: 800493 webPV: clouds.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 800493 - xfs_db suspect memory allocation To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800493 *Status : closed Priority : 3 Assigned Engineer : dxm Submitter : nathans Opened Date : 08/29/00 *Closed Date : 08/31/00 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 08/31/00 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Aug 31 2000 06:14:20PM ========================== Modid: 2.4.0-test1-xfs:slinx:73468a Date: Thu Aug 31 17:42:15 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/db/io.c - 1.27 - remove malloc(0) From owner-linux-xfs@oss.sgi.com Thu Aug 31 18:19:24 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 18:19:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:52065 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 18:19:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA04552 for ; Thu, 31 Aug 2000 18:25:27 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA85251 for linux-xfs@oss.sgi.com; Fri, 1 Sep 2000 12:16:27 +1100 (EST) Date: Fri, 1 Sep 2000 12:16:27 +1100 (EST) From: Daniel Moore Message-Id: <200009010116.MAA85251@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - logprint efence-ive behaviour Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing stop coredump in QA 018 with efence Modid: 2.4.0-test1-xfs:slinx:73471a Date: Thu Aug 31 18:15:45 PDT 2000 Workarea: snort:/build1/people/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/logprint/log_misc.c - 1.69 - protect xlog_print_trans_inode from input parameter smaller than xfs_inode_log_format_t From owner-linux-xfs@oss.sgi.com Thu Aug 31 21:52:55 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 21:52:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:52575 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 21:52:39 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA06419; Thu, 31 Aug 2000 21:45:00 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA79011; Thu, 31 Aug 2000 21:50:52 -0700 (PDT) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id VAA83145; Thu, 31 Aug 2000 21:49:35 -0700 (PDT) Date: Thu, 31 Aug 2000 21:49:35 -0700 (PDT) Message-Id: <200009010449.VAA83145@info.engr.sgi.com> X-Pv-Incident: 800752 webPV: wobbly.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: BUG 800752 - repair core dump in scanfunc_bno To: nathans@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800752 Submitter : nathans Submitter Domain : engr Assigned Engineer : nathans Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 2 Project : xfs-linux Status : open Description : QA 030 fails for me now - repair dumping core. Happens with both the libsim version and the new version with writes back on, so isn't a new problem... I'm going to checkin my changes despite this one & will look into this and the other remaining xfs_repair bug (test 031) early next week... $ sudo gdb /usr/sbin/xfs_repair ./030.core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `xfs_repair /dev/hda6'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x808ac6b in scanfunc_bno (ablock=0x401ae000, level=0, bno=1, agno=0, suspect=0, isroot=1) at scan.c:555 555 if (get_agbno_state(mp, agno, b) (gdb) where #0 0x808ac6b in scanfunc_bno (ablock=0x401ae000, level=0, bno=1, agno=0, suspect=0, isroot=1) at scan.c:555 #1 0x80882bd in scan_sbtree (root=1, nlevels=1, agno=0, suspect=0, func=0x808a49c , isroot=1) at scan.c:125 #2 0x808e316 in scan_ag (agno=0) at scan.c:1236 #3 0x806ce19 in phase2 (mp=0x4015acac, simargs=0xbffffa10) at phase2.c:158 #4 0x808f8b2 in main (argc=2, argv=0xbffffae4) at xfs_repair.c:584 (gdb) From owner-linux-xfs@oss.sgi.com Thu Aug 31 22:10:34 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 22:10:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62049 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 22:10:11 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA07527 for ; Thu, 31 Aug 2000 22:02:31 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08093; Fri, 1 Sep 2000 16:08:52 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA21314; Fri, 1 Sep 2000 16:08:51 +1100 (EDT) From: "Nathan Scott" Message-Id: <10009011608.ZM21369@wobbly.melbourne.sgi.com> Date: Fri, 1 Sep 2000 16:08:49 -0400 In-Reply-To: Steve Lord "Re: xfs on ppc status" (Aug 31, 3:45am) References: <200008301634.LAA28143@jen.americas.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Thomas Graichen , thomas.graichen@innominate.de Subject: Re: xfs on ppc status Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Thomas, On Aug 31, 3:45am, Steve Lord wrote: > Subject: Re: xfs on ppc status > > > > also now it would be really good to have a working non-sim > > xfs_repair ... > > Does the non-sim version build on the ppc? If it does then xfs_repair -n > output would be a good thing to see. > The output from xfs_check might provide some insight also. I'm not sure that a "working non-sim xfs_repair" is going to prove useful yet - the part which doesn't work currently is the write path & since repair shares much of this code with the kernel, anything broken in the kernel already is quite likely to also be broken in repair. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Aug 31 22:28:25 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 22:28:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63084 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 22:27:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA07565 for ; Thu, 31 Aug 2000 22:34:04 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA03966 for linux-xfs@oss.sgi.com; Fri, 1 Sep 2000 16:26:13 +1100 (EST) Date: Fri, 1 Sep 2000 16:26:13 +1100 (EST) From: Nathan Scott Message-Id: <200009010526.QAA03966@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libxfs/repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This switches writes back on in xfs_repair. There are still a couple of known bugs in repair, but these exist in both libsim and libxfs versions, so I figure its safe to check this in... Requires a "make clean; make" in libxfs, mkfs and repair. cheers. Modid: 2.4.0-test1-xfs:slinx:73479a Date: Thu Aug 31 22:21:11 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/include/libxfs.h - 1.12 - changes required to do real transactions. cmd/xfs/include/xfs_buf_item.h - 1.2 - make BLI flags visible to userspace. cmd/xfs/include/xfs_inode_item.h - 1.3 - make ILI flags visible to userspace. cmd/xfs/include/xfs_trans.h - 1.4 - make additional types visible to userspace for transactions. cmd/xfs/libxfs/Makefile - 1.5 - add couple of new files to implement real transactions. split kernel.c into xfs_mount.c and xfs_trans.c. cmd/xfs/libxfs/init.c - 1.8 - couple of new zones need initializing for transactions. cmd/xfs/libxfs/rdwr.c - 1.13 - changes required to do real transactions. cmd/xfs/libxfs/util.c - 1.3 - xfs_iflush_fork moved back to xfs_inode.c -> now the same as it was before. cmd/xfs/libxfs/xfs.h - 1.6 - changes required to do real transactions. cmd/xfs/libxfs/xfs_dir2_block.c - 1.3 - back out the xfs_dir2_data_log_header call I added earlier. cmd/xfs/libxfs/xfs_inode.c - 1.3 - xfs_iflush_fork now the same as in the kernel again. cmd/xfs/repair/xfs_repair.c - 1.51 - switch writes back on. linux/fs/xfs/xfs_dir2_block.c - 1.15 - back out the xfs_dir2_data_log_header call I added earlier. cmd/xfs/libxfs/logitem.c - 1.1 cmd/xfs/libxfs/trans.c - 1.1 - changes required to do real transactions. cmd/xfs/libxfs/xfs_mount.c - 1.1 cmd/xfs/libxfs/xfs_trans.c - 1.1 - split kernel.c routines out for simpler change monitoring. From owner-linux-xfs@oss.sgi.com Thu Aug 31 22:46:54 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 22:46:45 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39277 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 22:46:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA06359 for ; Thu, 31 Aug 2000 22:52:48 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA68192 for linux-xfs@oss.sgi.com; Fri, 1 Sep 2000 16:43:48 +1100 (EST) Date: Fri, 1 Sep 2000 16:43:48 +1100 (EST) From: Nathan Scott Message-Id: <200009010543.QAA68192@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - logprint Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing recant on the old naming scheme ... same named files will be easier to keep track of. Modid: 2.4.0-test1-xfs:slinx:73482a Date: Thu Aug 31 22:42:31 PDT 2000 Workarea: snort:/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.0-test1-xfs cmd/xfs/logprint/Makefile - 1.38 - use xfs_log_recover.c not kernel.c cmd/xfs/logprint/xfs_log_recover.c - 1.1 - rename kernel.c back to its original name. From owner-linux-xfs@oss.sgi.com Thu Aug 31 23:06:05 2000 Received: by oss.sgi.com id ; Thu, 31 Aug 2000 23:05:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:361 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 31 Aug 2000 23:05:34 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA11230; Thu, 31 Aug 2000 22:57:56 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA04580; Thu, 31 Aug 2000 23:05:33 -0700 (PDT) Date: Thu, 31 Aug 2000 23:05:33 -0700 (PDT) Message-Id: <200009010605.XAA04580@info.engr.sgi.com> X-Pv-Incident: 799518 webPV: wobbly.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (nathans@engr.sgi.com) Subject: CLOSE 799518 - panic machine when mounting filesystems and xfs_repair core dump To: nathans@engr.sgi.com Cc: ananth@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799518 *Status : closed Priority : 2 Assigned Engineer : nathans Submitter : nelsond Opened Date : 08/20/00 *Closed Date : 08/31/00 *Fixed By : nathans *Fixed By Domain : engr *Modified Date : 08/31/00 *Modified User : nathans *Modified User Domain : engr *Fix Description : From: nathans@snort.melbourne.sgi.com (nathan scott) (PARTIAL) Date: Aug 20 2000 08:15:03PM [pvnews version: 1.71] ---------------------------- To build the known-working version of xfs_repair: - run "make config" in $WORKAREA/linux directory (libsim requires this in order to build). - cd $WORKAREA/cmd/xfs/sim - run "make" ..... ========================== ADDITIONAL INFORMATION (CLOSE) From: nathans@engr (BugWorks) Date: Aug 31 2000 11:05:32PM ========================== All of the mkfs & repair changes have now been made & checked in - this kind of problem shouldn't occur any more.