From owner-linux-xfs@oss.sgi.com Sat Nov 1 06:31:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Nov 2003 06:32:27 -0800 (PST) Received: from uni-kl.de (mail.uni-kl.de [131.246.137.52]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1EVi25014318 for ; Sat, 1 Nov 2003 06:31:45 -0800 Received: from mailgate1.uni-kl.de (mailgate1.uni-kl.de [131.246.120.5]) by uni-kl.de (8.12.8/8.12.8) with ESMTP id h9UGBLZI004270 for ; Thu, 30 Oct 2003 17:11:22 +0100 (MET) Received: from mailinf.rhrk.uni-kl.de (mailinf.rhrk.uni-kl.de [131.246.137.54]) by mailgate1.uni-kl.de (8.12.10/8.12.10) with ESMTP id h9UGBIIj021829 for ; Thu, 30 Oct 2003 17:11:19 +0100 Received: from vw1-nehmer.informatik.uni-kl.de (vw1-nehmer.informatik.uni-kl.de [131.246.19.251]) by mailinf.rhrk.uni-kl.de (8.12.6/8.12.6) with SMTP id h9UGBIQC004835 for ; Thu, 30 Oct 2003 16:11:18 GMT Received: from 131.246.16.250 by vw1-nehmer.informatik.uni-kl.de (InterScan E-Mail VirusWall NT); Thu, 30 Oct 2003 17:13:32 +0100 Received: from forsyth.informatik.uni-kl.de ([192.168.16.135]) by gateway1-theorie.informatik.uni-kl.de with ESMTP id <119047>; Thu, 30 Oct 2003 17:11:14 +0100 From: Bernd Strieder Organization: Universitaet Kaiserlautern To: linux-xfs@oss.sgi.com Subject: Fwd: Re: xfsdump hanging in uninterruptible sleep Date: Thu, 30 Oct 2003 17:11:10 +0100 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_egTo/wazOLeapfy" Message-Id: <200310301711.10737.strieder@informatik.uni-kl.de> X-archive-position: 891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: strieder@informatik.uni-kl.de Precedence: bulk X-list: linux-xfs --Boundary-00=_egTo/wazOLeapfy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, after getting the mail bounced, a second try forwarding my own message. I had some conversation with Steve Lord on the subject, but I was not able to reach him directly. The hanging xfsdump process is still there, in the case you need more info. The machine will have to be rebooted as soon as possible to get backup working again. If it gets unstable it will be rebooted immediately, since quite some people are relying on it. Bernd Strieder --Boundary-00=_egTo/wazOLeapfy Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Bernd Strieder : Re: xfsdump hanging in uninterruptible sleep From: Bernd Strieder Organization: Universitaet Kaiserlautern To: Steve Lord Subject: Re: xfsdump hanging in uninterruptible sleep Date: Wed, 29 Oct 2003 15:48:00 +0100 User-Agent: KMail/1.5.3 References: <200309252314.39433.strieder@informatik.uni-kl.de> <1064535652.1529.25.camel@laptop.americas.sgi.com> In-Reply-To: <1064535652.1529.25.camel@laptop.americas.sgi.com> X-KMail-Link-Message: 1092177642 X-KMail-Link-Type: reply MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_gM9n/ji85fqsqVq" Message-Id: <200310291548.00109.strieder@informatik.uni-kl.de> Status: RO X-Status: S X-KMail-EncryptionState: X-KMail-SignatureState: --Boundary-00=_gM9n/ji85fqsqVq Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Am Freitag, 26. September 2003 02:20 schrieben Sie: > On Thu, 2003-09-25 at 16:14, Bernd Strieder wrote: > > Hello > > > > The filesystem in question is on a 36GB SCSI drive, the only > > partition on this drive. The fs contains 22 GB of data, > > quota is used with few exception. The filesystem is exported > > to about 15 Linux clients, 1 Debian, the others SuSE8.2 and > > 8.1 , and 1 OpenBSD client. The server is P3 2-way SMP with > > 4GB of RAM. > > > > Occasionally xfsdump is hanging in uninterruptible sleep. > > Occasionally means, that it happens sometimes, but I have > > not been able to trigger the problem. > > > > Usually xfsdump is run at night writing about 20 GB via rmt > > to a Sun box with a DLT streamer attached to it. If the > > problem happens, it must be at the beginning of the dump, > > from the backup logs I have. > > > > I have not found a way to kill xfsdump in this state, the > > machine has to be booted, or the other night the next > > xfsdump started will get into the same state. There are no > > diagnostics somewhere in the system, syslog, console, dmesg. > > ps says xfsdump is in lock_p. > > > > The problem happens with the SuSE-kernels delivered with > > SuSE-8.1 and 8.2, and with all patched Linus with XFS > > patched, and with -ac kernels. All kernels I have tried show > > the problem. Before the update to SuSE 8.2 it took once 3 > > months between two cases of hanging xfsdump using a vanilla > > 2.4.21 kernel with xfs 1.2 patched. > > > > I have tried xfsdump to /dev/null and putting the system > > under load (more disk load, more network load), but I could > > not trigger the problem. The tape drive swallows about > > 5MB/sec, by dumping to /dev/zero the rate is about 15MB/sec, > > which should be more stress to the system. > > > > Twice, the hanging xfsdump was not noticed for some days and > > the system got instable, kernel NFSd hanging, which made a > > reboot mandatory. > > > > Any ideas? > > > > Bernd Strieder > > Using sysrq to get a stack trace of the xfsdump thread in the > kernel will give some pointers to where it is hanging. Since > it happens when you use the real tape rather than the dummy > one, there is a fair chance that the tape end of the dump is > where the problem lies. > > You need a kernel with sysrq enabled, and you need to turn it > on, then there is an option to dump stacks of all kernel > threads. After 1 month it happened again... I used sysrq 't' with level 9 and piped the output of dmesg into ksymoops. The hanging xfsdump is included, but possibly not all processes. The file is attached. Since any other xfsdump will fail, eventually, the system will have to be rebooted to get our backup running again. If there is any chance you need and can get more information from the running system, please let me know, otherwise the machine should be rebooted as soon as possible. I will try to leave it in its state as long as possible. # cat /proc/version Linux version 2.4.22-xfs (root@doyle) (gcc version 3.3.1 (SuSE Linux)) #3 SMP Fri Sep 19 13:50:09 CEST 2003 # strings xfs.o SGI XFS snapshot 2.4.22-2003-09-03_04:09_UTC with ACLs, no debug enabled # xfsdump --help xfsdump: version 2.2.6 (dump format 3.0) Bernd Strieder --Boundary-00=_gM9n/ji85fqsqVq Content-Type: text/plain; charset="iso-8859-15"; name="xfsdump.syms" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xfsdump.syms" ksymoops 2.4.8 on i686 2.4.22-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.22-xfs/ (default) -m /boot/System.map-2.4.22-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. xfslogd/1 S E538F220 0 16 1 15 17 (L-TLB) Using defaults from ksymoops -t elf32-i386 -a i386 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] xfsdatad/0 S FFFFFFFF 0 17 1 16 18 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] xfsdatad/1 S FFFFFFFF 0 18 1 17 11 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] xfssyncd S F8B70AA7 2344 19 1 82 14 (L-TLB) Call Trace: [] [] [] [] [] [] [] mdrecoveryd S C02A8000 2344 82 1 146 19 (L-TLB) Call Trace: [] [] [] [] xfssyncd S 00236011 0 146 1 505 82 (L-TLB) Call Trace: [] [] [] [] [] [] [] syslogd S C0292E94 0 505 1 557 146 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] khubd S 000003E8 0 557 1 590 505 (L-TLB) Call Trace: [] [] [] [] [] resmgrd S C0292E94 0 590 1 621 557 (NOTLB) Call Trace: [] [] [] [] [] [] portmap S C0292E94 1372 621 1 634 590 (NOTLB) Call Trace: [] [] [] [] [] [] nmbd S C0292E94 2344 634 1 677 621 (NOTLB) Call Trace: [] [] [] [] [] [] [] rpc.statd S C0292E94 1376 677 1 707 634 (NOTLB) Call Trace: [] [] [] [] [] [] [] ypserv S C0292E94 2344 707 1 723 677 (NOTLB) Call Trace: [] [] [] [] [] [] rpc.yppasswdd S C0292E94 8 723 1 739 707 (NOTLB) Call Trace: [] [] [] [] [] [] [] rpc.ypxfrd S C0292E94 5152 739 1 776 723 (NOTLB) Call Trace: [] [] [] [] [] [] in.identd S C0328528 0 776 1 791 834 739 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] in.identd S 00000000 4 791 776 793 (NOTLB) Call Trace: [] [] [] [] [] [] [] in.identd S C88C802E 12 792 791 793 (NOTLB) Call Trace: [] [] in.identd S CD77102E 0 793 791 792 (NOTLB) Call Trace: [] [] rwhod S 00000001 2344 834 1 866 776 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] ypbind S C0292E94 2344 866 1 867 931 834 (NOTLB) Call Trace: [] [] [] [] [] [] ypbind S 00000000 2344 867 866 869 (NOTLB) Call Trace: [] [] [] [] [] [] [] ypbind S F5EBBF90 1376 868 867 869 (NOTLB) Call Trace: [] [] ypbind S 00000202 2344 869 867 868 (NOTLB) Call Trace: [] [] [] [] [] sshd S C0292E94 0 931 1 31571 987 866 (NOTLB) Call Trace: [] [] [] [] [] [] [] automount S 00000000 0 987 1 989 931 (NOTLB) Call Trace: [] [] [] [] [] automount S 00000000 2344 989 1 991 987 (NOTLB) Call Trace: [] [] [] [] [] automount S 00000000 0 991 1 1205 989 (NOTLB) Call Trace: [] [] [] [] [] rpc.rquotad S C0292E94 1376 1205 1 1309 991 (NOTLB) Call Trace: [] [] [] [] [] [] nfsd S 00000070 2344 1306 1 1310 1307 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] nfsd S 00001080 2344 1307 1 1306 1308 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] nfsd S 00000080 0 1308 1 1307 1309 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] nfsd S 00000070 2344 1309 1 1308 1205 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] lockd S 00000024 1376 1310 1 1311 1314 1306 (L-TLB) Call Trace: [] [] [] [] [] [] [] rpciod S 00000000 8 1311 1310 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] rpc.mountd S C0292E94 8 1314 1 1370 1310 (NOTLB) Call Trace: [] [] [] [] [] [] master S 000243D5 2344 1370 1 31159 1445 1314 (NOTLB) Call Trace: [] [] [] [] [] [] [] qmgr S C0292E94 2344 1391 1370 31159 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] smbd S C0292E94 2344 1445 1 1469 1370 (NOTLB) Call Trace: [] [] [] [] [] [] kdm S C0292E94 8 1469 1 28602 1489 1445 (NOTLB) Call Trace: [] [] [] [] [] [] atd S 00000001 68 1489 1 1507 1469 (NOTLB) Call Trace: [] [] [] [] cron S 00000000 4 1507 1 1534 1489 (NOTLB) Call Trace: [] [] [] [] [] dhcpd S C0292E94 2344 1534 1 1553 1507 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] nscd S 00000000 2344 1553 1 1559 1574 1534 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nscd S 00000000 0 1559 1553 1564 (NOTLB) Call Trace: [] [] [] [] [] [] [] nscd S 00000000 68 1560 1559 1561 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] nscd S 00000001 0 1561 1559 1562 1560 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] nscd S 00000029 2344 1562 1559 1563 1561 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] nscd S 00000000 2344 1563 1559 1564 1562 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] nscd S C0292E94 2344 1564 1559 1563 (NOTLB) Call Trace: [] [] [] [] [] [] [] inetd S C0292E94 2344 1574 1 30052 1593 1553 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 0 1593 1 1594 1574 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 0 1594 1 1595 1593 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 1376 1595 1 1596 1594 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 36 1596 1 1597 1595 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 2344 1597 1 1598 1596 (NOTLB) Call Trace: [] [] [] [] [] [] [] mingetty S 00000000 2344 1598 1 20513 1597 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] cupsd S C0292E94 2344 20513 1 29928 1598 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] X S C0292E94 2344 28601 1469 28602 (NOTLB) Call Trace: [] [] [] [] [] [] [] kdm S F7FFFBC4 0 28602 1469 28611 28601 (NOTLB) Call Trace: [] [] [] [] kdm_greet S C0292E94 28 28611 28602 (NOTLB) Call Trace: [] [] [] [] [] [] [] sshd S 00007B55 2344 28997 931 29000 31366 (NOTLB) Call Trace: [] [] [] [] [] [] xfsdump D 00003286 0 29000 28997 29018 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] rsh Z 00000292 0 29010 29000 29018 (L-TLB) Call Trace: [] [] [] [] rsh S C0292E94 0 29018 29000 29021 29010 (NOTLB) Call Trace: [] [] [] [] [] [] [] rsh S 00000000 0 29021 29018 (NOTLB) Call Trace: [] [] [] [] [] [] xload S C0292E94 2344 29928 1 30350 20513 (NOTLB) Call Trace: [] [] [] [] [] [] [] in.rshd S C0292E94 2344 30052 1574 30054 (NOTLB) Call Trace: [] [] [] [] [] xterm S C0292E94 60 30054 30052 30079 (NOTLB) Call Trace: [] [] [] [] [] [] [] bash S 00000000 32 30079 30054 30094 (NOTLB) Call Trace: [] [] [] su S 00000001 2344 30094 30079 30108 (NOTLB) Call Trace: [] [] bash S 656C796F 64 30108 30094 (NOTLB) Call Trace: [] [] [] [] [] [] ntpd S C0292E94 2344 30350 1 29928 (NOTLB) Call Trace: [] [] [] [] [] [] [] pickup S C0292E94 0 31159 1370 1391 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] sshd S 00000000 2344 31366 931 31371 31571 28997 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] sshd S 00026A43 2344 31371 31366 31373 (NOTLB) Call Trace: [] [] [] [] [] [] bash S 00000001 2344 31373 31371 31761 (NOTLB) Call Trace: [] [] [] sshd S 00000000 2344 31571 931 31574 31366 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] sshd S 00020CA2 2344 31574 31571 31576 (NOTLB) Call Trace: [] [] [] [] [] [] bash S 00000000 2344 31576 31574 31608 (NOTLB) Call Trace: [] [] [] su S 00000001 2344 31608 31576 31610 (NOTLB) Call Trace: [] [] bash R current 2344 31610 31608 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] less S 5B1B4B5B 2344 31761 31373 (NOTLB) Call Trace: [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Proc; xfslogd/1 >>EIP; e538f220 <_end+25057868/387c96a8> <===== Trace; f8bbc320 <[xfs]pbhash+840/1000> Trace; f8bbb64c <[xfs]pagebuf_logiodone_wait+c/180> Trace; f8bbb548 <[xfs]pagebuf_logiodone_tq+8/100> Trace; f8b90a3f <[xfs]pagebuf_iodone_daemon+13f/190> Trace; f8bbb548 <[xfs]pagebuf_logiodone_tq+8/100> Trace; f8bb645e <[xfs].rodata.end+ec7/4e29> Trace; f8bb6464 <[xfs].rodata.end+ecd/4e29> Trace; f8bbb650 <[xfs]pagebuf_logiodone_wait+10/180> Trace; f8bbb650 <[xfs]pagebuf_logiodone_wait+10/180> Trace; f8b90aff <[xfs]pagebuf_logiodone_daemon+2f/40> Trace; f8bb6464 <[xfs].rodata.end+ecd/4e29> Trace; f8bbb4c0 <[xfs]pb_logio_daemons+0/80> Trace; f8bbb540 <[xfs]pagebuf_logiodone_tq+0/100> Trace; f8bbb640 <[xfs]pagebuf_logiodone_wait+0/180> Trace; c010753e Trace; f8b90ad0 <[xfs]pagebuf_logiodone_daemon+0/40> Proc; xfsdatad/0 >>EIP; ffffffff <===== Trace; f8bbb940 <[xfs]pagebuf_dataiodone_wait+0/180> Trace; f8bbb840 <[xfs]pagebuf_dataiodone_tq+0/100> Trace; f8b90a3f <[xfs]pagebuf_iodone_daemon+13f/190> Trace; f8bb645e <[xfs].rodata.end+ec7/4e29> Trace; f8bb646c <[xfs].rodata.end+ed5/4e29> Trace; f8bbb944 <[xfs]pagebuf_dataiodone_wait+4/180> Trace; f8bbb944 <[xfs]pagebuf_dataiodone_wait+4/180> Trace; f8b90b3f <[xfs]pagebuf_dataiodone_daemon+2f/40> Trace; f8bb646c <[xfs].rodata.end+ed5/4e29> Trace; f8bbb7c0 <[xfs]pb_dataio_daemons+0/80> Trace; f8bbb840 <[xfs]pagebuf_dataiodone_tq+0/100> Trace; f8bbb940 <[xfs]pagebuf_dataiodone_wait+0/180> Trace; c010753e Trace; f8b90b10 <[xfs]pagebuf_dataiodone_daemon+0/40> Proc; xfsdatad/1 >>EIP; ffffffff <===== Trace; f8bbb94c <[xfs]pagebuf_dataiodone_wait+c/180> Trace; f8bbb848 <[xfs]pagebuf_dataiodone_tq+8/100> Trace; f8b90a3f <[xfs]pagebuf_iodone_daemon+13f/190> Trace; f8bb645e <[xfs].rodata.end+ec7/4e29> Trace; f8bb646c <[xfs].rodata.end+ed5/4e29> Trace; f8bbb950 <[xfs]pagebuf_dataiodone_wait+10/180> Trace; f8bbb950 <[xfs]pagebuf_dataiodone_wait+10/180> Trace; f8b90b3f <[xfs]pagebuf_dataiodone_daemon+2f/40> Trace; f8bb646c <[xfs].rodata.end+ed5/4e29> Trace; f8bbb7c0 <[xfs]pb_dataio_daemons+0/80> Trace; f8bbb840 <[xfs]pagebuf_dataiodone_tq+0/100> Trace; f8bbb940 <[xfs]pagebuf_dataiodone_wait+0/180> Trace; c010753e Trace; f8b90b10 <[xfs]pagebuf_dataiodone_daemon+0/40> Proc; xfssyncd >>EIP; f8b70aa7 <[xfs]xfs_log_force+47/70> <===== Trace; f8b70aa7 <[xfs]xfs_log_force+47/70> Trace; c011c034 Trace; c011bf80 Trace; f8b9baf3 <[xfs]vfs_sync+43/50> Trace; f8b9ae41 <[xfs]syncd+a1/f0> Trace; c010753e Trace; f8b9ada0 <[xfs]syncd+0/f0> Proc; mdrecoveryd >>EIP; c02a8000 <===== Trace; f8bc3ecd <[md]md_thread+15d/1d0> Trace; f8bc5cba <[md].text.end+498/1f46> Trace; c010753e Trace; f8bc3d70 <[md]md_thread+0/1d0> Proc; xfssyncd >>EIP; 00236011 Before first symbol <===== Trace; c011c034 Trace; f8b846c9 <[xfs]xfs_sync+29/30> Trace; c011bf80 Trace; f8b9baf3 <[xfs]vfs_sync+43/50> Trace; f8b9ae41 <[xfs]syncd+a1/f0> Trace; c010753e Trace; f8b9ada0 <[xfs]syncd+0/f0> Proc; syslogd >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c07e Trace; c020897e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c012450d Trace; c0109297 Proc; khubd >>EIP; 000003e8 Before first symbol <===== Trace; f8e8a5b7 <[usbcore]usb_hub_thread+b7/100> Trace; f8e94acc <[usbcore]khubd_wait+4/c> Trace; f8e94acc <[usbcore]khubd_wait+4/c> Trace; c010753e Trace; f8e8a500 <[usbcore]usb_hub_thread+0/100> Proc; resmgrd >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; portmap >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; nmbd >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c011bf80 Trace; c01511b1 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; rpc.statd >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c07e Trace; c020897e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; ypserv >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; rpc.yppasswdd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; rpc.ypxfrd >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; in.identd >>EIP; c0328528 <===== Trace; c021ad0f Trace; c011c07e Trace; c0252d0a Trace; c022757c Trace; c0227662 Trace; c0245235 Trace; c0202dd6 Trace; c0109073 Trace; c0150fca Trace; c0203c06 Trace; c0108556 Trace; c0109297 Proc; in.identd >>EIP; 00000000 Before first symbol Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c01511b1 Trace; c011bf80 Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; in.identd >>EIP; c88c802e <_end+8590676/387c96a8> <===== Trace; c010819b Trace; c0109297 Proc; in.identd >>EIP; cd77102e <_end+d439676/387c96a8> <===== Trace; c010819b Trace; c0109297 Proc; rwhod >>EIP; 00000001 Before first symbol <===== Trace; c011c07e Trace; f8b4375e <[xfs]xfs_bmapi+2be/14f0> Trace; c0207fa6 Trace; c02080bb Trace; c023dba4 Trace; c02454bc Trace; c0201ffb Trace; c0201d2c Trace; c020329a Trace; f8b6890e <[xfs]xfs_iunlock+5e/90> Trace; f8b87858 <[xfs]xfs_inactive_free_eofblocks+118/310> Trace; c0203b27 Trace; c0109297 Proc; ypbind >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; ypbind >>EIP; 00000000 Before first symbol Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c01511b1 Trace; c011bf80 Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; ypbind >>EIP; f5ebbf90 <_end+35b845d8/387c96a8> <===== Trace; c010819b Trace; c0109297 Proc; ypbind >>EIP; 00000202 Before first symbol <===== Trace; c011c034 Trace; c0158f5b Trace; c011bf80 Trace; c0129b4b Trace; c0109297 Proc; sshd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0146ef5 Trace; c0109297 Proc; automount >>EIP; 00000000 Before first symbol Trace; c0150c14 Trace; c0150d10 Trace; c012450d Trace; c0145c3b Trace; c0109297 Proc; automount >>EIP; 00000000 Before first symbol Trace; c0150c14 Trace; c0150d10 Trace; c012450d Trace; c0145c3b Trace; c0109297 Proc; automount >>EIP; 00000000 Before first symbol Trace; c0150c14 Trace; c0150d10 Trace; c012450d Trace; c0145c3b Trace; c0109297 Proc; rpc.rquotad >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; nfsd >>EIP; 00000070 Before first symbol <===== Trace; c011c034 Trace; f8f938e9 <[sunrpc]svc_sock_release+79/d0> Trace; c011bf80 Trace; f8f9511a <[sunrpc]svc_send+5a/e0> Trace; f8f94fba <[sunrpc]svc_recv+40a/4d0> Trace; f8f9327c <[sunrpc]svc_process+2cc/599> Trace; f8fbe0ac <[nfsd].data.end+58d/2541> Trace; f8fac318 <[nfsd]nfsd+108/380> Trace; f8fbd0e0 <[nfsd]nfsd_list+0/0> Trace; c010753e Trace; f8fac210 <[nfsd]nfsd+0/380> Proc; nfsd >>EIP; 00001080 Before first symbol <===== Trace; c011c034 Trace; f8f938e9 <[sunrpc]svc_sock_release+79/d0> Trace; c011bf80 Trace; f8f9511a <[sunrpc]svc_send+5a/e0> Trace; f8f94fba <[sunrpc]svc_recv+40a/4d0> Trace; f8f9327c <[sunrpc]svc_process+2cc/599> Trace; f8fbe0ac <[nfsd].data.end+58d/2541> Trace; f8fac318 <[nfsd]nfsd+108/380> Trace; c010753e Trace; f8fac210 <[nfsd]nfsd+0/380> Proc; nfsd >>EIP; 00000080 Before first symbol <===== Trace; c011c034 Trace; c011bf80 Trace; f8f94fba <[sunrpc]svc_recv+40a/4d0> Trace; f8f9327c <[sunrpc]svc_process+2cc/599> Trace; f8fbe0ac <[nfsd].data.end+58d/2541> Trace; f8fac318 <[nfsd]nfsd+108/380> Trace; c010753e Trace; f8fac210 <[nfsd]nfsd+0/380> Proc; nfsd >>EIP; 00000070 Before first symbol <===== Trace; c011c034 Trace; c011bf80 Trace; f8f94fba <[sunrpc]svc_recv+40a/4d0> Trace; f8f9327c <[sunrpc]svc_process+2cc/599> Trace; f8fbe0ac <[nfsd].data.end+58d/2541> Trace; f8fac318 <[nfsd]nfsd+108/380> Trace; f8fbd0e0 <[nfsd]nfsd_list+0/0> Trace; c010753e Trace; f8fac210 <[nfsd]nfsd+0/380> Proc; lockd >>EIP; 00000024 Before first symbol <===== Trace; c011c07e Trace; f8f938e9 <[sunrpc]svc_sock_release+79/d0> Trace; f8f94fba <[sunrpc]svc_recv+40a/4d0> Trace; f8f9327c <[sunrpc]svc_process+2cc/599> Trace; f8fa02cd <[lockd]lockd+16d/320> Trace; c010753e Trace; f8fa0160 <[lockd]lockd+0/320> Proc; rpciod >>EIP; 00000000 Before first symbol Trace; f8f9069d <[sunrpc]__rpc_schedule+dd/160> Trace; f8f91130 <[sunrpc]rpciod+220/280> Trace; f8f90f10 <[sunrpc]rpciod+0/280> Trace; f8f9b8ac <[sunrpc]rpciod_killer+0/c> Trace; f8f9b8a4 <[sunrpc]rpciod_idle+4/c> Trace; f8f9b8a4 <[sunrpc]rpciod_idle+4/c> Trace; c010753e Trace; f8f9b8ac <[sunrpc]rpciod_killer+0/c> Trace; f8f90f10 <[sunrpc]rpciod+0/280> Proc; rpc.mountd >>EIP; c0292e94 <===== Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; master >>EIP; 000243d5 Before first symbol <===== Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0124775 Trace; c0109297 Proc; qmgr >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c011bf80 Trace; c01511b1 Trace; c015850c Trace; c01588c5 Trace; c0146ef5 Trace; c0124775 Trace; c0109297 Proc; smbd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c01511b1 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; kdm >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c07e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; atd >>EIP; 00000001 Before first symbol <===== Trace; c011c034 Trace; c011bf80 Trace; c0129b4b Trace; c0109297 Proc; cron >>EIP; 00000000 Before first symbol Trace; c011c034 Trace; c011bf80 Trace; c014ebed Trace; c0129b4b Trace; c0109297 Proc; dhcpd >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c011bf80 Trace; f8fc3900 <[af_packet]packet_ops_spkt+0/60> Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; nscd >>EIP; 00000000 Before first symbol Trace; c021b020 Trace; c021b100 Trace; c011c07e Trace; c0252d0a Trace; c0207fa6 Trace; c02080bb Trace; c024fb02 Trace; c0202dd6 Trace; c011c03e Trace; c02024b9 Trace; c0158acb Trace; c0158144 Trace; c0158f5b Trace; c0203c06 Trace; c0109297 Proc; nscd >>EIP; 00000000 Before first symbol Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c01511b1 Trace; c011bf80 Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; nscd >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c0252d0a Trace; c0207fa6 Trace; c02080bb Trace; c024fb02 Trace; c0202dd6 Trace; c011c03e Trace; c02024b9 Trace; c0158acb Trace; c0158144 Trace; c0158f5b Trace; c0203c06 Trace; c0109297 Proc; nscd >>EIP; 00000001 Before first symbol <===== Trace; c011c07e Trace; c0252d0a Trace; c0207fa6 Trace; c02080bb Trace; c024fb02 Trace; c0202dd6 Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158144 Trace; c0158f5b Trace; c0203c06 Trace; c0109297 Proc; nscd >>EIP; 00000029 Before first symbol <===== Trace; c011c07e Trace; c0252d0a Trace; c0207fa6 Trace; c02080bb Trace; c024fb02 Trace; c0202dd6 Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158144 Trace; c0158f5b Trace; c0203c06 Trace; c0109297 Proc; nscd >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c0252d0a Trace; c0207fa6 Trace; c02080bb Trace; c024fb02 Trace; c0202dd6 Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158144 Trace; c0158f5b Trace; c0203c06 Trace; c0109297 Proc; nscd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c02024b9 Trace; c0158acb Trace; c0158bce Trace; c0158e54 Trace; c0109297 Proc; inetd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c020897e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; mingetty >>EIP; 00000000 Before first symbol Trace; c01b5194 Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0132f63 Trace; c0109297 Proc; cupsd >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0124775 Trace; c0109297 Proc; X >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; kdm >>EIP; f7fffbc4 <_end+37cc820c/387c96a8> <===== Trace; c0150c14 Trace; c0150d10 Trace; c0145c3b Trace; c0109297 Proc; kdm_greet >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; sshd >>EIP; 00007b55 Before first symbol <===== Trace; c011c07e Trace; c0250efe Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; xfsdump >>EIP; 00003286 Before first symbol <===== Trace; c012553a <__run_task_queue+6a/80> Trace; c01344f5 <__lock_page+95/c0> Trace; c013453b Trace; c0134650 <__find_lock_page_helper+40/70> Trace; c0134708 Trace; f8b8ec5e <[xfs]_pagebuf_lookup_pages+15e/320> Trace; f8b8f14c <[xfs]_pagebuf_find+19c/200> Trace; f8b8f2ad <[xfs]pagebuf_get+bd/160> Trace; f8b81a0c <[xfs]xfs_trans_read_buf+1bc/3d0> Trace; f8b68fa4 <[xfs]xfs_itobp+94/290> Trace; f8bbc380 <[xfs]pbhash+8a0/1000> Trace; f8b8f850 <[xfs]pagebuf_rele+c0/d0> Trace; f8b6f621 <[xfs]xfs_bulkstat+c41/f70> Trace; f8b959a4 <[xfs]xfs_ioc_bulkstat+154/2a0> Trace; f8b6e450 <[xfs]xfs_bulkstat_one+0/590> Trace; f8b952ab <[xfs]xfs_ioctl+48b/940> Trace; c0105865 Trace; c0131501 Trace; c011b254 Trace; c01243a0 Trace; c01f7b5f Trace; c01f7b40 Trace; c0129d9d Trace; c0105865 Trace; f8b93f30 <[xfs]linvfs_ioctl+30/50> Trace; c0105865 Trace; c0157595 Trace; c0105865 Trace; c0124775 Trace; c0109297 Trace; c0105865 Proc; rsh >>EIP; 00000292 Before first symbol <===== Trace; c014538f Trace; c01239cd Trace; c0123c83 Trace; c0109297 Proc; rsh >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c0245400 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; rsh >>EIP; 00000000 Before first symbol Trace; c024551f Trace; c0201f54 Trace; c0150c14 Trace; c0150d10 Trace; c0145c3b Trace; c0109297 Proc; xload >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; in.rshd >>EIP; c0292e94 <===== Trace; c011c07e Trace; c01511b1 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; xterm >>EIP; c0292e94 <===== Trace; c013dc8c <__get_free_pages+1c/20> Trace; c011c07e Trace; c01aa02b Trace; c01a7d66 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; bash >>EIP; 00000000 Before first symbol Trace; c0123ece Trace; c01a48fa Trace; c0109297 Proc; su >>EIP; 00000001 Before first symbol <===== Trace; c0123ece Trace; c0109297 Proc; bash >>EIP; 656c796f Before first symbol <===== Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0109297 Proc; ntpd >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c07e Trace; c020897e Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; pickup >>EIP; c0292e94 <===== Trace; c013db22 <__alloc_pages+42/190> Trace; c011c034 Trace; c011bf80 Trace; c02024b9 Trace; c015850c Trace; c01588c5 Trace; c0124775 Trace; c0109297 Proc; sshd >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c0149b2d Trace; c0250835 Trace; c0250b9f Trace; c0201ffb Trace; c0146a32 Trace; c0202152 Trace; c0145c3b Trace; c0109297 Proc; sshd >>EIP; 00026a43 Before first symbol <===== Trace; c011c07e Trace; c01aa02b Trace; c01a7d66 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; bash >>EIP; 00000001 Before first symbol <===== Trace; c0123ece Trace; c01a48fa Trace; c0109297 Proc; sshd >>EIP; 00000000 Before first symbol Trace; c011c07e Trace; c0149b2d Trace; c0250835 Trace; c0250b9f Trace; c0201ffb Trace; c0146a32 Trace; c0202152 Trace; c0145c3b Trace; c0109297 Proc; sshd >>EIP; 00020ca2 Before first symbol <===== Trace; c011c07e Trace; c01aa02b Trace; c01a7d66 Trace; c015850c Trace; c01588c5 Trace; c0109297 Proc; bash >>EIP; 00000000 Before first symbol Trace; c0123ece Trace; c01a48fa Trace; c0109297 Proc; su >>EIP; 00000001 Before first symbol <===== Trace; c0123ece Trace; c0109297 Proc; bash >>EIP; 0000000c Before first symbol <===== Trace; c011fe2e <__call_console_drivers+4e/70> Trace; c011ffe0 Trace; c01201e3 Trace; c01201e3 Trace; c0109529 Trace; c0109529 Trace; c011d56d Trace; c01becfa <__handle_sysrq_nolock+7a/f0> Trace; c01bec59 Trace; c01710d1 Trace; c0145dab Trace; c0109297 Proc; less >>EIP; 5b1b4b5b Before first symbol <===== Trace; c011c07e Trace; c01a7bc2 Trace; c01a7802 Trace; c01a2f35 Trace; c0145c3b Trace; c0124775 Trace; c0109297 2 warnings issued. Results may not be reliable. --Boundary-00=_gM9n/ji85fqsqVq-- --Boundary-00=_egTo/wazOLeapfy-- From owner-linux-xfs@oss.sgi.com Sat Nov 1 15:50:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Nov 2003 15:51:31 -0800 (PST) Received: from hotmail.com (bay2-dav57.bay2.hotmail.com [65.54.246.192]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1NoT25025740 for ; Sat, 1 Nov 2003 15:50:49 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 Nov 2003 15:50:22 -0800 Received: from 66.169.216.70 by bay2-dav57.bay2.hotmail.com with DAV; Sat, 01 Nov 2003 23:50:22 +0000 X-Originating-IP: [66.169.216.70] X-Originating-Email: [oldshield@hotmail.com] From: "oldshield" To: Subject: Iso files Date: Sat, 1 Nov 2003 17:48:15 -0800 Message-ID: <000001c3a0e3$61c6ba60$fe01a8c0@DPLAP02> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 01 Nov 2003 23:50:22.0444 (UTC) FILETIME=[E9E8F2C0:01C3A0D2] X-archive-position: 892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: oldshield@hotmail.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- I was going to upgrade from 1.1 tro 1.3. What happened to the iso installer. Your ftp site seems to go in loops. The latest and 1.3 directory are empty. Dick Baker -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQIVAwUBP6RiWhss3cCQclZuAQGc8A//SCZjboKVpZLHaY/2zJLiJmD5MBA3Qz7g NQH0zJ7CifFxD+UnVoQxfMl3KZdDohlruioTtaieAlOVEX8wFDTmeMrgr1xvWTiB +sHQL7/cSCo0T5yXbmuKZyK06CRBolCxWLW+OFSo47nRzh6fPcfzU8yb+cCY+mgj BrIZJVVIoNn4wetO1pAHMvZtt/VaIUvZhhHsNrKaPt4VnOAtXRxCUHr7xfePmuyG dn/FbHLWJ0ekXgGzehxlgY3R3kaspKUxgrJTu2JHd9t7jJUt9fpsRj1+hyphhf1W 8J77MMfNIxtdWzQDaOtotHg1Xf9zqFqMZawn0cHBQngHVOQ1+LxbwkFVtymy1dH3 okNxzkXppYsusgf7aMZ6/8NUb3I08VkTs0oiSTT0tiNRc9bntD32KlC8plx/xbXK v0+XAMzVnyEv2IcrAu7bDwySXnvn/vxIDOKIfDgNicwUKLfFMecgMIufud5RtYKZ RD6vEL1sxZhfNsG7TSwWpER90rt+X368WJCUDFNaJO19tOdvQj+jaWfuZck0QNAP 1nczy+klxHv/QwEEd8IfZDSoqlvbkm9mpunEpwSwi8GyjQEuYT7FTqpYkq8Ev/ko oafYXzI12qM/fro44rDQ9shb8W1vJ8cAUOFOCS4AiaUKTt/8SICj/9rpWdV4Z/h4 1uf9NbVqUio= =dhnC -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Nov 1 16:17:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Nov 2003 16:17:49 -0800 (PST) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA20Gs25026641 for ; Sat, 1 Nov 2003 16:17:14 -0800 Received: from erbenson.alaska.net (211-pm32.nwc.alaska.net [209.112.158.211]) by malik.acsalaska.net (8.12.10/8.12.10) with ESMTP id hA20Gq5L005160 for ; Sat, 1 Nov 2003 15:16:52 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 4184C39E5 for ; Sat, 1 Nov 2003 15:16:50 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 474EA40FF35; Sat, 1 Nov 2003 15:16:50 -0900 (AKST) Date: Sat, 1 Nov 2003 15:16:50 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031102001650.GP3648@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hnpg0BSo5EvPlUVi" Content-Disposition: inline In-Reply-To: <20031031215013.GB25822@dkp.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --Hnpg0BSo5EvPlUVi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2003 at 04:50:13PM -0500, Andrew Klaassen wrote: > I've been experiencing *very* slow sustained write ( < .5MB/sec) > using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware > 7506 card in JBOD mode. Software RAID 5. No such problems with > Ext3 ( > 20MB/sec sustained write) with the same kernel on the > same software RAID 5 device. Obviously there's something very > wrong here. >=20 > Known issue? Any idea what might be causing this? make sure you use a v2 log. man mkfs.xfs --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Hnpg0BSo5EvPlUVi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj+kTPIACgkQJKx7GixEevwlaQCfbBNCpcYgrwSc8E3l7YSdZpH6 bkQAn2hIQlCaDi7Rig0+eBgDLgSKiVJq =QfHi -----END PGP SIGNATURE----- --Hnpg0BSo5EvPlUVi-- From owner-linux-xfs@oss.sgi.com Sat Nov 1 17:11:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Nov 2003 17:12:08 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA21BT25030191 for ; Sat, 1 Nov 2003 17:11:29 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA21BOq0031473 for ; Sat, 1 Nov 2003 17:11:24 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA21BNP512910456; Sat, 1 Nov 2003 19:11:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA21BNK24921683; Sat, 1 Nov 2003 19:11:23 -0600 (CST) Date: Sat, 1 Nov 2003 19:11:23 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: oldshield cc: linux-xfs@oss.sgi.com Subject: Re: Iso files In-Reply-To: <000001c3a0e3$61c6ba60$fe01a8c0@DPLAP02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs the top-level README on the ftp site explains why there is a bit less content these days. The installer has not been re-spun, we'll probably get it done eventually but unfortunately it's not the highest priority. -Eric On Sat, 1 Nov 2003, oldshield wrote: > > I was going to upgrade from 1.1 tro 1.3. > What happened to the iso installer. Your ftp site seems to go in > loops. The latest and 1.3 directory are empty. > Dick Baker > From owner-linux-xfs@oss.sgi.com Sun Nov 2 14:51:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Nov 2003 14:52:26 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Mpl25003886 for ; Sun, 2 Nov 2003 14:51:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA2Mpdq0027062 for ; Sun, 2 Nov 2003 14:51:41 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA2Mpbjj4987778 for ; Mon, 3 Nov 2003 09:51:37 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hA2MpZDb5493083 for linux-xfs@oss.sgi.com; Mon, 3 Nov 2003 09:51:35 +1100 (EST) Date: Mon, 3 Nov 2003 09:51:35 +1100 (EST) From: Nathan Scott Message-Id: <200311022251.hA2MpZDb5493083@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Debian packaging tweak X-archive-position: 895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Debian packaging update to close out an old DMAPI package-naming request. Only affects Debian. Date: Sun Nov 2 14:50:25 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:161065a xfsdump/VERSION - 1.54 xfsdump/doc/CHANGES - 1.61 xfsdump/debian/control - 1.17 xfsdump/debian/changelog - 1.43 xfsdump/debian/shlibs.local - 1.4 dmapi/doc/CHANGES - 1.17 dmapi/debian/control - 1.10 dmapi/debian/Makefile - 1.6 dmapi/debian/changelog - 1.18 dmapi/debian/rules - 1.7 From owner-linux-xfs@oss.sgi.com Sun Nov 2 22:21:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Nov 2003 22:22:40 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA36Lp25014232 for ; Sun, 2 Nov 2003 22:21:51 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA36f1Hc024655 for ; Mon, 3 Nov 2003 00:41:03 -0600 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 RAA22297; Mon, 3 Nov 2003 17:21:37 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA36LZUc1109490; Mon, 3 Nov 2003 17:21:36 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA36M4tJ005389; Mon, 3 Nov 2003 17:22:04 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA36M0Ed005387; Mon, 3 Nov 2003 17:22:00 +1100 Date: Mon, 3 Nov 2003 17:22:00 +1100 From: Nathan Scott To: Andrew Klaassen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031103062200.GI914@frodo> References: <20031031215013.GB25822@dkp.com> <20031031223220.GC25822@dkp.com> <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> <20031101024425.GA28503@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031101024425.GA28503@dkp.com> User-Agent: Mutt/1.5.3i X-archive-position: 896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Oct 31, 2003 at 09:44:25PM -0500, Andrew Klaassen wrote: > On Sat, Nov 01, 2003 at 12:14:45AM +0100, Simon Matter wrote: > > > > Did you try your setup with an external log? > > *Wow*, that made huge difference. From < .5MB/sec to > > 10MB/sec. Still not as good as Ext3, but getting better. > > I've noticed the variance in amount of data going out to disk > with XFS was much higher than with Ext3, too. Using the > external log on XFS, as you suggested, and a default Ext3 (these > both on software RAID 5, of course): > > Ext3: > Mean: 17541.5MB/s > Std. Dev: 2375.89MB/s > > XFS: > Mean: 12960.4MB/s > Std. Dev: 6535.16MB/s > > That's computed with a 5-second timeslices. In English, it > means that XFS write rates are jumping all over the place, from > .5MB/s to 20MB/s. Any reason why that would be? IIRC, this is probably caused by the caching that md does for the raid5 personality, which is sensitive to changes in the size of blocks which are coming down from the filesystem (if the size changes this cache is flushed, IIRC). There are two kinds of writes which are smaller than the (default) XFS 4K blocksize - log writes and SB/AGI/AGF/AGFL (allocation group header structures) writes. Making the log external eliminates the first kind (as will using a version 2 log with suitable stripe size). The allocation group header structures are sector sized, so you will be able to eliminate the second kind by going to a 4K sector size (assuming default 4K filesystem blocksize) - try the -ssize=4k option to mkfs.xfs. I'd be interested in hearing back as to whether this helps any... ext3 will always be passing down constant blocksized IOs, I believe, so isn't susceptible to this issue. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 3 04:07:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 04:08:19 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3C7f25028943 for ; Mon, 3 Nov 2003 04:07:43 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id hA3C7UOS094071; Mon, 3 Nov 2003 13:07:34 +0100 (CET) Message-Id: <4.3.2.7.2.20031103130440.035d3430@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Nov 2003 13:07:29 +0100 To: Andrew Klaassen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS + SMP + Software RAID 5 slow? In-Reply-To: <20031031215013.GB25822@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 16:50 31-10-2003 -0500, Andrew Klaassen wrote: >I've been experiencing *very* slow sustained write ( < .5MB/sec) >using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware >7506 card in JBOD mode. Software RAID 5. No such problems with >Ext3 ( > 20MB/sec sustained write) with the same kernel on the >same software RAID 5 device. Obviously there's something very >wrong here. You are probably not using a version 2 logfile. See the manpage for exact syntax. IIRC it's something like: mkfs.xfs -l size=32768b,version=2 /dev/md? You can also specify sunit and swidth parameters but mkfs.xfs should set those automatically. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Mon Nov 3 13:51:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 13:51:39 -0800 (PST) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3Lp425018466 for ; Mon, 3 Nov 2003 13:51:05 -0800 Received: from corona.local (caracas-0403.adsl.interware.hu [213.178.101.147]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id hA3LopjU004269 for ; Mon, 3 Nov 2003 22:51:00 +0100 (CET) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id hA3Lojl2003037 for ; Mon, 3 Nov 2003 22:50:45 +0100 (CET) Date: Mon, 3 Nov 2003 22:50:45 +0100 From: Rumi Szabolcs To: linux-xfs@oss.sgi.com Subject: strange File exists errors Message-Id: <20031103225045.73fc7c54.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 966 Lines: 24 Hello! I'm experiencing mysterious "File exists" errors when running scripts that are flooding the filesystem with operations, like make clean, or make menuconfig in the kernel tree, or emerge sync (it's Gentoo Linux), etc. This may or may not be an xfs problem, but I don't know how to track it down... No clear error messages from the kernel or anything, just these mysterious errors everywhere because of existing directories which should not exist at that point. The directories can be deleted by hand after a script/makefile aborts with such an error. It's reproducible and apparently hits the same directories over and over. I'm using Gentoo xfs-sources-2.4.22 (w/XFS snapshot 2003.10.10) and the whole system including the kernel was compiled with gcc-3.3.2. The userland was compiled using "-march=pentium4 -mfpmath=sse -O3 -pipe". The underlying filesystems are 1-2 gigs in size, created with -l internal,size=16m. Any thoughts? Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Mon Nov 3 20:04:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 20:05:08 -0800 (PST) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA444H25030392 for ; Mon, 3 Nov 2003 20:04:23 -0800 Received: from corona.local (caracas-0403.adsl.interware.hu [213.178.101.147]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id hA444AjU009746 for ; Tue, 4 Nov 2003 05:04:15 +0100 (CET) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id hA4444l2003192 for ; Tue, 4 Nov 2003 05:04:04 +0100 (CET) Date: Tue, 4 Nov 2003 05:04:04 +0100 From: Rumi Szabolcs To: linux-xfs@oss.sgi.com Subject: strange File exists errors (addendum) Message-Id: <20031104050404.5db7afee.rumi_ml@rtfm.hu> In-Reply-To: <20031103225045.73fc7c54.rumi_ml@rtfm.hu> References: <20031103225045.73fc7c54.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 1778 Lines: 41 On Mon, 3 Nov 2003 22:50:45 +0100 Rumi Szabolcs wrote: > I'm using Gentoo xfs-sources-2.4.22 (w/XFS snapshot 2003.10.10) > and the whole system including the kernel was compiled with > gcc-3.3.2. The userland was compiled using "-march=pentium4 > -mfpmath=sse -O3 -pipe". The underlying filesystems are 1-2 > gigs in size, created with -l internal,size=16m. Here are the improvements of the situation: I have reinstalled the whole system from stage3 (in Gentoo terms this means a fully precompiled system, with gcc-3.2.3 using -march=i686 and a bit more conservative optimization settings) and recompiled the same 2.4.22 kernel as above but this time with that stock gcc-3.2.3 shipped with Gentoo 1.4 and voila`: it still exhibits the very same errors! I have to admit that I was a bit surprised about that, I thought it's probably gcc-3.3.2's fault optimizing away some crucial stuff but apparently it's not. Realizing that, I have compiled xfs-sources-2.4.20-r3 (Gentoo kernels are usually a bit patched up from the stock with -ac, EVMS, xfs, etc. but this version works rock solid on two other production servers of mine, with xfs on all filesystems) on the same stable userland, and with this kernel the problem disappeared! It is using the XFS snapshot from 2003.04.07. So, my conclusion is, this problem is somewhere inside the kernel, maybe in the stock codebase, or the other patchsets, but most likely in the XFS part. I hope someone will comment on this really soon, as the time is rolling and this machine must go into production within 2-3 days (and should have been in production yesterday already). Or you can direct me to LKML or gentoo-dev or whatever ML you think is more appropriate to discuss this problem on. Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Mon Nov 3 20:17:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 20:18:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA44Hq25030915 for ; Mon, 3 Nov 2003 20:17:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA44bAHc023588 for ; Mon, 3 Nov 2003 22:37:10 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA44HkP512998426; Mon, 3 Nov 2003 22:17:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA44HkK25119640; Mon, 3 Nov 2003 22:17:46 -0600 (CST) Date: Mon, 3 Nov 2003 22:17:46 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rumi Szabolcs cc: linux-xfs@oss.sgi.com Subject: Re: strange File exists errors (addendum) In-Reply-To: <20031104050404.5db7afee.rumi_ml@rtfm.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 562 Lines: 14 On Tue, 4 Nov 2003, Rumi Szabolcs wrote: > I hope someone will comment on this really soon, as the time > is rolling and this machine must go into production within > 2-3 days (and should have been in production yesterday already). > Or you can direct me to LKML or gentoo-dev or whatever ML you > think is more appropriate to discuss this problem on. Not sure what to tell you, I don't think this is a known problem. Trying to reproduce it with a vanilla kernel + xfs (cvs or the 1.3.1 release) would help narrow down where the problem lies, I think. -Eric From owner-linux-xfs@oss.sgi.com Mon Nov 3 21:59:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 22:00:33 -0800 (PST) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA45xu25002446 for ; Mon, 3 Nov 2003 21:59:57 -0800 Received: from corona.local (caracas-0403.adsl.interware.hu [213.178.101.147]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id hA45xtjU011206 for ; Tue, 4 Nov 2003 06:59:55 +0100 (CET) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id hA45xnl2003228 for ; Tue, 4 Nov 2003 06:59:49 +0100 (CET) Date: Tue, 4 Nov 2003 06:59:49 +0100 From: Rumi Szabolcs To: linux-xfs@oss.sgi.com Subject: Re: strange File exists errors (addendum) Message-Id: <20031104065949.2aed164d.rumi_ml@rtfm.hu> In-Reply-To: References: <20031104050404.5db7afee.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 13 On Mon, 3 Nov 2003 22:17:46 -0600 (CST) Eric Sandeen wrote: > Not sure what to tell you, I don't think this is a known problem. > Trying to reproduce it with a vanilla kernel + xfs (cvs or the 1.3.1 > release) would help narrow down where the problem lies, I think. Aye, Sir! I have compiled a vanilla 2.4.21 kernel patched with xfs-1.3.1-release, and it seems to be OK, no problems! Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Mon Nov 3 22:06:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Nov 2003 22:07:31 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA466r25002980 for ; Mon, 3 Nov 2003 22:06:58 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA46QBHc017957 for ; Tue, 4 Nov 2003 00:26:11 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA466lP512975483; Tue, 4 Nov 2003 00:06:48 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA466lK25124529; Tue, 4 Nov 2003 00:06:47 -0600 (CST) Date: Tue, 4 Nov 2003 00:06:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rumi Szabolcs cc: linux-xfs@oss.sgi.com Subject: Re: strange File exists errors (addendum) In-Reply-To: <20031104065949.2aed164d.rumi_ml@rtfm.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 609 Lines: 17 On Tue, 4 Nov 2003, Rumi Szabolcs wrote: > On Mon, 3 Nov 2003 22:17:46 -0600 (CST) > Eric Sandeen wrote: > > > Not sure what to tell you, I don't think this is a known problem. > > Trying to reproduce it with a vanilla kernel + xfs (cvs or the 1.3.1 > > release) would help narrow down where the problem lies, I think. > > Aye, Sir! I have compiled a vanilla 2.4.21 kernel patched with > xfs-1.3.1-release, and it seems to be OK, no problems! Just for kicks, want to try the cvs snapshot as well? Just to see if anything has crept in since the release. If not, blame Gentoo ;) -Eric From owner-linux-xfs@oss.sgi.com Tue Nov 4 02:04:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Nov 2003 02:04:49 -0800 (PST) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4A4725015374 for ; Tue, 4 Nov 2003 02:04:08 -0800 Received: from corona.local (caracas-0403.adsl.interware.hu [213.178.101.147]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id hA4A3ujU014402; Tue, 4 Nov 2003 11:04:04 +0100 (CET) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id hA4A3ol2003345; Tue, 4 Nov 2003 11:03:50 +0100 (CET) Date: Tue, 4 Nov 2003 11:03:50 +0100 From: Rumi Szabolcs To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: strange File exists errors (addendum) Message-Id: <20031104110350.60abcb84.rumi_ml@rtfm.hu> In-Reply-To: References: <20031104065949.2aed164d.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 1101 Lines: 28 On Tue, 4 Nov 2003 00:06:47 -0600 (CST) Eric Sandeen wrote: > > Aye, Sir! I have compiled a vanilla 2.4.21 kernel patched with > > xfs-1.3.1-release, and it seems to be OK, no problems! > > Just for kicks, want to try the cvs snapshot as well? Just to see > if anything has crept in since the release. If not, blame Gentoo ;) I pulled a fresh one from CVS, compiled a minimalistic config, then booted it and compiled a full fledged one with all bells and whistles (smp, acpi) enabled, booted this and recompiled the whole thing again with HT enabled (smp kernel) and make -j2 to put a bit more stress on the fs and the kernel itself but in any case it seems to work fine (although I still wouldn't call this an extensive testing). Well, the conclusion is really that there might be something in the Gentoo kernel causing the problem (or triggering it?). Maybe it's still worth it to keep an eye open until it gets tracked down. Maybe you got some comments on the sunit/swidth questions I posted here twelve days ago? Nobody replied yet... Thank you! Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Tue Nov 4 17:23:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Nov 2003 17:24:28 -0800 (PST) Received: from sun.krithika.net ([205.158.115.30]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA51Nn25029497 for ; Tue, 4 Nov 2003 17:23:50 -0800 Received: from localhost (localhost.krithika.net [127.0.0.1]) by localhost.krithika.net (Postfix) with ESMTP id 73BAF30226; Tue, 4 Nov 2003 17:23:43 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from sun.krithika.net ([127.0.0.1]) by localhost (sun.itsprojects.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13743-01; Tue, 4 Nov 2003 17:23:41 -0800 (PST) Received: from swathi.krithika.net (unknown [202.88.158.15]) by sun.krithika.net (Postfix) with ESMTP id 43790301EF; Tue, 4 Nov 2003 17:23:41 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id EBF7D4F95D7; Wed, 5 Nov 2003 06:54:51 +0530 (IST) (envelope-from xfs@ramaswamy.net) From: Ajay Ramaswamy To: linux-xfs@oss.sgi.com Subject: Anaconda Date: Wed, 5 Nov 2003 06:54:49 +0530 User-Agent: KMail/1.5.4 Cc: katzj@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311050654.51573.xfs@ramaswamy.net> X-Virus-Scanned: by amavisd-new at krithika.net X-archive-position: 908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ramaswamy.net Precedence: bulk X-list: linux-xfs Content-Length: 4253 Lines: 131 Hello, I have been watching the progress of anaconda in the fedora core development and finally over the last 3 days I have started patching XFS support into it. I now need some help. As I see it the XFS support in fedora core can be broken down into the following components 1. Kernel - DaveJ has said NO :-< ... solution is to make our own. 2. Userspace - SGI provides RPMS they work fine. 3. Comps file add 2 lines one for xfsprogs & the other for xfsdump. I just copied and pasted the lines for e2fsprogs and dump and changed the names. This time around anaconda does dependency resolvind during the install so no need to run /usr/share/comps/getfullcomps.py to make the packages section. 4. Enable XFS as a supported filesystem in anaconda. Trivial patch, this time around I added xfs_copy to the rescue image so that one can boot off the cd and copy partitions. --- anaconda-9.0.96/scripts/upd-instroot.orig 2003-10-08 01:33:15.000000000 +0530 +++ anaconda-9.0.96/scripts/upd-instroot 2003-10-23 20:23:25.000000000 +0530 @@ -110,7 +110,8 @@ bzip2-libs dosfstools pciutils reiserfs-utils parted sed busybox-anaconda rpm-python booty hdparm lvm beecrypt rhpl pyxf86config libxml2 libxml2-python glib2 - elfutils-libelf bogl-bterm bogl krb5-libs convertdb1 jfsutils" + elfutils-libelf bogl-bterm bogl krb5-libs convertdb1 jfsutils + xfsprogs xfsdump dmapi libacl libattr attr acl" if [ $ARCH = i386 -o $ARCH = x86_64 ]; then PACKAGES="$PACKAGES kernel-pcmcia-cs kernel-utils" @@ -156,7 +157,8 @@ redhat-config-keyboard Xft fontconfig redhat-artwork ttfonts-ja ttfonts-zh_TW bitmap-fonts-cjk urw-fonts comps-extras XFree86-libs-data convertdb1 - vnc-server libjpeg tcp_wrappers redhat-config-date" + vnc-server libjpeg tcp_wrappers redhat-config-date + xfsprogs xfsdump dmapi libacl libattr attr acl" # # stuff ONLY included for rescue mode @@ -239,6 +241,9 @@ $LIBDIR/librt[-.]* $LIBDIR/libss* $LIBDIR/libtermcap* +$LIBDIR/libhandle* +$LIBDIR/libattr* +$LIBDIR/libdm* $LIBDIR/libutil* $LIBDIR/libuuid* sbin/badblocks @@ -250,6 +255,8 @@ sbin/e2label sbin/fsck.ext2 sbin/fsck.ext3 +sbin/fsck.jfs +sbin/fsck.xfs sbin/fdisk sbin/hdparm sbin/hwclock @@ -273,6 +280,7 @@ sbin/mkfs.ext2 sbin/mkfs.ext3 sbin/mkfs.jfs +sbin/mkfs.xfs sbin/mkfs.msdos sbin/mkfs.vfat sbin/mkreiserfs @@ -290,6 +298,12 @@ sbin/resize2fs sbin/sfdisk sbin/tune2fs +sbin/xfsdump +sbin/xfsrestore +sbin/xfs_repair +usr/sbin/xfs_db +usr/sbin/xfs_check +usr/sbin/xfs_copy sbin/vgcfgbackup sbin/vgcfgrestore sbin/vgchange --- anaconda-9.0.96/scripts/mk-images.i386.orig 2003-10-15 00:28:28.000000000 +0530 +++ anaconda-9.0.96/scripts/mk-images.i386 2003-10-23 20:15:27.000000000 +0530 @@ -92,7 +92,7 @@ IDEMODS="ide-cd" SCSIMODS="sd_mod sg sr_mod st" -FSMODS="msdos vfat ext3 reiserfs jfs" +FSMODS="msdos vfat ext3 reiserfs jfs xfs" SECSTAGE="agpgart md raid0 raid1 raid5 lvm-mod $FSMODS $IDEMODS $SCSIMODS $LATEUSBMODS st parport_pc parport" BTERMMODULES="vga16fb" --- anaconda-9.0.96/fsset.py.orig 2003-10-21 04:38:12.000000000 +0530 +++ anaconda-9.0.96/fsset.py 2003-10-23 20:13:19.000000000 +0530 @@ -51,12 +51,14 @@ availRaidLevels = ['RAID0', 'RAID1', 'RAID5'] def fileSystemTypeGetDefault(): - if fileSystemTypeGet('ext3').isSupported(): + if fileSystemTypeGet('xfs').isSupported(): + return fileSystemTypeGet('xfs') + elif fileSystemTypeGet('ext3').isSupported(): return fileSystemTypeGet('ext3') elif fileSystemTypeGet('ext2').isSupported(): return fileSystemTypeGet('ext2') else: - raise ValueError, "You have neither ext3 or ext2 support in your kernel!" + raise ValueError, "You have neither xfs, ext3 or ext2 support in your kernel!" def fileSystemTypeGet(key): @@ -397,9 +399,7 @@ self.name = "xfs" self.maxSizeMB = 1024 * 1024 self.maxLabelChars = 12 - # we don't even have the module, so it won't be mountable... but - # just in case - self.supported = 0 + self.supported = 1 def formatDevice(self, entry, progress, chroot='/'): devicePath = entry.device.setupDevice(chroot) From owner-linux-xfs@oss.sgi.com Tue Nov 4 17:43:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Nov 2003 17:44:01 -0800 (PST) Received: from sun.krithika.net ([205.158.115.30]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA51hH25030021 for ; Tue, 4 Nov 2003 17:43:17 -0800 Received: from localhost (localhost.krithika.net [127.0.0.1]) by localhost.krithika.net (Postfix) with ESMTP id 544103021B; Tue, 4 Nov 2003 17:43:11 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from sun.krithika.net ([127.0.0.1]) by localhost (sun.itsprojects.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13743-03-2; Tue, 4 Nov 2003 17:43:09 -0800 (PST) Received: from swathi.krithika.net (unknown [202.88.158.15]) by sun.krithika.net (Postfix) with ESMTP id 4A637301EF; Tue, 4 Nov 2003 17:43:09 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id 9224C4F95D7; Wed, 5 Nov 2003 07:14:21 +0530 (IST) (envelope-from xfs@ramaswamy.net) From: Ajay Ramaswamy To: linux-xfs@oss.sgi.com Subject: Re: Anaconda Date: Wed, 5 Nov 2003 07:14:19 +0530 User-Agent: KMail/1.5.4 References: <200311050654.51573.xfs@ramaswamy.net> In-Reply-To: <200311050654.51573.xfs@ramaswamy.net> Cc: katzj@redhat.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_1XFq/1vjXGxDfa3" Message-Id: <200311050714.21180.xfs@ramaswamy.net> X-Virus-Scanned: by amavisd-new at krithika.net X-archive-position: 909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ramaswamy.net Precedence: bulk X-list: linux-xfs Content-Length: 4600 Lines: 139 --Boundary-00=_1XFq/1vjXGxDfa3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 05 Nov 2003 6:54 am, Ajay Ramaswamy wrote: > Hello, > I have been watching the progress of anaconda in the fedora core > development and finally over the last 3 days I have started patching XFS > support into it. > Mummy! the dog ( kmail ) ate my homework. 5. Anaconda hangs while installing grub, this is a reproducable problem and has been reported before, this is because booty uses root (hd0,0) install .... before we used to do root (hd0,) setup .... this used to call embed behind the scenes. I have tried useing setup in booty but that does not work this version does not work since I dont know how to find out the fstype of the /boot partition 6. anaconda does not work for upgrades and rescue since it never reads back the fs LABEL I am trying this and need help here --Boundary-00=_1XFq/1vjXGxDfa3 Content-Type: text/x-diff; charset="us-ascii"; name="anaconda-xfs-label.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="anaconda-xfs-label.patch" diff -Naur anaconda-9.2/fsset.py anaconda-9.2-patched/fsset.py --- anaconda-9.2/fsset.py 2003-11-04 19:05:05.000000000 +0530 +++ anaconda-9.2-patched/fsset.py 2003-11-04 19:04:11.000000000 +0530 @@ -1337,6 +1337,10 @@ try: label = isys.readExt2Label(dev) except: + try: + label = readXFSLabel(dev) + except: + continue continue if label: entry.setLabel(label) @@ -1646,6 +1650,10 @@ try: return isys.readExt2Label(self.setupDevice(), makeDevNode = 0) except: + try: + return readXFSLabel(self.setupDevice()) + except: + return "" return "" class DevDevice(Device): @@ -2214,6 +2222,22 @@ return 0 +def readXFSLabel(device): + fd = getDevFD(device) + if fd == -1: + return "" + + buf = os.read(fd, 128) + os.close(fd) + + if len(buf) != 128: + xfslabel = "" + + if buf[0:4] == "XFSB": + xfslabel = string.rstrip(buf[108:120]) + + return xfslabel + # this will return a list of types of filesystems which device # looks like it could be to try mounting as def getFStoTry(device): --Boundary-00=_1XFq/1vjXGxDfa3 Content-Type: text/x-diff; charset="us-ascii"; name="booty-grub-setup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="booty-grub-setup.patch" diff -Naur booty-0.31.1/bootloaderInfo.py booty-0.31.1-patched/bootloaderInfo.py --- booty-0.31.1/bootloaderInfo.py 2003-08-16 02:20:35.000000000 +0530 +++ booty-0.31.1-patched/bootloaderInfo.py 2003-11-04 21:57:43.000000000 +0530 @@ -803,8 +803,15 @@ part = self.grubbyPartitionName(bootDev) prefix = "%s/%s" % (self.grubbyPartitionName(bootDev), grubPath) - cmd = "root %s\ninstall %s%s/stage1 d %s %s/stage2 p %s%s/grub.conf" % \ - (part, forcelba, grubPath, self.grubbyPartitionName(grubTarget), + bootfstype = fsset.getPartedFileSystemType(bootDev) + if (bootfstype == "ext2" or bootfstype == "ext3"): + imbcmd = "embed %s/e2fs_stage1_5 %s" % ( prefix, self.grubbyPartitionName(grubTarget) ) + elif (bootfstype == "xfs"): + imbcmd = "embed %s/xfs_stage1_5 %s" % ( prefix, self.grubbyPartitionName(grubTarget) ) + else: + imbcmd = "" + cmd = "root %s\n%s\ninstall %s%s/stage1 d %s %s/stage2 p %s%s/grub.conf" % \ + (part, imbcmd, forcelba, grubPath, self.grubbyPartitionName(grubTarget), grubPath, part, grubPath) if not justConfigFile: @@ -1009,8 +1016,15 @@ part = self.grubbyPartitionName(bootDev) prefix = "%s/%s" % (self.grubbyPartitionName(bootDev), grubPath) - cmd = "root %s\ninstall %s/stage1 d %s %s/stage2 p %s%s/grub.conf" % \ - (part, grubPath, self.grubbyPartitionName(theDev[5:]), + bootfstype = fsset.getPartedFileSystemType(bootDev) + if (bootfstype == "ext2" or bootfstype == "ext3"): + imbcmd = "embed %s/e2fs_stage1_5 %s" % ( prefix, self.grubbyPartitionName(grubTarget) ) + elif (bootfstype == "xfs"): + imbcmd = "embed %s/xfs_stage1_5 %s" % ( prefix, self.grubbyPartitionName(grubTarget) ) + else: + imbcmd = "" + cmd = "root %s\n%s\ninstall %s%s/stage1 d %s %s/stage2 p %s%s/grub.conf" % \ + (part, imbcmd, forcelba, grubPath, self.grubbyPartitionName(grubTarget), grubPath, part, grubPath) if not justConfigFile: --Boundary-00=_1XFq/1vjXGxDfa3-- From owner-linux-xfs@oss.sgi.com Tue Nov 4 18:46:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Nov 2003 18:46:40 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA52k425030838 for ; Tue, 4 Nov 2003 18:46:05 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA535PHc022268 for ; Tue, 4 Nov 2003 21:05:25 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA52jxP513027648; Tue, 4 Nov 2003 20:45:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA52jwK25212969; Tue, 4 Nov 2003 20:45:58 -0600 (CST) Date: Tue, 4 Nov 2003 20:45:58 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ajay Ramaswamy cc: linux-xfs@oss.sgi.com, Subject: Re: Anaconda In-Reply-To: <200311050654.51573.xfs@ramaswamy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1612 Lines: 40 On Wed, 5 Nov 2003, Ajay Ramaswamy wrote: > Hello, > I have been watching the progress of anaconda in the fedora core development > and finally over the last 3 days I have started patching XFS support into it. > > I now need some help. As I see it the XFS support in fedora core can be broken > down into the following components > > 1. Kernel - DaveJ has said NO :-< ... > solution is to make our own. where'd he say that? *grumble* At this point we need something like 3 exports to make xfs work with RHEL, I assume it's similar for fedora. rh already has 98% of what they need to make xfs work. :/ > 2. Userspace - SGI provides RPMS they work fine. > > 3. Comps file add 2 lines one for xfsprogs & the other for xfsdump. I just > copied and pasted the lines for e2fsprogs and dump and changed the names. > This time around anaconda does dependency resolvind during the install so no > need to run /usr/share/comps/getfullcomps.py to make the packages section. If you can find one of our old installers you can look at the anaconda patch we had to get things working. But the above sounds about right. > 4. Enable XFS as a supported filesystem in anaconda. Trivial patch, this time > around I added xfs_copy to the rescue image so that one can boot off the cd > and copy partitions. Attached patch looks about right, too. If you're interested in spinning Fedora+xfs installers, we'd be eternally grateful. But i must say that it's a bit frustrating that Red Hat is >this close< to being able to support xfs, yet they still don't want to go the last short haul to get there. -eric From owner-linux-xfs@oss.sgi.com Tue Nov 4 18:50:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Nov 2003 18:50:35 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA52o225031266 for ; Tue, 4 Nov 2003 18:50:02 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA539NHc024659 for ; Tue, 4 Nov 2003 21:09:23 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA52n0P513079131; Tue, 4 Nov 2003 20:49:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA52n0K25205265; Tue, 4 Nov 2003 20:49:00 -0600 (CST) Date: Tue, 4 Nov 2003 20:49:00 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ajay Ramaswamy cc: linux-xfs@oss.sgi.com, Subject: Re: Anaconda In-Reply-To: <200311050714.21180.xfs@ramaswamy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 702 Lines: 22 On Wed, 5 Nov 2003, Ajay Ramaswamy wrote: > 5. Anaconda hangs while installing grub, this is a reproducable problem and > has been reported before, this is because booty uses root (hd0,0) install > .... > before we used to do root (hd0,) setup .... this used to call embed behind the > scenes. I have tried useing setup in booty but that does not work Ah yes, grub, that does need to be sorted out. > 6. anaconda does not work for upgrades and rescue since it never reads back > the fs LABEL I am trying this and need help here how can we help? Any pointers to where this fails? Russell and I have both poked around a bit in anaconda + xfs, so I'm sure we can get somewhere. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 5 11:42:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 11:43:34 -0800 (PST) Received: from mx03.ca.mci.com (mx03.ca.mci.com [142.77.2.11]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Jgk25026569 for ; Wed, 5 Nov 2003 11:42:46 -0800 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx03.ca.mci.com (Postfix) with ESMTP id 0F837136C7 for ; Wed, 5 Nov 2003 14:05:51 -0500 (EST) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id hA5J5Sc05493 for ; Wed, 5 Nov 2003 14:05:28 -0500 Message-ID: <3FA94A37.B11B3275@calibredigital.com> Date: Wed, 05 Nov 2003 14:06:31 -0500 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs barfing on TB fs. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 915 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 7290 Lines: 149 Hello- FYI, and forgive me is this is the wrong place to post.. I was doing an rsync between 2 FC arrays on a common machine watching the files copy (life is that exciting) when I noticed a pause. Typing 'dmesg' provided the below data. The copy continued, I'm nervous. system: IBM xSeries 335 dual p4 1g HBA: QLogic QLA2312 dual port. Firmware 3.01.18, Driver 6.05.00b9 Kernel: 2.4.21-xfs on RH9 XFSprogs: 2.3.5-1 Array1: SUN Model: T4 src disk connected at 2G Array2: JetStor Model: III (sd(8,48)) dest disk connected at 2G XFS FS created using defaults. I was copying over 1TB of data at the time, all network file serving dameons killed. Both arrays are plugged into the same FC card. I do notice the copy is much slower than expected. For example in 1 minute only 1395308 k was copied. take care, Agent Smith 8) 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 00000002 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] -- UNIX is user friendly, it's just selective about who its friends are. From owner-linux-xfs@oss.sgi.com Wed Nov 5 12:06:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 12:07:26 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5K6k25027204 for ; Wed, 5 Nov 2003 12:06:47 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA5KQAHc013583 for ; Wed, 5 Nov 2003 14:26:10 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA5K6fP513144364; Wed, 5 Nov 2003 14:06:41 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AHTvN-0004OY-00; Wed, 05 Nov 2003 14:06:41 -0600 Date: Wed, 5 Nov 2003 14:06:40 -0600 From: Nathan Straz To: Greg Whynott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs barfing on TB fs. Message-ID: <20031105200640.GA14248@sgi.com> Mail-Followup-To: Greg Whynott , linux-xfs@oss.sgi.com References: <3FA94A37.B11B3275@calibredigital.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA94A37.B11B3275@calibredigital.com> User-Agent: Mutt/1.5.3i X-archive-position: 916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1088 Lines: 21 On Wed, Nov 05, 2003 at 02:06:31PM -0500, Greg Whynott wrote: > 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 > of file xfs_da_btree.c. Caller 0xc01d2cb7 > e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 > c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 > 00000002 > 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 > 00000001 > Call Trace: [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] You need to decode these with ksymoops so we can make sense out of them. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Nov 5 12:41:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 12:42:41 -0800 (PST) Received: from jupiter.ucsd.edu (jupiter.ucsd.edu [132.239.126.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Kfq25031421 for ; Wed, 5 Nov 2003 12:41:52 -0800 Received: from localhost (vly@localhost) by jupiter.ucsd.edu (SGI-8.9.3p2/8.9.3) with ESMTP id MAA98005 for ; Wed, 5 Nov 2003 12:59:03 -0800 (PST) Date: Wed, 5 Nov 2003 12:59:03 -0800 From: Vinh Ly To: linux-xfs@oss.sgi.com Subject: booting & HIGHMEM64G Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vly@ucsd.edu Precedence: bulk X-list: linux-xfs Content-Length: 572 Lines: 26 kernel=2.6.0-test* (SMP) distro=RedHat 9 w/ XFS glibc=2.3.2-27.9 xfs-cmds=1.3.1 When I compile the kernel w/ HIGHMEM64G=y, it will fail to boot. The error message is: Kernel panic: No init found. Try passing init= option to kernel Using the kernel option mem with a number less than 4 GB will boot fine, ie, mem=3500M. In other words, compiling it w/ HIGHMEM4G=y boots OK. The 2.4.22 kernel doesn't have a problem w/ HIGHMEM64G=y. (BTW, I upgraded to lilo version 22.5.8, but it didn't help.) Any ideas of what I should try next? Thank you, vl v.t.ly@ieee.org From owner-linux-xfs@oss.sgi.com Wed Nov 5 13:10:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 13:11:39 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5LAb25001186 for ; Wed, 5 Nov 2003 13:10:58 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-174-35.quicknet.nl [212.58.174.35]) (authenticated bits=0) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id hA5LAZI4048539; Wed, 5 Nov 2003 22:10:35 +0100 (CET) Message-Id: <4.3.2.7.2.20031105220519.03a025f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Nov 2003 22:10:34 +0100 To: Vinh Ly , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: booting & HIGHMEM64G In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 30 At 12:59 5-11-2003 -0800, Vinh Ly wrote: >kernel=2.6.0-test* (SMP) >distro=RedHat 9 w/ XFS >glibc=2.3.2-27.9 >xfs-cmds=1.3.1 > >When I compile the kernel w/ HIGHMEM64G=y, it will fail to boot. >The error message is: > > Kernel panic: No init found. Try passing init= option to kernel Perhaps an initrd error, or possibly a raid controller problem. Do you see the driver getting loaded and scrolling by assuming it is either compiled in or as a module in the initrd image. Some raid controllers like the Megaraid u160 cards actually map a piece of highmem between 3.5-4G for use. This means that it won't be possible to see it or address it since they overlap. It is also quite possible that a raid/scsi controller is unable to work with 64G highmem but that shouldn't happen. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Nov 5 13:38:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 13:38:59 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5LcJ25001854 for ; Wed, 5 Nov 2003 13:38:19 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA5JhhOO019834 for ; Wed, 5 Nov 2003 11:43:43 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA5LcDP511632254; Wed, 5 Nov 2003 15:38:13 -0600 (CST) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA5LcCRn349265573; Wed, 5 Nov 2003 15:38:12 -0600 (CST) Subject: Re: xfs barfing on TB fs. From: Russell Cattelan To: Nathan Straz Cc: Greg Whynott , linux-xfs@oss.sgi.com In-Reply-To: <20031105200640.GA14248@sgi.com> References: <3FA94A37.B11B3275@calibredigital.com> <20031105200640.GA14248@sgi.com> Content-Type: text/plain Message-Id: <1068068292.4242.41.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-9mdk Date: Wed, 05 Nov 2003 15:38:12 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 919 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 980 Lines: 20 On Wed, 2003-11-05 at 14:06, Nathan Straz wrote: > On Wed, Nov 05, 2003 at 02:06:31PM -0500, Greg Whynott wrote: > > 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Filesystem "sd(8,48)": XFS internal error xfs_da_do_buf(2) at line 2281 > > of file xfs_da_btree.c. Caller 0xc01d2cb7 > > e7d47c8c c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 > > c01d2cb7 e7d47cf4 00000002 00000001 00000000 00000005 000000f0 > > 00000002 > > 00000018 00000000 00000000 00000001 00000000 f661d800 e7d47d10 > > 00000001 > > Call Trace: [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] > > You need to decode these with ksymoops so we can make sense out of them. and file a bug in bugzilla From owner-linux-xfs@oss.sgi.com Wed Nov 5 13:52:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 13:53:19 -0800 (PST) Received: from jupiter.ucsd.edu (jupiter.ucsd.edu [132.239.126.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Lqe25005245 for ; Wed, 5 Nov 2003 13:52:41 -0800 Received: from localhost (vly@localhost) by jupiter.ucsd.edu (SGI-8.9.3p2/8.9.3) with ESMTP id OAA98950 for ; Wed, 5 Nov 2003 14:09:52 -0800 (PST) Date: Wed, 5 Nov 2003 14:09:52 -0800 From: Vinh Ly To: linux-xfs@oss.sgi.com Subject: Re: booting & HIGHMEM64G Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vly@ucsd.edu Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 18 >Do you see the driver getting loaded and scrolling by assuming it is either compiled in or as a module in the initrd image. Yes, I do see it scrolling by. It seemed to have loaded OK, and it detected my one RAID volume. I'm using the GDTH driver for my Intel controller, and it's compiled in. >It is also quite possible that a raid/scsi controller is unable to work >with 64G highmem but that shouldn't happen. The interesting part is that the 2.4.22 kernel w/ XFS works just fine. Of course, the GDTH driver is very different in version 2.6.0-test* and 2.4.22 (1.64 versus 1.61). Thanks, vl From owner-linux-xfs@oss.sgi.com Wed Nov 5 14:02:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 14:03:00 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5M2P25005725 for ; Wed, 5 Nov 2003 14:02:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA5MLkHc009180 for ; Wed, 5 Nov 2003 16:21:47 -0600 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 JAA13191; Thu, 6 Nov 2003 09:02:12 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA5M2BUc1184804; Thu, 6 Nov 2003 09:02:12 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA5M2bfY000899; Thu, 6 Nov 2003 09:02:37 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA5M2btC000897; Thu, 6 Nov 2003 09:02:37 +1100 Date: Thu, 6 Nov 2003 09:02:37 +1100 From: Nathan Scott To: Vinh Ly Cc: linux-xfs@oss.sgi.com Subject: Re: booting & HIGHMEM64G Message-ID: <20031105220237.GC780@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 797 Lines: 31 On Wed, Nov 05, 2003 at 12:59:03PM -0800, Vinh Ly wrote: > > kernel=2.6.0-test* (SMP) > distro=RedHat 9 w/ XFS > glibc=2.3.2-27.9 > xfs-cmds=1.3.1 > > When I compile the kernel w/ HIGHMEM64G=y, it will fail to boot. > The error message is: > > Kernel panic: No init found. Try passing init= option to kernel > > Using the kernel option mem with a number less than > 4 GB will boot fine, ie, mem=3500M. > In other words, compiling it w/ HIGHMEM4G=y boots OK. > > The 2.4.22 kernel doesn't have a problem w/ HIGHMEM64G=y. > > (BTW, I upgraded to lilo version 22.5.8, but it didn't help.) > > Any ideas of what I should try next? This is with an XFS root filesystem I assume? To isolate the problem to XFS, could you try an ext2 root (e.g. on a different partition). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 5 14:45:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 14:46:17 -0800 (PST) Received: from jupiter.ucsd.edu (jupiter.ucsd.edu [132.239.126.151]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Mjh25006544 for ; Wed, 5 Nov 2003 14:45:43 -0800 Received: from localhost (vly@localhost) by jupiter.ucsd.edu (SGI-8.9.3p2/8.9.3) with ESMTP id PAA99207 for ; Wed, 5 Nov 2003 15:02:55 -0800 (PST) Date: Wed, 5 Nov 2003 15:02:55 -0800 From: Vinh Ly To: linux-xfs@oss.sgi.com Subject: Re: booting & HIGHMEM64G Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vly@ucsd.edu Precedence: bulk X-list: linux-xfs Content-Length: 477 Lines: 17 >It is also quite possible that a raid/scsi controller is unable to work >with 64G highmem but that shouldn't happen. I will try the 2.5.55 kernel which has the same GDTH driver version (1.61) as in kernel 2.4.22. >This is with an XFS root filesystem I assume? To isolate >the problem to XFS, could you try an ext2 root (e.g. on a >different partition). Yes, the root fs is XFS. I will install ext2 on a different root partition and report my findings. Thank you, vl From owner-linux-xfs@oss.sgi.com Wed Nov 5 15:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 15:49:24 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA5Nmi25009067 for ; Wed, 5 Nov 2003 15:48:44 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hA5Nmh0h029452 for ; Wed, 5 Nov 2003 18:48:43 -0500 (EST) Date: Wed, 5 Nov 2003 18:48:42 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: assertion err == 0 failed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 402 Lines: 19 Hi, I am trying to repair a disk partition with XFS on it, and I get the following message: Phase 4 - check for duplicate blocks... .... data fork in regular inode 513996 claims used block 32128 xfs_repair: dinode.c:2381: process_dinode_int: Assertion `err == 0' failed. Aborted Any clue on how to proceed? (RH9.0 with 2.4.20-9SGI_XFS_1.2.0BOOT kernel as booted from the ISO cdrom) Cheers Gaspar From owner-linux-xfs@oss.sgi.com Wed Nov 5 16:14:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 16:15:15 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60EZ25010043 for ; Wed, 5 Nov 2003 16:14:36 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0011DEF1@mailhub2.arup.com>; Thu, 6 Nov 2003 0:14:30 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Thu, 06 Nov 2003 00:14:29 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Thu, 06 Nov 2003 11:12:54 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Thu, 06 Nov 2003 11:12:30 +1100 From: "Scott Fagg" To: Subject: couple of questions about version number Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA60Eb25010044 X-archive-position: 924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 405 Lines: 16 I understand that 1.3.1 is the version that SGI are encouraging us to use, so : - which versions of the kernel are 1.3.1 patches officially available for ? - which versions of the kernal do 1.3.1 patches happen to work against ? - how do i tell which version of XFS i'm using ? - what version of xfs is in 2.6.0-test9 ? regards, Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Wed Nov 5 16:31:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 16:31:49 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60VE25013622 for ; Wed, 5 Nov 2003 16:31:14 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA60V9q0001664 for ; Wed, 5 Nov 2003 16:31:09 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA60V8P513180325; Wed, 5 Nov 2003 18:31:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA60V7K15323225; Wed, 5 Nov 2003 18:31:07 -0600 (CST) Subject: Re: couple of questions about version number From: Eric Sandeen To: Scott Fagg Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1068078667.2285.62.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Nov 2003 18:31:07 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 925 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 666 Lines: 21 On Wed, 2003-11-05 at 18:12, Scott Fagg wrote: > I understand that 1.3.1 is the version that SGI are encouraging us to use, so : > > - which versions of the kernel are 1.3.1 patches officially available for ? 2.4.21 and a Red Hat errata kernel (see the ftp site) > - which versions of the kernal do 1.3.1 patches happen to work against ? you tell us ;-) > - how do i tell which version of XFS i'm using ? modinfo xfs, or dmesg | grep -i xfs > - what version of xfs is in 2.6.0-test9 ? Top of development tree minus some delta -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Nov 5 16:38:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 16:39:31 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA60cr25014500 for ; Wed, 5 Nov 2003 16:38:54 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <1.017CC407@mailhub2.arup.com>; Thu, 6 Nov 2003 0:38:49 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Thu, 06 Nov 2003 00:38:48 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Thu, 06 Nov 2003 11:37:13 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Thu, 06 Nov 2003 11:35:30 +1100 From: "Scott Fagg" To: Subject: Re: couple of questions about version number Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA60ct25014504 X-archive-position: 926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1307 Lines: 45 Neither modinfo nor dmesg | grep -i xfs gave me any clues .. [root@bneuxs01 /tmp]# modinfo xfs filename: /lib/modules/2.4.17-xfs/kernel/fs/xfs/xfs.o description: "SGI XFS with ACLs, EAs, no debug enabled" author: "SGI " license: "GPL" .. i believe this box is actually 1.1 dmesg didn't help as the box as been up for 200+ days and the info has long since gone from the log. Anyway, i'm going to upgrade all the boxes to 1.3.1 today.... aahh the joys of watching kernels compile :) Scott Fagg Arup Brisbane (07) 3023 6000 >>> Eric Sandeen 06/11/2003 10:31:07 AM >>> On Wed, 2003-11-05 at 18:12, Scott Fagg wrote: > I understand that 1.3.1 is the version that SGI are encouraging us to use, so : > > - which versions of the kernel are 1.3.1 patches officially available for ? 2.4.21 and a Red Hat errata kernel (see the ftp site) > - which versions of the kernal do 1.3.1 patches happen to work against ? you tell us ;-) > - how do i tell which version of XFS i'm using ? modinfo xfs, or dmesg | grep -i xfs > - what version of xfs is in 2.6.0-test9 ? Top of development tree minus some delta -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Nov 5 19:05:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Nov 2003 19:05:50 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA635G25018709 for ; Wed, 5 Nov 2003 19:05:16 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA61AeOO016144 for ; Wed, 5 Nov 2003 17:10:41 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA635AP513205993; Wed, 5 Nov 2003 21:05:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA6359K25310450; Wed, 5 Nov 2003 21:05:09 -0600 (CST) Date: Wed, 5 Nov 2003 21:05:09 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Scott Fagg cc: linux-xfs@oss.sgi.com Subject: Re: couple of questions about version number In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 326 Lines: 15 On Thu, 6 Nov 2003, Scott Fagg wrote: > > Neither modinfo nor dmesg | grep -i xfs gave me any clues .. > > .. i believe this box is actually 1.1 yep, I think the versioning started around 1.2. > dmesg didn't help as the box as been up for 200+ days and the info has long since gone from the log. good for you :) -Eric From owner-linux-xfs@oss.sgi.com Thu Nov 6 03:59:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 04:00:21 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Bxd25001750 for ; Thu, 6 Nov 2003 03:59:40 -0800 Received: from online.no (29.80-203-65.nextgentel.com [80.203.65.29]) by mail.broadpark.no (Postfix) with ESMTP id BA7FB78835 for ; Thu, 6 Nov 2003 12:59:30 +0100 (MET) Message-ID: <3FAA37DD.3070409@online.no> Date: Thu, 06 Nov 2003 13:00:29 +0100 From: Knut J Bjuland User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS installer for Fedora 1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs Content-Length: 90 Lines: 4 Will there be a Fedora XFS 1.3.1 installer since Redhat XFS 1.3 installer was removed? From owner-linux-xfs@oss.sgi.com Thu Nov 6 04:37:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 04:38:17 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6CbU25006344 for ; Thu, 6 Nov 2003 04:37:31 -0800 Received: (qmail 1897 invoked from network); 6 Nov 2003 12:37:27 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Nov 2003 12:37:27 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 0B750C00AC; Thu, 6 Nov 2003 23:37:05 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 08B1E140126; Thu, 6 Nov 2003 23:37:05 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 In-reply-to: Your message of "Thu, 06 Nov 2003 13:00:29 BST." <3FAA37DD.3070409@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Nov 2003 23:37:04 +1100 Message-ID: <4379.1068122224@ocs3.intra.ocs.com.au> X-archive-position: 930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 10 On Thu, 06 Nov 2003 13:00:29 +0100, Knut J Bjuland wrote: >Will there be a Fedora XFS 1.3.1 installer since Redhat XFS 1.3 >installer was removed? The entire Fedora model is based on community involvement and enhancement. Now is the time for everybody who wants XFS in 2.4 kernels from RH to get on the Fedora list and request this feature. RH will not add XFS to Fedora unless the community pushes for it. From owner-linux-xfs@oss.sgi.com Thu Nov 6 09:09:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 09:10:30 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6H9h25013536 for ; Thu, 6 Nov 2003 09:09:48 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA6H9EEi025657; Thu, 6 Nov 2003 18:09:19 +0100 Message-ID: <3FAA80AA.5000405@stesmi.com> Date: Thu, 06 Nov 2003 18:11:06 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Knut J Bjuland CC: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 References: <3FAA37DD.3070409@online.no> In-Reply-To: <3FAA37DD.3070409@online.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 252 Lines: 14 Knut J Bjuland wrote: > Will there be a Fedora XFS 1.3.1 installer since Redhat XFS 1.3 > installer was removed? > > Wouldn't surprise me if .. someone .. would make such a thing and even possibly make a DVD out of it. // Stefan From owner-linux-xfs@oss.sgi.com Thu Nov 6 09:57:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 09:57:32 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Hut25014733 for ; Thu, 6 Nov 2003 09:56:59 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 30B641400F31; Thu, 6 Nov 2003 12:56:55 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 1BF211437074; Thu, 6 Nov 2003 12:56:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 1A1473021462; Thu, 6 Nov 2003 12:56:51 -0500 (EST) Date: Thu, 6 Nov 2003 12:56:50 -0500 (EST) From: Mike Burger To: Stefan Smietanowski Cc: Knut J Bjuland , Subject: Re: XFS installer for Fedora 1 In-Reply-To: <3FAA80AA.5000405@stesmi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 40 If you do, Stefan, please make sure to let the list know...I'm debating sticking with RH/Fedora, or going to SuSE. Does anyone know if the SuSE distribution currently includes XFS support? On Thu, 6 Nov 2003, Stefan Smietanowski wrote: > Knut J Bjuland wrote: > > > Will there be a Fedora XFS 1.3.1 installer since Redhat XFS 1.3 > > installer was removed? > > > > > > Wouldn't surprise me if .. someone .. would make such a thing > and even possibly make a DVD out of it. > > > > // Stefan > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Thu Nov 6 10:05:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 10:06:19 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6I5e25015228 for ; Thu, 6 Nov 2003 10:05:42 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA6I5TEi025769; Thu, 6 Nov 2003 19:05:30 +0100 Message-ID: <3FAA8DD9.8060903@stesmi.com> Date: Thu, 06 Nov 2003 19:07:21 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Burger CC: Knut J Bjuland , linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 851 Lines: 39 Hi Mike. Well, I'm awaiting my RHEL CDs and I have the Fedora Core 1 ISOs here (no, downloading is NOT fun contrary to public belief :)) and I'm planning on looking at them both to convert to XFS just like I did with RH9 when it came. Wrap up some DVDs for them as well. // Stefan Mike Burger wrote: > If you do, Stefan, please make sure to let the list know...I'm debating > sticking with RH/Fedora, or going to SuSE. > > Does anyone know if the SuSE distribution currently includes XFS support? > > On Thu, 6 Nov 2003, Stefan Smietanowski wrote: > > >>Knut J Bjuland wrote: >> >> >>>Will there be a Fedora XFS 1.3.1 installer since Redhat XFS 1.3 >>>installer was removed? >>> >>> >> >>Wouldn't surprise me if .. someone .. would make such a thing >>and even possibly make a DVD out of it. >> >> >> >>// Stefan >> >> > > From owner-linux-xfs@oss.sgi.com Thu Nov 6 10:22:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 10:22:44 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6IM925015764 for ; Thu, 6 Nov 2003 10:22:09 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA6IM4q0008430 for ; Thu, 6 Nov 2003 10:22:04 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA6IM3P513296397; Thu, 6 Nov 2003 12:22:03 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA6IM1K15374658; Thu, 6 Nov 2003 12:22:01 -0600 (CST) Subject: Re: XFS installer for Fedora 1 From: Eric Sandeen To: Stefan Smietanowski Cc: Mike Burger , Knut J Bjuland , linux-xfs@oss.sgi.com In-Reply-To: <3FAA8DD9.8060903@stesmi.com> References: <3FAA8DD9.8060903@stesmi.com> Content-Type: text/plain Organization: Message-Id: <1068142921.1405.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 12:22:02 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 694 Lines: 20 Glad to hear you guys are looking at this. I don't mind putting together patches and maybe a spec file to make XFS 1.3.1 work in FC1 - if you guys want to take that, build some RPMS & installers, that sounds great! -Eric On Thu, 2003-11-06 at 12:07, Stefan Smietanowski wrote: > Hi Mike. > > Well, I'm awaiting my RHEL CDs and I have the Fedora Core 1 ISOs here > (no, downloading is NOT fun contrary to public belief :)) and I'm > planning on looking at them both to convert to XFS just like I did > with RH9 when it came. Wrap up some DVDs for them as well. > > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 6 10:47:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 10:47:44 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Il925016347 for ; Thu, 6 Nov 2003 10:47:09 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA6GqZOO030171 for ; Thu, 6 Nov 2003 08:52:36 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA6Il2P513298952; Thu, 6 Nov 2003 12:47:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA6Il1K15417034; Thu, 6 Nov 2003 12:47:01 -0600 (CST) Subject: Re: XFS installer for Fedora 1 From: Eric Sandeen To: Mike Burger Cc: Stefan Smietanowski , Knut J Bjuland , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1068144421.1405.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 12:47:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 184 Lines: 8 On Thu, 2003-11-06 at 11:56, Mike Burger wrote: > Does anyone know if the SuSE distribution currently includes XFS support? Yes, SuSE was one of the early supporters of XFS. -Eric From owner-linux-xfs@oss.sgi.com Thu Nov 6 10:47:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 10:47:48 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6IlA25016348 for ; Thu, 6 Nov 2003 10:47:13 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA6Ik2Ei025839; Thu, 6 Nov 2003 19:46:02 +0100 Message-ID: <3FAA975A.8040301@stesmi.com> Date: Thu, 06 Nov 2003 19:47:54 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Mike Burger , Knut J Bjuland , linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 References: <3FAA8DD9.8060903@stesmi.com> <1068142921.1405.2.camel@stout.americas.sgi.com> In-Reply-To: <1068142921.1405.2.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 26 Hi Eric. Terrific. I'll make a system I can build from (I always build itself using itself, sortof like GCC) and then get started on the rest. // Stefan > Glad to hear you guys are looking at this. I don't mind putting > together patches and maybe a spec file to make XFS 1.3.1 work in FC1 - > if you guys want to take that, build some RPMS & installers, that sounds > great! > > -Eric > > On Thu, 2003-11-06 at 12:07, Stefan Smietanowski wrote: > >>Hi Mike. >> >>Well, I'm awaiting my RHEL CDs and I have the Fedora Core 1 ISOs here >>(no, downloading is NOT fun contrary to public belief :)) and I'm >>planning on looking at them both to convert to XFS just like I did >>with RH9 when it came. Wrap up some DVDs for them as well. >> >> From owner-linux-xfs@oss.sgi.com Thu Nov 6 10:54:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 10:54:47 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6IsD25017160 for ; Thu, 6 Nov 2003 10:54:14 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 010EC1400F31; Thu, 6 Nov 2003 13:54:14 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 437E11437074; Thu, 6 Nov 2003 13:54:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 253EC3021462; Thu, 6 Nov 2003 13:54:12 -0500 (EST) Date: Thu, 6 Nov 2003 13:54:11 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: Stefan Smietanowski , Knut J Bjuland , Subject: Re: XFS installer for Fedora 1 In-Reply-To: <1068144421.1405.4.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 689 Lines: 27 On 6 Nov 2003, Eric Sandeen wrote: > On Thu, 2003-11-06 at 11:56, Mike Burger wrote: > > > Does anyone know if the SuSE distribution currently includes XFS support? > > Yes, SuSE was one of the early supporters of XFS. Excellent!!! At least, that way, I'll know that if I decide to migrate, my /home and /var don't have to be abandoned. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Thu Nov 6 11:06:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 11:07:00 -0800 (PST) Received: from mail.frequentous.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6J6L25017632 for ; Thu, 6 Nov 2003 11:06:25 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.frequentous.co.uk (Postfix) with ESMTP id C19DE28FDF3 for ; Thu, 6 Nov 2003 19:06:14 +0000 (GMT) Received: from mail.frequentous.co.uk ([127.0.0.1]) by localhost (utahia [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25277-09 for ; Thu, 6 Nov 2003 19:06:14 +0000 (GMT) Received: from arequipa.sweeney.demon.co.uk (unknown [10.0.0.180]) by mail.frequentous.co.uk (Postfix) with SMTP id 2DF0828FDF2 for ; Thu, 6 Nov 2003 19:06:14 +0000 (GMT) Date: Thu, 6 Nov 2003 19:08:25 +0000 From: Keith Matthews To: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 Message-Id: <20031106190825.1d21a626.keith_m@sweeney.demon.co.uk> In-Reply-To: <1068144421.1405.4.camel@stout.americas.sgi.com> References: <1068144421.1405.4.camel@stout.americas.sgi.com> Organization: Frequentous Consultants Ltd X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: keith_m@sweeney.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 985 Lines: 28 On 06 Nov 2003 12:47:01 -0600 Eric Sandeen wrote: > On Thu, 2003-11-06 at 11:56, Mike Burger wrote: > > > Does anyone know if the SuSE distribution currently includes XFS > > support? > > Yes, SuSE was one of the early supporters of XFS. > > Despite the 8.1 system saying something like 'are you sure you want to use XFS, its still experimental'. BTW, if anyone wants to use SuSE to re-install without reformatting any of the filesystems - DONT. the installer as of 8.1 has no way for the user to specify the f/s type and assumes it is ext2/3. Certainly ext3 is the value put in the new fstab. ext2.fsck then comes along and tries to check it, complaining bitterly as it goes which implies the FS magic number has been overwritten (God only knows why if the f/s is not to be reformatted). If it was XFS the result is a completely trashed superblock. I have not checked 8.2. The RH and Slackware installers check, detect correctly and ask the user to confirm. From owner-linux-xfs@oss.sgi.com Thu Nov 6 11:09:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 11:09:42 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6J9925018037 for ; Thu, 6 Nov 2003 11:09:09 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 77DD01400F37; Thu, 6 Nov 2003 14:09:09 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 4ED471437074; Thu, 6 Nov 2003 14:09:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4CEAD3021462; Thu, 6 Nov 2003 14:09:08 -0500 (EST) Date: Thu, 6 Nov 2003 14:09:08 -0500 (EST) From: Mike Burger To: Keith Matthews Cc: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 In-Reply-To: <20031106190825.1d21a626.keith_m@sweeney.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1477 Lines: 48 On Thu, 6 Nov 2003, Keith Matthews wrote: > On 06 Nov 2003 12:47:01 -0600 > Eric Sandeen wrote: > > > On Thu, 2003-11-06 at 11:56, Mike Burger wrote: > > > > > Does anyone know if the SuSE distribution currently includes XFS > > > support? > > > > Yes, SuSE was one of the early supporters of XFS. > > > > > Despite the 8.1 system saying something like 'are you sure you want to > use XFS, its still experimental'. > > BTW, if anyone wants to use SuSE to re-install without reformatting any > of the filesystems - DONT. the installer as of 8.1 has no way for the > user to specify the f/s type and assumes it is ext2/3. Certainly ext3 is > the value put in the new fstab. ext2.fsck then comes along and tries to > check it, complaining bitterly as it goes which implies the FS magic > number has been overwritten (God only knows why if the f/s is not to be > reformatted). If it was XFS the result is a completely trashed > superblock. > > I have not checked 8.2. > > The RH and Slackware installers check, detect correctly and ask the user > to confirm. Hmm...I wonder about the current SuSE 9 release. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Thu Nov 6 11:21:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 11:22:17 -0800 (PST) Received: from mx03.ca.mci.com (mx03.ca.mci.com [142.77.2.11]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6JLd25018504 for ; Thu, 6 Nov 2003 11:21:40 -0800 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx03.ca.mci.com (Postfix) with ESMTP id 26941DF8B; Thu, 6 Nov 2003 14:21:34 -0500 (EST) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id hA6JLQ621445; Thu, 6 Nov 2003 14:21:26 -0500 Message-ID: <3FAA9F75.7915E777@calibredigital.com> Date: Thu, 06 Nov 2003 14:22:29 -0500 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Straz Cc: linux-xfs@oss.sgi.com Subject: Re: xfs barfing on TB fs. References: <3FA94A37.B11B3275@calibredigital.com> <20031105200640.GA14248@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 3100 Lines: 84 > You need to decode these with ksymoops so we can make sense out of them. whoops sorry folks. I'll send it to bugz too. greg Here is the output: [root@nova ksymoops-2.4.9]# ksymoops -m /boot/System.map-2.4.21-xfs -o /lib/modules/2.4.21-xfs/ -l /proc/modules -k /proc/ksyms /tmp/oops ksymoops 2.4.9 on i686 2.4.21-xfs. Options used -V (default) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.21-xfs/ (specified) -m /boot/System.map-2.4.21-xfs (specified) Warning (compare_maps): ksyms_base symbol create_bounce_R__ver_create_bounce not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol highmem_start_page_R__ver_highmem_start_page not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_high_R__ver_kmap_high not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_prot_R__ver_kmap_prot not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_pte_R__ver_kmap_pte not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kunmap_high_R__ver_kunmap_high not found in System.map. Ignoring ksyms_base entry df065d08 c01d2839 c031a3ae 00000001 f661d800 c031a2b5 000008e9 c01d2cb7 c01d2cb7 df065d70 00000001 c01ea8b1 d5bfb980 00001200 f7223280 310000a0 00000018 00000000 00000000 00000001 00000000 f661d800 df065d8c 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01d2839 Trace; c01d2cb7 Trace; c01d2cb7 Trace; c01ea8b1 Trace; c02103f5 <_pagebuf_free_object+a5/120> Trace; c01d2cb7 Trace; c01d6a3d Trace; c01d6a3d Trace; c01c49df Trace; c01e9b33 Trace; c01d5cd0 Trace; c01d5bf2 Trace; c01d5cd0 Trace; c01d5431 Trace; c01d5cd0 Trace; c020c2b5 Trace; c02154b0 Trace; c01eec48 Trace; c01ea1de Trace; c014fe7e Trace; c01505b0 Trace; c015071b Trace; c01505b0 Trace; c014f46d Trace; c010770f 7 warnings issued. Results may not be reliable. -- UNIX is user friendly, it's just selective about who its friends are. From owner-linux-xfs@oss.sgi.com Thu Nov 6 12:13:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 12:14:34 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6KDu25020025 for ; Thu, 6 Nov 2003 12:13:58 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hA6KDexv026256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Nov 2003 21:13:51 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hA6KDbN2017282; Thu, 6 Nov 2003 21:13:37 +0100 Date: Thu, 6 Nov 2003 21:13:37 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 Message-ID: <20031106201337.GG13576@puariko.nirvana> References: <1068144421.1405.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bO4vSxwwZtUjUWHo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1505 Lines: 49 --bO4vSxwwZtUjUWHo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 01:54:11PM -0500, Mike Burger wrote: > On 6 Nov 2003, Eric Sandeen wrote: >=20 > > On Thu, 2003-11-06 at 11:56, Mike Burger wrote: > >=20 > > > Does anyone know if the SuSE distribution currently includes XFS supp= ort? > >=20 > > Yes, SuSE was one of the early supporters of XFS. >=20 > Excellent!!! At least, that way, I'll know that if I decide to migrate,= =20 > my /home and /var don't have to be abandoned. You can use apt or yum to upgrade which will not replace your kernel w/o your explicit wish to do so ;) In fact one can take a Fedora Core kernel enriched with XFS (like the ATrpms kernel) and install it on a RH9 and then do the apt/yum upgrade. Nevertheless Keith is right in asking for pressure at RH for XFS inclusion. They are indeed only a micrometer away from it, so a small push would suffice (at least one is tempted to think so ...;). Fedora Core 2 is scheduled 4-6 months from now, start lobbying! :) (I don't think RH will put XFS in the "updates", previously known as "errata") --=20 Axel.Thimm@physik.fu-berlin.de --bO4vSxwwZtUjUWHo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qqtxQBVS1GOamfERAskoAJ9tqkOfDrAcxwutyjW6GDCjGUqUkQCfWSMu HZhC8F32GHLlBD13paX7He0= =SJcF -----END PGP SIGNATURE----- --bO4vSxwwZtUjUWHo-- From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:08:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:08:37 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6L8125024922 for ; Thu, 6 Nov 2003 13:08:03 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA6JDSOO015333 for ; Thu, 6 Nov 2003 11:13:28 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA6L7sP513317235; Thu, 6 Nov 2003 15:07:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA6L7rK15435094; Thu, 6 Nov 2003 15:07:53 -0600 (CST) Subject: Re: XFS installer for Fedora 1 From: Eric Sandeen To: Axel Thimm Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031106201337.GG13576@puariko.nirvana> References: <1068144421.1405.4.camel@stout.americas.sgi.com> <20031106201337.GG13576@puariko.nirvana> Content-Type: text/plain Organization: Message-Id: <1068152873.1405.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 15:07:53 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 15 On Thu, 2003-11-06 at 14:13, Axel Thimm wrote: > Fedora Core 2 is scheduled 4-6 months from now, start lobbying! :) (I > don't think RH will put XFS in the "updates", previously known as > "errata") FC2 is supposed to have the linux 2.6 kernel, so if they strip xfs out of that, then we'll know how they -really- feel about us. ;-) -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:15:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:16:23 -0800 (PST) Received: from cyber1hq.adic.com (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LFb25025707 for ; Thu, 6 Nov 2003 13:15:37 -0800 X-Authentication-Warning: localhost.localdomain: slord set sender to lord@adic.com using -f Subject: Re: XFS installer for Fedora 1 From: Steve Lord To: Eric Sandeen Cc: Axel Thimm , linux-xfs@oss.sgi.com In-Reply-To: <1068152873.1405.6.camel@adic.com> References: <1068144421.1405.4.camel@adic.com> <20031106201337.GG13576@puariko.nirvana> <1068152873.1405.6.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1068153344.2657.212.camel@adic.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 15:15:44 -0600 X-archive-position: 943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Content-Length: 605 Lines: 16 On Thu, 2003-11-06 at 15:07, Eric Sandeen wrote: > On Thu, 2003-11-06 at 14:13, Axel Thimm wrote: > > > Fedora Core 2 is scheduled 4-6 months from now, start lobbying! :) (I > > don't think RH will put XFS in the "updates", previously known as > > "errata") > > FC2 is supposed to have the linux 2.6 kernel, so if they strip xfs out > of that, then we'll know how they -really- feel about us. ;-) Has anyone looked at the kernel rpms Arjan is creating for 2.6, there is an unsupported kernel rpm, I have not downloaded or looked inside them, but I have this terrible sinking feeling about it. Steve From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:29:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:30:13 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LTa25026540 for ; Thu, 6 Nov 2003 13:29:37 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hA6LTYxv008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Nov 2003 22:29:35 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hA6LTWXu021860; Thu, 6 Nov 2003 22:29:32 +0100 Date: Thu, 6 Nov 2003 22:29:31 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 Message-ID: <20031106212931.GL13576@puariko.nirvana> References: <1068144421.1405.4.camel@adic.com> <20031106201337.GG13576@puariko.nirvana> <1068152873.1405.6.camel@stout.americas.sgi.com> <1068153344.2657.212.camel@adic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+278g007AL/ykmV8" Content-Disposition: inline In-Reply-To: <1068153344.2657.212.camel@adic.com> User-Agent: Mutt/1.4.1i X-archive-position: 944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1512 Lines: 45 --+278g007AL/ykmV8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 03:15:44PM -0600, Steve Lord wrote: > On Thu, 2003-11-06 at 15:07, Eric Sandeen wrote: > > On Thu, 2003-11-06 at 14:13, Axel Thimm wrote: > >=20 > > > Fedora Core 2 is scheduled 4-6 months from now, start lobbying! :) (I > > > don't think RH will put XFS in the "updates", previously known as > > > "errata") > >=20 > > FC2 is supposed to have the linux 2.6 kernel, so if they strip xfs out > > of that, then we'll know how they -really- feel about us. ;-) >=20 > Has anyone looked at the kernel rpms Arjan is creating for 2.6, there > is an unsupported kernel rpm, I have not downloaded or looked inside > them, but I have this terrible sinking feeling about it. No, xfs is not (yet?) moved to the unsupported rpm: /lib/modules/2.6.0-0.test9.1.70/kernel/fs/xfs/xfs.ko The more important point is will RH introduce proper anaconda support for XFS? At least like jfs/reiserfs have with "hidden" enablers? The XFS patches are said to have found their way into anaconda, but are not enabled (didn't check lately). --=20 Axel.Thimm@physik.fu-berlin.de --+278g007AL/ykmV8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qr07QBVS1GOamfERApvGAJ9PdD9L4jaaI62+J2GSK1lTngflsACgjezi VRnnbZdqKMJKOoQpd8uJCl4= =oo+F -----END PGP SIGNATURE----- --+278g007AL/ykmV8-- From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:34:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:34:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LYN25026941 for ; Thu, 6 Nov 2003 13:34:24 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA6LrkHc001588 for ; Thu, 6 Nov 2003 15:53:49 -0600 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 IAA27605; Fri, 7 Nov 2003 08:34:08 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA6LY6Uc1210622; Fri, 7 Nov 2003 08:34:07 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA6LYTZQ000801; Fri, 7 Nov 2003 08:34:29 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA6LYPtM000799; Fri, 7 Nov 2003 08:34:25 +1100 Date: Fri, 7 Nov 2003 08:34:25 +1100 From: Nathan Scott To: Mike Burger Cc: Stefan Smietanowski , Knut J Bjuland , linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 Message-ID: <20031106213425.GA782@frodo> References: <3FAA80AA.5000405@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 14 On Thu, Nov 06, 2003 at 12:56:50PM -0500, Mike Burger wrote: > > Does anyone know if the SuSE distribution currently includes XFS support? > It does indeed, and Suse have supported XFS in a number of ways for a long time now - particularly Andreas Gruenbacher and Andi Kleen have worked with us a whole lot. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:38:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:39:05 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6LcV25027327 for ; Thu, 6 Nov 2003 13:38:32 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA6JhxOO018019 for ; Thu, 6 Nov 2003 11:43:59 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA6LcQP513369963; Thu, 6 Nov 2003 15:38:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA6LcPK15411872; Thu, 6 Nov 2003 15:38:25 -0600 (CST) Subject: Re: XFS installer for Fedora 1 From: Eric Sandeen To: Steve Lord Cc: Axel Thimm , linux-xfs@oss.sgi.com In-Reply-To: <1068153344.2657.212.camel@adic.com> References: <1068144421.1405.4.camel@adic.com> <20031106201337.GG13576@puariko.nirvana> <1068152873.1405.6.camel@stout.americas.sgi.com> <1068153344.2657.212.camel@adic.com> Content-Type: text/plain Organization: Message-Id: <1068154705.1405.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 15:38:25 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 704 Lines: 19 On Thu, 2003-11-06 at 15:15, Steve Lord wrote: > Has anyone looked at the kernel rpms Arjan is creating for 2.6, there > is an unsupported kernel rpm, I have not downloaded or looked inside > them, but I have this terrible sinking feeling about it. [sandeen@stout sandeen]$ rpm -qpl kernel-smp-unsupported-2.6.0-0.test9.1.70.i686.rpm | grep xfs.ko /lib/modules/2.6.0-0.test9.1.70smp/unsupported/fs/freevxfs/freevxfs.ko boo.... [sandeen@stout sandeen]$ rpm -qpl kernel-smp-2.6.0-0.test9.1.70.i686.rpm | grep xfs.ko /lib/modules/2.6.0-0.test9.1.70smp/kernel/fs/xfs/xfs.ko Yay! -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 6 13:40:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 13:41:15 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6Led25027709 for ; Thu, 6 Nov 2003 13:40:41 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA6Jk1OO018374 for ; Thu, 6 Nov 2003 11:46:06 -0800 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 IAA27650; Fri, 7 Nov 2003 08:40:26 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA6LeOUc1223049; Fri, 7 Nov 2003 08:40:25 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA6LemZQ000838; Fri, 7 Nov 2003 08:40:48 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA6LekSi000836; Fri, 7 Nov 2003 08:40:46 +1100 Date: Fri, 7 Nov 2003 08:40:46 +1100 From: Nathan Scott To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: assertion err == 0 failed Message-ID: <20031106214046.GB782@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 23 On Wed, Nov 05, 2003 at 06:48:42PM -0500, Gaspar Bakos wrote: > Hi, > > I am trying to repair a disk partition with XFS on it, and I get the > following message: > > Phase 4 - check for duplicate blocks... > .... > data fork in regular inode 513996 claims used block 32128 > xfs_repair: dinode.c:2381: process_dinode_int: Assertion `err == 0' > failed. > Aborted Looks like a case that xfs_repair doesn't know how to handle, or expects to have seen fixed in an earlier phase. Options are to either hack on repair to fix/work around the issue, or do a restore from backups... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 6 14:31:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 14:32:22 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6MVe25029021 for ; Thu, 6 Nov 2003 14:31:41 -0800 Received: (qmail 19361 invoked from network); 6 Nov 2003 22:31:38 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Nov 2003 22:31:38 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E9EC7C00AA; Fri, 7 Nov 2003 09:31:14 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E6EBD14008C; Fri, 7 Nov 2003 09:31:14 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Greg Whynott Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: xfs barfing on TB fs. In-reply-to: Your message of "Thu, 06 Nov 2003 14:22:29 CDT." <3FAA9F75.7915E777@calibredigital.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Nov 2003 09:31:13 +1100 Message-ID: <11738.1068157873@ocs3.intra.ocs.com.au> X-archive-position: 948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1280 Lines: 26 On Thu, 06 Nov 2003 14:22:29 -0500, Greg Whynott wrote: >Warning (compare_maps): ksyms_base symbol >create_bounce_R__ver_create_bounce not found in System.map. Ignoring >ksyms_base entry >Warning (compare_maps): ksyms_base symbol >highmem_start_page_R__ver_highmem_start_page not found in System.map. >Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol kmap_high_R__ver_kmap_high not >found in System.map. Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol kmap_prot_R__ver_kmap_prot not >found in System.map. Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol kmap_pte_R__ver_kmap_pte not >found in System.map. Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol kunmap_high_R__ver_kunmap_high >not found in System.map. Ignoring ksyms_base entry Those ksymoops messages indicate an incomplete kernel build. At some stage you switched the value of CONFIG_HIGHMEM and rebuilt but the kernel build process did not get it right, one of the many known kbuild 2.4 bugs. It has probably not caused any problems, OTOH it cannot be ruled out as a possible cause of your problem. Can you do a complete kernel build starting from make mrproper and see if the problem still exists? From owner-linux-xfs@oss.sgi.com Thu Nov 6 15:03:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 15:04:42 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6N3v25029930 for ; Thu, 6 Nov 2003 15:03:58 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hA6N3rxv027197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Nov 2003 00:03:55 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hA6N3q3F024152; Fri, 7 Nov 2003 00:03:52 +0100 Date: Fri, 7 Nov 2003 00:03:51 +0100 From: Axel Thimm To: fedora-list@redhat.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem support in Fedora Message-ID: <20031106230351.GP13576@puariko.nirvana> References: <20031106210804.B034A1437074@burgers.bubbanfriends.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r/w8vo2lxBmCPGjQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1400 Lines: 47 --r/w8vo2lxBmCPGjQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 07:14:27PM -0300, Fabian Arias wrote: > On Thu, 6 Nov 2003, Mike Burger wrote: >=20 > > Are there any plans to include SGI's XFS filesystem support into Fedora= 's > > kernels and/or installers? >=20 > >=20 > XFS support in 2.4 kernels require too much API rewrite, and don't seem to > be useful such an effort when 2.6 is out of the door, with vanilla XFS > support included. There is currently very little to do kernel wise to get Fedora Core kernels to run XFS (in fact Fedora Core kernels already _do_ have XFS, but not XFS 1.3.x). > > Such support would be incredibly appreciated. >=20 > Shure it would, but unpractical (in terms of development I mean) for now > until a couple of next releases that ships 2.6 kernels. It would be great if the FC steering committee or whoever is in charge would decide to add the very little needed hooks to allow for externaly built xfs kernel modules. --=20 Axel.Thimm@physik.fu-berlin.de --r/w8vo2lxBmCPGjQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qtNXQBVS1GOamfERAh7JAJ48pWf1NTjb/QmaFCJr7YraL1uD3ACgknXB cXJiOShY1PfmJtrZkz6KtA4= =8jSW -----END PGP SIGNATURE----- --r/w8vo2lxBmCPGjQ-- From owner-linux-xfs@oss.sgi.com Thu Nov 6 15:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 15:37:13 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA6NaV25030706 for ; Thu, 6 Nov 2003 15:36:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA6NaPq0016600 for ; Thu, 6 Nov 2003 15:36:25 -0800 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 KAA29300; Fri, 7 Nov 2003 10:36:22 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA6NaLUc1230354; Fri, 7 Nov 2003 10:36:22 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA6NakZQ001157; Fri, 7 Nov 2003 10:36:46 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA6Najol001155; Fri, 7 Nov 2003 10:36:45 +1100 Date: Fri, 7 Nov 2003 10:36:45 +1100 From: Nathan Scott To: Greg Whynott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs barfing on TB fs. Message-ID: <20031106233645.GD782@frodo> References: <3FAA9F75.7915E777@calibredigital.com> <11738.1068157873@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11738.1068157873@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.5.3i X-archive-position: 950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1646 Lines: 40 hi Greg, On Fri, Nov 07, 2003 at 09:31:13AM +1100, Keith Owens wrote: > On Thu, 06 Nov 2003 14:22:29 -0500, > Greg Whynott wrote: > >Warning (compare_maps): ksyms_base symbol > >create_bounce_R__ver_create_bounce not found in System.map. Ignoring > >ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >highmem_start_page_R__ver_highmem_start_page not found in System.map. > >Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol kmap_high_R__ver_kmap_high not > >found in System.map. Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol kmap_prot_R__ver_kmap_prot not > >found in System.map. Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol kmap_pte_R__ver_kmap_pte not > >found in System.map. Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol kunmap_high_R__ver_kunmap_high > >not found in System.map. Ignoring ksyms_base entry > > Those ksymoops messages indicate an incomplete kernel build. At some > stage you switched the value of CONFIG_HIGHMEM and rebuilt but the > kernel build process did not get it right, one of the many known kbuild > 2.4 bugs. > > It has probably not caused any problems, OTOH it cannot be ruled out as > a possible cause of your problem. Can you do a complete kernel build > starting from make mrproper and see if the problem still exists? And if you have a reproducible test case showing this problem, I would _really_ like to hear the details, please -- an exact recipe, from go (mkfs) to woe would be extremely helpful. Thanks for reporting the problem, btw. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 6 16:24:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 16:25:31 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA70Op25011342 for ; Thu, 6 Nov 2003 16:24:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA6MUIOO002259 for ; Thu, 6 Nov 2003 14:30:19 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA70OjP513236761 for ; Thu, 6 Nov 2003 18:24:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA70OiK15448210 for ; Thu, 6 Nov 2003 18:24:44 -0600 (CST) Subject: FC1 + XFS 1.3.1: test SRPM available From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1068164684.1405.42.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Nov 2003 18:24:44 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 720 Lines: 19 So I was feeling charitable today... You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that seems to more or less pass our QA suite. It's a hurry-up job though, so give it some cautious testing if you'd like. To the RH folks, if you're listening, I think I've done patches in such a way that you can strip out acls & dmapi, and have a functional xfs with extremely minimal impact to the rest of the kernel. (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch would be nice). -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 6 17:00:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 17:01:36 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA710X25012084 for ; Thu, 6 Nov 2003 17:00:54 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA710WEi027119; Fri, 7 Nov 2003 02:00:32 +0100 Message-ID: <3FAAEF21.1040900@stesmi.com> Date: Fri, 07 Nov 2003 02:02:25 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: <1068164684.1405.42.camel@stout.americas.sgi.com> In-Reply-To: <1068164684.1405.42.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 844 Lines: 23 Hi Eric. > So I was feeling charitable today... > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > seems to more or less pass our QA suite. It's a hurry-up job though, so > give it some cautious testing if you'd like. > > To the RH folks, if you're listening, I think I've done patches in such > a way that you can strip out acls & dmapi, and have a functional xfs > with extremely minimal impact to the rest of the kernel. > (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be > able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch > would be nice). Someone's been keeping busy I see. Alright, I'll try to have a mockup an installer this weekend for FC1. No promises though. Excellent work. One thought only ... Aren't ACLs enabled on the normal FC1 kernel? // Stefan From owner-linux-xfs@oss.sgi.com Thu Nov 6 17:10:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 17:11:09 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA71AZ25012524 for ; Thu, 6 Nov 2003 17:10:36 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA71U3Hc007126 for ; Thu, 6 Nov 2003 19:30:03 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA71AUP513351566; Thu, 6 Nov 2003 19:10:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA71ATK25454732; Thu, 6 Nov 2003 19:10:29 -0600 (CST) Date: Thu, 6 Nov 2003 19:10:29 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available In-Reply-To: <3FAAEF21.1040900@stesmi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 227 Lines: 13 I saw it in the configs, but i did not see any acl headers... -eric On Fri, 7 Nov 2003, Stefan Smietanowski wrote: > Excellent work. One thought only ... Aren't ACLs enabled on the normal > FC1 kernel? > > // Stefan > > From owner-linux-xfs@oss.sgi.com Thu Nov 6 17:34:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 17:35:16 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA71YZ25013042 for ; Thu, 6 Nov 2003 17:34:35 -0800 Received: from tlinx.org (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id hA71YRNI027050 for ; Thu, 6 Nov 2003 17:34:27 -0800 Message-ID: <3FAAF6A3.6020405@tlinx.org> Date: Thu, 06 Nov 2003 17:34:27 -0800 From: lw User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en-ca, en-gb, en-nz, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Fedora 1 References: <1068144421.1405.4.camel@stout.americas.sgi.com> <20031106190825.1d21a626.keith_m@sweeney.demon.co.uk> In-Reply-To: <20031106190825.1d21a626.keith_m@sweeney.demon.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2220 Lines: 74 I was able to specify file system types and which partitions to format/not format and have been using a SuSE-supported XFS root partition since 8.0 -- using XFS under SuSE since 7.3. Had some hiccups in the 9.0 upgrade (didn't recognize my 8.1 SuSE release as an upgradable version -- no doubt because I was supposed to upgrade to 8.2 in between time), but have never lost data in the way you describe. I always do the manual config though -- the automatic config gives you about as much control as a sledge hammer. Also had no problem with their installer doing a new install onto a Win-disk and resizing the FAT partition. It just seems to be upgrades from their own previous vesions that sometimes run a bit rough. You can tell their level of testing / intent: even when it discovers a previous version, the install option defaults to "new install (formatting old system) rather than upgrade :-/. But selecting upgrade, it had no problem recognizing and mounting XFS partitions. Of course now that Novell has bought them, all bets are off. Hard to think of Novell having enough Linux savvy to make such a marriage work. -l Keith Matthews wrote: >On 06 Nov 2003 12:47:01 -0600 >Eric Sandeen wrote: > > > >>On Thu, 2003-11-06 at 11:56, Mike Burger wrote: >> >> >> >>>Does anyone know if the SuSE distribution currently includes XFS >>>support? >>> >>> >>Yes, SuSE was one of the early supporters of XFS. >> >> >> >> >Despite the 8.1 system saying something like 'are you sure you want to >use XFS, its still experimental'. > >BTW, if anyone wants to use SuSE to re-install without reformatting any >of the filesystems - DONT. the installer as of 8.1 has no way for the >user to specify the f/s type and assumes it is ext2/3. Certainly ext3 is >the value put in the new fstab. ext2.fsck then comes along and tries to >check it, complaining bitterly as it goes which implies the FS magic >number has been overwritten (God only knows why if the f/s is not to be >reformatted). If it was XFS the result is a completely trashed >superblock. > >I have not checked 8.2. > >The RH and Slackware installers check, detect correctly and ask the user >to confirm. > > > > From owner-linux-xfs@oss.sgi.com Thu Nov 6 17:36:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 17:36:46 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA71a925013301 for ; Thu, 6 Nov 2003 17:36:12 -0800 Received: from [24.118.170.148] (c-24-118-170-148.mn.client2.attbi.com [24.118.170.148]) by lips.thebarn.com (8.12.10/8.12.10) with ESMTP id hA71YBWe066512; Thu, 6 Nov 2003 19:34:12 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: FC1 + XFS 1.3.1: test SRPM available From: Russell Cattelan To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FAAEF21.1040900@stesmi.com> References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FAAEF21.1040900@stesmi.com> Content-Type: text/plain Message-Id: <1068168899.89014.50.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 19:35:00 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 31 On Thu, 2003-11-06 at 19:02, Stefan Smietanowski wrote: > Hi Eric. > > > So I was feeling charitable today... > > > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > > seems to more or less pass our QA suite. It's a hurry-up job though, so > > give it some cautious testing if you'd like. > > > > To the RH folks, if you're listening, I think I've done patches in such > > a way that you can strip out acls & dmapi, and have a functional xfs > > with extremely minimal impact to the rest of the kernel. > > (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be > > able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch > > would be nice). > > Someone's been keeping busy I see. Alright, I'll try to have a mockup an > installer this weekend for FC1. No promises though. Are you going to do just the DVD version? If you get anaconda in shape I'll work on getting the ordered genhdlist worked out. Which is usually the most annoying part of the "CD 4" installer > > Excellent work. One thought only ... Aren't ACLs enabled on the normal > FC1 kernel? > > // Stefan -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Thu Nov 6 17:44:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 17:44:57 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA71iM25013897 for ; Thu, 6 Nov 2003 17:44:23 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA71iLEi027205; Fri, 7 Nov 2003 02:44:21 +0100 Message-ID: <3FAAF966.4000902@stesmi.com> Date: Fri, 07 Nov 2003 02:46:14 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FAAEF21.1040900@stesmi.com> <1068168899.89014.50.camel@lupo.thebarn.com> In-Reply-To: <1068168899.89014.50.camel@lupo.thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1709 Lines: 47 Russell Cattelan wrote: > On Thu, 2003-11-06 at 19:02, Stefan Smietanowski wrote: > >>Hi Eric. >> >> >>>So I was feeling charitable today... >>> >>>You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that >>>seems to more or less pass our QA suite. It's a hurry-up job though, so >>>give it some cautious testing if you'd like. >>> >>>To the RH folks, if you're listening, I think I've done patches in such >>>a way that you can strip out acls & dmapi, and have a functional xfs >>>with extremely minimal impact to the rest of the kernel. >>>(linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be >>>able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch >>>would be nice). >> >>Someone's been keeping busy I see. Alright, I'll try to have a mockup an >>installer this weekend for FC1. No promises though. > > Are you going to do just the DVD version? > If you get anaconda in shape I'll work on getting > the ordered genhdlist worked out. > Which is usually the most annoying part of the "CD 4" installer > > >>Excellent work. One thought only ... Aren't ACLs enabled on the normal >>FC1 kernel? >> >>// Stefan My priority is the DVD version but I am interested in doing an "extra CD" version as well. If we can work together and share some work it makes it easier. For instance if you can look through at what artwork you want to replace, etc I can look more closely at the rest. If I whip anything up this weekend it's bound to be something that looks exactly like the original installer most likely. Next will be modifying it to actually comply with RedHat's rules (name, etc..). But anything I can get help with is truly excellent. // Stefan From owner-linux-xfs@oss.sgi.com Thu Nov 6 18:22:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 18:23:06 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA72ML25014551 for ; Thu, 6 Nov 2003 18:22:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA70RnOO013025 for ; Thu, 6 Nov 2003 16:27:49 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA72MFP513354499; Thu, 6 Nov 2003 20:22:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA72MEK25425696; Thu, 6 Nov 2003 20:22:14 -0600 (CST) Date: Thu, 6 Nov 2003 20:22:14 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: Russell Cattelan , Subject: Re: FC1 + XFS 1.3.1: test SRPM available In-Reply-To: <3FAAF966.4000902@stesmi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1082 Lines: 25 On Fri, 7 Nov 2003, Stefan Smietanowski wrote: > My priority is the DVD version but I am interested in doing an "extra > CD" version as well. If we can work together and share some work it > makes it easier. For instance if you can look through at what artwork > you want to replace, etc I can look more closely at the rest. > If I whip anything up this weekend it's bound to be something that > looks exactly like the original installer most likely. Next will be > modifying it to actually comply with RedHat's rules (name, etc..). I don't think we need to do any mucking with the artwork, or any other non-functional changes. It's my understanding (as an individual user, not speaking for SGI here) that Fedora can be much more freely distributed than Red Hat Linux could be - i.e. no more "Pink Tie Linux" and probably no need to purge references to "Red Hat" or copyrighted images. You guys should also be talking with jkatz@ red hat, he's their installer guy and seems very interested in making xfs work. Maybe not the cd4 version, but at least grub fixes etc. -Eric From owner-linux-xfs@oss.sgi.com Thu Nov 6 19:38:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 19:38:22 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA73cI25030421 for ; Thu, 6 Nov 2003 19:38:19 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA73viHc013361 for ; Thu, 6 Nov 2003 21:57:45 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hA73Zlog001877 for ; Fri, 7 Nov 2003 14:35:47 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hA73ZlgI001876 for linux-xfs@oss.sgi.com; Fri, 7 Nov 2003 14:35:47 +1100 Date: Fri, 7 Nov 2003 14:35:47 +1100 From: FSG QA Message-Id: <200311070335.hA73ZlgI001876@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 420 Lines: 17 Test out some issues we have at the moment dealing with writing when out of free space. Fixes are in the works. -- nathans. Date: Thu Nov 6 19:21:51 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:161363a cmd/xfstests/083 - 1.1 cmd/xfstests/083.out - 1.1 cmd/xfstests/group - 1.45 From owner-linux-xfs@oss.sgi.com Thu Nov 6 20:13:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 20:13:12 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA74D725031053 for ; Thu, 6 Nov 2003 20:13:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hA74WXHc030044 for ; Thu, 6 Nov 2003 22:32:34 -0600 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 PAA02461; Fri, 7 Nov 2003 15:12:57 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hA74CtUc1225951; Fri, 7 Nov 2003 15:12:56 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hA74DJZQ001961; Fri, 7 Nov 2003 15:13:19 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hA74DGJ6001959; Fri, 7 Nov 2003 15:13:16 +1100 Date: Fri, 7 Nov 2003 15:13:16 +1100 From: Nathan Scott To: Libor Vanek , Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: System halts when disk full Message-ID: <20031107041316.GH782@frodo> References: <3F9568A5.6050308@conet.cz> <1066757213.1870.1.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <1066757213.1870.1.camel@localhost.localdomain> User-Agent: Mutt/1.5.3i X-archive-position: 959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4250 Lines: 137 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi there, I've found a few problems in the way we deal with out-of-space conditions in XFS at the moment - probably the problem you are hitting can be fixed with the attached patch. It resolves one class of deadlock, I'm still looking at one more which is alot more difficult to trip though (as it requires multiple parallel writers under low free space conditions). Let me know if this helps, please. If not, that kdb output I asked for earlier would still be useful. thanks. On Tue, Oct 21, 2003 at 12:26:53PM -0500, Austin Gonyou wrote: > I'm kind of curious if the disk is 100% or just near, i.e. 1mb to go, or > even 10K free, etc. Look back in this list. I have a message around here > about the same thing, from several revisions ago. > > On Tue, 2003-10-21 at 12:11, Libor Vanek wrote: > > Hi, > > we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 > > and also 2.4.22 + XFS 1.3). > > > > When ANY mount point using XFS (/, /raid etc...) gets full, complete > > system halt and needs to be rebooted - is this bug or feature? :) > > > > Best regards, > > Libor > -- > Austin Gonyou > Coremetrics, Inc. > > -- Nathan --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iomap_rejigged.patch" =========================================================================== linux/fs/xfs/linux/xfs_iomap.c =========================================================================== --- /usr/tmp/TmpDir.1845-0/linux/fs/xfs/linux/xfs_iomap.c_1.16 2003-11-07 14:32:02.000000000 +1100 +++ linux/fs/xfs/linux/xfs_iomap.c 2003-11-07 12:33:54.130183320 +1100 @@ -243,7 +243,7 @@ case 0: if (ip->i_delayed_blks) { xfs_iunlock(ip, XFS_ILOCK_EXCL); - fsync_inode_data_buffers(LINVFS_GET_IP(vp)); + filemap_fdatawrite(LINVFS_GET_IP(vp)->i_mapping); xfs_ilock(ip, XFS_ILOCK_EXCL); *fsynced = 1; } else { =========================================================================== linux/include/linux/fs.h =========================================================================== --- /usr/tmp/TmpDir.1845-0/linux/include/linux/fs.h_1.166 2003-11-07 14:32:02.000000000 +1100 +++ linux/include/linux/fs.h 2003-11-07 14:29:24.486609000 +1100 @@ -1292,6 +1292,7 @@ } extern int inode_has_buffers(struct inode *); extern int do_fdatasync(struct file *); +extern int filemap_fdatawrite(struct address_space *); extern int filemap_fdatasync(struct address_space *); extern int filemap_fdatawait(struct address_space *); extern void sync_supers(kdev_t dev, int wait); =========================================================================== linux/mm/filemap.c =========================================================================== --- /usr/tmp/TmpDir.1845-0/linux/mm/filemap.c_1.120 2003-11-07 14:32:02.000000000 +1100 +++ linux/mm/filemap.c 2003-11-07 14:27:52.920529160 +1100 @@ -546,6 +546,49 @@ EXPORT_SYMBOL(fail_writepage); /** + * filemap_fdatawrite - walk the list of dirty pages of the given address space + * and writepage() each unlocked page (does not wait on locked pages). + * + * @mapping: address space structure to write + * + */ +int filemap_fdatawrite(struct address_space * mapping) +{ + int ret = 0; + int (*writepage)(struct page *) = mapping->a_ops->writepage; + + spin_lock(&pagecache_lock); + + while (!list_empty(&mapping->dirty_pages)) { + struct page *page = list_entry(mapping->dirty_pages.prev, struct page, list); + + list_del(&page->list); + list_add(&page->list, &mapping->locked_pages); + + if (!PageDirty(page)) + continue; + + page_cache_get(page); + spin_unlock(&pagecache_lock); + + if (!TryLockPage(page)) { + if (PageDirty(page)) { + int err; + ClearPageDirty(page); + err = writepage(page); + if (err && !ret) + ret = err; + } else + UnlockPage(page); + } + page_cache_release(page); + spin_lock(&pagecache_lock); + } + spin_unlock(&pagecache_lock); + return ret; +} + +/** * filemap_fdatasync - walk the list of dirty pages of the given address space * and writepage() all of them. * --rS8CxjVDS/+yyDmU-- From owner-linux-xfs@oss.sgi.com Thu Nov 6 23:16:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Nov 2003 23:16:39 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA77GB25003086 for ; Thu, 6 Nov 2003 23:16:32 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA77G9Ei027981; Fri, 7 Nov 2003 08:16:09 +0100 Message-ID: <3FAB472A.5040708@stesmi.com> Date: Fri, 07 Nov 2003 08:18:02 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 821 Lines: 22 Hi Eric. > I don't think we need to do any mucking with the artwork, or any > other non-functional changes. It's my understanding (as an individual > user, not speaking for SGI here) that Fedora can be much more freely > distributed than Red Hat Linux could be - i.e. no more "Pink Tie > Linux" and probably no need to purge references to "Red Hat" or > copyrighted images. I was thinking about that and honestly, I don't know what to believe :) Yes more freely but how freely? > > You guys should also be talking with jkatz@ red hat, he's their > installer guy and seems very interested in making xfs work. Maybe > not the cd4 version, but at least grub fixes etc. Right. Have someone been able to get a fix for the grub issue yet? My most asked for feature for the DVD is just a fix for that issue. // Stefan From owner-linux-xfs@oss.sgi.com Fri Nov 7 00:53:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 00:54:06 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA78rk25007389 for ; Fri, 7 Nov 2003 00:53:49 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hA78rgxv021368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Nov 2003 09:53:44 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hA78rfLL015616; Fri, 7 Nov 2003 09:53:41 +0100 Date: Fri, 7 Nov 2003 09:53:41 +0100 From: Axel Thimm To: Eric Sandeen Cc: Stefan Smietanowski , Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available Message-ID: <20031107085341.GE14128@puariko.nirvana> References: <3FAAF966.4000902@stesmi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h56sxpGKRmy85csR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2197 Lines: 56 --h56sxpGKRmy85csR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 08:22:14PM -0600, Eric Sandeen wrote: > On Fri, 7 Nov 2003, Stefan Smietanowski wrote: >=20 > > My priority is the DVD version but I am interested in doing an "extra > > CD" version as well. If we can work together and share some work it > > makes it easier. For instance if you can look through at what artwork > > you want to replace, etc I can look more closely at the rest. >=20 > > If I whip anything up this weekend it's bound to be something that > > looks exactly like the original installer most likely. Next will be > > modifying it to actually comply with RedHat's rules (name, etc..). >=20 > I don't think we need to do any mucking with the artwork, or any > other non-functional changes. It's my understanding (as an individual > user, not speaking for SGI here) that Fedora can be much more freely > distributed than Red Hat Linux could be - i.e. no more "Pink Tie > Linux" and probably no need to purge references to "Red Hat" or=20 > copyrighted images. Not really, Fedora is RH's trademark that is allowed to be used for verbatim copies of the ISOs. Any modifications, additions etc are not allowed to be called that way w/o explicit authorization from RH. http://fedora.redhat.com/about/trademarks/guidelines/page4.html You only need to touch anaconda-images and fedora-logos. There are only a few files to be replaced. Some poeple already have GPL'd version of these rpms (replacing the trademarks with neutral text), which one could use. Note that the rpms should provide "fedora-logos". > You guys should also be talking with jkatz@ red hat, he's their > installer guy and seems very interested in making xfs work. Maybe > not the cd4 version, but at least grub fixes etc. --=20 Axel.Thimm@physik.fu-berlin.de --h56sxpGKRmy85csR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/q12VQBVS1GOamfERAnvjAJ419aspXJP4yKvoVosl2LuEOJPIoACfafvT 42z6U/ehyORMD7Pzc0gC68o= =RbZB -----END PGP SIGNATURE----- --h56sxpGKRmy85csR-- From owner-linux-xfs@oss.sgi.com Fri Nov 7 02:56:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 02:56:47 -0800 (PST) Received: from darwin.libc.org (ucntcme224.dsl.spro.net [206.207.111.224] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7AuO25010349 for ; Fri, 7 Nov 2003 02:56:25 -0800 Received: (qmail 23913 invoked from network); 7 Nov 2003 10:56:23 -0000 Received: from unknown (HELO archimedes) (192.168.1.12) by 192.168.1.11 with SMTP; 7 Nov 2003 10:56:23 -0000 Subject: Re: XFS installer for Fedora 1 From: Bill Anderson To: linux-xfs@oss.sgi.com In-Reply-To: <20031106212931.GL13576@puariko.nirvana> References: <1068144421.1405.4.camel@adic.com> <20031106201337.GG13576@puariko.nirvana> <1068152873.1405.6.camel@stout.americas.sgi.com> <1068153344.2657.212.camel@adic.com> <20031106212931.GL13576@puariko.nirvana> Content-Type: text/plain Organization: Immosys LLC Message-Id: <1068202498.6775.209.camel@locutus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 07 Nov 2003 03:54:58 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@immosys.com Precedence: bulk X-list: linux-xfs Content-Length: 799 Lines: 25 On Thu, 2003-11-06 at 14:29, Axel Thimm wrote: > > Has anyone looked at the kernel rpms Arjan is creating for 2.6, there > > is an unsupported kernel rpm, I have not downloaded or looked inside > > them, but I have this terrible sinking feeling about it. > > No, xfs is not (yet?) moved to the unsupported rpm: Hmm I'm running Arjan's test2 kernel, and my entire system is on XFS. Methinks it's there. ;) > > /lib/modules/2.6.0-0.test9.1.70/kernel/fs/xfs/xfs.ko > > The more important point is will RH introduce proper anaconda support > for XFS? At least like jfs/reiserfs have with "hidden" enablers? The > XFS patches are said to have found their way into anaconda, but are > not enabled (didn't check lately). THAT is the real question. -- Bill Anderson Immosys LLC From owner-linux-xfs@oss.sgi.com Fri Nov 7 03:46:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 03:46:31 -0800 (PST) Received: from sun.krithika.net ([205.158.115.30]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7BkP25014846 for ; Fri, 7 Nov 2003 03:46:27 -0800 Received: from localhost (localhost.krithika.net [127.0.0.1]) by localhost.krithika.net (Postfix) with ESMTP id DFE42301FB; Fri, 7 Nov 2003 03:46:18 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from sun.krithika.net ([127.0.0.1]) by localhost (sun.itsprojects.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08357-04-6; Fri, 7 Nov 2003 03:46:17 -0800 (PST) Received: from swathi.krithika.net (unknown [202.88.158.15]) by sun.krithika.net (Postfix) with ESMTP id DA59F301E7; Fri, 7 Nov 2003 03:46:14 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id 500B153743B; Fri, 7 Nov 2003 17:17:49 +0530 (IST) (envelope-from xfs@ramaswamy.net) Date: Fri, 7 Nov 2003 17:17:49 +0530 (IST) From: Ajay Ramaswamy X-X-Sender: ajayr@swathi.krithika.net To: Eric Sandeen Cc: Ajay Ramaswamy , linux-xfs@oss.sgi.com Subject: Re: Anaconda In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1489637278-964571896-1068205669=:5259" X-Virus-Scanned: by amavisd-new at krithika.net X-archive-position: 963 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ramaswamy.net Precedence: bulk X-list: linux-xfs Content-Length: 13371 Lines: 233 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1489637278-964571896-1068205669=:5259 Content-Type: TEXT/PLAIN; charset=US-ASCII Eric, Success on the anaconda front, I have a installer that has proper rescue support. Here are the patches that I have added to the installer. I am no closer to finding an answer to the grub problem, but I am working on it. Thanks & regards Ajay --1489637278-964571896-1068205669=:5259 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="anaconda-xfs-label.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="anaconda-xfs-label.patch" ZGlmZiAtTmF1ciBhbmFjb25kYS05LjIvZnNzZXQucHkgYW5hY29uZGEtOS4y LXBhdGNoZWQvZnNzZXQucHkNCi0tLSBhbmFjb25kYS05LjIvZnNzZXQucHkJ MjAwMy0xMC0yMSAwNDozODoxMi4wMDAwMDAwMDAgKzA1MzANCisrKyBhbmFj b25kYS05LjItcGF0Y2hlZC9mc3NldC5weQkyMDAzLTExLTA2IDE3OjQ2OjAw LjAwMDAwMDAwMCArMDUzMA0KQEAgLTEzMzUsNyArMTMzNSw3IEBADQogICAg ICAgICAgICAgaWYgbm90IGVudHJ5Lm1vdW50cG9pbnQgb3IgZW50cnkubW91 bnRwb2ludCA9PSAic3dhcCI6DQogICAgICAgICAgICAgICAgIGNvbnRpbnVl DQogICAgICAgICAgICAgdHJ5Og0KLSAgICAgICAgICAgICAgICBsYWJlbCA9 IGlzeXMucmVhZEV4dDJMYWJlbChkZXYpDQorICAgICAgICAgICAgICAgIGxh YmVsID0gaXN5cy5yZWFkRlNMYWJlbChkZXYpDQogICAgICAgICAgICAgZXhj ZXB0Og0KICAgICAgICAgICAgICAgICBjb250aW51ZQ0KICAgICAgICAgICAg IGlmIGxhYmVsOg0KQEAgLTE2NDQsNyArMTY0NCw3IEBADQogDQogICAgIGRl ZiBnZXRMYWJlbChzZWxmKToNCiAgICAgICAgIHRyeToNCi0gICAgICAgICAg ICByZXR1cm4gaXN5cy5yZWFkRXh0MkxhYmVsKHNlbGYuc2V0dXBEZXZpY2Uo KSwgbWFrZURldk5vZGUgPSAwKQ0KKyAgICAgICAgICAgIHJldHVybiBpc3lz LnJlYWRGU0xhYmVsKHNlbGYuc2V0dXBEZXZpY2UoKSwgbWFrZURldk5vZGUg PSAwKQ0KICAgICAgICAgZXhjZXB0Og0KICAgICAgICAgICAgIHJldHVybiAi Ig0KIA0KQEAgLTIyMTMsNiArMjIxMywyMyBAQA0KICAgICBvcy5jbG9zZShm ZCkNCiAgICAgcmV0dXJuIDAgICAgDQogDQorZGVmIGlzVmFsaWRKRlMoZGV2 aWNlKToNCisgICAgZmQgPSBnZXREZXZGRChkZXZpY2UpDQorICAgIGlmIGZk ID09IC0xOg0KKyAgICAgICAgcmV0dXJuIDANCisNCisgICAgdHJ5Og0KKyAg ICAgICAgb3MubHNlZWsoZmQsIDMyNzY4LCAwKQ0KKyAgICAgICAgYnVmID0g b3MucmVhZChmZCwgMTI4KQ0KKyAgICBleGNlcHQ6DQorICAgICAgICBidWYg PSAiIg0KKw0KKyAgICBpZiAoYnVmWzA6NF0gPT0gIkpGUzEiKToNCisgICAg ICAgIG9zLmNsb3NlKGZkKQ0KKwlyZXR1cm4gMQ0KKw0KKyAgICBvcy5jbG9z ZShmZCkNCisgICAgcmV0dXJuIDAgICAgDQogDQogIyB0aGlzIHdpbGwgcmV0 dXJuIGEgbGlzdCBvZiB0eXBlcyBvZiBmaWxlc3lzdGVtcyB3aGljaCBkZXZp Y2UNCiAjIGxvb2tzIGxpa2UgaXQgY291bGQgYmUgdG8gdHJ5IG1vdW50aW5n IGFzDQpAQCAtMjIyNSw2ICsyMjQyLDkgQEANCiAgICAgaWYgaXNWYWxpZFJl aXNlckZTKGRldmljZSk6DQogICAgICAgICByYy5hcHBlbmQoInJlaXNlcmZz IikNCiANCisgICAgaWYgaXNWYWxpZEpGUyhkZXZpY2UpOg0KKyAgICAgICAg cmMuYXBwZW5kKCJqZnMiKQ0KKw0KICAgICBpZiBpc1ZhbGlkRXh0MihkZXZp Y2UpOg0KICAgICAgICAgaWYgb3MuYWNjZXNzKGRldmljZSwgb3MuT19SRE9O TFkpOg0KICAgICAgICAgICAgIGNyZWF0ZSA9IDANCmRpZmYgLU5hdXIgYW5h Y29uZGEtOS4yL2lzeXMvaXN5cy5weSBhbmFjb25kYS05LjItcGF0Y2hlZC9p c3lzL2lzeXMucHkNCi0tLSBhbmFjb25kYS05LjIvaXN5cy9pc3lzLnB5CTIw MDMtMTAtMTcgMDU6MDg6MTkuMDAwMDAwMDAwICswNTMwDQorKysgYW5hY29u ZGEtOS4yLXBhdGNoZWQvaXN5cy9pc3lzLnB5CTIwMDMtMTEtMDcgMDc6MTE6 MzUuMDAwMDAwMDAwICswNTMwDQpAQCAtNDczLDYgKzQ3MywzMiBAQA0KICAg ICAjIG90aGVyd2lzZQ0KICAgICByZXR1cm4gX2lzeXMucHVtcG5ldGRldmlj ZShkZXZpY2UpDQogDQorZGVmIHJlYWRYRlNMYWJlbF9pbnQoZGV2aWNlKToN CisgICAgdHJ5Og0KKyAgICAgICAgZmQgPSBvcy5vcGVuKGRldmljZSwgb3Mu T19SRE9OTFkpDQorICAgIGV4Y2VwdDoNCisgICAgICAgIHJldHVybiBOb25l DQorDQorICAgIGJ1ZiA9IG9zLnJlYWQoZmQsIDEyOCkNCisgICAgb3MuY2xv c2UoZmQpDQorDQorICAgIGlmIGxlbihidWYpICE9IDEyODoNCisgICAgICAg IHhmc2xhYmVsID0gTm9uZQ0KKw0KKyAgICBpZiBidWZbMDo0XSA9PSAiWEZT QiI6DQorICAgICAgICB4ZnNsYWJlbCA9IHN0cmluZy5yc3RyaXAoYnVmWzEw ODoxMjBdLCJcMHgwMCIpDQorDQorICAgIHJldHVybiB4ZnNsYWJlbA0KKyAg ICANCitkZWYgcmVhZFhGU0xhYmVsKGRldmljZSwgbWFrZURldk5vZGUgPSAx KToNCisgICAgaWYgbWFrZURldk5vZGU6DQorICAgICAgICBtYWtlRGV2SW5v ZGUoZGV2aWNlLCAiL3RtcC9kaXNrIikNCisJbGFiZWwgPSByZWFkWEZTTGFi ZWxfaW50KCIvdG1wL2Rpc2siKQ0KKwlvcy51bmxpbmsoIi90bXAvZGlzayIp DQorICAgIGVsc2U6DQorICAgICAgICBsYWJlbCA9IHJlYWRYRlNMYWJlbF9p bnQoZGV2aWNlKQ0KKyAgICByZXR1cm4gbGFiZWwNCisNCiBkZWYgcmVhZEV4 dDJMYWJlbChkZXZpY2UsIG1ha2VEZXZOb2RlID0gMSk6DQogICAgIGlmIG1h a2VEZXZOb2RlOg0KICAgICAgICAgbWFrZURldklub2RlKGRldmljZSwgIi90 bXAvZGlzayIpDQpAQCAtNDgyLDYgKzUwOCwyMSBAQA0KICAgICAgICAgbGFi ZWwgPSBfaXN5cy5lMmZzbGFiZWwoZGV2aWNlKQ0KICAgICByZXR1cm4gbGFi ZWwNCiANCitkZWYgcmVhZEZTTGFiZWwoZGV2aWNlLCBtYWtlRGV2Tm9kZSA9 IDEpOg0KKyAgICBsYWJlbCA9IHJlYWRYRlNMYWJlbChkZXZpY2UsIG1ha2VE ZXZOb2RlKQ0KKyAgICBpZiAobGFiZWwgPT0gTm9uZSk6DQorICAgICAgICBs YWJlbCA9IHJlYWRFeHQyTGFiZWwoZGV2aWNlLCBtYWtlRGV2Tm9kZSkNCisg ICAgcmV0dXJuIGxhYmVsDQorCQ0KKyNkZWYgcmVhZEZTTGFiZWwoZGV2aWNl LCBtYWtlRGV2Tm9kZSA9IDEpOg0KKyMgICAgZnN0eXBlID0gcGFydGVkVXRp bHMuc25pZmZGaWxlc3lzdGVtVHlwZShkZXZpY2UpDQorIyAgICBpZiAoZnN0 eXBlID09ICJleHQyIiBvciBmc3R5cGUgPT0gImV4dDMiKQ0KKyMgICAgICAg IHJldHVybiByZWFkRXh0MkxhYmVsKGRldmljZSwgbWFrZURldk5vZGUpDQor IyAgICBlbGlmIChmc3R5cGUgPT0gInhmcyIpOg0KKyMgICAgICAgIHJldHVy biByZWFkWEZTTGFiZWwoZGV2aWNlLCBtYWtlRGV2Tm9kZSkNCisjICAgIGVs c2U6DQorIyAgICAgICAgcmV0dXJuICIiDQorDQogZGVmIGV4dDJJc0RpcnR5 KGRldmljZSk6DQogICAgIG1ha2VEZXZJbm9kZShkZXZpY2UsICIvdG1wL2Rp c2siKQ0KICAgICBsYWJlbCA9IF9pc3lzLmUyZGlydHkoIi90bXAvZGlzayIp Ow0KZGlmZiAtTmF1ciBhbmFjb25kYS05LjIvcGFydGVkVXRpbHMucHkgYW5h Y29uZGEtOS4yLXBhdGNoZWQvcGFydGVkVXRpbHMucHkNCi0tLSBhbmFjb25k YS05LjIvcGFydGVkVXRpbHMucHkJMjAwMy0xMC0xNCAwNDoyMDoxMC4wMDAw MDAwMDAgKzA1MzANCisrKyBhbmFjb25kYS05LjItcGF0Y2hlZC9wYXJ0ZWRV dGlscy5weQkyMDAzLTExLTA2IDE3OjUwOjU2LjAwMDAwMDAwMCArMDUzMA0K QEAgLTQyMSw2ICs0MjEsOSBAQA0KICAgICBpZiBmc3NldC5pc1ZhbGlkUmVp c2VyRlMoZGV2KToNCiAgICAgICAgIHJldHVybiAicmVpc2VyZnMiDQogDQor ICAgIGlmIGZzc2V0LmlzVmFsaWRKRlMoZGV2KToNCisgICAgICAgIHJldHVy biAiamZzIg0KKw0KICAgICAjIEZJWE1FOiAgd2UgZG9uJ3QgbG9vayBmb3Ig amZzLCBvciB2ZmF0DQogDQogICAgIHJldHVybiBOb25lDQpAQCAtNTMwLDE2 ICs1MzMsMTcgQEANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG9yIHBhcnQuZ2V0X2ZsYWcocGFydGVkLlBBUlRJVElPTl9MVk0p KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBwYXJ0 LmZzX3R5cGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh bmQgKHBhcnQuZnNfdHlwZS5uYW1lID09ICJleHQyIg0KLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3IgcGFydC5mc190eXBlLm5h bWUgPT0gImV4dDMiKSkNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG9yIHBhcnQuZnNfdHlwZS5uYW1lID09ICJleHQzIg0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3IgcGFydC5m c190eXBlLm5hbWUgPT0gInhmcyIpKQ0KICAgICAgICAgICAgIHBhcnRzID0g ZmlsdGVyX3BhcnRpdGlvbnMoZGlzaywgZnVuYykNCiAgICAgICAgICAgICBm b3IgcGFydCBpbiBwYXJ0czoNCiAgICAgICAgICAgICAgICAgbm9kZSA9IGdl dF9wYXJ0aXRpb25fbmFtZShwYXJ0KQ0KLSAgICAgICAgICAgICAgICBsYWJl bCA9IGlzeXMucmVhZEV4dDJMYWJlbChub2RlKQ0KKyAgICAgICAgICAgICAg ICBsYWJlbCA9IGlzeXMucmVhZEZTTGFiZWwobm9kZSkNCiAgICAgICAgICAg ICAgICAgaWYgbGFiZWw6DQogICAgICAgICAgICAgICAgICAgICBsYWJlbHNb bm9kZV0gPSBsYWJlbA0KIA0KICAgICAgICAgZm9yIGRldiwgZGV2aWNlcywg bGV2ZWwsIG51bUFjdGl2ZSBpbiBEaXNrU2V0Lm1kTGlzdDoNCi0gICAgICAg ICAgICBsYWJlbCA9IGlzeXMucmVhZEV4dDJMYWJlbChkZXYpDQorICAgICAg ICAgICAgbGFiZWwgPSBpc3lzLnJlYWRGU0xhYmVsKGRldikNCiAgICAgICAg ICAgICBpZiBsYWJlbDoNCiAgICAgICAgICAgICAgICAgbGFiZWxzW2Rldl0g PSBsYWJlbA0KIA0K --1489637278-964571896-1068205669=:5259 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="anaconda-xfs.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="anaconda-xfs.patch" LS0tIGFuYWNvbmRhLTkuMC45Ni9zY3JpcHRzL3VwZC1pbnN0cm9vdC5vcmln CTIwMDMtMTAtMDggMDE6MzM6MTUuMDAwMDAwMDAwICswNTMwDQorKysgYW5h Y29uZGEtOS4wLjk2L3NjcmlwdHMvdXBkLWluc3Ryb290CTIwMDMtMTAtMjMg MjA6MjM6MjUuMDAwMDAwMDAwICswNTMwDQpAQCAtMTEwLDcgKzExMCw4IEBA DQogCSBiemlwMi1saWJzIGRvc2ZzdG9vbHMgcGNpdXRpbHMgcmVpc2VyZnMt dXRpbHMgcGFydGVkIHNlZA0KIAkgYnVzeWJveC1hbmFjb25kYSBycG0tcHl0 aG9uIGJvb3R5IGhkcGFybSBsdm0gYmVlY3J5cHQNCiAJIHJocGwgcHl4Zjg2 Y29uZmlnIGxpYnhtbDIgbGlieG1sMi1weXRob24gZ2xpYjINCi0JIGVsZnV0 aWxzLWxpYmVsZiBib2dsLWJ0ZXJtIGJvZ2wga3JiNS1saWJzIGNvbnZlcnRk YjEgamZzdXRpbHMiDQorCSBlbGZ1dGlscy1saWJlbGYgYm9nbC1idGVybSBi b2dsIGtyYjUtbGlicyBjb252ZXJ0ZGIxIGpmc3V0aWxzDQorIAkgeGZzcHJv Z3MgeGZzZHVtcCBkbWFwaSBsaWJhY2wgbGliYXR0ciBhdHRyIGFjbCINCiAN CiBpZiBbICRBUkNIID0gaTM4NiAtbyAkQVJDSCA9IHg4Nl82NCBdOyB0aGVu DQogICAgIFBBQ0tBR0VTPSIkUEFDS0FHRVMga2VybmVsLXBjbWNpYS1jcyBr ZXJuZWwtdXRpbHMiDQpAQCAtMTU2LDcgKzE1Nyw4IEBADQogICAgICAgICAg ICByZWRoYXQtY29uZmlnLWtleWJvYXJkIFhmdCBmb250Y29uZmlnIHJlZGhh dC1hcnR3b3JrDQogICAgICAgICAgICB0dGZvbnRzLWphIHR0Zm9udHMtemhf VFcgYml0bWFwLWZvbnRzLWNqayB1cnctZm9udHMgDQogICAgICAgICAgICBj b21wcy1leHRyYXMgWEZyZWU4Ni1saWJzLWRhdGEgY29udmVydGRiMQ0KLSAg ICAgICAgICAgdm5jLXNlcnZlciBsaWJqcGVnIHRjcF93cmFwcGVycyByZWRo YXQtY29uZmlnLWRhdGUiDQorICAgICAgICAgICB2bmMtc2VydmVyIGxpYmpw ZWcgdGNwX3dyYXBwZXJzIHJlZGhhdC1jb25maWctZGF0ZQ0KKyAgICAgICAg ICAgeGZzcHJvZ3MgeGZzZHVtcCBkbWFwaSBsaWJhY2wgbGliYXR0ciBhdHRy IGFjbCINCiANCiAjDQogIyBzdHVmZiBPTkxZIGluY2x1ZGVkIGZvciByZXNj dWUgbW9kZQ0KQEAgLTIzOSw2ICsyNDEsOSBAQA0KICRMSUJESVIvbGlicnRb LS5dKg0KICRMSUJESVIvbGlic3MqDQogJExJQkRJUi9saWJ0ZXJtY2FwKg0K KyRMSUJESVIvbGliaGFuZGxlKg0KKyRMSUJESVIvbGliYXR0cioNCiskTElC RElSL2xpYmRtKg0KICRMSUJESVIvbGlidXRpbCoNCiAkTElCRElSL2xpYnV1 aWQqDQogc2Jpbi9iYWRibG9ja3MNCkBAIC0yNTAsNiArMjU1LDggQEANCiBz YmluL2UybGFiZWwNCiBzYmluL2ZzY2suZXh0Mg0KIHNiaW4vZnNjay5leHQz DQorc2Jpbi9mc2NrLmpmcw0KK3NiaW4vZnNjay54ZnMNCiBzYmluL2ZkaXNr DQogc2Jpbi9oZHBhcm0NCiBzYmluL2h3Y2xvY2sNCkBAIC0yNzMsNiArMjgw LDcgQEANCiBzYmluL21rZnMuZXh0Mg0KIHNiaW4vbWtmcy5leHQzDQogc2Jp bi9ta2ZzLmpmcw0KK3NiaW4vbWtmcy54ZnMNCiBzYmluL21rZnMubXNkb3MN CiBzYmluL21rZnMudmZhdA0KIHNiaW4vbWtyZWlzZXJmcw0KQEAgLTI5MCw2 ICsyOTgsMTIgQEANCiBzYmluL3Jlc2l6ZTJmcw0KIHNiaW4vc2ZkaXNrDQog c2Jpbi90dW5lMmZzDQorc2Jpbi94ZnNkdW1wDQorc2Jpbi94ZnNyZXN0b3Jl DQorc2Jpbi94ZnNfcmVwYWlyDQordXNyL3NiaW4veGZzX2RiDQordXNyL3Ni aW4veGZzX2NoZWNrDQordXNyL3NiaW4veGZzX2NvcHkNCiBzYmluL3ZnY2Zn YmFja3VwDQogc2Jpbi92Z2NmZ3Jlc3RvcmUNCiBzYmluL3ZnY2hhbmdlDQot LS0gYW5hY29uZGEtOS4wLjk2L3NjcmlwdHMvbWstaW1hZ2VzLmkzODYub3Jp ZwkyMDAzLTEwLTE1IDAwOjI4OjI4LjAwMDAwMDAwMCArMDUzMA0KKysrIGFu YWNvbmRhLTkuMC45Ni9zY3JpcHRzL21rLWltYWdlcy5pMzg2CTIwMDMtMTAt MjMgMjA6MTU6MjcuMDAwMDAwMDAwICswNTMwDQpAQCAtOTIsNyArOTIsNyBA QA0KIElERU1PRFM9ImlkZS1jZCINCiBTQ1NJTU9EUz0ic2RfbW9kIHNnIHNy X21vZCBzdCINCiANCi1GU01PRFM9Im1zZG9zIHZmYXQgZXh0MyByZWlzZXJm cyBqZnMiDQorRlNNT0RTPSJtc2RvcyB2ZmF0IGV4dDMgcmVpc2VyZnMgamZz IHhmcyINCiBTRUNTVEFHRT0iYWdwZ2FydCBtZCByYWlkMCByYWlkMSByYWlk NSBsdm0tbW9kICRGU01PRFMgJElERU1PRFMgJFNDU0lNT0RTICRMQVRFVVNC TU9EUyBzdCBwYXJwb3J0X3BjIHBhcnBvcnQiDQogDQogQlRFUk1NT0RVTEVT PSJ2Z2ExNmZiIg0KLS0tIGFuYWNvbmRhLTkuMC45Ni9mc3NldC5weS5vcmln CTIwMDMtMTAtMjEgMDQ6Mzg6MTIuMDAwMDAwMDAwICswNTMwDQorKysgYW5h Y29uZGEtOS4wLjk2L2Zzc2V0LnB5CTIwMDMtMTAtMjMgMjA6MTM6MTkuMDAw MDAwMDAwICswNTMwDQpAQCAtNTEsMTIgKzUxLDE0IEBADQogYXZhaWxSYWlk TGV2ZWxzID0gWydSQUlEMCcsICdSQUlEMScsICdSQUlENSddDQogDQogZGVm IGZpbGVTeXN0ZW1UeXBlR2V0RGVmYXVsdCgpOg0KLSAgICBpZiBmaWxlU3lz dGVtVHlwZUdldCgnZXh0MycpLmlzU3VwcG9ydGVkKCk6DQorICAgIGlmIGZp bGVTeXN0ZW1UeXBlR2V0KCd4ZnMnKS5pc1N1cHBvcnRlZCgpOg0KKyAgICAg ICAgcmV0dXJuIGZpbGVTeXN0ZW1UeXBlR2V0KCd4ZnMnKQ0KKyAgICBlbGlm IGZpbGVTeXN0ZW1UeXBlR2V0KCdleHQzJykuaXNTdXBwb3J0ZWQoKToNCiAg ICAgICAgIHJldHVybiBmaWxlU3lzdGVtVHlwZUdldCgnZXh0MycpDQogICAg IGVsaWYgZmlsZVN5c3RlbVR5cGVHZXQoJ2V4dDInKS5pc1N1cHBvcnRlZCgp Og0KICAgICAgICAgcmV0dXJuIGZpbGVTeXN0ZW1UeXBlR2V0KCdleHQyJykN CiAgICAgZWxzZToNCi0gICAgICAgIHJhaXNlIFZhbHVlRXJyb3IsICJZb3Ug aGF2ZSBuZWl0aGVyIGV4dDMgb3IgZXh0MiBzdXBwb3J0IGluIHlvdXIga2Vy bmVsISINCisgICAgICAgIHJhaXNlIFZhbHVlRXJyb3IsICJZb3UgaGF2ZSBu ZWl0aGVyIHhmcywgZXh0MyBvciBleHQyIHN1cHBvcnQgaW4geW91ciBrZXJu ZWwhIg0KIA0KIA0KIGRlZiBmaWxlU3lzdGVtVHlwZUdldChrZXkpOg0KQEAg LTM5Nyw5ICszOTksNyBAQA0KICAgICAgICAgc2VsZi5uYW1lID0gInhmcyIN CiAgICAgICAgIHNlbGYubWF4U2l6ZU1CID0gMTAyNCAqIDEwMjQNCiAgICAg ICAgIHNlbGYubWF4TGFiZWxDaGFycyA9IDEyDQotICAgICAgICAjIHdlIGRv bid0IGV2ZW4gaGF2ZSB0aGUgbW9kdWxlLCBzbyBpdCB3b24ndCBiZSBtb3Vu dGFibGUuLi4gYnV0DQotICAgICAgICAjIGp1c3QgaW4gY2FzZQ0KLSAgICAg ICAgc2VsZi5zdXBwb3J0ZWQgPSAwDQorICAgICAgICBzZWxmLnN1cHBvcnRl ZCA9IDENCiAgICAgICAgIA0KICAgICBkZWYgZm9ybWF0RGV2aWNlKHNlbGYs IGVudHJ5LCBwcm9ncmVzcywgY2hyb290PScvJyk6DQogICAgICAgICBkZXZp Y2VQYXRoID0gZW50cnkuZGV2aWNlLnNldHVwRGV2aWNlKGNocm9vdCkNCi0t LSBhbmFjb25kYS05LjIvc2NyaXB0cy9idWlsZGluc3RhbGwub3JpZwkyMDAz LTEwLTE1IDAxOjA2OjMyLjAwMDAwMDAwMCArMDUzMA0KKysrIGFuYWNvbmRh LTkuMi9zY3JpcHRzL2J1aWxkaW5zdGFsbAkyMDAzLTExLTA3IDE2OjEwOjQz LjAwMDAwMDAwMCArMDUzMA0KQEAgLTEyMiw3ICsxMjIsNyBAQA0KIGlmIFsg LXggL3Vzci9iaW4vcnVucm9vdCBdOyB0aGVuDQogICAgIHJ1bnJvb3QgJENP TVBOQU1FIC0tb25seW9uZSAtLWFyY2ggJEJVSUxEQVJDSCAiJEJVSUxESU5T VEFMTCAtLWJ1aWxkaW5zdGRpciAkQlVJTERJTlNURElSIC0tc2Vjb25kICRQ S0dPUkRFUlNUUiAtLWNvbXAgJENPTVBOQU1FIC0tdmVyc2lvbiAkVkVSU0lP TiAtLXJlbGVhc2UgJ1wiJFJFTEVBU0VTVFJcIicgLS1wcm9kdWN0ICdcIiRQ Uk9EVUNUU1RSXCInIC0tcHJvZHBhdGggJFBST0RVQ1RQQVRIICRESVIiIA0K IGVsc2UNCi0gICAgJEJVSUxESU5TVEFMTCAtLWJ1aWxkaW5zdGRpciAkQlVJ TERJTlNURElSIC0tc2Vjb25kICRQS0dPUkRFUlNUUiAtLWNvbXAgJENPTVBO QU1FIC0tdmVyc2lvbiAkVkVSU0lPTiAtLXJlbGVhc2UgXCIkUkVMRUFTRVNU UlwiIC0tcHJvZHVjdCBcIiRQUk9EVUNUU1RSXCIgLS1wcm9kcGF0aCAkUFJP RFVDVFBBVEggJERJUg0KKyAgICAkQlVJTERJTlNUQUxMIC0tYnVpbGRpbnN0 ZGlyICRCVUlMRElOU1RESVIgLS1zZWNvbmQgJFBLR09SREVSU1RSIC0tY29t cCAkQ09NUE5BTUUgLS12ZXJzaW9uICRWRVJTSU9OIC0tcmVsZWFzZSAiJFJF TEVBU0VTVFIiIC0tcHJvZHVjdCAiJFBST0RVQ1RTVFIiIC0tcHJvZHBhdGgg JFBST0RVQ1RQQVRIICRESVINCiBmaQ0KIA0KIHJtIC1yZiAkQlVJTERJTlNU RElSDQo= --1489637278-964571896-1068205669=:5259-- From owner-linux-xfs@oss.sgi.com Fri Nov 7 03:59:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 04:00:17 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7Bxq25015304 for ; Fri, 7 Nov 2003 03:59:55 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hA7BxpCi001481; Fri, 7 Nov 2003 12:59:51 +0100 Message-ID: <3FAB89A8.4070109@stesmi.com> Date: Fri, 07 Nov 2003 13:01:44 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ajay Ramaswamy CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Anaconda References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 964 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1829 Lines: 47 Hi Ajay. > Eric, I'm not Eric, nor do I claim to be Eric but I want to respond anyway :) > Success on the anaconda front, I have a installer that has proper rescue > support. Here are the patches that I have added to the installer. I am no > closer to finding an answer to the grub problem, but I am working on it. Rescue support ? You mean that "mount filesystems" works? Or did you mean "upgrade" support? But before I continue : WELL DONE! Saves me a load of time. > +def readFSLabel(device, makeDevNode = 1): > + label = readXFSLabel(device, makeDevNode) > + if (label == None): > + label = readExt2Label(device, makeDevNode) > + return label > + > +#def readFSLabel(device, makeDevNode = 1): > +# fstype = partedUtils.sniffFilesystemType(device) > +# if (fstype == "ext2" or fstype == "ext3") > +# return readExt2Label(device, makeDevNode) > +# elif (fstype == "xfs"): > +# return readXFSLabel(device, makeDevNode) > +# else: > +# return "" > + Umm... why? Before they check what filesystem it is and then use the correct way to read the label and you instead just assume it's XFS and if the label reading fails then you try if it's ext2. I'm probably missing something though. > - $BUILDINSTALL --buildinstdir $BUILDINSTDIR --second $PKGORDERSTR --comp $COMPNAME --version $VERSION --release \"$RELEASESTR\" --product \"$PRODUCTSTR\" --prodpath $PRODUCTPATH $DIR > + $BUILDINSTALL --buildinstdir $BUILDINSTDIR --second $PKGORDERSTR --comp $COMPNAME --version $VERSION --release "$RELEASESTR" --product "$PRODUCTSTR" --prodpath $PRODUCTPATH $DIR Why do you remove the "\" ? If $RELEASESTR is something with a space this will not work. Also, I see you adding JFS support here and there but not everywhere. Not necessary in other places or ... ? // Stefan From owner-linux-xfs@oss.sgi.com Fri Nov 7 04:52:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 04:52:15 -0800 (PST) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7CqB25020003 for ; Fri, 7 Nov 2003 04:52:12 -0800 Received: from corona.local (caracas-0324.adsl.interware.hu [213.178.101.68]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id hA7CoWjU016949 for ; Fri, 7 Nov 2003 13:52:09 +0100 (CET) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id hA7CoQl2005795 for ; Fri, 7 Nov 2003 13:50:26 +0100 (CET) Date: Fri, 7 Nov 2003 13:50:26 +0100 From: Rumi Szabolcs To: linux-xfs@oss.sgi.com Subject: kernel base for XFS development tree Message-Id: <20031107135026.65af2ebb.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 314 Lines: 14 Hello! My question is pretty simple: is the XFS CVS development source tree based on the plain vanilla (2.4.22) kernel or are there some extra patches applied? When I make a diff of a current CVS pull against a vanilla (2.4.22) tree, is this considered a valid XFS snapshot? Thank you! Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Fri Nov 7 04:51:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 04:51:58 -0800 (PST) Received: from sun.krithika.net ([205.158.115.30]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7Cpf25019935 for ; Fri, 7 Nov 2003 04:51:42 -0800 Received: from localhost (localhost.krithika.net [127.0.0.1]) by localhost.krithika.net (Postfix) with ESMTP id 00C0930211 for ; Fri, 7 Nov 2003 04:51:36 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from sun.krithika.net ([127.0.0.1]) by localhost (sun.itsprojects.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09335-05 for ; Fri, 7 Nov 2003 04:51:34 -0800 (PST) Received: from swathi.krithika.net (unknown [202.88.158.15]) by sun.krithika.net (Postfix) with ESMTP id DAFB5301F4 for ; Fri, 7 Nov 2003 04:51:33 -0800 (PST) (envelope-from xfs@ramaswamy.net) Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id C939E53743B for ; Fri, 7 Nov 2003 18:23:12 +0530 (IST) (envelope-from xfs@ramaswamy.net) From: Ajay Ramaswamy (by way of Ajay Ramaswamy ) Subject: Re: Anaconda Date: Fri, 7 Nov 2003 18:23:12 +0530 User-Agent: KMail/1.5.4 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_4W5q/q5IvYDlBKV" Message-Id: <200311071823.12538.xfs@ramaswamy.net> X-Virus-Scanned: by amavisd-new at krithika.net X-archive-position: 966 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ramaswamy.net Precedence: bulk X-list: linux-xfs Content-Length: 4129 Lines: 114 --Boundary-00=_4W5q/q5IvYDlBKV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 07 Nov 2003 5:31 pm, Stefan Smietanowski wrote: > Hi Ajay. > > > Eric, > > I'm not Eric, nor do I claim to be Eric but I want to respond anyway :) > > > Success on the anaconda front, I have a installer that has proper rescue > > support. Here are the patches that I have added to the installer. I am no > > closer to finding an answer to the grub problem, but I am working on it. > > Rescue support ? You mean that "mount filesystems" works? Or did you > mean "upgrade" support? The rescue cd works for mount filesystems, yes > But before I continue : WELL DONE! Saves me a load of time. Thanks, as ESR says if you have an itch scratch it, much of all this was done by others before all I did was build on those bits. > > +def readFSLabel(device, makeDevNode = 1): > > + label = readXFSLabel(device, makeDevNode) > > + if (label == None): > > + label = readExt2Label(device, makeDevNode) > > + return label > > + > > +#def readFSLabel(device, makeDevNode = 1): > > +# fstype = partedUtils.sniffFilesystemType(device) > > +# if (fstype == "ext2" or fstype == "ext3") > > +# return readExt2Label(device, makeDevNode) > > +# elif (fstype == "xfs"): > > +# return readXFSLabel(device, makeDevNode) > > +# else: > > +# return "" > > + > > Umm... why? Before they check what filesystem it is and then > use the correct way to read the label and you instead just assume > it's XFS and if the label reading fails then you try if it's ext2. > I'm probably missing something though. just enable the so called correct way of doing it and import partedUtils in isys/isys.py and watch anaconda fall apart. It has something to do with circular imports and I dont have the time, knolwedge and paitence to sort it out. > > - $BUILDINSTALL --buildinstdir $BUILDINSTDIR --second $PKGORDERSTR > > --comp $COMPNAME --version $VERSION --release \"$RELEASESTR\" --product > > \"$PRODUCTSTR\" --prodpath $PRODUCTPATH $DIR + $BUILDINSTALL > > --buildinstdir $BUILDINSTDIR --second $PKGORDERSTR --comp $COMPNAME > > --version $VERSION --release "$RELEASESTR" --product "$PRODUCTSTR" > > --prodpath $PRODUCTPATH $DIR > > Why do you remove the "\" ? If $RELEASESTR is something with a space > this will not work. I am using this to invoke the buildinstall /usr/lib/anaconda-runtime/buildinstall --comp dist-1 --pkgorder /tmp/pkgorder.lst --version 1 --product 'Fedora Core XFS' --release 1 --prodpath Fedora $BASEDIR/i386 if I use the \" it will not work I have tried various ways of quoting that string "Fedora\ Core\ XFS", with single quotes, double quotes, with backslash escapes for the spaces and all combos thereof to no avail. > Also, I see you adding JFS support here and there but not everywhere. > Not necessary in other places or ... ? I am just adding in the easy bits, like getting the filesystem recognized etc., since I see FIXME in the code. I dont use JFS anywhere on my system so I am not enabling much more deep stuff like label support for JFS etc. After booting the rescue CD, I was tempted to "eat my own dogfood" and tried to do a HDD install from the rescue CD, but since I had the ISO images on a XFS partition that failed, I have since added this patch to my copy of anaconda. You will want to add this on too. Thanks & regards Ajay --Boundary-00=_4W5q/q5IvYDlBKV Content-Type: text/x-diff; charset="iso-8859-1"; name="hdins.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hdins.patch" --- anaconda-9.2/loader2/hdinstall.c 2003-10-15 01:06:32.000000000 +0530 +++ anaconda-9.2-patched/loader2/hdinstall.c 2003-11-07 18:01:19.000000000 +0530 @@ -315,7 +315,7 @@ char * url; char filespec[1024]; char * path; - char *typetry[] = {"ext2", "vfat", NULL}; + char *typetry[] = {"ext2", "xfs", "jfs", "reiserfs", "vfat", NULL}; char **type; logMessage("mounting device %s for hard drive install", device); --Boundary-00=_4W5q/q5IvYDlBKV-- From owner-linux-xfs@oss.sgi.com Fri Nov 7 05:11:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 05:11:31 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7DB825020911 for ; Fri, 7 Nov 2003 05:11:09 -0800 Received: (qmail 3901 invoked from network); 7 Nov 2003 13:11:04 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Nov 2003 13:11:04 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 4BEE6C00AA; Sat, 8 Nov 2003 00:10:40 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 491F01400AB; Sat, 8 Nov 2003 00:10:40 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Rumi Szabolcs Cc: linux-xfs@oss.sgi.com Subject: Re: kernel base for XFS development tree In-reply-to: Your message of "Fri, 07 Nov 2003 13:50:26 BST." <20031107135026.65af2ebb.rumi_ml@rtfm.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Nov 2003 00:10:39 +1100 Message-ID: <3383.1068210639@ocs3.intra.ocs.com.au> X-archive-position: 968 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 299 Lines: 8 On Fri, 7 Nov 2003 13:50:26 +0100, Rumi Szabolcs wrote: >My question is pretty simple: is the XFS CVS development >source tree based on the plain vanilla (2.4.22) kernel or >are there some extra patches applied? See ftp://oss.sgi.com/projects/xfs/download/patches/2.4.22/README From owner-linux-xfs@oss.sgi.com Fri Nov 7 06:44:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 06:44:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7EiK25022895 for ; Fri, 7 Nov 2003 06:44:23 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA7F3oHc016377 for ; Fri, 7 Nov 2003 09:03:50 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA7EiEP513365388; Fri, 7 Nov 2003 08:44:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA7EiDK25551201; Fri, 7 Nov 2003 08:44:14 -0600 (CST) Date: Fri, 7 Nov 2003 08:44:14 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ajay Ramaswamy cc: linux-xfs@oss.sgi.com Subject: Re: Anaconda In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 492 Lines: 17 thanks Ajay - honestly, I have not had any time to look at your patches, but I'm glad you're making progress. hm, maybe we need a temporary anaconda-xfs-devel list on oss ;0 -eric On Fri, 7 Nov 2003, Ajay Ramaswamy wrote: > Eric, > Success on the anaconda front, I have a installer that has proper rescue > support. Here are the patches that I have added to the installer. I am no > closer to finding an answer to the grub problem, but I am working on it. > > Thanks & regards > Ajay From owner-linux-xfs@oss.sgi.com Fri Nov 7 08:54:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 08:54:29 -0800 (PST) Received: from mail.automatix.de (237.230.131.213.rev.inetbone.net [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7GsE25024546 for ; Fri, 7 Nov 2003 08:54:15 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1AI9sG-0004q2-00 for linux-xfs@oss.sgi.com; Fri, 07 Nov 2003 17:54:16 +0100 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1AI9ap-00072F-00 for linux-xfs@oss.sgi.com; Fri, 07 Nov 2003 17:36:15 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying Date: Fri, 7 Nov 2003 17:36:11 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200311071736.11742.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA7GsG25024547 X-archive-position: 970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 2197 Lines: 72 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi List ! Since upgrading to Kernel 2.4.22-xfs (direct from SGI-CVS) I get this problems, during bigger file NFS-copying (local XFS -> remote NFS-based filesserver (also completely in XFS). Nov 7 17:20:02 pc2 kernel: nfs: server server not responding, still trying Nov 7 17:20:02 pc2 kernel: nfs: server server not responding, still trying Nov 7 17:20:02 pc2 kernel: nfs: server server OK This is my Test-Setup: server: 64GB XFS-fs on ICP-Vortex (Hardware Raid5) SCSI controller I tried everything, mentioned on the NFS FAQ Page to avoid this problems. http://nfs.sourceforge.net/nfs-howto/performance.html#TIMEOUT jojo@pc2:jojo $ ssh root@localhost Linux pc2 2.4.22-xfs #2 Don Okt 23 17:01:40 CEST 2003 i686 unknown root@pc2:root# nfsstat [...] Client rpc stats: calls retrans authrefrsh 1483912 21137 0 [...] root@pc2:root# echo 262144 > /proc/sys/net/core/rmem_default root@pc2:root# echo 262144 > /proc/sys/net/core/rmem_max root@pc2:root# mount /home -o remount,timeo=14,retrans=6 Copy Try -> Same Problem root@pc2:root# mount /home -o remount,timeo=30,retrans=12 root@pc2:root# mount /home -o remount,timeo=30,retrans=12,rsize=32768,wsize=32768 root@pc2:jojo# nfsstat ... Client rpc stats: calls retrans authrefrsh 1752966 23343 0 ... root@pc2:jojo# mount /home -o remount,timeo=30,retrans=12,rsize=32768,wsize=32768,nfsvers=3 root@pc2:jojo# mount server:/home on /home type nfs (rw,lock,timeo=30,retrans=12,rsize=32768,wsize=32768,nfsvers=3,addr=192.168.11.1) Copy Try -> Same Problem This Kernel 2.4.22-xfs is in case of NFS performance the worst since 2.4.7 and reiserfs or the userspace nfs daemon. How can we stop the problem ? Any ideas ? TIA ! mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de ICQ: #344389676 ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/q8n7W7UKI9EqarERAibYAJ0YD47dxjvuFlXOdAivT+kQiBNcVwCg4jut 1OVaUVKDm1R6WAXhXQH/vro= =Cwa1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Nov 7 10:43:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 10:43:49 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7IhY25026589 for ; Fri, 7 Nov 2003 10:43:34 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA7IhTq0004298 for ; Fri, 7 Nov 2003 10:43:29 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hA7IhSP513186519 for ; Fri, 7 Nov 2003 12:43:28 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hA7IhRRn309816380; Fri, 7 Nov 2003 12:43:27 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hA7IdJGf032125; Fri, 7 Nov 2003 12:39:19 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hA7IdJVB032123; Fri, 7 Nov 2003 12:39:19 -0600 Date: Fri, 7 Nov 2003 12:39:19 -0600 From: Eric Sandeen Message-Id: <200311071839.hA7IdJVB032123@penguin.americas.sgi.com> Subject: PARTIAL TAKE 903541 - Remove a nested transaction X-archive-position: 971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 592 Lines: 18 Remove a nested transaction in xfs_dm_punch_hole Date: Fri Nov 7 10:42:59 PST 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161392a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.24 - Remove a nested transaction in xfs_dm_punch_hole Commit one before starting the next, this also helps alleviate problems with the still-problematic PF_FSTRANS process flag handling. The nested transactions would cause the PF macros to leak the flag. From owner-linux-xfs@oss.sgi.com Fri Nov 7 12:51:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Nov 2003 12:51:41 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA7KpG25031648 for ; Fri, 7 Nov 2003 12:51:17 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 66BEA102570 for ; Fri, 7 Nov 2003 21:12:08 +0100 (CET) Received: from nx-01.sapienti-sat.org (pD9E7ED3F.dip.t-dialin.net [217.231.237.63]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 2007910011F for ; Fri, 7 Nov 2003 21:12:08 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id 5264240819 for ; Fri, 7 Nov 2003 21:12:03 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id 1CC124051F for ; Fri, 7 Nov 2003 21:12:03 +0100 (CET) Message-ID: <3FABFC92.5030607@koschikode.com> Date: Fri, 07 Nov 2003 21:12:02 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying References: <200311071736.11742.juergen.sauer@automatix.de> In-Reply-To: <200311071736.11742.juergen.sauer@automatix.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 750 Lines: 23 Juergen Sauer wrote: > Since upgrading to Kernel 2.4.22-xfs (direct from SGI-CVS) I get this > problems, during bigger file NFS-copying (local XFS -> > remote NFS-based filesserver (also completely in XFS). > > Nov 7 17:20:02 pc2 kernel: nfs: server server not responding, still trying > Nov 7 17:20:02 pc2 kernel: nfs: server server not responding, still trying > Nov 7 17:20:02 pc2 kernel: nfs: server server OK > This Kernel 2.4.22-xfs is in case of NFS performance the worst since 2.4.7 and reiserfs or the userspace > nfs daemon. > > How can we stop the problem ? > Any ideas ? I think this is completely a NFS problem so you better might ask on the NFS ML. Or what reasons do you have to believe that it's a XFS problem? Cheers, Juri From owner-linux-xfs@oss.sgi.com Sun Nov 9 14:18:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Nov 2003 14:19:05 -0800 (PST) Received: from mail.automatix.de (237.230.131.213.rev.inetbone.net [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9MIn25011716 for ; Sun, 9 Nov 2003 14:18:51 -0800 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1AIOrN-0007GB-00 for linux-xfs@oss.sgi.com; Sat, 08 Nov 2003 09:54:21 +0100 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1AIOmp-0004iv-00; Sat, 08 Nov 2003 09:49:39 +0100 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: Juri Haberland , linux-xfs@oss.sgi.com Subject: Re: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying Date: Sat, 8 Nov 2003 09:49:35 +0100 User-Agent: KMail/1.5.4 References: <200311071736.11742.juergen.sauer@automatix.de> <3FABFC92.5030607@koschikode.com> In-Reply-To: <3FABFC92.5030607@koschikode.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200311080949.35106.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hA9MIp25011717 X-archive-position: 973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 987 Lines: 33 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 7. November 2003 21:12 schrieb Juri Haberland: > Juergen Sauer wrote: > I think this is completely a NFS problem so you better might ask on the > NFS ML. > Or what reasons do you have to believe that it's a XFS problem? On the NFS List they belive it's a XFS-related problem. I posted this to the NFS List also. Because the problem was arising on a new kernel on the server (2.4.22-xfs is now back on 2.4.20-xfs) and a new kernel on client 2.4.22-xfs, which is hardware tied to .22. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de ICQ: #344389676 ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rK4fW7UKI9EqarERAkLjAKDR6WrFMWNtJqymeUsIc16ov+iZpQCeIgsX hwRuP/XhwFG5fLhgfEISqZU= =P9kG -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Nov 9 15:15:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Nov 2003 15:15:42 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA9NF625012562 for ; Sun, 9 Nov 2003 15:15:27 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hA9NF0HS018804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2003 00:15:03 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hA9NEw43029883; Mon, 10 Nov 2003 00:14:58 +0100 Date: Mon, 10 Nov 2003 00:14:57 +0100 From: Axel Thimm To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available Message-ID: <20031109231457.GK19355@puariko.nirvana> References: <1068164684.1405.42.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOhpupldhMlYbdva" Content-Disposition: inline In-Reply-To: <1068164684.1405.42.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1797 Lines: 52 --BOhpupldhMlYbdva Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 06:24:44PM -0600, Eric Sandeen wrote: > So I was feeling charitable today... >=20 > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > seems to more or less pass our QA suite. It's a hurry-up job though, so > give it some cautious testing if you'd like. Thanks Erik! > To the RH folks, if you're listening, I think I've done patches in such > a way that you can strip out acls & dmapi, and have a functional xfs > with extremely minimal impact to the rest of the kernel.=20 > (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be > able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch > would be nice). I have updated the ATrpms' kernels for FC1 to sync with your src.rpm, e.g. ATrpms goes XFS 1.3.1 (previously it was 1.3.0). Well, not a really big difference, but at least SCO cannot sue me anymore ;) I'd be interested in minimizing [1] kernel patches and building XFS out of the tree (so that the needed patches could be pushed easier into RH/ac kernels). I won't have time until the end of the year, but if anyone manages to do so, I will gladly repackage his/her recipe into kernel and xfs-kmdl rpms. [1] minimizing as in full functional together with the XFS kernel modules, not minimizing as in castrated-without-acls ;) --=20 Axel.Thimm@physik.fu-berlin.de --BOhpupldhMlYbdva Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/rspxQBVS1GOamfERAqnXAJ9ahnz2eNM1AhQTMo4S9iUE95hZhACfQnEJ JiiZTeZIgjeS9wLyQJUMsvE= =XAe/ -----END PGP SIGNATURE----- --BOhpupldhMlYbdva-- From owner-linux-xfs@oss.sgi.com Sun Nov 9 17:30:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Nov 2003 17:30:48 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAA1UM25017191 for ; Sun, 9 Nov 2003 17:30:34 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hA9NZxOO026638 for ; Sun, 9 Nov 2003 15:36:00 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAA1RvjX001660 for ; Mon, 10 Nov 2003 12:27:57 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAA1Rvo1001659 for linux-xfs@oss.sgi.com; Mon, 10 Nov 2003 12:27:57 +1100 Date: Mon, 10 Nov 2003 12:27:57 +1100 From: FSG QA Message-Id: <200311100127.hAA1Rvo1001659@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 414 Lines: 17 Make out of space test more general so I can try different scenarios more easily; add 083 into the auto group. -- nathans. Date: Sun Nov 9 17:29:28 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:161442a cmd/xfstests/group - 1.46 cmd/xfstests/083 - 1.2 From owner-linux-xfs@oss.sgi.com Sun Nov 9 21:57:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Nov 2003 21:58:15 -0800 (PST) Received: from ns.turbolinux.com.cn ([210.77.38.126]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAA5vk25023441 for ; Sun, 9 Nov 2003 21:57:49 -0800 Received: from turbolinux.com.cn (kunlun.turbolinux.com.cn [210.74.191.34]) (authenticated bits=0) by ns.turbolinux.com.cn (8.12.5/8.12.5) with ESMTP id hAA65bit001471 for ; Mon, 10 Nov 2003 14:05:37 +0800 Message-ID: <3FAF2982.7080809@turbolinux.com.cn> Date: Mon, 10 Nov 2003 14:00:34 +0800 From: Passion Zhao User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-archive-position: 976 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: passion.zhao@turbolinux.com.cn Precedence: bulk X-list: linux-xfs Content-Length: 54 Lines: 3 subscribe linux-xfs passion.zhao@turbolinux.com.cn From owner-linux-xfs@oss.sgi.com Mon Nov 10 03:44:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 03:44:41 -0800 (PST) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAABiP25032160 for ; Mon, 10 Nov 2003 03:44:26 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1AJAT0-0007Sn-00 for linux-xfs@oss.sgi.com; Mon, 10 Nov 2003 12:44:22 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hAABiMEa002770 for linux-xfs@oss.sgi.com; Mon, 10 Nov 2003 12:44:22 +0100 Date: Mon, 10 Nov 2003 12:44:22 +0100 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Subject: RH-8 kernel Message-ID: <20031110114422.GB1878@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1AJAT0-0007Sn-00*LPAnALDyj2A* X-archive-position: 977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 234 Lines: 9 What is the recommended way of getting a good XFS-kernel for a RedHat-8 box? Should a rebuild of kernel-2.4.20-20.9.XFS1.3.1.src.rpm work, or are there NPTL related configs or patches that I should exclude in this kernel? -jf From owner-linux-xfs@oss.sgi.com Mon Nov 10 04:11:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 04:11:41 -0800 (PST) Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAACBE25000861 for ; Mon, 10 Nov 2003 04:11:15 -0800 Received: from ip02 (c191_122.cellus.no [193.91.191.122]) by cellus.no (8.9.3/8.9.3) with SMTP id NAA30626 for ; Mon, 10 Nov 2003 13:11:13 +0100 From: =?iso-8859-1?Q?Christian_Sander_R=F8snes?= To: Subject: AIO for XFS kernel 2.4.x ? Date: Mon, 10 Nov 2003 13:12:08 +0100 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 V5.50.4927.1200 X-archive-position: 978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian@cellus.no Precedence: bulk X-list: linux-xfs Content-Length: 84 Lines: 6 Hello Is AIO (async i/o) for XFS working on any 2.4.x kernel version ? Christian From owner-linux-xfs@oss.sgi.com Mon Nov 10 05:03:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 05:03:27 -0800 (PST) Received: from anu.edu.au (anumail4.anu.edu.au [150.203.2.44]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAD2x25005188 for ; Mon, 10 Nov 2003 05:03:00 -0800 Received: from pulp.anu.edu.au (pulp.anu.edu.au [150.203.126.25]) by anu.edu.au (8.12.10/8.12.10) with ESMTP id hAAD2vIB029887 for ; Tue, 11 Nov 2003 00:02:57 +1100 (EST) Received: from pulp.anu.edu.au (localhost [127.0.0.1]) by pulp.anu.edu.au (8.12.10/8.12.10/Debian-4) with ESMTP id hAAD3qsx001676 for ; Tue, 11 Nov 2003 00:03:52 +1100 Received: (from abate@localhost) by pulp.anu.edu.au (8.12.10/8.12.10/Debian-4) id hAAD3q8B001672 for linux-xfs@oss.sgi.com; Tue, 11 Nov 2003 00:03:52 +1100 Date: Tue, 11 Nov 2003 00:03:52 +1100 From: Pietro Abate To: linux-xfs@oss.sgi.com Subject: Re: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying Message-ID: <20031110130352.GA32116@anu.edu.au> References: <200311071736.11742.juergen.sauer@automatix.de> <3FABFC92.5030607@koschikode.com> <200311080949.35106.juergen.sauer@automatix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311080949.35106.juergen.sauer@automatix.de> X-Operating-System: GNU/Linux X-Organization: Research School of Information Science and Engineering (Australian National University) User-Agent: Mutt/1.5.4i X-Sender: abate@pulp.anu.edu.au X-Sender-Domain: pulp.anu.edu.au X-Spam-Score: (-3.9) X-Spam-Tests: IN_REP_TO,REFERENCES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.36 X-archive-position: 980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Pietro.Abate@anu.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 645 Lines: 20 Hi all, > On the NFS List they belive it's a XFS-related problem. if I can add somethign to this thread, I've a nfs server with xfs and I'm noticing the same kind of problems. I've no idea if it's a nfs problem or xfs problem, but the other server we have with reiserfs doesn't generate any warnings... my setup is a big server with hw raid and xfs and a bunch of diskless clients... my 2 cents p -- ++ As I grow older, I pay less attention to what men say. I just watch what they do. Andrew Carnegie (1835-1919). ++ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From owner-linux-xfs@oss.sgi.com Mon Nov 10 07:32:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 07:33:05 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAFWm25007479 for ; Mon, 10 Nov 2003 07:32:49 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAAFWhq0030119 for ; Mon, 10 Nov 2003 07:32:43 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAAFWgP513448441; Mon, 10 Nov 2003 09:32:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAAFWfK15917544; Mon, 10 Nov 2003 09:32:41 -0600 (CST) Subject: Re: RH-8 kernel From: Eric Sandeen To: Jan-Frode Myklebust Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031110114422.GB1878@ii.uib.no> References: <20031110114422.GB1878@ii.uib.no> Content-Type: text/plain Organization: Message-Id: <1068478362.4517.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Nov 2003 09:32:42 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 722 Lines: 21 Those RH kernels are done in such a way that the ntpl patches are turned on & off with a single %define - otherwise the rh8 and rh9 specfiles are almost identical. Just compare the two to turn off the nptl patches. Or, go to Axel's atrpms page, and grab one of his kernels with xfs. -Eric On Mon, 2003-11-10 at 05:44, Jan-Frode Myklebust wrote: > What is the recommended way of getting a good XFS-kernel > for a RedHat-8 box? Should a rebuild of > kernel-2.4.20-20.9.XFS1.3.1.src.rpm work, or are there NPTL > related configs or patches that I should exclude in this > kernel? > > > -jf -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Nov 10 08:45:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 08:45:56 -0800 (PST) Received: from cyber1hq.adic.com (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAGja25011461 for ; Mon, 10 Nov 2003 08:45:37 -0800 X-Authentication-Warning: localhost.localdomain: slord set sender to lord@adic.com using -f Subject: Re: AIO for XFS kernel 2.4.x ? From: Steve Lord Reply-To: lord@adic.com To: Christian Sander =?ISO-8859-1?Q?R=F8snes?= Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1068482749.2613.111.camel@adic.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Nov 2003 10:45:50 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAAGjb25011462 X-archive-position: 982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 18 On Mon, 2003-11-10 at 06:12, Christian Sander Rřsnes wrote: > Hello > > Is AIO (async i/o) for XFS working on any 2.4.x kernel version ? > > Christian No, the way XFS works and the way AIO in 2.4 works are pretty incompatible. The worktodo mechanism behind the 2.4 AIO code assumes a lot about how a filesystem implements locking. AIO on XFS in 2.6 works though. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Mon Nov 10 09:12:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 09:13:10 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAHCv25020811 for ; Mon, 10 Nov 2003 09:12:59 -0800 Received: from titanic (titanic.skynet.coplanar.net [192.168.7.98]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAHCu34005368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 12:12:57 -0500 Message-ID: <002a01c3a7ad$ff260b50$6207a8c0@titanic> From: "Jeremy Jackson" To: Subject: xfsdump feature request Date: Mon, 10 Nov 2003 12:13:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 1787 Lines: 38 Hi, I have just recently started using xfsdump. I consider it to be one of the main benifits to using the XFS filesystem, due to it's inventory system. There are a few things I haven't found a way to do yet, though. Any suggestions welcome. 1) xfsdump -J ... it is required when /var is mounted read-only. This inhibits writing the dump session to /var/lib/xfsdump/inventory, as well as writing the dump session to a tape file. Yet when booted from cd/network and root is read-only, it is often desirable to make a dump while doing system repairs (xfs_repair needs to boot from somewhere else to run even). Also related is the "miniroot" environment in the xfsdump man page... this could use some more explanation. It would be nice if -J or some other option would allow the user to bypass the update of /var/lib/xfsdump/inventory, but still write the session inventory to a tape file, since xfsrestore can later be used to merge (or inspect?) it when listing/restore a session. (related to #2) 2) The man page for xfsdump states that the inventory written to tape is currently not used, however I was able to merge it into /var/lib/xfsdump/inventory when using xfsrestore to list a session on tape. It would be nice if the man pages stated exactly when and how the inventory file on the tape is used/not used. 3) This has been mentioned before on the list... What is the difference between "mt erase" and "xfsdump -o" and "xfsdump -E". Is there a way to erase a tape but keep it's media object UUID. It would be ideal to allow this, and prune the inventory of that's media object's UUID automatically. If this is possible, then adding a counter to how many times that media object has been used would give it all the features of Veritas. Would be nice. Regards, Jeremy From owner-linux-xfs@oss.sgi.com Mon Nov 10 11:42:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 11:43:01 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAJgk25025013 for ; Mon, 10 Nov 2003 11:42:49 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 0D5281400F32; Mon, 10 Nov 2003 14:42:51 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id B78621437124; Mon, 10 Nov 2003 14:42:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id B45BA3027B40; Mon, 10 Nov 2003 14:42:49 -0500 (EST) Date: Mon, 10 Nov 2003 14:42:49 -0500 (EST) From: Mike Burger To: Passion Zhao Cc: linux-xfs@oss.sgi.com Subject: Re: (no subject) In-Reply-To: <3FAF2982.7080809@turbolinux.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 513 Lines: 28 Um...no? Try sending that to linux-xfs-request@oss.sgi.com On Mon, 10 Nov 2003, Passion Zhao wrote: > subscribe linux-xfs passion.zhao@turbolinux.com.cn > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Mon Nov 10 13:27:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 13:27:31 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAALRF25029059 for ; Mon, 10 Nov 2003 13:27:16 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hAALRECs017692 for ; Mon, 10 Nov 2003 22:27:14 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 10 Nov 2003 22:27:14 +0100 (CET) Received: (qmail 10038 invoked from network); 10 Nov 2003 22:27:13 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 10 Nov 2003 22:27:13 +0100 Subject: xfs and 2.4.23-rc From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1068499634.666.5.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 22:27:14 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 221 Lines: 11 Hi all, As of today, the first release candidate of linux-2.4.23 is out. Are there any plans at SGI to merge CVS up with 2.4.23-rc, or do you intend to pull out a new full release based on 2.4.22? regards. Christian From owner-linux-xfs@oss.sgi.com Mon Nov 10 14:00:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 14:00:54 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAM0g25031395 for ; Mon, 10 Nov 2003 14:00:43 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAAM0Zq0018115 for ; Mon, 10 Nov 2003 14:00:36 -0800 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 JAA21497; Tue, 11 Nov 2003 09:00:27 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAAM0QUc1236295; Tue, 11 Nov 2003 09:00:26 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAAM0khF000877; Tue, 11 Nov 2003 09:00:46 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAAM0k49000875; Tue, 11 Nov 2003 09:00:46 +1100 Date: Tue, 11 Nov 2003 09:00:46 +1100 From: Nathan Scott To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and 2.4.23-rc Message-ID: <20031110220046.GA780@frodo> References: <1068499634.666.5.camel@bonnie79> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1068499634.666.5.camel@bonnie79> User-Agent: Mutt/1.5.3i X-archive-position: 986 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 367 Lines: 15 On Mon, Nov 10, 2003 at 10:27:14PM +0100, Christian Guggenberger wrote: > Hi all, > > As of today, the first release candidate of linux-2.4.23 is out. Are > there any plans at SGI to merge CVS up with 2.4.23-rc, or do you intend > to pull out a new full release based on 2.4.22? > I will be merging our 2.4 tree up to 2.4.23-rc1 later today. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 10 14:03:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 14:03:54 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAAM3f25031828 for ; Mon, 10 Nov 2003 14:03:42 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hAAM3eCs001549 for ; Mon, 10 Nov 2003 23:03:40 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 10 Nov 2003 23:03:40 +0100 (CET) Received: (qmail 10426 invoked from network); 10 Nov 2003 23:03:40 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 10 Nov 2003 23:03:40 +0100 Subject: Re: xfs and 2.4.23-rc From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031110220046.GA780@frodo> References: <1068499634.666.5.camel@bonnie79> <20031110220046.GA780@frodo> Content-Type: text/plain Message-Id: <1068501819.978.5.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 Nov 2003 23:03:40 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 508 Lines: 19 On Mon, 2003-11-10 at 23:00, Nathan Scott wrote: > On Mon, Nov 10, 2003 at 10:27:14PM +0100, Christian Guggenberger wrote: > > Hi all, > > > > As of today, the first release candidate of linux-2.4.23 is out. Are > > there any plans at SGI to merge CVS up with 2.4.23-rc, or do you intend > > to pull out a new full release based on 2.4.22? > > > > I will be merging our 2.4 tree up to 2.4.23-rc1 later today. Great to hear! I hope this will show up soon in the exported tree, too. cheers. Christian From owner-linux-xfs@oss.sgi.com Mon Nov 10 15:44:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 15:44:15 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAANi225001477 for ; Mon, 10 Nov 2003 15:44:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAALnaOO022276 for ; Mon, 10 Nov 2003 13:49:37 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAANhkEU1032571 for ; Tue, 11 Nov 2003 10:43:47 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAANhfEp1082572 for linux-xfs@oss.sgi.com; Tue, 11 Nov 2003 10:43:41 +1100 (EST) Date: Tue, 11 Nov 2003 10:43:41 +1100 (EST) From: Nathan Scott Message-Id: <200311102343.hAANhfEp1082572@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix 2.4 write/enospc deadlock X-archive-position: 988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 742 Lines: 26 Fix a deadlock while writing when low on free space. Date: Mon Nov 10 15:24:46 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161506a linux/fs/xfs/linux/xfs_iomap.c - 1.17 - Use the filemap_fdatawrite interface for flushing delayed allocate space so that we do not deadlock on pages locked by the generic write code. Modid: 2.4.x-xfs:slinx:161506b linux/mm/filemap.c - 1.121 linux/kernel/ksyms.c - 1.148 linux/include/linux/fs.h - 1.167 - Provide a flush mechanism which is suitable for calling when flushing delayed allocate space while some pages are locked for writing already. From owner-linux-xfs@oss.sgi.com Mon Nov 10 21:49:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Nov 2003 21:50:24 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB5np25011637 for ; Mon, 10 Nov 2003 21:49:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAB69VHc023586 for ; Tue, 11 Nov 2003 00:09:32 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAB5neEU1298715 for ; Tue, 11 Nov 2003 16:49:40 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAB5nd5i1297279 for linux-xfs@oss.sgi.com; Tue, 11 Nov 2003 16:49:39 +1100 (EST) Date: Tue, 11 Nov 2003 16:49:39 +1100 (EST) From: Nathan Scott Message-Id: <200311110549.hAB5nd5i1297279@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - 2.4.23-rc1 X-archive-position: 989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 58773 Lines: 1537 Merge up to 2.4.23-rc1 Date: Mon Nov 10 21:40:57 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:161525a linux/scripts/mkuboot.sh - 1.1 linux/arch/ppc/platforms/ibm440gx.c - 1.1 linux/Documentation/README.nsp32_cb.eng - 1.1 linux/arch/ppc/platforms/ibm440gx.h - 1.1 linux/arch/ppc/platforms/ocotea.c - 1.1 linux/drivers/char/hw_random.c - 1.1 linux/drivers/char/sn_serial.c - 1.1 linux/net/sctp/ulpqueue.c - 1.1 linux/Documentation/firmware_class/README - 1.1 linux/Documentation/firmware_class/firmware_sample_driver.c - 1.1 linux/Documentation/firmware_class/hotplug-script - 1.1 linux/Documentation/hw_random.txt - 1.1 linux/drivers/char/fetchop.c - 1.1 linux/drivers/char/drm/via_mm.h - 1.1 linux/net/sctp/ulpevent.c - 1.1 linux/Documentation/laptop-mode.txt - 1.1 linux/Documentation/mkdev_dyn.cciss - 1.1 linux/drivers/char/drm/via_mm.c - 1.1 linux/net/sctp/tsnmap.c - 1.1 linux/net/sctp/transport.c - 1.1 linux/net/sctp/sysctl.c - 1.1 linux/net/sctp/ssnmap.c - 1.1 linux/net/sctp/socket.c - 1.1 linux/Documentation/rmdev_dyn.cciss - 1.1 linux/net/sctp/sm_statetable.c - 1.1 linux/Documentation/usb/sl811hc.txt - 1.1 linux/net/sctp/sm_statefuns.c - 1.1 linux/Documentation/usb/w9968cf.txt - 1.1 linux/net/sctp/sm_sideeffect.c - 1.1 linux/net/sctp/sm_make_chunk.c - 1.1 linux/Documentation/wolfson-touchscreen.txt - 1.1 linux/net/sctp/sla1.c - 1.1 linux/net/sctp/protocol.c - 1.1 linux/drivers/char/drm/via_map.c - 1.1 linux/drivers/char/drm/via_ds.h - 1.1 linux/drivers/char/drm/via_ds.c - 1.1 linux/drivers/char/drm/via_drv.h - 1.1 linux/arch/alpha/boot/bootpz.c - 1.1 linux/arch/alpha/boot/misc.c - 1.1 linux/drivers/char/drm/via_drv.c - 1.1 linux/drivers/char/drm/via_drm.h - 1.1 linux/drivers/char/drm/via.h - 1.1 linux/drivers/ide/legacy/sibyte.c - 1.1 linux/drivers/ide/pci/sgiioc4.c - 1.1 linux/net/sctp/proc.c - 1.1 linux/drivers/char/drm/savage_state.c - 1.1 linux/drivers/char/drm/savage_drv.h - 1.1 linux/net/sctp/primitive.c - 1.1 linux/net/sctp/outqueue.c - 1.1 linux/drivers/char/drm/savage_drv.c - 1.1 linux/net/sctp/output.c - 1.1 linux/drivers/char/drm/savage_drm.h - 1.1 linux/drivers/char/drm/savage_dma.c - 1.1 linux/drivers/char/drm/savage.h - 1.1 linux/drivers/ide/pci/sgiioc4.h - 1.1 linux/net/sctp/objcnt.c - 1.1 linux/net/sctp/ipv6.c - 1.1 linux/net/sctp/inqueue.c - 1.1 linux/net/sctp/input.c - 1.1 linux/net/sctp/hashdriver.c - 1.1 linux/arch/i386/kernel/edd.c - 1.1 linux/drivers/char/drm/radeon_mem.c - 1.1 linux/drivers/char/drm/radeon_irq.c - 1.1 linux/drivers/char/drm/i830_irq.c - 1.1 linux/drivers/net/mv64340_eth.c - 1.1 linux/net/sctp/endpointola.c - 1.1 linux/net/sctp/debug.c - 1.1 linux/net/sctp/crc32c.c - 1.1 linux/net/sctp/command.c - 1.1 linux/net/sctp/bind_addr.c - 1.1 linux/net/sctp/associola.c - 1.1 linux/drivers/net/mv64340_eth.h - 1.1 linux/drivers/net/sk98lin/skdim.c - 1.1 linux/net/sctp/adler32.c - 1.1 linux/drivers/net/wan/hdlc_raw_eth.c - 1.1 linux/drivers/char/drm/gamma_drm.h - 1.1 linux/net/sctp/Makefile - 1.1 linux/net/sctp/Config.in - 1.1 linux/drivers/net/zorro8390.c - 1.1 linux/drivers/char/drm/drm_sarea.h - 1.1 linux/arch/ia64/configs/numa - 1.1 linux/drivers/char/drm/drm_os_linux.h - 1.1 linux/drivers/scsi/changelog.megaraid2 - 1.1 linux/drivers/scsi/megaraid2.c - 1.1 linux/arch/ia64/drivers/Makefile - 1.1 linux/arch/ia64/drivers/simeth.c - 1.1 linux/arch/ia64/drivers/simscsi.c - 1.1 linux/arch/ia64/drivers/simscsi.h - 1.1 linux/arch/ia64/drivers/simserial.c - 1.1 linux/drivers/scsi/megaraid2.h - 1.1 linux/drivers/bluetooth/Makefile.lib - 1.1 linux/drivers/sound/ac97_plugin_wm97xx.c - 1.1 linux/drivers/usb/gadget/Config.in - 1.1 linux/drivers/usb/gadget/Makefile - 1.1 linux/drivers/usb/gadget/ether.c - 1.1 linux/drivers/usb/gadget/net2280.c - 1.1 linux/drivers/usb/gadget/net2280.h - 1.1 linux/drivers/usb/gadget/usbstring.c - 1.1 linux/drivers/usb/gadget/zero.c - 1.1 linux/drivers/usb/host/hc_simple.c - 1.1 linux/drivers/usb/host/hc_simple.h - 1.1 linux/drivers/usb/host/hc_sl811.c - 1.1 linux/drivers/usb/host/hc_sl811.h - 1.1 linux/drivers/usb/host/hc_sl811_rh.c - 1.1 linux/drivers/usb/serial/keyspan_usa90msg.h - 1.1 linux/drivers/usb/w9968cf.c - 1.1 linux/drivers/usb/w9968cf.h - 1.1 linux/drivers/usb/w9968cf_decoder.h - 1.1 linux/drivers/usb/w9968cf_externaldef.h - 1.1 linux/include/asm-alpha/kmap_types.h - 1.1 linux/crypto/cast5.c - 1.1 linux/include/asm-arm/hc_sl811-hw.h - 1.1 linux/net/ipv6/ipv6_syms.c - 1.1 linux/include/asm-arm/sl811-hw.h - 1.1 linux/include/asm-i386/edd.h - 1.1 linux/include/asm-i386/hc_sl811-hw.h - 1.1 linux/include/asm-i386/sl811-hw.h - 1.1 linux/include/asm-ia64/mmzone.h - 1.1 linux/include/asm-ia64/nodedata.h - 1.1 linux/include/asm-ia64/numa.h - 1.1 linux/include/asm-ia64/numnodes.h - 1.1 linux/include/asm-ia64/sn/serialio.h - 1.1 linux/net/ipv4/ipvs/ip_vs_wrr.c - 1.1 linux/arch/ia64/mm/discontig.c - 1.1 linux/net/ipv4/ipvs/ip_vs_wlc.c - 1.1 linux/arch/ia64/mm/numa.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sync.c - 1.1 linux/arch/ia64/scripts/make_gas_hint_test.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sh.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sed.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sched.c - 1.1 linux/net/ipv4/ipvs/ip_vs_rr.c - 1.1 linux/net/ipv4/ipvs/ip_vs_nq.c - 1.1 linux/arch/ia64/sn/fakeprom/make_textsym - 1.1 linux/net/ipv4/ipvs/ip_vs_lc.c - 1.1 linux/net/ipv4/ipvs/ip_vs_lblcr.c - 1.1 linux/net/ipv4/ipvs/ip_vs_lblc.c - 1.1 linux/net/ipv4/ipvs/ip_vs_ftp.c - 1.1 linux/net/ipv4/ipvs/ip_vs_est.c - 1.1 linux/net/ipv4/ipvs/ip_vs_dh.c - 1.1 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.1 linux/net/ipv4/ipvs/ip_vs_core.c - 1.1 linux/net/ipv4/ipvs/ip_vs_conn.c - 1.1 linux/net/ipv4/ipvs/ip_vs_app.c - 1.1 linux/net/ipv4/ipvs/Makefile - 1.1 linux/net/ipv4/ipvs/Config.in - 1.1 linux/include/asm-ia64/topology.h - 1.1 linux/include/asm-ia64/ustack.h - 1.1 linux/include/asm-ppc/ibm44x.h - 1.1 linux/include/asm-ppc/ppc4xx_dma.h - 1.1 linux/include/asm-sh/io_microdev.h - 1.1 linux/include/asm-sh/irq_microdev.h - 1.1 linux/arch/sh/lib/udivdi3.c - 1.1 linux/arch/ia64/sn/io/sn2/ioc4/Makefile - 1.1 linux/arch/ia64/sn/io/sn2/ioc4/ioc4.c - 1.1 linux/arch/ia64/sn/io/sn2/ioc4/sio_ioc4.c - 1.1 linux/arch/sh/lib/div64.S - 1.1 linux/arch/sh/kernel/setup_microdev.c - 1.1 linux/arch/sh/kernel/mach_microdev.c - 1.1 linux/arch/sh/kernel/irq_microdev.c - 1.1 linux/include/linux/firmware.h - 1.1 linux/arch/sh/kernel/io_microdev.c - 1.1 linux/net/core/ethtool.c - 1.1 linux/arch/ppc/platforms/ocotea.h - 1.1 linux/arch/ppc/kernel/ibm440gp_common.c - 1.1 linux/arch/ppc/platforms/ibm440gp.h - 1.1 linux/arch/ppc/platforms/ibm440gp.c - 1.1 linux/arch/ppc/platforms/ebony.h - 1.1 linux/arch/ppc/platforms/ebony.c - 1.1 linux/arch/ppc/platforms/dbox2.h - 1.1 linux/arch/ppc/mm/44x_mmu.c - 1.1 linux/include/linux/sctp.h - 1.1 linux/arch/ppc/kernel/ppc4xx_sgdma.c - 1.1 linux/arch/ppc/kernel/ppc4xx_dma.c - 1.1 linux/arch/ppc/kernel/ibm44x_common.c - 1.1 linux/arch/ppc/kernel/ibm440gp_common.h - 1.1 linux/lib/firmware_class.c - 1.1 linux/arch/ia64/sn/io/snia_if.c - 1.1 linux/arch/ppc/configs/ocotea_defconfig - 1.1 linux/arch/ppc/kernel/head_44x.S - 1.1 linux/include/linux/usb_ch9.h - 1.1 linux/arch/ia64/sn/kernel/led.c - 1.1 linux/include/linux/usb_gadget.h - 1.1 linux/include/net/sctp/command.h - 1.1 linux/arch/ppc/configs/ebony_defconfig - 1.1 linux/include/linux/wm97xx.h - 1.1 linux/include/net/ip_vs.h - 1.1 linux/arch/ia64/sn/kernel/sn2/timer_interrupt.c - 1.1 linux/arch/ia64/sn/kernel/sn2_smp.c - 1.1 linux/arch/ia64/sn/kernel/sn_ivt.S - 1.1 linux/include/net/sctp/constants.h - 1.1 linux/include/net/sctp/compat.h - 1.1 linux/arch/ppc/boot/simple/misc-44x.c - 1.1 linux/include/net/sctp/sm.h - 1.1 linux/include/net/sctp/sctp.h - 1.1 linux/include/net/sctp/sla1.h - 1.1 linux/include/net/sctp/tsnmap.h - 1.1 linux/include/net/sctp/structs.h - 1.1 linux/include/net/sctp/ulpevent.h - 1.1 linux/include/net/sctp/ulpqueue.h - 1.1 linux/include/net/sctp/user.h - 1.1 linux/net/sunrpc/xprt.c - 1.27 linux/net/sunrpc/svcsock.c - 1.19 linux/net/sunrpc/clnt.c - 1.18 linux/net/socket.c - 1.33 linux/net/sched/sch_generic.c - 1.13 linux/net/netsyms.c - 1.46 linux/net/netlink/af_netlink.c - 1.20 linux/net/irda/wrapper.c - 1.11 linux/net/irda/qos.c - 1.17 linux/net/irda/irttp.c - 1.17 linux/net/irda/irqueue.c - 1.9 linux/net/irda/irlmp_frame.c - 1.11 linux/net/irda/irlap_frame.c - 1.17 linux/net/irda/irlap_event.c - 1.24 linux/net/irda/irlan/irlan_provider_event.c - 1.4 linux/net/irda/irlan/irlan_provider.c - 1.7 linux/net/irda/irlan/irlan_filter.c - 1.4 linux/net/irda/irlan/irlan_event.c - 1.4 linux/net/irda/irlan/irlan_eth.c - 1.17 linux/net/irda/irlan/irlan_common.c - 1.18 linux/net/irda/irlan/irlan_client_event.c - 1.7 linux/net/irda/irlan/irlan_client.c - 1.12 linux/net/irda/irias_object.c - 1.12 linux/net/irda/irda_device.c - 1.25 linux/net/irda/af_irda.c - 1.33 linux/net/ipv6/udp.c - 1.28 linux/net/ipv6/tcp_ipv6.c - 1.40 linux/net/ipv6/sit.c - 1.23 linux/net/ipv6/route.c - 1.25 linux/net/ipv6/raw.c - 1.25 linux/net/ipv6/ndisc.c - 1.22 linux/net/ipv6/mcast.c - 1.18 linux/net/ipv6/icmp.c - 1.19 linux/net/ipv6/af_inet6.c - 1.23 linux/net/ipv6/addrconf.c - 1.27 linux/net/ipv6/Makefile - 1.6 linux/net/ipv4/udp.c - 1.32 linux/net/ipv4/tcp_output.c - 1.30 linux/net/ipv4/tcp_ipv4.c - 1.48 linux/net/ipv4/tcp_input.c - 1.40 linux/net/ipv4/route.c - 1.39 linux/net/ipv4/ipmr.c - 1.22 linux/net/ipv4/ipip.c - 1.25 linux/net/ipv4/ipconfig.c - 1.31 linux/net/ipv4/ip_output.c - 1.34 linux/net/ipv4/ip_gre.c - 1.22 linux/net/ipv4/igmp.c - 1.19 linux/net/ipv4/icmp.c - 1.29 linux/net/ipv4/devinet.c - 1.17 linux/net/ipv4/arp.c - 1.24 linux/net/ipv4/af_inet.c - 1.35 linux/net/ipv4/Config.in - 1.13 linux/net/core/sysctl_net_core.c - 1.6 linux/net/core/neighbour.c - 1.17 linux/net/core/dev.c - 1.55 linux/net/core/Makefile - 1.8 linux/net/Makefile - 1.20 linux/net/Config.in - 1.23 linux/mm/vmscan.c - 1.98 linux/mm/swap.c - 1.22 linux/mm/slab.c - 1.34 linux/mm/page_alloc.c - 1.78 linux/mm/mprotect.c - 1.23 linux/mm/mmap.c - 1.51 linux/mm/memory.c - 1.82 linux/mm/filemap.c - 1.122 linux/lib/vsprintf.c - 1.19 linux/lib/Makefile - 1.12 linux/kernel/sysctl.c - 1.54 linux/kernel/sys.c - 1.31 linux/kernel/sched.c - 1.53 linux/kernel/resource.c - 1.17 linux/kernel/printk.c - 1.22 linux/kernel/panic.c - 1.19 linux/kernel/ksyms.c - 1.149 linux/kernel/kmod.c - 1.17 linux/kernel/fork.c - 1.45 linux/init/main.c - 1.73 linux/include/scsi/scsi.h - 1.8 linux/include/net/tcp.h - 1.33 linux/include/net/sock.h - 1.29 linux/include/net/snmp.h - 1.12 linux/include/net/pkt_sched.h - 1.12 linux/include/net/neighbour.h - 1.8 linux/include/net/ipv6.h - 1.11 linux/include/net/ip.h - 1.17 linux/include/net/inet_common.h - 1.4 linux/include/net/if_inet6.h - 1.10 linux/include/linux/wireless.h - 1.11 linux/include/linux/videodev.h - 1.22 linux/include/linux/sysctl.h - 1.58 linux/include/linux/swap.h - 1.55 linux/include/linux/sunrpc/xprt.h - 1.13 linux/include/linux/sunrpc/svc.h - 1.6 linux/include/linux/socket.h - 1.12 linux/include/linux/sched.h - 1.56 linux/include/linux/rtnetlink.h - 1.15 linux/include/linux/quota.h - 1.17 linux/include/linux/ptrace.h - 1.3 linux/include/linux/proc_fs.h - 1.32 linux/include/linux/pkt_sched.h - 1.7 linux/include/linux/personality.h - 1.13 linux/include/linux/pci.h - 1.58 linux/include/linux/pagemap.h - 1.43 linux/include/linux/nfsd/export.h - 1.12 linux/include/linux/netdevice.h - 1.36 linux/include/linux/net.h - 1.10 linux/include/linux/mm.h - 1.90 linux/include/linux/list.h - 1.12 linux/include/linux/ipv6_route.h - 1.3 linux/include/linux/ipv6.h - 1.3 linux/include/linux/ioport.h - 1.13 linux/include/linux/interrupt.h - 1.18 linux/include/linux/in.h - 1.6 linux/include/linux/if.h - 1.6 linux/include/linux/fs.h - 1.168 linux/include/linux/console.h - 1.11 linux/include/linux/byteorder/generic.h - 1.5 linux/include/asm-sparc64/visasm.h - 1.4 linux/include/asm-sparc64/smp.h - 1.14 linux/include/asm-sparc64/ptrace.h - 1.4 linux/include/asm-sparc64/processor.h - 1.27 linux/include/asm-sparc64/pbm.h - 1.13 linux/include/asm-sparc64/irq.h - 1.12 linux/include/asm-sparc64/ioctl.h - 1.4 linux/include/asm-sparc64/io.h - 1.17 linux/include/asm-sparc64/head.h - 1.6 linux/include/asm-sparc64/asi.h - 1.6 linux/include/asm-sparc/viking.h - 1.3 linux/include/asm-sparc/vac-ops.h - 1.5 linux/include/asm-sparc/turbosparc.h - 1.3 linux/include/asm-sparc/tsunami.h - 1.3 linux/include/asm-sparc/system.h - 1.13 linux/include/asm-sparc/swift.h - 1.3 linux/include/asm-sparc/ross.h - 1.3 linux/include/asm-sparc/processor.h - 1.21 linux/include/asm-sparc/pgtsun4c.h - 1.4 linux/include/asm-sparc/pgtsun4.h - 1.4 linux/include/asm-sparc/pgtsrmmu.h - 1.4 linux/include/asm-sparc/ioctl.h - 1.5 linux/include/asm-sparc/checksum.h - 1.7 linux/include/asm-sparc/bitops.h - 1.15 linux/include/asm-sparc/atomic.h - 1.10 linux/include/asm-ppc/unistd.h - 1.21 linux/include/asm-ppc/ucontext.h - 1.6 linux/include/asm-ppc/uaccess.h - 1.13 linux/include/asm-ppc/sigcontext.h - 1.5 linux/include/asm-ppc/serial.h - 1.14 linux/include/asm-ppc/scatterlist.h - 1.8 linux/include/asm-ppc/processor.h - 1.35 linux/include/asm-ppc/pgtable.h - 1.33 linux/include/asm-ppc/page.h - 1.17 linux/include/asm-ppc/mmu.h - 1.12 linux/include/asm-ppc/irq.h - 1.18 linux/include/asm-ppc/ipc.h - 1.6 linux/include/asm-ppc/io.h - 1.18 linux/include/asm-ppc/cache.h - 1.11 linux/include/asm-mips/pci.h - 1.18 linux/include/asm-mips/elf.h - 1.13 linux/include/asm-m68k/system.h - 1.12 linux/include/asm-m68k/processor.h - 1.15 linux/include/asm-m68k/elf.h - 1.7 linux/include/asm-m68k/dvma.h - 1.8 linux/include/asm-i386/msr.h - 1.15 linux/include/asm-i386/hardirq.h - 1.17 linux/include/asm-i386/elf.h - 1.8 linux/include/asm-arm/elf.h - 1.7 linux/include/asm-alpha/sysinfo.h - 1.3 linux/include/asm-alpha/ptrace.h - 1.4 linux/include/asm-alpha/processor.h - 1.16 linux/include/asm-alpha/pci.h - 1.17 linux/include/asm-alpha/irq.h - 1.8 linux/include/asm-alpha/elf.h - 1.8 linux/fs/proc/proc_devtree.c - 1.8 linux/fs/proc/inode.c - 1.18 linux/fs/proc/generic.c - 1.26 linux/fs/proc/base.c - 1.35 linux/fs/proc/array.c - 1.35 linux/fs/ntfs/super.c - 1.12 linux/fs/ntfs/inode.c - 1.15 linux/fs/ntfs/fs.c - 1.37 linux/fs/ntfs/dir.c - 1.11 linux/fs/nfsd/vfs.c - 1.46 linux/fs/nfsd/nfsfh.c - 1.37 linux/fs/nfsd/export.c - 1.25 linux/fs/nfs/write.c - 1.37 linux/fs/nfs/nfs3xdr.c - 1.10 linux/fs/minix/inode.c - 1.25 linux/fs/lockd/svcproc.c - 1.13 linux/fs/lockd/svclock.c - 1.14 linux/fs/inode.c - 1.69 linux/fs/fcntl.c - 1.20 linux/fs/exec.c - 1.55 linux/fs/dquot.c - 1.52 linux/fs/buffer.c - 1.123 linux/fs/binfmt_elf.c - 1.42 linux/fs/Config.in - 1.92 linux/drivers/video/vesafb.c - 1.21 linux/drivers/video/q40fb.c - 1.11 linux/drivers/video/fbcmap.c - 1.5 linux/drivers/video/Config.in - 1.38 linux/drivers/usb/usb.c - 1.64 linux/drivers/usb/audio.c - 1.39 linux/drivers/usb/Makefile - 1.52 linux/drivers/usb/Config.in - 1.55 linux/drivers/sound/Makefile - 1.38 linux/drivers/sound/Config.in - 1.35 linux/drivers/scsi/tmscsim.h - 1.7 linux/drivers/scsi/tmscsim.c - 1.15 linux/drivers/scsi/t128.c - 1.11 linux/drivers/scsi/sg.c - 1.29 linux/drivers/scsi/pas16.c - 1.12 linux/drivers/scsi/megaraid.h - 1.16 linux/drivers/scsi/megaraid.c - 1.37 linux/drivers/scsi/mac_scsi.c - 1.11 linux/drivers/scsi/ide-scsi.c - 1.24 linux/drivers/scsi/g_NCR5380.c - 1.14 linux/drivers/scsi/dtc.c - 1.10 linux/drivers/scsi/NCR5380.h - 1.5 linux/drivers/scsi/NCR5380.c - 1.11 linux/drivers/scsi/Makefile - 1.39 linux/drivers/scsi/Config.in - 1.34 linux/drivers/scsi/53c7xx.h - 1.6 linux/drivers/scsi/53c7xx.c - 1.18 linux/drivers/scsi/53c7,8xx.h - 1.6 linux/drivers/scsi/53c7,8xx.c - 1.17 linux/drivers/sbus/char/envctrl.c - 1.17 linux/drivers/pci/quirks.c - 1.34 linux/drivers/pci/pci.c - 1.53 linux/drivers/net/yellowfin.c - 1.32 linux/drivers/net/via-rhine.c - 1.38 linux/drivers/net/tlan.c - 1.26 linux/drivers/net/sunhme.c - 1.37 linux/drivers/net/sonic.c - 1.10 linux/drivers/net/seeq8005.c - 1.16 linux/drivers/net/pcnet32.c - 1.36 linux/drivers/net/net_init.c - 1.22 linux/drivers/net/ne2k-pci.c - 1.26 linux/drivers/net/fmv18x.c - 1.18 linux/drivers/net/eth16i.c - 1.22 linux/drivers/net/epic100.c - 1.31 linux/drivers/net/dummy.c - 1.11 linux/drivers/net/ariadne2.c - 1.13 linux/drivers/net/Makefile - 1.54 linux/drivers/net/Config.in - 1.64 linux/drivers/net/8390.h - 1.12 linux/drivers/net/8390.c - 1.26 linux/drivers/net/3c59x.c - 1.38 linux/drivers/net/3c527.c - 1.20 linux/drivers/net/3c523.c - 1.18 linux/drivers/net/3c515.c - 1.23 linux/drivers/net/3c507.c - 1.23 linux/drivers/net/3c505.c - 1.26 linux/drivers/net/3c503.c - 1.23 linux/drivers/net/3c501.c - 1.19 linux/drivers/isdn/Config.in - 1.25 linux/drivers/char/tty_io.c - 1.45 linux/drivers/char/synclink.c - 1.23 linux/drivers/char/softdog.c - 1.17 linux/drivers/char/rtc.c - 1.29 linux/drivers/char/rocket_int.h - 1.6 linux/drivers/char/rocket.c - 1.15 linux/drivers/char/pcwd.c - 1.19 linux/drivers/char/n_hdlc.c - 1.13 linux/drivers/char/mem.c - 1.43 linux/drivers/char/keyboard.c - 1.28 linux/drivers/char/console.c - 1.29 linux/drivers/char/Makefile - 1.60 linux/drivers/char/Config.in - 1.62 linux/drivers/cdrom/cdrom.c - 1.39 linux/drivers/block/ll_rw_blk.c - 1.88 linux/drivers/block/Config.in - 1.37 linux/drivers/Makefile - 1.31 linux/arch/sparc64/kernel/unaligned.c - 1.8 linux/arch/sparc64/kernel/traps.c - 1.20 linux/arch/sparc64/kernel/time.c - 1.21 linux/arch/sparc64/kernel/sys_sunos32.c - 1.35 linux/arch/sparc64/kernel/sys_sparc32.c - 1.50 linux/arch/sparc64/kernel/smp.c - 1.39 linux/arch/sparc64/kernel/setup.c - 1.28 linux/arch/sparc64/kernel/irq.c - 1.25 linux/arch/sparc64/kernel/ioctl32.c - 1.56 linux/arch/sparc64/kernel/head.S - 1.20 linux/arch/sparc64/kernel/entry.S - 1.22 linux/arch/sparc64/kernel/cpu.c - 1.9 linux/arch/sparc64/kernel/Makefile - 1.23 linux/arch/sparc64/defconfig - 1.63 linux/arch/sparc64/config.in - 1.51 linux/arch/sparc/mm/srmmu.c - 1.32 linux/arch/sparc/lib/memset.S - 1.5 linux/arch/sparc/lib/copy_user.S - 1.5 linux/arch/sparc/lib/checksum.S - 1.3 linux/arch/sparc/kernel/sys_sunos.c - 1.34 linux/arch/sparc/kernel/sun4d_smp.c - 1.19 linux/arch/sparc/kernel/devices.c - 1.6 linux/arch/sparc/kernel/Makefile - 1.15 linux/arch/sparc/config.in - 1.35 linux/arch/sparc/boot/btfixupprep.c - 1.4 linux/arch/ppc/mm/init.c - 1.43 linux/arch/ppc/mm/fault.c - 1.21 linux/arch/ppc/mm/Makefile - 1.10 linux/arch/ppc/kernel/traps.c - 1.26 linux/arch/ppc/kernel/syscalls.c - 1.15 linux/arch/ppc/kernel/signal.c - 1.19 linux/arch/ppc/kernel/setup.c - 1.44 linux/arch/ppc/kernel/process.c - 1.37 linux/arch/ppc/kernel/ppc_ksyms.c - 1.46 linux/arch/ppc/kernel/ppc_htab.c - 1.18 linux/arch/ppc/kernel/ppc-stub.c - 1.11 linux/arch/ppc/kernel/mk_defs.c - 1.16 linux/arch/ppc/kernel/misc.S - 1.40 linux/arch/ppc/kernel/irq.c - 1.37 linux/arch/ppc/kernel/indirect_pci.c - 1.10 linux/arch/ppc/kernel/head.S - 1.36 linux/arch/ppc/kernel/Makefile - 1.31 linux/arch/ppc/config.in - 1.47 linux/arch/ppc/boot/Makefile - 1.21 linux/arch/ppc/Makefile - 1.27 linux/arch/ppc/8xx_io/uart.c - 1.21 linux/arch/ppc/8xx_io/fec.c - 1.20 linux/arch/ppc/8xx_io/enet.c - 1.20 linux/arch/ppc/8xx_io/commproc.c - 1.13 linux/arch/mips/kernel/irq.c - 1.16 linux/arch/m68k/q40/q40ints.c - 1.8 linux/arch/m68k/mm/memory.c - 1.14 linux/arch/m68k/mm/kmap.c - 1.6 linux/arch/m68k/kernel/ptrace.c - 1.12 linux/arch/m68k/defconfig - 1.14 linux/arch/m68k/config.in - 1.28 linux/arch/m68k/atari/time.c - 1.6 linux/arch/m68k/apollo/dn_ints.c - 1.7 linux/arch/i386/mm/ioremap.c - 1.11 linux/arch/i386/kernel/time.c - 1.22 linux/arch/i386/kernel/setup.c - 1.70 linux/arch/i386/kernel/process.c - 1.44 linux/arch/i386/kernel/irq.c - 1.40 linux/arch/i386/kernel/io_apic.c - 1.39 linux/arch/i386/kernel/i386_ksyms.c - 1.49 linux/arch/i386/kernel/head.S - 1.23 linux/arch/i386/kernel/Makefile - 1.26 linux/arch/i386/defconfig - 1.90 linux/arch/i386/config.in - 1.77 linux/arch/i386/boot/setup.S - 1.26 linux/arch/arm/mm/mm-armv.c - 1.25 linux/arch/arm/config.in - 1.34 linux/arch/alpha/mm/init.c - 1.22 linux/arch/alpha/kernel/setup.c - 1.29 linux/arch/alpha/kernel/irq.c - 1.22 linux/arch/alpha/kernel/Makefile - 1.21 linux/arch/alpha/config.in - 1.44 linux/arch/alpha/boot/tools/objstrip.c - 1.5 linux/arch/alpha/boot/Makefile - 1.8 linux/arch/alpha/Makefile - 1.12 linux/Makefile - 1.194 linux/MAINTAINERS - 1.95 linux/Documentation/networking/00-INDEX - 1.8 linux/Documentation/ioctl-number.txt - 1.19 linux/Documentation/i386/zero-page.txt - 1.4 linux/Documentation/Configure.help - 1.150 linux/CREDITS - 1.78 linux/include/linux/ide.h - 1.37 linux/drivers/usb/acm.c - 1.45 linux/drivers/sound/cmpci.c - 1.33 linux/arch/sparc/math-emu/sfp-util.h - 1.2 linux/Documentation/kernel-parameters.txt - 1.18 linux/include/linux/threads.h - 1.4 linux/arch/arm/kernel/isa.c - 1.5 linux/drivers/pnp/isapnp.c - 1.27 linux/arch/m68k/math-emu/fp_log.c - 1.2 linux/arch/m68k/math-emu/fp_emu.h - 1.5 linux/drivers/net/sis900.c - 1.36 linux/drivers/char/ip2main.c - 1.16 linux/drivers/atm/eni.c - 1.16 linux/drivers/atm/atmtcp.c - 1.11 linux/drivers/atm/Makefile - 1.17 linux/net/atm/svc.c - 1.12 linux/net/atm/signaling.c - 1.10 linux/net/atm/resources.h - 1.5 linux/net/atm/resources.c - 1.10 linux/net/atm/pvc.c - 1.11 linux/net/atm/proc.c - 1.17 linux/net/atm/mpoa_caches.c - 1.4 linux/net/atm/mpc.h - 1.3 linux/net/atm/mpc.c - 1.11 linux/net/atm/lec.h - 1.9 linux/net/atm/lec.c - 1.17 linux/net/atm/common.h - 1.5 linux/net/atm/common.c - 1.20 linux/net/atm/clip.c - 1.14 linux/net/atm/atm_misc.c - 1.7 linux/net/atm/addr.c - 1.7 linux/include/linux/atmdev.h - 1.13 linux/arch/ppc/kernel/head_8xx.S - 1.19 linux/arch/ppc/kernel/entry.S - 1.28 linux/arch/sparc64/kernel/pci_sabre.c - 1.30 linux/arch/sparc64/kernel/pci_psycho.c - 1.27 linux/arch/sparc64/kernel/pci_iommu.c - 1.15 linux/arch/sparc64/kernel/pci_common.c - 1.17 linux/arch/sparc64/kernel/pci.c - 1.26 linux/arch/sh/lib/Makefile - 1.8 linux/arch/sh/kernel/signal.c - 1.15 linux/arch/sh/kernel/sh_ksyms.c - 1.13 linux/arch/sh/kernel/entry.S - 1.22 linux/arch/sh/kernel/Makefile - 1.15 linux/arch/sh/config.in - 1.24 linux/arch/sh/Makefile - 1.10 linux/drivers/scsi/ips.h - 1.14 linux/drivers/scsi/ips.c - 1.29 linux/net/irda/parameters.c - 1.11 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.8 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.11 linux/net/irda/ircomm/ircomm_ttp.c - 1.6 linux/net/irda/ircomm/ircomm_param.c - 1.9 linux/net/irda/ircomm/ircomm_lmp.c - 1.6 linux/net/irda/ircomm/ircomm_event.c - 1.6 linux/net/irda/ircomm/ircomm_core.c - 1.14 linux/include/asm-sh/processor.h - 1.19 linux/include/asm-sh/irq.h - 1.13 linux/include/asm-sh/io.h - 1.13 linux/include/asm-sh/elf.h - 1.8 linux/include/asm-sh/delay.h - 1.9 linux/include/asm-sh/checksum.h - 1.9 linux/include/asm-i386/pci.h - 1.18 linux/drivers/pcmcia/i82365.c - 1.24 linux/include/asm-sparc64/pci.h - 1.12 linux/include/asm-sparc/pci.h - 1.13 linux/include/asm-ppc/pci.h - 1.18 linux/drivers/net/starfire.c - 1.27 linux/drivers/net/pcmcia/ray_cs.c - 1.26 linux/drivers/net/pcmcia/pcnet_cs.c - 1.19 linux/drivers/net/pcmcia/3c589_cs.c - 1.22 linux/drivers/char/drm/gamma_drv.h - 1.6 linux/drivers/char/drm/gamma_drv.c - 1.12 linux/drivers/char/drm/gamma_dma.c - 1.10 linux/drivers/char/drm/drmP.h - 1.17 linux/drivers/char/drm/drm.h - 1.11 linux/drivers/char/drm/Makefile - 1.15 linux/include/linux/acpi.h - 1.24 linux/drivers/net/dmfe.c - 1.25 linux/drivers/net/wan/Makefile - 1.16 linux/drivers/net/wan/Config.in - 1.16 linux/arch/ppc/8xx_io/Config.in - 1.7 linux/arch/i386/kernel/smpboot.c - 1.32 linux/arch/i386/kernel/pci-visws.c - 1.8 linux/arch/i386/kernel/pci-pc.c - 1.36 linux/arch/i386/kernel/pci-i386.h - 1.9 linux/arch/i386/kernel/pci-i386.c - 1.19 linux/include/linux/pci_ids.h - 1.67 linux/drivers/net/wan/sdlamain.c - 1.12 linux/drivers/net/wan/sdla_ppp.c - 1.18 linux/drivers/net/wan/sdla_fr.c - 1.20 linux/drivers/video/tdfxfb.c - 1.20 linux/include/asm-ppc/mpc8xx.h - 1.10 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.19 linux/drivers/net/pcmcia/3c574_cs.c - 1.20 linux/drivers/net/pcmcia/nmclan_cs.c - 1.17 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.19 linux/drivers/net/pcmcia/netwave_cs.c - 1.19 linux/arch/arm/mm/mm-armo.c - 1.9 linux/drivers/net/pcmcia/wavelan_cs.c - 1.16 linux/include/asm-arm/pci.h - 1.18 linux/drivers/video/aty128fb.c - 1.28 linux/fs/proc/proc_misc.c - 1.34 linux/fs/proc/kcore.c - 1.13 linux/drivers/scsi/sun3_scsi.c - 1.12 linux/drivers/pci/pci.ids - 1.48 linux/drivers/net/sk98lin/skxmac2.c - 1.7 linux/drivers/net/sk98lin/h/skgehwt.h - 1.5 linux/drivers/net/sk98lin/skgepnmi.c - 1.7 linux/drivers/net/sk98lin/h/skgeinit.h - 1.6 linux/drivers/net/sk98lin/skgesirq.c - 1.7 linux/Documentation/networking/sk98lin.txt - 1.7 linux/drivers/net/sk98lin/Makefile - 1.5 linux/drivers/net/sk98lin/h/lm80.h - 1.6 linux/drivers/net/sk98lin/h/skaddr.h - 1.6 linux/drivers/net/sk98lin/h/skdebug.h - 1.4 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.9 linux/drivers/net/sk98lin/h/skdrv2nd.h - 1.6 linux/drivers/net/sk98lin/h/skerror.h - 1.4 linux/drivers/net/sk98lin/skvpd.c - 1.7 linux/drivers/net/sk98lin/sktimer.c - 1.5 linux/drivers/net/sk98lin/skrlmt.c - 1.6 linux/drivers/net/sk98lin/h/skgedrv.h - 1.4 linux/drivers/net/sk98lin/h/skgehw.h - 1.7 linux/drivers/net/sk98lin/skgeinit.c - 1.7 linux/drivers/net/sk98lin/skge.c - 1.23 linux/drivers/net/sk98lin/skgehwt.c - 1.5 linux/drivers/net/sk98lin/h/skgepnm2.h - 1.6 linux/drivers/net/sk98lin/h/skgepnmi.h - 1.6 linux/drivers/net/sk98lin/h/skgesirq.h - 1.6 linux/drivers/net/sk98lin/skqueue.c - 1.6 linux/drivers/net/sk98lin/h/ski2c.h - 1.6 linux/drivers/net/sk98lin/h/skqueue.h - 1.5 linux/drivers/net/sk98lin/ski2c.c - 1.6 linux/drivers/net/sk98lin/h/skrlmt.h - 1.6 linux/drivers/net/sk98lin/h/sktimer.h - 1.5 linux/drivers/net/sk98lin/h/sktypes.h - 1.3 linux/drivers/net/sk98lin/h/skvpd.h - 1.6 linux/drivers/net/sk98lin/h/xmac_ii.h - 1.7 linux/drivers/net/sk98lin/skaddr.c - 1.7 linux/drivers/net/sk98lin/skcsum.c - 1.6 linux/include/asm-ppc/pgalloc.h - 1.9 linux/arch/ppc/kernel/head_4xx.S - 1.9 linux/arch/ppc/configs/mbx_defconfig - 1.16 linux/arch/ppc/configs/apus_defconfig - 1.17 linux/arch/alpha/kernel/sys_nautilus.c - 1.10 linux/include/linux/mmzone.h - 1.20 linux/include/asm-sparc/sfp-machine.h - 1.4 linux/include/linux/agp_backend.h - 1.21 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.16 linux/drivers/char/drm/tdfx_drv.c - 1.11 linux/drivers/char/agp/agpgart_be.c - 1.38 linux/drivers/char/agp/agp.h - 1.27 linux/include/linux/i2c-id.h - 1.12 linux/Documentation/video4linux/bttv/CARDLIST - 1.17 linux/arch/i386/kernel/acpi.c - 1.24 linux/drivers/usb/scanner.c - 1.29 linux/Documentation/usb/usb-serial.txt - 1.21 linux/drivers/usb/devio.c - 1.23 linux/drivers/ieee1394/raw1394.h - 1.6 linux/drivers/ieee1394/raw1394.c - 1.21 linux/drivers/ieee1394/pcilynx.c - 1.24 linux/drivers/ieee1394/ieee1394_core.c - 1.25 linux/drivers/ieee1394/ohci1394.c - 1.27 linux/drivers/ieee1394/ieee1394_types.h - 1.16 linux/drivers/ieee1394/ieee1394_transactions.h - 1.7 linux/drivers/ieee1394/ieee1394_transactions.c - 1.14 linux/arch/i386/kernel/apic.c - 1.27 linux/drivers/ieee1394/highlevel.h - 1.8 linux/arch/i386/kernel/mpparse.c - 1.19 linux/drivers/ieee1394/csr.c - 1.13 linux/drivers/ieee1394/highlevel.c - 1.12 linux/drivers/scsi/scsi_scan.c - 1.29 linux/drivers/scsi/3w-xxxx.c - 1.21 linux/drivers/net/wan/sdla_chdlc.c - 1.18 linux/include/asm-m68k/pci.h - 1.6 linux/drivers/usb/scanner.h - 1.22 linux/drivers/sound/ac97_codec.c - 1.27 linux/drivers/net/irda/nsc-ircc.c - 1.20 linux/arch/ia64/kernel/head.S - 1.13 linux/arch/ia64/kernel/entry.h - 1.6 linux/arch/ia64/kernel/entry.S - 1.25 linux/arch/ia64/kernel/efi_stub.S - 1.6 linux/arch/ia64/kernel/efi.c - 1.17 linux/arch/ia64/kernel/acpi.c - 1.15 linux/arch/ia64/kernel/Makefile - 1.14 linux/arch/ia64/ia32/sys_ia32.c - 1.25 linux/arch/ia64/ia32/ia32_support.c - 1.9 linux/arch/ia64/ia32/ia32_signal.c - 1.10 linux/arch/ia64/ia32/binfmt_elf32.c - 1.16 linux/arch/ppc/kernel/pci-dma.c - 1.5 linux/arch/ia64/tools/print_offsets.c - 1.12 linux/arch/ia64/defconfig - 1.17 linux/arch/ia64/config.in - 1.25 linux/arch/ia64/Makefile - 1.14 linux/Documentation/networking/atm.txt - 1.2 linux/arch/ia64/kernel/setup.c - 1.16 linux/arch/ia64/kernel/signal.c - 1.15 linux/arch/ia64/kernel/traps.c - 1.16 linux/arch/ia64/kernel/unaligned.c - 1.13 linux/arch/ia64/kernel/unwind.c - 1.14 linux/arch/ia64/kernel/ivt.S - 1.16 linux/arch/ia64/kernel/pci.c - 1.13 linux/arch/ia64/kernel/ptrace.c - 1.18 linux/arch/ia64/kernel/process.c - 1.16 linux/arch/ia64/kernel/perfmon.c - 1.13 linux/arch/ia64/mm/tlb.c - 1.13 linux/arch/ia64/kernel/mca.c - 1.13 linux/arch/ia64/mm/init.c - 1.17 linux/arch/ia64/mm/Makefile - 1.4 linux/arch/ia64/kernel/mca_asm.S - 1.12 linux/arch/ia64/kernel/pal.S - 1.10 linux/drivers/scsi/qla1280.h - 1.3 linux/drivers/scsi/qla1280.c - 1.12 linux/drivers/scsi/ql1280_fw.h - 1.2 linux/drivers/scsi/ql12160_fw.h - 1.2 linux/include/asm-ia64/sigcontext.h - 1.6 linux/include/asm-ia64/ia32.h - 1.13 linux/include/asm-ia64/elf.h - 1.6 linux/include/asm-ia64/bitops.h - 1.11 linux/include/asm-ia64/a.out.h - 1.6 linux/include/asm-ia64/smp.h - 1.11 linux/include/asm-ia64/sal.h - 1.13 linux/include/asm-ia64/processor.h - 1.20 linux/include/asm-ia64/pgtable.h - 1.17 linux/include/asm-ia64/pci.h - 1.16 linux/include/asm-ia64/page.h - 1.14 linux/include/asm-ia64/resource.h - 1.3 linux/include/asm-ia64/ptrace_offsets.h - 1.7 linux/include/asm-ia64/ptrace.h - 1.11 linux/include/asm-ia64/mca.h - 1.9 linux/include/asm-ia64/spinlock.h - 1.10 linux/include/asm-ia64/unwind.h - 1.7 linux/include/asm-ia64/system.h - 1.16 linux/drivers/net/8139too.c - 1.41 linux/net/bridge/br_forward.c - 1.6 linux/include/linux/lvm.h - 1.15 linux/net/bridge/br_stp_bpdu.c - 1.5 linux/fs/lockd/svc4proc.c - 1.9 linux/drivers/net/tulip/tulip_core.c - 1.44 linux/include/asm-mips64/elf.h - 1.11 linux/include/asm-mips64/pci.h - 1.14 linux/arch/mips64/defconfig - 1.23 linux/drivers/atm/fore200e.c - 1.16 linux/include/asm-sh/pci.h - 1.13 linux/include/asm-sh/div64.h - 1.2 linux/drivers/char/sh-sci.h - 1.10 linux/drivers/char/sh-sci.c - 1.19 linux/arch/sh/kernel/fpu.c - 1.6 linux/Documentation/zorro.txt - 1.3 linux/include/linux/usb.h - 1.26 linux/include/asm-ia64/hw_irq.h - 1.8 linux/drivers/usb/serial/usb-serial.h - 1.18 linux/drivers/usb/serial/keyspan_pda_fw.h - 1.3 linux/drivers/usb/serial/ftdi_sio.h - 1.9 linux/drivers/ide/ide.c - 1.43 linux/drivers/ide/ide-tape.c - 1.18 linux/drivers/ide/ide-probe.c - 1.23 linux/drivers/ide/ide-geometry.c - 1.12 linux/drivers/ide/ide-disk.c - 1.24 linux/drivers/ide/ide-cd.c - 1.26 linux/drivers/ide/Makefile - 1.19 linux/drivers/ide/Config.in - 1.23 linux/net/ipv4/netfilter/ipt_unclean.c - 1.10 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.18 linux/net/ipv4/netfilter/ipt_REDIRECT.c - 1.7 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.9 linux/net/ipv4/netfilter/ipt_LOG.c - 1.10 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.16 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.9 linux/net/ipv4/netfilter/ip_nat_core.c - 1.14 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.12 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.15 linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.11 linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_proto_generic.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.18 linux/include/linux/netfilter_ipv4/ip_nat_rule.h - 1.3 linux/include/linux/netfilter_ipv4/ip_conntrack_tuple.h - 1.6 linux/drivers/usb/mdc800.c - 1.17 linux/drivers/sound/dmasound/dmasound_core.c - 1.13 linux/drivers/scsi/dmx3191d.c - 1.9 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.11 linux/arch/i386/kernel/pci-irq.c - 1.26 linux/include/linux/usbdevice_fs.h - 1.6 linux/include/linux/nfs_xdr.h - 1.8 linux/fs/ramfs/inode.c - 1.17 linux/fs/nfs/nfs3proc.c - 1.12 linux/drivers/usb/serial/keyspan_pda.c - 1.19 linux/drivers/usb/serial/ftdi_sio.c - 1.31 linux/drivers/usb/serial/usbserial.c - 1.30 linux/drivers/usb/serial/visor.h - 1.11 linux/drivers/usb/serial/visor.c - 1.32 linux/arch/ia64/kernel/smpboot.c - 1.11 linux/arch/ia64/kernel/minstate.h - 1.8 linux/drivers/sound/i810_audio.c - 1.29 linux/drivers/net/wan/lmc/lmc_proto.c - 1.4 linux/include/asm-ppc/cpm_8260.h - 1.8 linux/drivers/net/pppoe.c - 1.21 linux/arch/ppc/8260_io/uart.c - 1.13 linux/arch/s390/config.in - 1.14 linux/arch/s390/defconfig - 1.15 linux/include/asm-s390/elf.h - 1.5 linux/arch/sh/kernel/irq_ipr.c - 1.8 linux/include/linux/sisfb.h - 1.9 linux/drivers/char/drm/r128_drv.h - 1.9 linux/drivers/char/drm/r128_drv.c - 1.8 linux/drivers/char/drm/r128_drm.h - 1.5 linux/drivers/char/drm/mga_state.c - 1.9 linux/drivers/char/drm/mga_drv.h - 1.9 linux/drivers/char/drm/mga_drv.c - 1.7 linux/drivers/char/drm/mga_drm.h - 1.5 linux/drivers/char/drm/mga_dma.c - 1.8 linux/drivers/char/drm/i810_drv.h - 1.4 linux/drivers/char/drm/i810_drv.c - 1.7 linux/drivers/char/drm/i810_drm.h - 1.4 linux/drivers/char/drm/i810_dma.c - 1.11 linux/drivers/char/drm/Config.in - 1.8 linux/drivers/char/sbc60xxwdt.c - 1.12 linux/drivers/usb/storage/protocol.c - 1.10 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.5 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.5 linux/drivers/usb/serial/keyspan.h - 1.10 linux/drivers/usb/serial/keyspan.c - 1.20 linux/drivers/acpi/tables/tbinstal.c - 1.9 linux/drivers/acpi/tables.c - 1.4 linux/drivers/acpi/resources/rsirq.c - 1.8 linux/drivers/acpi/resources/rsaddr.c - 1.8 linux/drivers/acpi/parser/psparse.c - 1.10 linux/drivers/acpi/namespace/nsutils.c - 1.9 linux/drivers/acpi/namespace/nssearch.c - 1.10 linux/drivers/usb/bluetooth.c - 1.20 linux/drivers/acpi/hardware/hwacpi.c - 1.10 linux/drivers/acpi/events/evregion.c - 1.11 linux/drivers/acpi/ec.c - 1.9 linux/drivers/acpi/dispatcher/dswstate.c - 1.10 linux/drivers/acpi/dispatcher/dswscope.c - 1.9 linux/drivers/acpi/dispatcher/dswload.c - 1.9 linux/drivers/acpi/dispatcher/dsutils.c - 1.9 linux/drivers/acpi/dispatcher/dsopcode.c - 1.10 linux/drivers/acpi/dispatcher/dsfield.c - 1.9 linux/arch/ia64/kernel/palinfo.c - 1.10 linux/arch/sh/boot/compressed/head.S - 1.5 linux/arch/sh/boot/compressed/Makefile - 1.4 linux/arch/ppc/configs/rpxlite_defconfig - 1.16 linux/arch/ppc/configs/rpxcllf_defconfig - 1.17 linux/arch/ppc/configs/bseip_defconfig - 1.16 linux/kernel/user.c - 1.4 linux/include/asm-sh/machvec.h - 1.6 linux/drivers/net/natsemi.c - 1.24 linux/drivers/media/video/videodev.c - 1.13 linux/drivers/media/video/tvmixer.c - 1.11 linux/drivers/media/video/tuner.c - 1.13 linux/drivers/media/video/tda9875.c - 1.12 linux/drivers/media/video/tda7432.c - 1.13 linux/drivers/media/video/saa7110.c - 1.6 linux/drivers/media/video/msp3400.c - 1.14 linux/drivers/media/video/cpia.h - 1.6 linux/drivers/media/video/cpia.c - 1.10 linux/drivers/media/video/bttv-if.c - 1.9 linux/drivers/media/video/bttv-driver.c - 1.21 linux/drivers/media/video/bttv-cards.c - 1.15 linux/drivers/char/i810-tco.h - 1.4 linux/drivers/char/i810-tco.c - 1.13 linux/drivers/md/lvm.c - 1.28 linux/Documentation/SubmittingDrivers - 1.8 linux/Documentation/cciss.txt - 1.7 linux/drivers/acpi/namespace/nsdump.c - 1.7 linux/drivers/block/cciss.c - 1.26 linux/drivers/block/cciss.h - 1.9 linux/drivers/md/lvm-snap.c - 1.14 linux/drivers/net/winbond-840.c - 1.19 linux/include/asm-ppc/highmem.h - 1.8 linux/arch/ia64/lib/idiv64.S - 1.4 linux/mm/oom_kill.c - 1.14 linux/drivers/video/sis/initdef.h - 1.8 linux/drivers/video/sis/sis_main.c - 1.15 linux/drivers/media/video/tvaudio.c - 1.13 linux/drivers/media/video/id.h - 1.4 linux/drivers/media/video/bttvp.h - 1.11 linux/net/irda/irnet/irnet.h - 1.11 linux/include/asm-alpha/xor.h - 1.2 linux/include/asm-i386/cpufeature.h - 1.5 linux/include/linux/ethtool.h - 1.14 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.4 linux/include/asm-parisc/pci.h - 1.7 linux/arch/i386/kernel/dmi_scan.c - 1.17 linux/drivers/sound/ymfpci.c - 1.19 linux/include/asm-parisc/elf.h - 1.3 linux/arch/parisc/config.in - 1.5 linux/drivers/acpi/tables/tbconvrt.c - 1.8 linux/mm/shmem.c - 1.37 linux/drivers/acpi/power.c - 1.5 linux/include/asm-ia64/sn/cdl.h - 1.6 linux/include/asm-ia64/sn/dmamap.h - 1.6 linux/include/asm-ia64/sn/hcl.h - 1.6 linux/include/asm-ia64/sn/invent.h - 1.5 linux/include/asm-ia64/sn/io.h - 1.6 linux/drivers/char/drm/r128_state.c - 1.4 linux/include/asm-ia64/sn/ioerror.h - 1.6 linux/include/asm-ia64/sn/ioerror_handling.h - 1.5 linux/include/asm-ia64/sn/iograph.h - 1.6 linux/include/asm-ia64/sn/klconfig.h - 1.6 linux/drivers/char/drm/r128_cce.c - 1.6 linux/include/asm-ia64/sn/ksys/l1.h - 1.6 linux/arch/ia64/kernel/iosapic.c - 1.9 linux/include/asm-ia64/sn/module.h - 1.6 linux/include/asm-ia64/sn/xtalk/xwidget.h - 1.5 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.6 linux/arch/ia64/sn/io/Makefile - 1.7 linux/arch/ia64/sn/io/io.c - 1.6 linux/arch/ia64/sn/io/sgi_if.c - 1.6 linux/include/asm-ia64/sn/nodepda.h - 1.6 linux/include/asm-ia64/sn/sgi.h - 1.6 linux/include/asm-ia64/sn/pci/pciio.h - 1.6 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.7 linux/include/asm-ia64/sn/pci/pcibr.h - 1.6 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.6 linux/include/asm-ia64/sn/pci/bridge.h - 1.6 linux/drivers/char/drm/radeon_cp.c - 1.7 linux/drivers/char/drm/radeon_drm.h - 1.3 linux/drivers/char/drm/radeon_drv.c - 1.3 linux/drivers/char/drm/radeon_drv.h - 1.5 linux/drivers/char/drm/radeon_state.c - 1.5 linux/arch/sparc64/kernel/pci_schizo.c - 1.15 linux/fs/reiserfs/ioctl.c - 1.8 linux/drivers/usb/storage/unusual_devs.h - 1.12 linux/drivers/sbus/char/cpwatchdog.c - 1.5 linux/include/asm-s390x/elf.h - 1.4 linux/arch/cris/config.in - 1.12 linux/arch/s390x/kernel/binfmt_elf32.c - 1.5 linux/arch/s390x/defconfig - 1.14 linux/arch/s390x/config.in - 1.9 linux/include/asm-cris/elf.h - 1.4 linux/drivers/md/lvm-internal.h - 1.6 linux/drivers/md/lvm-fs.c - 1.8 linux/include/linux/hdlc.h - 1.4 linux/drivers/usb/serial/io_usbvend.h - 1.8 linux/drivers/usb/serial/io_ionsp.h - 1.3 linux/drivers/usb/serial/io_fw_down2.h - 1.3 linux/drivers/usb/serial/io_fw_down.h - 1.3 linux/drivers/usb/serial/io_fw_boot2.h - 1.3 linux/drivers/usb/serial/io_fw_boot.h - 1.3 linux/drivers/usb/serial/io_edgeport.h - 1.4 linux/drivers/usb/serial/io_edgeport.c - 1.20 linux/drivers/usb/serial/io_16654.h - 1.3 linux/drivers/net/wan/n2.c - 1.4 linux/drivers/net/wan/hd6457x.c - 1.3 linux/drivers/net/wan/dscc4.c - 1.7 linux/drivers/net/wan/c101.c - 1.4 linux/drivers/net/sungem.c - 1.16 linux/arch/ppc/configs/TQM860L_defconfig - 1.15 linux/arch/ppc/configs/TQM850L_defconfig - 1.14 linux/arch/ppc/configs/TQM823L_defconfig - 1.14 linux/arch/ppc/configs/SPD823TS_defconfig - 1.14 linux/arch/ppc/configs/SM850_defconfig - 1.14 linux/arch/ppc/configs/IVMS8_defconfig - 1.15 linux/drivers/net/wan/wanpipe_multppp.c - 1.8 linux/drivers/s390/net/ctctty.c - 1.5 linux/drivers/sbus/char/bbc_envctrl.c - 1.3 linux/arch/sh/kernel/irq_intc2.c - 1.6 linux/include/asm-ia64/sn/pci/pciba.h - 1.5 linux/include/asm-ia64/sn/sn_sal.h - 1.5 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.7 linux/arch/ia64/kernel/efivars.c - 1.8 linux/include/asm-sparc64/chafsr.h - 1.2 linux/arch/sparc64/kernel/isa.c - 1.3 linux/drivers/net/fealnx.c - 1.15 linux/drivers/net/irda/irda-usb.c - 1.14 linux/drivers/net/wireless/Config.in - 1.6 linux/drivers/net/wireless/Makefile - 1.5 linux/include/asm-sparc64/isa.h - 1.2 linux/drivers/usb/pwc.h - 1.11 linux/arch/ppc/boot/images/Makefile - 1.4 linux/drivers/usb/pwc-uncompress.h - 1.4 linux/arch/ppc/boot/common/crt0.S - 1.7 linux/drivers/usb/pwc-uncompress.c - 1.5 linux/drivers/usb/pwc-misc.c - 1.5 linux/drivers/usb/pwc-ioctl.h - 1.7 linux/drivers/usb/pwc-if.c - 1.12 linux/drivers/usb/pwc-ctrl.c - 1.10 linux/include/asm-m68k/mc146818rtc.h - 1.3 linux/drivers/bluetooth/hci_usb.c - 1.9 linux/drivers/bluetooth/Config.in - 1.7 linux/drivers/acpi/utilities/utglobal.c - 1.5 linux/drivers/acpi/utilities/utdelete.c - 1.5 linux/drivers/acpi/utilities/utalloc.c - 1.5 linux/drivers/acpi/Config.in - 1.3 linux/drivers/usb/serial/pl2303.h - 1.5 linux/drivers/net/wireless/airo.c - 1.16 linux/drivers/acpi/executer/exsystem.c - 1.4 linux/drivers/acpi/executer/exstoren.c - 1.4 linux/drivers/acpi/executer/exconfig.c - 1.5 linux/drivers/acpi/executer/excreate.c - 1.5 linux/drivers/acpi/executer/exfield.c - 1.4 linux/drivers/acpi/executer/exfldio.c - 1.5 linux/drivers/acpi/executer/exprep.c - 1.5 linux/drivers/acpi/executer/exresnte.c - 1.6 linux/drivers/acpi/executer/exresolv.c - 1.5 linux/drivers/acpi/executer/exresop.c - 1.5 linux/drivers/usb/serial/pl2303.c - 1.11 linux/Documentation/README.nsp_cs.eng - 1.3 linux/drivers/net/sk98lin/h/skversion.h - 1.4 linux/drivers/net/sk98lin/skproc.c - 1.9 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.10 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.6 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.7 linux/drivers/scsi/pcmcia/nsp_io.h - 1.6 linux/Documentation/sonypi.txt - 1.10 linux/Documentation/video4linux/meye.txt - 1.6 linux/drivers/char/sonypi.h - 1.11 linux/drivers/media/video/meye.h - 1.6 linux/drivers/media/video/meye.c - 1.10 linux/drivers/usb/usb-skeleton.c - 1.9 linux/drivers/char/ser_a2232.c - 1.4 linux/include/linux/sonypi.h - 1.7 linux/drivers/char/sonypi.c - 1.11 linux/drivers/message/fusion/linux_compat.h - 1.8 linux/drivers/ieee1394/sbp2.c - 1.15 linux/drivers/ieee1394/sbp2.h - 1.13 linux/drivers/ieee1394/nodemgr.c - 1.16 linux/drivers/video/aty/mach64_gx.c - 1.3 linux/drivers/video/aty/atyfb.h - 1.3 linux/drivers/video/aty/atyfb_base.c - 1.11 linux/drivers/video/aty/mach64.h - 1.2 linux/drivers/video/aty/mach64_ct.c - 1.2 linux/drivers/video/aty/mach64_cursor.c - 1.3 linux/drivers/scsi/pcmcia/nsp_message.c - 1.4 linux/drivers/char/drm/radeon.h - 1.3 linux/drivers/char/drm/drm_ioctl.h - 1.5 linux/drivers/char/drm/r128.h - 1.2 linux/drivers/char/drm/mga_warp.c - 1.3 linux/drivers/char/drm/mga.h - 1.2 linux/drivers/char/drm/i810.h - 1.2 linux/drivers/char/drm/gamma.h - 1.2 linux/drivers/char/drm/drm_vm.h - 1.11 linux/drivers/char/drm/drm_stub.h - 1.3 linux/drivers/char/drm/drm_proc.h - 1.4 linux/drivers/char/drm/drm_memory.h - 1.3 linux/drivers/char/drm/drm_lock.h - 1.3 linux/drivers/char/drm/drm_fops.h - 1.3 linux/drivers/char/drm/drm_drv.h - 1.5 linux/drivers/char/drm/drm_dma.h - 1.3 linux/drivers/char/drm/drm_context.h - 1.6 linux/drivers/char/drm/drm_bufs.h - 1.3 linux/drivers/char/drm/drm_agpsupport.h - 1.7 linux/drivers/net/wan/farsync.c - 1.7 linux/drivers/usb/usbnet.c - 1.14 linux/arch/ppc/mm/cachemap.c - 1.4 linux/arch/ppc/mm/mmu_context.c - 1.5 linux/arch/ppc/mm/mmu_decl.h - 1.7 linux/arch/ppc/mm/pgtable.c - 1.7 linux/arch/ppc/mm/ppc_mmu.c - 1.8 linux/arch/ppc/kernel/cputable.c - 1.10 linux/arch/sh/mm/__clear_user_page-sh4.S - 1.2 linux/arch/sh/mm/__copy_user_page-sh4.S - 1.2 linux/arch/sh/mm/cache-sh4.c - 1.5 linux/arch/sh/mm/clear_page.S - 1.3 linux/drivers/usb/serial/xircom_pgs_fw.h - 1.3 linux/fs/jffs2/dir.c - 1.7 linux/fs/jffs2/erase.c - 1.5 linux/fs/jffs2/file.c - 1.7 linux/fs/jffs2/gc.c - 1.6 linux/fs/jffs2/nodelist.h - 1.6 linux/fs/jffs2/read.c - 1.4 linux/fs/jffs2/readinode.c - 1.6 linux/fs/jffs2/scan.c - 1.6 linux/fs/jffs2/write.c - 1.6 linux/drivers/net/pcmcia/xircom_cb.c - 1.8 linux/fs/namespace.c - 1.15 linux/include/asm-ppc/commproc.h - 1.5 linux/drivers/net/8139cp.c - 1.11 linux/drivers/pcmcia/i82092.c - 1.7 linux/drivers/acpi/executer/exoparg1.c - 1.3 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.4 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.5 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.7 linux/net/8021q/vlanproc.c - 1.7 linux/net/8021q/vlan_dev.c - 1.6 linux/net/8021q/vlan.c - 1.6 linux/Documentation/networking/ifenslave.c - 1.5 linux/Documentation/networking/bonding.txt - 1.5 linux/drivers/atm/idt77252.c - 1.7 linux/fs/jbd/journal.c - 1.8 linux/drivers/scsi/sym53c8xx_2/Makefile - 1.2 linux/drivers/video/sis/300vtbl.h - 1.7 linux/drivers/video/sis/310vtbl.h - 1.7 linux/drivers/video/sis/init.c - 1.7 linux/drivers/video/sis/init.h - 1.7 linux/drivers/video/sis/init301.c - 1.7 linux/drivers/video/sis/init301.h - 1.7 linux/drivers/video/sis/oem300.h - 1.7 linux/drivers/video/sis/oem310.h - 1.7 linux/drivers/video/sis/sis_main.h - 1.7 linux/net/atm/pppoatm.c - 1.5 linux/drivers/video/sis/vgatypes.h - 1.7 linux/drivers/video/sis/vstruct.h - 1.6 linux/arch/i386/kernel/acpitable.c - 1.5 linux/drivers/hotplug/pci_hotplug_util.c - 1.3 linux/drivers/hotplug/pci_hotplug_core.c - 1.5 linux/drivers/hotplug/pci_hotplug.h - 1.4 linux/drivers/hotplug/cpqphp_proc.c - 1.3 linux/drivers/hotplug/cpqphp_pci.c - 1.3 linux/drivers/hotplug/cpqphp_nvram.h - 1.2 linux/drivers/hotplug/cpqphp_nvram.c - 1.3 linux/drivers/hotplug/cpqphp_ctrl.c - 1.5 linux/drivers/hotplug/cpqphp_core.c - 1.5 linux/drivers/hotplug/cpqphp.h - 1.4 linux/include/linux/seq_file.h - 1.3 linux/fs/jbd/transaction.c - 1.6 linux/fs/seq_file.c - 1.5 linux/drivers/hotplug/Config.in - 1.5 linux/arch/i386/kernel/acpitable.h - 1.3 linux/drivers/net/pcmcia/axnet_cs.c - 1.5 linux/drivers/char/drm/sis_ds.c - 1.4 linux/drivers/char/drm/sis_drv.c - 1.3 linux/drivers/char/drm/sis_drm.h - 1.3 linux/drivers/char/drm/sis.h - 1.2 linux/drivers/scsi/aacraid/linit.c - 1.6 linux/drivers/scsi/aacraid/dpcsup.c - 1.5 linux/drivers/scsi/aacraid/aachba.c - 1.6 linux/drivers/scsi/aacraid/commsup.c - 1.5 linux/drivers/scsi/aacraid/comminit.c - 1.5 linux/drivers/scsi/aacraid/commctrl.c - 1.4 linux/drivers/scsi/aacraid/aacraid.h - 1.5 linux/drivers/char/drm-4.0/agpsupport.c - 1.4 linux/drivers/usb/stv680.c - 1.4 linux/drivers/usb/serial/ipaq.c - 1.6 linux/drivers/usb/vicam.c - 1.7 linux/net/ipv4/netfilter/ipt_esp.c - 1.2 linux/net/ipv4/netfilter/ipt_ah.c - 1.3 linux/fs/quota_v1.c - 1.3 linux/drivers/bluetooth/hci_usb.h - 1.4 linux/drivers/block/umem.c - 1.7 linux/drivers/char/hcdp_serial.c - 1.4 linux/drivers/hotplug/ibmphp.h - 1.3 linux/drivers/hotplug/ibmphp_core.c - 1.3 linux/drivers/block/cciss_scsi.h - 1.3 linux/drivers/block/cciss_scsi.c - 1.5 linux/drivers/hotplug/ibmphp_ebda.c - 1.6 linux/drivers/hotplug/ibmphp_hpc.c - 1.3 linux/drivers/hotplug/ibmphp_pci.c - 1.3 linux/drivers/hotplug/ibmphp_res.c - 1.3 linux/drivers/ieee1394/cmp.c - 1.6 linux/drivers/ieee1394/eth1394.c - 1.7 linux/drivers/ieee1394/eth1394.h - 1.6 linux/net/core/wireless.c - 1.4 linux/net/core/pktgen.c - 1.3 linux/net/atm/br2684.c - 1.4 linux/drivers/net/tg3.c - 1.11 linux/drivers/net/tg3.h - 1.7 linux/init/do_mounts.c - 1.9 linux/include/net/iw_handler.h - 1.4 linux/include/asm-ppc64/pci.h - 1.3 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.5 linux/arch/ia64/sn/fakeprom/fpmem.h - 1.3 linux/arch/ia64/sn/fakeprom/fpromasm.S - 1.4 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.5 linux/arch/ia64/sn/fakeprom/main.c - 1.4 linux/include/asm-ppc64/elf.h - 1.4 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.4 linux/arch/ia64/sn/io/sn2/shub_intr.c - 1.4 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.4 linux/arch/ia64/sn/kernel/Makefile - 1.4 linux/arch/ia64/sn/kernel/bte.c - 1.4 linux/arch/ia64/sn/kernel/irq.c - 1.4 linux/arch/ia64/sn/kernel/setup.c - 1.4 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.4 linux/arch/ia64/sn/kernel/sn2/cache.c - 1.3 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.5 linux/arch/ppc64/defconfig - 1.5 linux/arch/ppc64/config.in - 1.5 linux/arch/ppc/kernel/prom_init.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.5 linux/arch/ppc/boot/utils/mkimage.wrapper - 1.2 linux/arch/ppc/boot/simple/misc-embedded.c - 1.4 linux/include/asm-ia64/sn/uart16550.h - 1.4 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.4 linux/include/asm-ia64/sn/sn2/shubio.h - 1.4 linux/include/asm-ia64/sn/sn2/arch.h - 1.4 linux/include/asm-ia64/sn/simulator.h - 1.4 linux/include/asm-ia64/sn/bte.h - 1.4 linux/arch/ppc/boot/simple/head.S - 1.4 linux/arch/ppc/boot/simple/embed_config.c - 1.4 linux/arch/ppc/boot/simple/Makefile - 1.5 linux/arch/ppc/boot/common/util.S - 1.4 linux/drivers/usb/brlvger.c - 1.3 linux/arch/mips64/kernel/irq.c - 1.5 linux/net/sunrpc/timer.c - 1.2 linux/arch/x86_64/Makefile - 1.4 linux/arch/x86_64/boot/setup.S - 1.4 linux/net/sched/sch_htb.c - 1.4 linux/Documentation/filesystems/jfs.txt - 1.4 linux/arch/x86_64/config.in - 1.4 linux/arch/x86_64/defconfig - 1.4 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.4 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.6 linux/arch/x86_64/ia32/ia32_signal.c - 1.3 linux/arch/x86_64/ia32/ia32entry.S - 1.3 linux/arch/x86_64/ia32/ipc32.c - 1.3 linux/arch/x86_64/ia32/socket32.c - 1.4 linux/arch/x86_64/ia32/sys_ia32.c - 1.4 linux/arch/x86_64/kernel/bluesmoke.c - 1.4 linux/arch/x86_64/kernel/e820.c - 1.4 linux/arch/x86_64/kernel/entry.S - 1.4 linux/arch/x86_64/kernel/head.S - 1.4 linux/arch/x86_64/kernel/io_apic.c - 1.4 linux/arch/x86_64/kernel/ioport.c - 1.4 linux/arch/x86_64/kernel/irq.c - 1.2 linux/arch/x86_64/kernel/mpparse.c - 1.3 linux/arch/x86_64/kernel/nmi.c - 1.3 linux/arch/x86_64/kernel/pci-gart.c - 1.4 linux/arch/x86_64/kernel/pci-pc.c - 1.3 linux/arch/x86_64/kernel/pci-x86_64.c - 1.3 linux/arch/x86_64/kernel/pci-x86_64.h - 1.3 linux/arch/x86_64/kernel/process.c - 1.4 linux/arch/x86_64/kernel/setup.c - 1.4 linux/arch/x86_64/kernel/setup64.c - 1.4 linux/arch/x86_64/kernel/signal.c - 1.3 linux/arch/x86_64/kernel/smp.c - 1.4 linux/arch/x86_64/kernel/smpboot.c - 1.3 linux/arch/x86_64/kernel/sys_x86_64.c - 1.3 linux/arch/x86_64/kernel/traps.c - 1.4 linux/arch/ia64/hp/common/sba_iommu.c - 1.4 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.3 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.3 linux/lib/Config.in - 1.3 linux/arch/x86_64/lib/copy_page.S - 1.3 linux/arch/x86_64/lib/copy_user.S - 1.4 linux/arch/x86_64/lib/csum-copy.S - 1.4 linux/arch/x86_64/lib/usercopy.c - 1.3 linux/arch/ia64/kernel/salinfo.c - 1.3 linux/arch/x86_64/mm/extable.c - 1.2 linux/arch/x86_64/mm/fault.c - 1.4 linux/arch/x86_64/mm/ioremap.c - 1.3 linux/arch/x86_64/mm/k8topology.c - 1.4 linux/include/linux/sunrpc/timer.h - 1.2 linux/drivers/char/amd76x_pm.c - 1.3 linux/drivers/char/amd7xx_tco.c - 1.2 linux/drivers/char/drm/i830.h - 1.2 linux/drivers/char/drm/i830_dma.c - 1.2 linux/drivers/char/drm/i830_drm.h - 1.2 linux/drivers/char/drm/i830_drv.c - 1.2 linux/drivers/char/drm/i830_drv.h - 1.2 linux/drivers/char/pcmcia/synclink_cs.c - 1.2 linux/drivers/char/synclinkmp.c - 1.2 linux/include/asm-x86_64/unistd.h - 1.3 linux/include/asm-x86_64/uaccess.h - 1.3 linux/include/asm-x86_64/system.h - 1.4 linux/include/asm-x86_64/smp.h - 1.5 linux/arch/mips/config-shared.in - 1.4 linux/include/asm-x86_64/ptrace.h - 1.2 linux/include/asm-x86_64/proto.h - 1.4 linux/include/asm-x86_64/processor.h - 1.4 linux/include/asm-x86_64/pgalloc.h - 1.2 linux/include/asm-x86_64/pci.h - 1.4 linux/include/asm-x86_64/msr.h - 1.2 linux/include/asm-x86_64/kdebug.h - 1.3 linux/include/asm-x86_64/io_apic.h - 1.3 linux/include/asm-x86_64/ia32.h - 1.3 linux/include/asm-x86_64/hardirq.h - 1.2 linux/include/asm-x86_64/elf.h - 1.2 linux/include/asm-x86_64/desc.h - 1.3 linux/include/asm-x86_64/cpufeature.h - 1.2 linux/include/asm-x86_64/calling.h - 1.2 linux/include/asm-x86_64/apic.h - 1.3 linux/drivers/hotplug/acpiphp.h - 1.4 linux/drivers/hotplug/acpiphp_core.c - 1.4 linux/drivers/hotplug/acpiphp_glue.c - 1.4 linux/drivers/hotplug/acpiphp_pci.c - 1.4 linux/drivers/hotplug/acpiphp_res.c - 1.4 linux/include/asm-ppc/ppc_asm.h - 1.4 linux/arch/ppc/platforms/Makefile - 1.4 linux/drivers/ide/ide-sibyte.c - 1.4 linux/drivers/net/e100/e100_config.c - 1.3 linux/drivers/net/e100/e100_config.h - 1.3 linux/drivers/net/e100/e100_main.c - 1.4 linux/drivers/net/e1000/e1000.h - 1.4 linux/drivers/net/e1000/e1000_ethtool.c - 1.4 linux/drivers/net/e1000/e1000_hw.c - 1.4 linux/drivers/net/e1000/e1000_hw.h - 1.4 linux/drivers/net/e1000/e1000_main.c - 1.4 linux/drivers/net/e1000/e1000_osdep.h - 1.4 linux/drivers/net/e1000/e1000_param.c - 1.3 linux/drivers/net/irda/act200l.c - 1.2 linux/drivers/net/irda/ma600.c - 1.3 linux/drivers/net/irda/mcp2120.c - 1.2 linux/include/asm-ia64/acpi.h - 1.3 linux/drivers/sound/ali5455.c - 1.3 linux/drivers/sound/forte.c - 1.4 linux/fs/jfs/xattr.c - 1.2 linux/fs/jfs/super.c - 1.4 linux/fs/jfs/resize.c - 1.4 linux/fs/jfs/namei.c - 1.4 linux/fs/jfs/jfs_xtree.c - 1.3 linux/fs/jfs/jfs_unicode.c - 1.3 linux/fs/jfs/jfs_txnmgr.c - 1.4 linux/fs/jfs/jfs_superblock.h - 1.2 linux/fs/jfs/jfs_mount.c - 1.3 linux/fs/jfs/jfs_metapage.c - 1.3 linux/fs/jfs/jfs_logmgr.h - 1.3 linux/fs/jfs/jfs_logmgr.c - 1.3 linux/fs/jfs/jfs_incore.h - 1.4 linux/fs/jfs/jfs_imap.c - 1.3 linux/fs/jfs/jfs_filsys.h - 1.2 linux/fs/jfs/jfs_extent.c - 1.4 linux/fs/jfs/jfs_dtree.c - 1.4 linux/fs/jfs/jfs_dmap.c - 1.3 linux/fs/jfs/jfs_btree.h - 1.3 linux/fs/jfs/inode.c - 1.3 linux/fs/jfs/file.c - 1.4 linux/drivers/usb/aiptek.c - 1.3 linux/drivers/usb/hc_simple.c - 1.2 linux/drivers/usb/hc_simple.h - 1.2 linux/drivers/usb/hc_sl811.c - 1.3 linux/drivers/usb/hc_sl811.h - 1.2 linux/drivers/usb/hc_sl811_rh.c - 1.2 linux/drivers/usb/serial/io_fw_down3.h - 1.2 linux/drivers/usb/serial/io_ti.c - 1.3 linux/drivers/usb/serial/io_ti.h - 1.2 linux/drivers/video/sis/sis_accel.h - 1.4 linux/drivers/video/sis/sis_accel.c - 1.5 linux/net/ipv6/netfilter/ip6t_ipv6header.c - 1.3 linux/net/ipv4/netfilter/ip_nat_tftp.c - 1.2 linux/net/ipv4/netfilter/ip_nat_amanda.c - 1.3 linux/net/bluetooth/rfcomm/core.c - 1.4 linux/include/net/bluetooth/rfcomm.h - 1.4 linux/Documentation/networking/generic-hdlc.txt - 1.2 linux/include/linux/hdlc/ioctl.h - 1.2 linux/include/asm-ia64/sn/pci/pic.h - 1.3 linux/include/asm-ia64/sn/ioc4.h - 1.3 linux/drivers/usb/host/uhci-debug.h - 1.3 linux/drivers/usb/host/ehci.h - 1.3 linux/drivers/usb/host/ehci-sched.c - 1.2 linux/drivers/usb/host/ehci-q.c - 1.3 linux/drivers/usb/host/ehci-hcd.c - 1.3 linux/drivers/usb/host/ehci-dbg.c - 1.3 linux/drivers/usb/host/Makefile - 1.3 linux/drivers/usb/host/Config.in - 1.3 linux/drivers/sound/ad1889.c - 1.4 linux/drivers/scsi/sun3_scsi_vme.c - 1.2 linux/drivers/scsi/nsp32_io.h - 1.3 linux/drivers/scsi/nsp32_debug.c - 1.2 linux/drivers/scsi/nsp32.h - 1.3 linux/drivers/scsi/nsp32.c - 1.3 linux/drivers/net/wan/hdlc_x25.c - 1.2 linux/drivers/net/wan/hdlc_raw.c - 1.2 linux/drivers/net/wan/hdlc_ppp.c - 1.2 linux/drivers/net/wan/hdlc_generic.c - 1.2 linux/drivers/net/wan/hdlc_fr.c - 1.2 linux/drivers/net/wan/hdlc_cisco.c - 1.2 linux/drivers/net/sk98lin/skgemib.c - 1.2 linux/drivers/net/r8169.c - 1.4 linux/drivers/media/video/tda9887.c - 1.3 linux/drivers/ieee1394/ieee1394-ioctl.h - 1.4 linux/drivers/ide/raid/silraid.c - 1.2 linux/arch/ia64/configs/dig - 1.3 linux/arch/ia64/configs/generic - 1.3 linux/arch/ia64/configs/ski - 1.3 linux/arch/ia64/configs/zx1 - 1.3 linux/drivers/ide/raid/pdcraid.c - 1.2 linux/drivers/ide/raid/hptraid.c - 1.4 linux/drivers/ide/pci/siimage.c - 1.5 linux/drivers/ide/pci/serverworks.c - 1.3 linux/drivers/ide/pci/piix.c - 1.3 linux/drivers/ide/pci/pdc202xx_old.c - 1.3 linux/drivers/ide/pci/Makefile - 1.2 linux/drivers/ide/legacy/Makefile - 1.2 linux/drivers/ide/ide-iops.c - 1.2 linux/drivers/ide/ide-io.c - 1.3 linux/drivers/ide/ide-default.c - 1.3 linux/arch/ia64/sn/io/sn2/Makefile - 1.3 linux/arch/ia64/sn/io/sn2/klconflib.c - 1.3 linux/arch/ia64/sn/io/sn2/klgraph.c - 1.3 linux/arch/ia64/sn/io/sn2/l1_command.c - 1.3 linux/arch/ia64/sn/io/sn2/ml_SN_init.c - 1.3 linux/arch/ia64/sn/io/sn2/ml_iograph.c - 1.3 linux/arch/ia64/sn/io/sn2/module.c - 1.3 linux/arch/ia64/sn/io/sn2/pciio.c - 1.3 linux/arch/ia64/sn/io/sn2/pic.c - 1.3 linux/arch/ia64/sn/io/sn2/shub.c - 1.3 linux/arch/ia64/sn/io/sn2/shubio.c - 1.3 linux/arch/ia64/sn/io/sn2/xbow.c - 1.3 linux/arch/ia64/sn/io/sn2/xtalk.c - 1.3 linux/arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.3 linux/Documentation/crypto/api-intro.txt - 1.2 linux/arch/sh/kernel/io_shmse.c - 1.2 linux/arch/sh/kernel/setup_shmse.c - 1.2 linux/Documentation/x86_64/boot-options.txt - 1.2 linux/arch/sh64/config.in - 1.2 linux/arch/sh64/defconfig - 1.2 linux/arch/sh64/kernel/fpu.c - 1.2 linux/arch/sh64/kernel/process.c - 1.2 linux/arch/sh64/kernel/traps.c - 1.2 linux/arch/ppc/kernel/idle_gen.c - 1.2 linux/arch/x86_64/kernel/acpi.c - 1.2 linux/arch/x86_64/kernel/acpi_wakeup.S - 1.2 linux/arch/x86_64/kernel/suspend.c - 1.2 linux/crypto/Config.in - 1.2 linux/crypto/Makefile - 1.2 linux/crypto/proc.c - 1.2 linux/crypto/tcrypt.c - 1.2 linux/crypto/tcrypt.h - 1.2 linux/drivers/acpi/asus_acpi.c - 1.2 linux/drivers/acpi/battery.c - 1.2 linux/drivers/acpi/bus.c - 1.2 linux/drivers/acpi/button.c - 1.2 linux/drivers/acpi/dispatcher/dsinit.c - 1.2 linux/drivers/acpi/events/evgpe.c - 1.2 linux/drivers/acpi/pci_irq.c - 1.2 linux/drivers/acpi/pci_link.c - 1.2 linux/drivers/acpi/system.c - 1.2 linux/drivers/atm/he.c - 1.2 linux/drivers/bluetooth/bfusb.c - 1.2 linux/drivers/bluetooth/bfusb.h - 1.2 linux/include/asm-x86_64/acpi.h - 1.2 linux/include/asm-sh64/registers.h - 1.2 linux/include/asm-sh64/processor.h - 1.2 linux/include/asm-sh64/pci.h - 1.2 linux/include/asm-sh64/elf.h - 1.2 linux/drivers/net/b44.c - 1.2 linux/include/asm-ppc/ocp.h - 1.2 linux/arch/ia64/sn/io/drivers/Makefile - 1.2 linux/arch/ia64/sn/io/drivers/ifconfig_net.c - 1.2 linux/arch/ia64/sn/io/drivers/ioconfig_bus.c - 1.2 linux/arch/ia64/sn/io/drivers/pciba.c - 1.2 linux/drivers/net/bonding/bond_alb.c - 1.2 linux/drivers/net/bonding/bond_alb.h - 1.2 linux/drivers/net/bonding/bond_main.c - 1.2 linux/drivers/net/bonding/bonding.h - 1.2 linux/arch/ia64/sn/io/hwgdfs/hcl.c - 1.2 linux/arch/ia64/sn/io/hwgdfs/hcl_util.c - 1.2 linux/arch/ia64/sn/io/hwgfs/hcl.c - 1.2 linux/arch/ia64/sn/io/hwgfs/hcl_util.c - 1.2 linux/arch/ia64/sn/io/hwgfs/interface.c - 1.2 linux/include/asm-ppc/ibm4xx.h - 1.2 linux/arch/ia64/sn/io/machvec/iomv.c - 1.2 linux/arch/ia64/sn/io/machvec/pci.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.2 linux/arch/ia64/sn/io/platform_init/Makefile - 1.2 linux/arch/ia64/sn/io/platform_init/irix_io_init.c - 1.2 linux/drivers/net/ibm_emac/ibm_emac.h - 1.2 linux/drivers/net/ibm_emac/ibm_ocp_enet.c - 1.2 linux/drivers/net/ibm_emac/ibm_ocp_mal.c - 1.2 linux/arch/ia64/sn/kernel/sn2/timer.c - 1.2 linux/include/asm-ia64/sn/sn2/io.h - 1.2 linux/drivers/usb/host/sl811.c - 1.2 linux/drivers/usb/speedtch.c - 1.2 linux/include/asm-i386/acpi.h - 1.2 linux/include/acpi/acconfig.h - 1.2 linux/include/acpi/acdisasm.h - 1.2 linux/include/acpi/acexcep.h - 1.2 linux/include/acpi/actypes.h - 1.2 linux/include/acpi/actbl2.h - 1.2 linux/include/acpi/actbl1.h - 1.2 linux/include/acpi/actbl.h - 1.2 linux/include/acpi/acstruct.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Nov 11 00:13:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 00:13:42 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB8DT25016514 for ; Tue, 11 Nov 2003 00:13:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAB8X8Hc031683 for ; Tue, 11 Nov 2003 02:33:10 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA29974 for ; Tue, 11 Nov 2003 19:13:18 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 6DC0BC00A9; Tue, 11 Nov 2003 19:13:17 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 6CE1D1400A3 for ; Tue, 11 Nov 2003 19:13:17 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Announce: XFS split patches for 2.4.23-rc1 Date: Tue, 11 Nov 2003 19:13:16 +1100 Message-ID: <9640.1068538396@kao2.melbourne.sgi.com> X-archive-position: 991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 892 Lines: 26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23-rc1. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.23/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/sJoci4UHNye0ZOoRAlCfAKCJASDXgqsTjlIWnjuM4W0ODKvfSQCeMZB0 5+OPlQf3ViTWEcNG5yIQCCo= =OodY -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Nov 11 00:12:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 00:13:33 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAB8Cj25016499 for ; Tue, 11 Nov 2003 00:12:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAB6IQOO005822 for ; Mon, 10 Nov 2003 22:18:27 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA29967 for ; Tue, 11 Nov 2003 19:12:38 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 6FB70C00A9; Tue, 11 Nov 2003 19:12:37 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 6CE161400A3 for ; Tue, 11 Nov 2003 19:12:37 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Announce: XFS split patches for 2.4.22 (respin) Date: Tue, 11 Nov 2003 19:12:36 +1100 Message-ID: <9617.1068538356@kao2.melbourne.sgi.com> X-archive-position: 990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 922 Lines: 27 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.22. Respin as of 2003-11-10_23:49_UTC. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.23/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/sJn0i4UHNye0ZOoRAjZzAJwL/31IDvdTaIRKS2P/EslpOFuuOgCg96x/ s94OsgSDAwOPVNJdAGR9j64= =++nR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Nov 11 04:22:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 04:22:51 -0800 (PST) Received: from smtp.austarmetro.com.au (root@smtp.austarmetro.com.au [203.166.224.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABCM925030396 for ; Tue, 11 Nov 2003 04:22:10 -0800 Received: from webmail.austarmetro.com.au (web-01.sys.bigblue.net.au [203.166.224.15] (may be forged)) by smtp.austarmetro.com.au (8.12.6/pre1.0-MySQL/8.12.6) with SMTP id hABCM6pe021520; Tue, 11 Nov 2003 23:22:06 +1100 Reply-To: lordvader@austarmetro.com.au From: lordvader@austarmetro.com.au (Michael Mamone) To: linux-xfs@oss.sgi.com Subject: Core dump when mounting disk Date: Tue, 11 Nov 2003 23:22:06 +1100 Message-Id: <3fb0d46ed017a2.75422683@austarmetro.com.au> X-Authenticated-IP: [203.221.28.231] X-Sender: lordvader@mail.austarmetro.com.au X-Mailer: PHPost 1.10 (http://webgadgets.com/phpost/) X-Info-1: Report spam to abuse@austarmetro.com.au MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by amavisd-new X-archive-position: 992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lordvader@austarmetro.com.au Precedence: bulk X-list: linux-xfs Content-Length: 3251 Lines: 57 My system recently locked up while I was compiling a program. My system has two partitions, and the files I was compiling lived on the second partition. When I reboot, the attempt to remount that partition fails with a kernel panic, and any subsequent attempts to mount or call xfs_repair on that disk just hang. I've attached the kernel panic output. Note that this is with Mandrake 9.1's default kernel (2.4.21-something-or-other). The same thing happens with kerne; 2.4.22, but the dump from the mandrake kernel had more information. I'll really appreciate any help on this. Starting XFS recovery on filesystem: ide0(3,5) (dev: 3/5) Unable to handle kernel paging request at virtual address 8df06753 printing eip: f8847bb7 *pde = 00000000 Oops: 0000 ide-scsi ide-cd cdrom sd_mod scsi_mod snd-seq-oss snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-intel8x0 snd-ac97-codec snd-pcm snd-timer snd-mpu401-uart snd-rawmidi snd-seq-device snd soundcore snd-page-alloc rtc xfs CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010292 EIP is at E xfs_bmbt_disk_get_all_R177e2d39+0x25d97/0x4a352 [xfs] eax: 00000039 ebx: 8df0674b ecx: f7c8bc6c edx: f7930260 esi: 6b67b13f edi: 8df06757 ebp: f7c8bbc8 esp: f7c8bba8 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 312, stackpage=f7c8b000) Stack: 00000333 00000000 0000000f 00000039 f59fa780 f5f6a200 f59f8000 00000001 f7c8bc7c f8848813 f7005d80 f7c8bc30 f5f6a200 f59f8000 00000001 f5f6a200 f59fa800 f7005d80 37363534 62613938 66656463 6a696867 6e6d6c6b 00000001 Call Trace: [] E xfs_bmbt_disk_get_all_R177e2d39+0x269f3/0x4a352 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x26fc1/0x4a352 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x2702f/0x4a352 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x271d2/0x4a352 [xfs] [] E pagebuf_offset_Ra0b8df28+0xe820/0x10b50 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x201dd/0x4a352 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x284c4/0x4a352 [xfs] [] E pagebuf_offset_Ra0b8df28+0x81a4/0x10b50 [xfs] [] E xfs_bmbt_disk_get_all_R177e2d39+0x2ffe3/0x4a352 [xfs] [] E pagebuf_offset_Ra0b8df28+0x84b9/0x10b50 [xfs] [] alloc_super+0x2f/0x160 [kernel] [] E pagebuf_offset_Ra0b8df28+0x10630/0x10b50 [xfs] [] get_sb_bdev+0x1a8/0x290 [kernel] [] E pagebuf_offset_Ra0b8df28+0x10630/0x10b50 [xfs] [] do_kern_mount+0xfa/0x110 [kernel] [] E pagebuf_offset_Ra0b8df28+0x10630/0x10b50 [xfs] [] do_add_mount+0x75/0x160 [kernel] [] do_mount+0x11f/0x180 [kernel] [] copy_mount_options+0x4b/0xa0 [kernel] [] sys_mount+0x85/0xb0 [kernel] [] system_call+0x33/0x40 [kernel] Code: 8a 43 08 3c 69 74 08 3c aa 0f 85 2b 01 00 00 8b 33 8b 4d 0c blk: queue c03cb420, I/O limit 4095Mb (mask 0xffffffff) ide0: Speed warnings UDMA 3/4/5 is not functional. blk: queue c03cb55c, I/O limit 4095Mb (mask 0xffffffff) CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). From owner-linux-xfs@oss.sgi.com Tue Nov 11 07:52:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 07:53:21 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABFqm25004906 for ; Tue, 11 Nov 2003 07:52:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hABGCWHc030873 for ; Tue, 11 Nov 2003 10:12:32 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hABFqgP513446253; Tue, 11 Nov 2003 09:52:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hABFqeK16070080; Tue, 11 Nov 2003 09:52:41 -0600 (CST) Subject: Re: Core dump when mounting disk From: Eric Sandeen To: lordvader@austarmetro.com.au Cc: linux-xfs@oss.sgi.com In-Reply-To: <3fb0d46ed017a2.75422683@austarmetro.com.au> References: <3fb0d46ed017a2.75422683@austarmetro.com.au> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1068565961.6271.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 11 Nov 2003 09:52:41 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1574 Lines: 37 On Tue, 2003-11-11 at 06:22, Michael Mamone wrote: > My system recently locked up while I was compiling a program. My > system has two partitions, and the files I was compiling lived on the > second partition. When I reboot, the attempt to remount that partition > fails with a kernel panic, and any subsequent attempts to mount or > call xfs_repair on that disk just hang. If the filesystem is small enough, it would be nice if you could dd the partition into a file so that you have a backup of the problem filesystem, before you try other things. If the filesystem is not a system disk, I'd comment it out of the fstab so that you can boot without an oops. Or, add "ro,norecovery" to the mount options. The fs will then be inconsistent, but it won't oops during recovery since that won't run. In a pinch, you can xfs_repair -L to zero out the log, but that will lose both the metadata still in your log, and any forensic evidence about what has happened here. Another xfs developer here has just worked out a log copy utility, if we can get that over to linux fairly quickly perhaps you could make a copy of your log and we could take a look. > I've attached the kernel panic output. Note that this is with Mandrake > 9.1's default kernel (2.4.21-something-or-other). The same thing > happens with kerne; 2.4.22, but the dump from the mandrake kernel had > more information. Not sure what to make of the backtrace at the moment... -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 11 08:39:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 08:40:06 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABGdr25008552 for ; Tue, 11 Nov 2003 08:39:53 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hABEjaOO016077 for ; Tue, 11 Nov 2003 06:45:36 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hABGdkP513491961; Tue, 11 Nov 2003 10:39:46 -0600 (CST) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hABGdjRn348881058; Tue, 11 Nov 2003 10:39:45 -0600 (CST) Subject: Re: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying From: Russell Cattelan To: juergen.sauer@automatix.de Cc: Juri Haberland , linux-xfs@oss.sgi.com In-Reply-To: <200311080949.35106.juergen.sauer@automatix.de> References: <200311071736.11742.juergen.sauer@automatix.de> <3FABFC92.5030607@koschikode.com> <200311080949.35106.juergen.sauer@automatix.de> Content-Type: text/plain Message-Id: <1068568785.29366.24.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-1mdk Date: Tue, 11 Nov 2003 10:39:46 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 975 Lines: 29 On Sat, 2003-11-08 at 02:49, Juergen Sauer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Freitag, 7. November 2003 21:12 schrieb Juri Haberland: > > Juergen Sauer wrote: > > > I think this is completely a NFS problem so you better might ask on the > > NFS ML. > > Or what reasons do you have to believe that it's a XFS problem? > > On the NFS List they belive it's a XFS-related problem. > I posted this to the NFS List also. > Because the problem was arising on a new kernel > on the server (2.4.22-xfs is now back on 2.4.20-xfs) > and a new kernel on client 2.4.22-xfs, which is hardware > tied to .22. Do the nfs people have any reason to claim this is an XFS bug? or is it just a case of "blame a bug". Since the problem is originating in nfs, that is were the debugging will have to start. If the nfs group can at least identify were the problem is originating from it would be helpful in determining were the problem really exists. -Russell From owner-linux-xfs@oss.sgi.com Tue Nov 11 10:38:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 10:39:29 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABIcs25013790 for ; Tue, 11 Nov 2003 10:38:55 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id C8503102598; Tue, 11 Nov 2003 19:38:52 +0100 (CET) Received: from nx-01.sapienti-sat.org (pD9E7F4BB.dip.t-dialin.net [217.231.244.187]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 7B158102590; Tue, 11 Nov 2003 19:38:52 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id 4FA691B057; Tue, 11 Nov 2003 19:38:47 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id 2BECC1B056; Tue, 11 Nov 2003 19:38:47 +0100 (CET) Message-ID: <3FB12CB6.9010606@koschikode.com> Date: Tue, 11 Nov 2003 19:38:46 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: Russell Cattelan Cc: juergen.sauer@automatix.de, linux-xfs@oss.sgi.com Subject: Re: XFS NFS Fileserver, kernel: nfs: server server not responding, still trying References: <200311071736.11742.juergen.sauer@automatix.de> <3FABFC92.5030607@koschikode.com> <200311080949.35106.juergen.sauer@automatix.de> <1068568785.29366.24.camel@naboo> In-Reply-To: <1068568785.29366.24.camel@naboo> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hABIcu25013792 X-archive-position: 995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 1058 Lines: 30 Russell Cattelan wrote: > On Sat, 2003-11-08 at 02:49, Juergen Sauer wrote: >> Am Freitag, 7. November 2003 21:12 schrieb Juri Haberland: >> > Juergen Sauer wrote: >> >> > I think this is completely a NFS problem so you better might ask on the >> > NFS ML. >> > Or what reasons do you have to believe that it's a XFS problem? >> >> On the NFS List they belive it's a XFS-related problem. >> I posted this to the NFS List also. >> Because the problem was arising on a new kernel >> on the server (2.4.22-xfs is now back on 2.4.20-xfs) >> and a new kernel on client 2.4.22-xfs, which is hardware >> tied to .22. > Do the nfs people have any reason to claim this is an XFS > bug? or is it just a case of "blame a bug". I had a look at the nfs list and actually no-one said it isn't a NFS problem. One said that there was an unusual high number of NFS retransmissons and he suggested to change some NFS parameters. The other suggested using NFS over TCP... In the mean time Jürgen seems to have found the real culprit: The NVIDIA network driver... Juri From owner-linux-xfs@oss.sgi.com Tue Nov 11 11:10:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 11:10:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hABJAZ25014776 for ; Tue, 11 Nov 2003 11:10:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hABJAZjN014775 for linux-xfs@oss.sgi.com; Tue, 11 Nov 2003 11:10:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hABJAX27014761 for ; Tue, 11 Nov 2003 11:10:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hABIJ490013693; Tue, 11 Nov 2003 10:19:04 -0800 Date: Tue, 11 Nov 2003 10:19:04 -0800 Message-Id: <200311111819.hABIJ490013693@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2579 Lines: 67 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-30-10 14:32 PDT ------- Created an attachment (id=89) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=89&action=view) decoded stack trace ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-31-10 08:14 PDT ------- Created an attachment (id=90) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=90&action=view) kdb backtraces and fs info ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-11-11 10:19 PDT ------- This is with latest CVS based on 2.4.23-rc1 - still the same error. (SGI-XFS CVS-2003-11-11_06:00_UTC with ACLs, no debug enabled) If some kdb traces are needed, please tell! Filesystem "ide0(3,6)": xfs_log_write: reservation ran out. Need to up reservati on xfs_force_shutdown(ide0(3,6),0x8) called from line 1715 of file xfs_log.c. Retu rn address = 0xe0919a0a Filesystem "ide0(3,6)": Corruption of in-memory data detected. Shutting down fi lesystem: ide0(3,6) d75dfd6c e090d522 00000015 dda1b400 00000005 00004b28 e0919a0a dda1b400 00000008 e0924c40 000006b3 e08f7757 dda1b400 00000008 e0924c40 000006b3 00000002 00000001 dda1b400 e0924e20 00000015 dda1b400 00000005 dd3d63c0 Call Trace: [] xfs_do_force_shutdown+0x92/0xf0 [xfs] [] vfs_force_shutdown+0x2a/0x30 [xfs] [] extflag.1208+0x286/0x3226 [xfs] [] xlog_write+0xcf/0x44c [xfs] [] extflag.1208+0x286/0x3226 [xfs] [] extflag.1208+0x466/0x3226 [xfs] [] xfs_log_write+0x3e/0x68 [xfs] [] xfs_trans_commit+0x1b9/0x2fc [xfs] [] kmem_zone_free+0xf/0x13 [xfs] [] xfs_bmap_del_free+0x30/0x38 [xfs] [] xfs_bmap_finish+0x167/0x180 [xfs] [] xfs_inactive+0x3f6/0x418 [xfs] [] linvfs_sops+0x0/0x60 [xfs] [] vn_rele+0x27/0x6c [xfs] [] linvfs_clear_inode+0x10/0x1c [xfs] [] clear_inode+0x8f/0xd4 [kernel] [] iput+0x116/0x1f8 [kernel] [] d_delete+0x4c/0x7c [kernel] [] vfs_unlink+0x16c/0x1a0 [kernel] [] sys_unlink+0x99/0x110 [kernel] [] system_call+0x33/0x38 [kernel] Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(ide0(3,6),0x2) called from line 723 of file xfs_log.c. Retur n address = 0xe0919a0a ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 11 13:12:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 13:12:40 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABLCI25021077 for ; Tue, 11 Nov 2003 13:12:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hABJI1OO009535 for ; Tue, 11 Nov 2003 11:18:01 -0800 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 IAA09294; Wed, 12 Nov 2003 08:12:06 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hABLC5Uc1340777; Wed, 12 Nov 2003 08:12:05 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hABLC3se1379279; Wed, 12 Nov 2003 08:12:03 +1100 (EST) Date: Wed, 12 Nov 2003 08:12:03 +1100 From: Nathan Scott To: lordvader@austarmetro.com.au, Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Core dump when mounting disk Message-ID: <20031112081203.B1125759@wobbly.melbourne.sgi.com> References: <3fb0d46ed017a2.75422683@austarmetro.com.au> <1068565961.6271.6.camel@stout.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: <1068565961.6271.6.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Tue, Nov 11, 2003 at 09:52:41AM -0600 X-archive-position: 997 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 723 Lines: 19 On Tue, Nov 11, 2003 at 09:52:41AM -0600, Eric Sandeen wrote: > On Tue, 2003-11-11 at 06:22, Michael Mamone wrote: > > My system recently locked up while I was compiling a program. My > > system has two partitions, and the files I was compiling lived on the > > second partition. When I reboot, the attempt to remount that partition > > fails with a kernel panic, and any subsequent attempts to mount or > > call xfs_repair on that disk just hang. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you have just rebooted and run xfs_repair on the block device, and it hangs, then this points to either a hardware problem or a device driver bug - the XFS kernel code is not involved at all in that case. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 11 13:22:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 13:22:31 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABLMA25021523 for ; Tue, 11 Nov 2003 13:22:10 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hABLJwMS003533; Tue, 11 Nov 2003 15:19:58 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hABLJvsv003531; Tue, 11 Nov 2003 15:19:57 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Core dump when mounting disk From: Austin Gonyou To: Nathan Scott Cc: lordvader@austarmetro.com.au, Eric Sandeen , XFS List In-Reply-To: <20031112081203.B1125759@wobbly.melbourne.sgi.com> References: <20031112081203.B1125759@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1068585597.3019.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 15:19:57 -0600 X-archive-position: 998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1822 Lines: 43 On Tue, 2003-11-11 at 15:12, Nathan Scott wrote: [...] > > > fails with a kernel panic, and any subsequent attempts to mount or > > > call xfs_repair on that disk just hang. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If you have just rebooted and run xfs_repair on the block device, > and it hangs, then this points to either a hardware problem or a > device driver bug - the XFS kernel code is not involved at all in > that case. This is incorrect, and correct, at the same time. I don't think he's rebooting before he does the xfs_repair. i.e. not mount that disk at all, then xfs_repair. What I think he should try is to mount that FS ro. Eric and I saw some stuff recently with a crash we had due to a power outage where the XFS log was messed up, i.e. xfs_logprint has "ERROR!!!" in it, but would cause the mount operation to segfault and the kernel will oops. So as for correct, yes, xfs_repair will hang becuse that device is now locked and the only way to un-do that is to reboot. As for the reason this happens, I don't think too many people are clear on that just yet, (look for "broken log" in the list history), and the only way you can test this condition is to not mount that FS at all, except using either -oro,norecovery, or using -oro. What I found is that if you mount -oro, and it works, something has been done to the log, even xfs_logprint doesn't show what, but then you can mount normally, so long as you see a log-replay in dmesg. If you do, then you should be good, and no xfs_repair is needed. if you can't mount -oro, then yes xfs_repair is needed, and you will need to do xfs_repair -L. Hope this helps. BTW, can someone help this guy dd out his log so he has a copy to send to this list? > cheers. > > -- > Nathan -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 11 13:24:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 13:25:09 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hABLOw25021916 for ; Tue, 11 Nov 2003 13:24:58 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hABLMjMS003645; Tue, 11 Nov 2003 15:22:45 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hABLMjU1003643; Tue, 11 Nov 2003 15:22:45 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Core dump when mounting disk From: Austin Gonyou To: Nathan Scott Cc: lordvader@austarmetro.com.au, Eric Sandeen , XFS List In-Reply-To: <1068585597.3019.32.camel@localhost.localdomain> References: <1068585597.3019.32.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1068585764.3019.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 11 Nov 2003 15:22:45 -0600 X-archive-position: 999 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 306 Lines: 11 On Tue, 2003-11-11 at 15:19, Austin Gonyou wrote: > BTW, can someone help this guy dd out his log so he has a copy to > send to this list? Belay this! Don't send a log to this list, but post it somewhere. Sorry for the bad advice there! :) -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 11 17:10:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 17:10:28 -0800 (PST) Received: from mx3.mail2000.com.tw (mx3.mail2000.com.tw [210.200.181.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAC19j25004598 for ; Tue, 11 Nov 2003 17:10:06 -0800 Received: from 210.200.181.211 by proxy.mail2000.com.tw with Mail2000 MTA Proxy 3.2(197:0:AUTH_RELAY) Wed, 12 Nov 2003 09:09:38 +0800 (CST); (envelope-from ) Received: By OpenMail Mailer;Wed, 12 Nov 2003 09:09:36 +0800 (CST) From: "nelsonjian" Reply-To: nelsonjian@mail2000.com.tw Subject: Restore the whole filesystem after doing mkfs.xfs Message-ID: <1068599376.84196.nelsonjian@mail2000.com.tw> To: "linux-xfs@oss.sgi.com " Date: Wed, 12 Nov 2003 09:09:36 +0800 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAC1A625004612 X-archive-position: 1000 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nelsonjian@mail2000.com.tw Precedence: bulk X-list: linux-xfs Content-Length: 155 Lines: 9 Hi, Is any possibility to restore the whole filesystem (which is xfs type) after doing mkfs.xfs? please help me. Thank you! Very truely yours Nelson From owner-linux-xfs@oss.sgi.com Tue Nov 11 23:00:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 23:00:36 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAC70P25008308 for ; Tue, 11 Nov 2003 23:00:25 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAC70Hq0030862 for ; Tue, 11 Nov 2003 23:00:18 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAC6vvBI020002 for ; Wed, 12 Nov 2003 17:57:58 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAC6vuLP020001 for linux-xfs@oss.sgi.com; Wed, 12 Nov 2003 17:57:56 +1100 Date: Wed, 12 Nov 2003 17:57:56 +1100 From: FSG QA Message-Id: <200311120657.hAC6vuLP020001@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 1002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 17 Add a test program to exercise a specific bug - racing unlink/write on a full filesystem. Fix coming soon. -- nathans. Date: Tue Nov 11 22:58:32 PST 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:161593a cmd/xfstests/src/enospc_unlink.c - 1.1 cmd/xfstests/src/Makefile - 1.19 From owner-linux-xfs@oss.sgi.com Tue Nov 11 22:58:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 22:59:09 -0800 (PST) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAC6wn25008193 for ; Tue, 11 Nov 2003 22:58:52 -0800 Received: (qmail 2609 invoked by uid 89); 12 Nov 2003 06:58:36 -0000 Received: from unknown (HELO tamiweb.com) (212.122.164.1) by 0 with SMTP; 12 Nov 2003 06:58:36 -0000 Message-ID: <3FB1D9C3.8040100@tamiweb.com> Date: Wed, 12 Nov 2003 08:57:07 +0200 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs-cmd and cvs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs Content-Length: 231 Lines: 7 Updating my cvs snapshot of linux-2.4-xfs I've noticed that there is directory linux/fs/xfs/cmd that contains xfs-tools and tests I believe that they are different cvs repository but still.... is this intentional ?? wwell larry From owner-linux-xfs@oss.sgi.com Tue Nov 11 23:55:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Nov 2003 23:56:13 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAC7td25023670 for ; Tue, 11 Nov 2003 23:55:40 -0800 Received: from erbenson.alaska.net (41-pm5.nwc.alaska.net [209.112.139.41]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id hAC7tbOF091295 for ; Tue, 11 Nov 2003 22:55:38 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 31D4F39E7 for ; Tue, 11 Nov 2003 22:55:35 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 2D44F40FF35; Tue, 11 Nov 2003 22:55:36 -0900 (AKST) Date: Tue, 11 Nov 2003 22:55:36 -0900 From: Ethan Benson To: "linux-xfs@oss.sgi.com " Subject: Re: Restore the whole filesystem after doing mkfs.xfs Message-ID: <20031112075536.GT3648@plato.local.lan> Mail-Followup-To: "linux-xfs@oss.sgi.com " References: <1068599376.84196.nelsonjian@mail2000.com.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ICzQLVUlUjFtnNCj" Content-Disposition: inline In-Reply-To: <1068599376.84196.nelsonjian@mail2000.com.tw> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 1003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 34 --ICzQLVUlUjFtnNCj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 12, 2003 at 09:09:36AM +0800, nelsonjian wrote: > Hi, >=20 > Is any possibility to restore the whole filesystem (which is xfs type) = after doing mkfs.xfs? > please help me. Thank you! xfsrestore. this however requires that you have previously dumped the filesystem with xfsdump. backups backups backups. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ICzQLVUlUjFtnNCj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj+x53gACgkQJKx7GixEevxajACggrZjR5xh/4CGKgYep963bVjk aXkAnjVs+L7g6cbMEHFLbtL6J7oIpq+S =99Cx -----END PGP SIGNATURE----- --ICzQLVUlUjFtnNCj-- From owner-linux-xfs@oss.sgi.com Wed Nov 12 02:57:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 02:57:50 -0800 (PST) Received: from rabin-c0.lbcons.net (rabin.hdsnet.hu [193.110.58.221]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACAvb25008343 for ; Wed, 12 Nov 2003 02:57:38 -0800 Received: from rabin-c0.lbcons.net (localhost [127.0.0.1]) by rabin-c0.lbcons.net (8.12.8/8.12.8) with ESMTP id hACAvU4J001997; Wed, 12 Nov 2003 11:57:31 +0100 Received: (from apache@localhost) by rabin-c0.lbcons.net (8.12.8/8.12.8/Submit) id hACAvUfn001995; Wed, 12 Nov 2003 11:57:30 +0100 X-Authentication-Warning: rabin-c0.lbcons.net: apache set sender to mmuller@lbcons.net using -f Received: from 193.110.58.52 (SquirrelMail authenticated user mmuller) by rabin.hdsnet.hu with HTTP; Wed, 12 Nov 2003 11:57:30 +0100 (CET) Message-ID: <64114.193.110.58.52.1068634650.squirrel@rabin.hdsnet.hu> Date: Wed, 12 Nov 2003 11:57:30 +0100 (CET) Subject: Re: FC1 + XFS 1.3.1: test SRPM available From: "=?iso-8859-2?Q?M=FCller_Mikl=F3s?=" To: In-Reply-To: <1068164684.1405.42.camel@stout.americas.sgi.com> References: <1068164684.1405.42.camel@stout.americas.sgi.com> X-Priority: 3 Importance: Normal Cc: X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-archive-position: 1004 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mmuller@lbcons.net Precedence: bulk X-list: linux-xfs Content-Length: 1003 Lines: 32 Hi, I've build the binaries successfully with rpm -bb. It created the kernel-source, kernel-doc, kernel-BOOT, and kernel-debuginfo rpms in /usr/src/redhat/RPMS/i386. Now how do i go on with compiling kernel-i[56]86, and kernel-smp? Thanks: Miklos > So I was feeling charitable today... > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > seems to more or less pass our QA suite. It's a hurry-up job though, so > give it some cautious testing if you'd like. > > To the RH folks, if you're listening, I think I've done patches in such > a way that you can strip out acls & dmapi, and have a functional xfs > with extremely minimal impact to the rest of the kernel. > (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be > able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch > would be nice). > > -Eric > > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Nov 12 04:24:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 04:24:49 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACCO425013774 for ; Wed, 12 Nov 2003 04:24:05 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hACCNvHS002270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Nov 2003 13:23:59 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hACCNvxH014573; Wed, 12 Nov 2003 13:23:57 +0100 Date: Wed, 12 Nov 2003 13:23:57 +0100 From: Axel Thimm To: =?iso-8859-1?Q?M=FCller_Mikl=F3s?= Cc: sandeen@sgi.com, linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available Message-ID: <20031112122357.GN19336@puariko.nirvana> References: <1068164684.1405.42.camel@stout.americas.sgi.com> <64114.193.110.58.52.1068634650.squirrel@rabin.hdsnet.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wxIXENaY2CYUgF8u" Content-Disposition: inline In-Reply-To: <64114.193.110.58.52.1068634650.squirrel@rabin.hdsnet.hu> User-Agent: Mutt/1.4.1i X-archive-position: 1005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1674 Lines: 59 --wxIXENaY2CYUgF8u Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 12, 2003 at 11:57:30AM +0100, M=FCller Mikl=F3s wrote: > Hi, >=20 > I've build the binaries successfully with rpm -bb. > It created the kernel-source, kernel-doc, kernel-BOOT, > and kernel-debuginfo rpms in /usr/src/redhat/RPMS/i386. >=20 > Now how do i go on with compiling kernel-i[56]86, and kernel-smp? add '--target ' to the rpmbuild command replacing with i686, athlon, i586 etc. smp/bigmem stuff is automatically build for the archs supporting it (unless you turn it off). > Thanks: > Miklos >=20 > > So I was feeling charitable today... > > > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > > seems to more or less pass our QA suite. It's a hurry-up job though, so > > give it some cautious testing if you'd like. > > > > To the RH folks, if you're listening, I think I've done patches in such > > a way that you can strip out acls & dmapi, and have a functional xfs > > with extremely minimal impact to the rest of the kernel. > > (linux-2.4.22-xfs-exports.patch is the only thing we -really- need to be > > able to ship an out-of-kernel module, linux-2.4.22-xfs-inode-init.patch > > would be nice). > > > > -Eric > > >=20 >=20 >=20 --=20 Axel.Thimm@physik.fu-berlin.de --wxIXENaY2CYUgF8u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/siZdQBVS1GOamfERApweAJ9MwWmB24jrwNtGfCCr/XxPELkHJQCfeOJW ZUUyGzOV7DjkkefgQXfsLms= =YrAx -----END PGP SIGNATURE----- --wxIXENaY2CYUgF8u-- From owner-linux-xfs@oss.sgi.com Wed Nov 12 06:23:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 06:23:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACEN725016177 for ; Wed, 12 Nov 2003 06:23:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hACEgsHc010737 for ; Wed, 12 Nov 2003 08:42:54 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hACEN0P513519205; Wed, 12 Nov 2003 08:23:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hACEMvK26131137; Wed, 12 Nov 2003 08:22:58 -0600 (CST) Date: Wed, 12 Nov 2003 08:22:59 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kostadin Karaivanov cc: linux-xfs@oss.sgi.com Subject: Re: xfs-cmd and cvs In-Reply-To: <3FB1D9C3.8040100@tamiweb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 438 Lines: 17 It's not intentional, i'll ask Russell to look into it. Must be something lost in the translation to the external cvs repository... -Eric On Wed, 12 Nov 2003, Kostadin Karaivanov wrote: > Updating my cvs snapshot of linux-2.4-xfs I've noticed that > there is directory linux/fs/xfs/cmd that contains xfs-tools and tests > I believe that they are different cvs repository but still.... is this > intentional ?? > > wwell larry > > From owner-linux-xfs@oss.sgi.com Wed Nov 12 08:21:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 08:21:31 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACGL925023732 for ; Wed, 12 Nov 2003 08:21:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hACGL4q0030451 for ; Wed, 12 Nov 2003 08:21:04 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hACGL4P513540178; Wed, 12 Nov 2003 10:21:04 -0600 (CST) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hACGL2Rn338035908; Wed, 12 Nov 2003 10:21:02 -0600 (CST) Subject: Re: xfs-cmd and cvs From: Russell Cattelan To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FB1D9C3.8040100@tamiweb.com> References: <3FB1D9C3.8040100@tamiweb.com> Content-Type: text/plain Message-Id: <1068654063.29382.41.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-1mdk Date: Wed, 12 Nov 2003 10:21:03 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1007 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 921 Lines: 23 On Wed, 2003-11-12 at 00:57, Kostadin Karaivanov wrote: > Updating my cvs snapshot of linux-2.4-xfs I've noticed that > there is directory linux/fs/xfs/cmd that contains xfs-tools and tests > I believe that they are different cvs repository but still.... is this > intentional ?? If you look you will find there is no actual file in those dirs. This is a side affect of the way cvs does deletes, all file are placed in the attic when deleted. But because cvs has no concept of path other that the directory structure of the repository its self directory can not be deleted with out also removing the "Attic" files. The Attic processing was something that was added to the ptools -> cvs script some time back to allow to checkout going backwards in time as well as looking up odd rev with cvsweb. Yes the extra dirs is just an annoying side affect but we want to keep more history around. -Russell > wwell larry > From owner-linux-xfs@oss.sgi.com Wed Nov 12 08:34:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 08:34:20 -0800 (PST) Received: from gate.firmix.at (gate.firmix.at [80.109.18.208]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACGY725030244 for ; Wed, 12 Nov 2003 08:34:08 -0800 Received: from buffy.firmix.at ([10.0.0.10]) by gate.firmix.at (8.12.8/8.12.8) with ESMTP id hACGY0ZH011174 for ; Wed, 12 Nov 2003 17:34:00 +0100 Received: from tara.firmix.at (tara.firmix.at [10.0.0.50]) by buffy.firmix.at (8.12.8/8.12.8) with ESMTP id hACGY0Zn008270 for ; Wed, 12 Nov 2003 17:34:00 +0100 Received: from tara.firmix.at (localhost [127.0.0.1]) by tara.firmix.at (8.12.8/8.12.8) with ESMTP id hACGY0op015199 for ; Wed, 12 Nov 2003 17:34:00 +0100 Received: (from bernd@localhost) by tara.firmix.at (8.12.8/8.12.8/Submit) id hACGY0FE015197 for linux-xfs@oss.sgi.com; Wed, 12 Nov 2003 17:34:00 +0100 Subject: Re: xfs-cmd and cvs From: Bernd Petrovitsch To: linux-xfs@oss.sgi.com In-Reply-To: <1068654063.29382.41.camel@naboo> References: <3FB1D9C3.8040100@tamiweb.com> <1068654063.29382.41.camel@naboo> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068654838.14062.9.camel@tara.firmix.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 12 Nov 2003 17:34:00 +0100 X-archive-position: 1008 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bernd@firmix.at Precedence: bulk X-list: linux-xfs Content-Length: 670 Lines: 16 On Mit, 2003-11-12 at 17:21, Russell Cattelan wrote: > On Wed, 2003-11-12 at 00:57, Kostadin Karaivanov wrote: > > Updating my cvs snapshot of linux-2.4-xfs I've noticed that > > there is directory linux/fs/xfs/cmd that contains xfs-tools and tests > > I believe that they are different cvs repository but still.... is this > > intentional ?? > If you look you will find there is no actual file in those dirs. Put "cvs -d" in your .cvsrc to get rid of empty directories on checkout. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From owner-linux-xfs@oss.sgi.com Wed Nov 12 10:26:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 10:26:32 -0800 (PST) Received: from iceberg.braxis.org (tdc-213.elsat.net.pl [213.216.97.213]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACIQ125007999 for ; Wed, 12 Nov 2003 10:26:04 -0800 Received: (from kszysiu@localhost) by iceberg.braxis.org (8.11.6/8.11.6) id hACIPtf15856; Wed, 12 Nov 2003 19:25:55 +0100 Date: Wed, 12 Nov 2003 19:25:54 +0100 From: Krzysztof Rusocki To: Bernd Petrovitsch Cc: linux-xfs@oss.sgi.com Subject: Re: xfs-cmd and cvs Message-ID: <20031112192554.A15852@iceberg.elsat.net.pl> References: <3FB1D9C3.8040100@tamiweb.com> <1068654063.29382.41.camel@naboo> <1068654838.14062.9.camel@tara.firmix.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1068654838.14062.9.camel@tara.firmix.at>; from bernd@firmix.at on Wed, Nov 12, 2003 at 05:34:00PM +0100 X-archive-position: 1009 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kszysiu@iceberg.elsat.net.pl Precedence: bulk X-list: linux-xfs Content-Length: 299 Lines: 13 On Wed, Nov 12, 2003 at 05:34:00PM +0100, Bernd Petrovitsch wrote: > On Mit, 2003-11-12 at 17:21, Russell Cattelan wrote: > > Put "cvs -d" in your .cvsrc to get rid of empty directories on checkout. > Accidentally, wasn't that -P switch? (prune empty dirs) Just my 2 cents. Cheers, Krzysztof. From owner-linux-xfs@oss.sgi.com Wed Nov 12 10:31:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 10:32:09 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACIVl25008423 for ; Wed, 12 Nov 2003 10:31:49 -0800 Received: from titanic (titanic.skynet.coplanar.net [192.168.7.98]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hACIVarM001797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Nov 2003 13:31:39 -0500 Message-ID: <011d01c3a94b$5920d0b0$6207a8c0@titanic> From: "Jeremy Jackson" To: "Bernd Petrovitsch" , References: <3FB1D9C3.8040100@tamiweb.com> <1068654063.29382.41.camel@naboo> <1068654838.14062.9.camel@tara.firmix.at> Subject: Re: xfs-cmd and cvs Date: Wed, 12 Nov 2003 13:32:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1010 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 1196 Lines: 37 actually cvs -d might set the repository path. definitely will not prune as you want. you want: update -d -P which will create new dirs that appear in the repository (-d) and then prune empty ones (-P) on each update and checkout -P which will get all directories of course, and then prune the empty ones (-P) Jeremy ----- Original Message ----- From: "Bernd Petrovitsch" To: Sent: Wednesday, November 12, 2003 11:34 AM Subject: Re: xfs-cmd and cvs > On Mit, 2003-11-12 at 17:21, Russell Cattelan wrote: > > On Wed, 2003-11-12 at 00:57, Kostadin Karaivanov wrote: > > > Updating my cvs snapshot of linux-2.4-xfs I've noticed that > > > there is directory linux/fs/xfs/cmd that contains xfs-tools and tests > > > I believe that they are different cvs repository but still.... is this > > > intentional ?? > > If you look you will find there is no actual file in those dirs. > > Put "cvs -d" in your .cvsrc to get rid of empty directories on checkout. > > Bernd > -- > Firmix Software GmbH http://www.firmix.at/ > mobil: +43 664 4416156 fax: +43 1 7890849-55 > Embedded Linux Development and Services > > From owner-linux-xfs@oss.sgi.com Wed Nov 12 13:45:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 13:45:55 -0800 (PST) Received: from smtp.seznam.cz (smtp.seznam.cz [212.80.76.43]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hACLjX25013965 for ; Wed, 12 Nov 2003 13:45:34 -0800 Received: (qmail 7952 invoked from network); 12 Nov 2003 21:45:27 -0000 Received: from unknown (HELO seznam.cz) (Daniel.Bar@62.177.107.63) by smtp.seznam.cz with SMTP; 12 Nov 2003 21:45:27 -0000 Message-ID: <3FB2A9F7.8030801@seznam.cz> Date: Wed, 12 Nov 2003 22:45:27 +0100 From: Dan Bar Reply-To: Daniel.Bar@seznam.cz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Patches for 2.4.22 kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1011 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Daniel.Bar@seznam.cz Precedence: bulk X-list: linux-xfs Content-Length: 339 Lines: 15 Hello there, Didn't found answer in archives, so I'm asking here. I understand there are stable, well tested releases and CVS snapshots (tp://oss.sgi.com/projects/xfs/download/patches). If I need to use e.g. kernel 2.4.22, is possible to say how safe/dangerous is to use mentioned ftp'ed shapshots for production server? TIA Dan From owner-linux-xfs@oss.sgi.com Wed Nov 12 22:07:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 22:07:57 -0800 (PST) Received: from mail.accusys.com.cn ([210.78.135.114]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAD67U25010696 for ; Wed, 12 Nov 2003 22:07:35 -0800 Received: from dj [218.94.87.252] by mail.accusys.com.cn with ESMTP (SMTPD32-7.12 ) id AAF21301FE; Thu, 13 Nov 2003 13:47:30 +0800 Date: Thu, 13 Nov 2003 13:44:59 +0800 From: "Liven Ding " To: "niuniu" , "linux-xfs" Subject: about xfs_alloc_lookup() X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <200311131347640.SM01384@dj> X-archive-position: 1012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djun@accusys.com.cn Precedence: bulk X-list: linux-xfs Content-Length: 293 Lines: 15 Hello! 1.Why xfs_alloc_lookup() always return 0 (can't find any such record) or error? 2.What's a record? 3.What's a btree block? 4.What's a allocation group? 5.What's the relationship about them? Thanks a lot! Best Wishes, Liven Ding Accusys Nanjing RD Center Tel : 025-4809629 #207 From owner-linux-xfs@oss.sgi.com Wed Nov 12 22:24:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 22:25:11 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAD6OZ25011189 for ; Wed, 12 Nov 2003 22:24:36 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAD6iMHc027712 for ; Thu, 13 Nov 2003 00:44:25 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAD6M6Rj013390 for ; Thu, 13 Nov 2003 17:22:06 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAD6M5aV013389 for linux-xfs@oss.sgi.com; Thu, 13 Nov 2003 17:22:05 +1100 Date: Thu, 13 Nov 2003 17:22:05 +1100 From: Nathan Scott Message-Id: <200311130622.hAD6M5aV013389@bruce.melbourne.sgi.com> Subject: PARTIAL TAKE 904566 - minor tidying X-archive-position: 1013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 446 Lines: 16 Remove some spurious 2.4/2.6 differences in support code. Date: Wed Nov 12 22:21:40 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161707a linux/fs/xfs/support/sema.h - 1.11 linux/fs/xfs/support/qsort.c - 1.9 linux/fs/xfs/support/mrlock.h - 1.12 linux/fs/xfs/support/ktrace.c - 1.18 linux/fs/xfs/support/spin.h - 1.15 From owner-linux-xfs@oss.sgi.com Wed Nov 12 22:28:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Nov 2003 22:28:49 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAD6Sc25011588 for ; Wed, 12 Nov 2003 22:28:38 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAD6SWq0001434 for ; Wed, 12 Nov 2003 22:28:33 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAD6Q8Rj013456 for ; Thu, 13 Nov 2003 17:26:08 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAD6Q8jG013455 for linux-xfs@oss.sgi.com; Thu, 13 Nov 2003 17:26:08 +1100 Date: Thu, 13 Nov 2003 17:26:08 +1100 From: Nathan Scott Message-Id: <200311130626.hAD6Q8jG013455@bruce.melbourne.sgi.com> Subject: TAKE - fix sign on error X-archive-position: 1014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 328 Lines: 13 Fix sign on a pagebuf error variable, backport from 2.6 tree. Good spottin' Eric. Date: Wed Nov 12 22:26:20 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161708a linux/fs/xfs/linux/xfs_aops.c - 1.52 From owner-linux-xfs@oss.sgi.com Thu Nov 13 02:11:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 02:12:15 -0800 (PST) Received: from gate.firmix.at (gate.firmix.at [80.109.18.208]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADABo25021762 for ; Thu, 13 Nov 2003 02:11:52 -0800 Received: from buffy.firmix.at ([10.0.0.10]) by gate.firmix.at (8.12.8/8.12.8) with ESMTP id hADABiZH016793 for ; Thu, 13 Nov 2003 11:11:44 +0100 Received: from tara.firmix.at (tara.firmix.at [10.0.0.50]) by buffy.firmix.at (8.12.8/8.12.8) with ESMTP id hADABiZn011503 for ; Thu, 13 Nov 2003 11:11:44 +0100 Received: from tara.firmix.at (localhost [127.0.0.1]) by tara.firmix.at (8.12.8/8.12.8) with ESMTP id hADABiop018827 for ; Thu, 13 Nov 2003 11:11:44 +0100 Received: (from bernd@localhost) by tara.firmix.at (8.12.8/8.12.8/Submit) id hADABiEw018825 for linux-xfs@oss.sgi.com; Thu, 13 Nov 2003 11:11:44 +0100 Subject: Re: xfs-cmd and cvs From: Bernd Petrovitsch To: linux-xfs@oss.sgi.com In-Reply-To: <20031112192554.A15852@iceberg.elsat.net.pl> References: <3FB1D9C3.8040100@tamiweb.com> <1068654063.29382.41.camel@naboo> <1068654838.14062.9.camel@tara.firmix.at> <20031112192554.A15852@iceberg.elsat.net.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068718303.18692.38.camel@tara.firmix.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 11:11:44 +0100 X-archive-position: 1015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bernd@firmix.at Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 19 On Mit, 2003-11-12 at 19:25, Krzysztof Rusocki wrote: > On Wed, Nov 12, 2003 at 05:34:00PM +0100, Bernd Petrovitsch wrote: > > On Mit, 2003-11-12 at 17:21, Russell Cattelan wrote: > > > > Put "cvs -d" in your .cvsrc to get rid of empty directories on checkout. > > Accidentally, wasn't that -P switch? (prune empty dirs) > > Just my 2 cents. ACK. Silly me - I have -d and -P in the .cvsrc. Thanks for correcting, Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From owner-linux-xfs@oss.sgi.com Thu Nov 13 09:06:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 09:06:53 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADH6O25008135 for ; Thu, 13 Nov 2003 09:06:24 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hADHQFHc007611 for ; Thu, 13 Nov 2003 11:26:15 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hADH6GP513566436; Thu, 13 Nov 2003 11:06:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hADH6DK16369542; Thu, 13 Nov 2003 11:06:15 -0600 (CST) Subject: Re: about xfs_alloc_lookup() From: Eric Sandeen To: Liven Ding Cc: niuniu , linux-xfs In-Reply-To: <200311131347640.SM01384@dj> References: <200311131347640.SM01384@dj> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1068743174.19225.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Nov 2003 11:06:15 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1016 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 638 Lines: 25 I'd start by looking at the original design docs to get a feel for what's going on in XFS: http://oss.sgi.com/projects/xfs/publications.html -Eric On Wed, 2003-11-12 at 23:44, Liven Ding wrote: > Hello! > 1.Why xfs_alloc_lookup() always return 0 (can't find any such record) or error? > 2.What's a record? > 3.What's a btree block? > 4.What's a allocation group? > 5.What's the relationship about them? > Thanks a lot! > > Best Wishes, > Liven Ding > Accusys Nanjing RD Center > Tel : 025-4809629 #207 > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 13 09:27:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 09:27:11 -0800 (PST) Received: from scortch.unisrv.net (scortch.unisrv.net [24.123.88.66]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADHQx25008781 for ; Thu, 13 Nov 2003 09:26:59 -0800 Received: from amber.unisrv.net (amber [24.123.88.69]) by scortch.unisrv.net (8.12.10/8.12.10) with ESMTP id hADHQwC7012068 for ; Thu, 13 Nov 2003 11:26:59 -0600 Received: from amber.unisrv.net (localhost [127.0.0.1]) by amber.unisrv.net (8.12.10/8.12.10) with ESMTP id hADHQwhf002386 for ; Thu, 13 Nov 2003 11:26:58 -0600 Received: (from pez@localhost) by amber.unisrv.net (8.12.10/8.12.8/Submit) id hADHQwQn002385 for linux-xfs@oss.sgi.com; Thu, 13 Nov 2003 11:26:58 -0600 Date: Thu, 13 Nov 2003 11:26:58 -0600 From: CJ Kucera To: linux-xfs@oss.sgi.com Subject: XFS and Quota problem Message-ID: <20031113172658.GA2322@unisrv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@apocalyptech.com Precedence: bulk X-list: linux-xfs Content-Length: 1092 Lines: 28 Hello, list! I'm having some issues on an XFS-formatted partition with quota support turned on. The partition is /var/spool, and a user who has only one zero-length file (a new account added, still using mbox on the system) in /var/spool is showing up as being over-quota: > /dev/sda5 15380 10500 15500 2 0 0 I've done a "find /var/spool -user user" and also with -uid instead, and the one file present is the user's empty mailbox. The filesystem *does* have group quotas enabled, and I checked both for "mail" (which is the group the mailbox is in) and "user" (the group the user belongs to by default), and those groups have no quotas set). The box is running kernel 2.4.20, with quota 3.06, and snapshot-xfs-2.4.20-2003-04-07_05:19_UTC. If anyone has any ideas as to what's going on here, I'd be keen to hear of 'em. Thanks! -CJ -- WOW: Kakistocracy | "The ships hung in the sky in much the same apocalyptech.com/wow | way that bricks don't." - Douglas Adams, xfs@apocalyptech.com | _The Hitchhiker's Guide To The Galaxy_ From owner-linux-xfs@oss.sgi.com Thu Nov 13 14:24:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 14:24:40 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADMOS25020205 for ; Thu, 13 Nov 2003 14:24:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hADKUHOO001987 for ; Thu, 13 Nov 2003 12:30:17 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hADMOJEU1817876 for ; Fri, 14 Nov 2003 09:24:19 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hADMOJHW1819340 for linux-xfs@oss.sgi.com; Fri, 14 Nov 2003 09:24:19 +1100 (EST) Date: Fri, 14 Nov 2003 09:24:19 +1100 (EST) From: Nathan Scott Message-Id: <200311132224.hADMOJHW1819340@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix an enospc race X-archive-position: 1018 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 501 Lines: 18 Fix an infinite writepage loop under a combination of low free space, and racing write/unlink calls to the same file. Date: Thu Nov 13 14:22:14 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/us-kern-2.4.x-xfs Author: nathans Merged by: nathans Merged mods: xfs-linux:slinx:161773a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-kern Modid: 2.4.x-xfs-kern:slinx:161773a linux/xfs_aops.c - 1.21 - Merge of xfs-linux:slinx:161773a by nathans. From owner-linux-xfs@oss.sgi.com Thu Nov 13 14:36:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 14:36:12 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADMa125020655 for ; Thu, 13 Nov 2003 14:36:01 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hADMtrHc015209 for ; Thu, 13 Nov 2003 16:55:53 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hADMZtP513583773 for ; Thu, 13 Nov 2003 16:35:55 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hADMZqRn351486254; Thu, 13 Nov 2003 16:35:52 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hADMUtdK032598; Thu, 13 Nov 2003 16:30:55 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hADMUtc5032596; Thu, 13 Nov 2003 16:30:55 -0600 Date: Thu, 13 Nov 2003 16:30:55 -0600 From: Eric Sandeen Message-Id: <200311132230.hADMUtc5032596@penguin.americas.sgi.com> Subject: PARTIAL TAKE 904615 - Use inode size semantics from 2.6 X-archive-position: 1019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 614 Lines: 25 Use i_size_read/i_size_write semantics from 2.6 kernel to reduce 2.4/2.6 differences in xfs Date: Thu Nov 13 14:35:10 PST 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-reconcile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:161776a linux/xfs_lrw.c - 1.204 - use i_size_read/i_size_write as in 2.6 linux/xfs_linux.h - 1.115 - Define i_size_read/i_size_write - 2.6 semantics linux/xfs_file.c - 1.99 linux/xfs_vnode.c - 1.122 linux/xfs_super.c - 1.275 linux/xfs_aops.c - 1.54 - use i_size_read/i_size_write as in 2.6 From owner-linux-xfs@oss.sgi.com Thu Nov 13 14:41:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 14:41:24 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hADMfD25021074 for ; Thu, 13 Nov 2003 14:41:13 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hADMf7q0024461 for ; Thu, 13 Nov 2003 14:41:08 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hADMf7P513651884 for ; Thu, 13 Nov 2003 16:41:07 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hADMf4Rn304941247; Thu, 13 Nov 2003 16:41:04 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hADMa7dK032693; Thu, 13 Nov 2003 16:36:07 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hADMa7gN032691; Thu, 13 Nov 2003 16:36:07 -0600 Date: Thu, 13 Nov 2003 16:36:07 -0600 From: Eric Sandeen Message-Id: <200311132236.hADMa7gN032691@penguin.americas.sgi.com> Subject: PARTIAL TAKE 904615 - Use buffer head flag set/clear routines X-archive-position: 1020 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 632 Lines: 24 Use buffer head flag set/clear routines as in 2.6 kernel to reduce 2.4/2.6 differences in xfs Date: Thu Nov 13 14:40:38 PST 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-reconcile The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:161777a pagebuf/page_buf.c - 1.139 - Define buffer head flag set/clear routines as in 2.6 pagebuf/page_buf.h - 1.72 - use set_buffer_FOO and clear_buffer_FOO macros linux/xfs_linux.h - 1.116 - emit BH_Unwritten flag handling macros linux/xfs_aops.c - 1.55 - use set_buffer_FOO and clear_buffer_FOO macros From owner-linux-xfs@oss.sgi.com Thu Nov 13 18:15:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Nov 2003 18:15:44 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAE2F225029053 for ; Thu, 13 Nov 2003 18:15:22 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hADJ6Vq0023634 for ; Thu, 13 Nov 2003 11:06:31 -0800 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 GAA14324; Fri, 14 Nov 2003 06:06:27 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hADJ6QUc1435689; Fri, 14 Nov 2003 06:06:26 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hADJ6Prk1432879; Fri, 14 Nov 2003 06:06:25 +1100 (EST) Date: Fri, 14 Nov 2003 06:06:25 +1100 From: Nathan Scott To: CJ Kucera Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and Quota problem Message-ID: <20031114060625.B1435026@wobbly.melbourne.sgi.com> References: <20031113172658.GA2322@unisrv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20031113172658.GA2322@unisrv.net>; from xfs@apocalyptech.com on Thu, Nov 13, 2003 at 11:26:58AM -0600 X-archive-position: 1021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 924 Lines: 26 On Thu, Nov 13, 2003 at 11:26:58AM -0600, CJ Kucera wrote: > Hello, list! > > I'm having some issues on an XFS-formatted partition with quota support > turned on. The partition is /var/spool, and a user who has only one > zero-length file (a new account added, still using mbox on the system) > in /var/spool is showing up as being over-quota: > > > /dev/sda5 15380 10500 15500 2 0 0 > > I've done a "find /var/spool -user user" and also with -uid instead, > and the one file present is the user's empty mailbox. The filesystem The output above suggests that there are 2 files (third column from the end). This could be an open but unlinked file. Other things that your find wouldn't have found include preallocated space and any additional space for extended attributes. Does unmount+mount change the output above? If not, does unmount+repair+mount change it? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 14 00:50:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Nov 2003 00:50:33 -0800 (PST) Received: from ise.co.za (spinnekop.ise.co.za [196.44.35.57]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAE8nq25011547 for ; Fri, 14 Nov 2003 00:49:59 -0800 Received: (qmail 7389 invoked by uid 204); 14 Nov 2003 08:49:40 -0000 Received: from gert@ise.co.za by spinnekop by uid 201 with qmail-scanner-1.16 (clamscan: 0.54. spamassassin: 2.44. Clear:. Processed in 0.291017 secs); 14 Nov 2003 08:49:40 -0000 Received: from unknown (HELO buddy) (192.168.1.22) by 192.168.1.1 with SMTP; 14 Nov 2003 08:49:39 -0000 From: "Gert Steyn" To: Subject: xfsrestore - bad media file header checksum Date: Fri, 14 Nov 2003 10:49:39 +0200 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 V5.00.2919.6700 Importance: Normal X-archive-position: 1022 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gert@ise.co.za Precedence: bulk X-list: linux-xfs Content-Length: 4934 Lines: 123 Hi All We had a server with XFS file systems. I put webmin on it to enable windoze administrators to create accounts etc. We used the webmin fsdump functionality. (We successfully used the restore multiple times) Well we had hard drive failure, so everything is gone. I am now trying to restore the backups on another system using xfsrestore. There now seems to be header checksum problems which I can not get past. Below is full details of everything. (Look specifically at the "validating media file header" section) Any help will be appreciated! Gert Steyn --- ISE Technologies (www.ise.co.za) office xfsdump # xfsrestore -f /dev/st0 -t -b 512 -v5 xfsrestore: RLIMIT_AS org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_STACK org cur 0x800000 max 0xffffffffffffffff xfsrestore: raising stack size soft limit from 0x800000 to 0x2000000 xfsrestore: RLIMIT_STACK new cur 0x2000000 max 0xffffffffffffffff xfsrestore: RLIMIT_DATA org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_FSIZE org cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_FSIZE now cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_CPU cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: RLIMIT_CPU now cur 0xffffffffffffffff max 0xffffffffffffffff xfsrestore: INTGENMAX == 2147483647 (0x7fffffff) xfsrestore: UINTGENMAX == 4294967295 (0xffffffff) xfsrestore: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: OFFMAX == -1 (0x7fffffff) xfsrestore: SIZEMAX == 4294967295 (0xffffffff) xfsrestore: INOMAX == 4294967295 (0xffffffff) xfsrestore: TIMEMAX == 2147483647 (0x7fffffff) xfsrestore: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: UINT32MAX == 4294967295 (0xffffffff) xfsrestore: INT32MAX == 2147483647 (0x7fffffff) xfsrestore: INT16MAX == 32767 (0x7fff) xfsrestore: UINT16MAX == 65535 (0xffff) xfsrestore: getpagesize( ) returns 4096 xfsrestore: parent pid is 5815 xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: tty fd: 0; terminal interrupt character: (03) xfsrestore: version 2.2.4 (dump format 3.0) - Running single-threaded xfsrestore: sizeof( pers_desc_t ) == 328, pgsz == 4096, perssz == 20480 ::::::::::: persistent inventory media file tree at initialization ::::::::::: session inventory unknown ...................... end persistent inventory display ...................... xfsrestore: drive op: init xfsrestore: drive op: sync xfsrestore: Media_create xfsrestore: checking and validating command line dump id/label xfsrestore: searching media for dump xfsrestore: Media_mfile_next: purp==0 pos==0 xfsrestore: drive op: begin read xfsrestore: preparing drive xfsrestore: tape op: opening drive xfsrestore: tape op: get status xfsrestore: tape status = bot wprot onl xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=512 xfsrestore: fixed block size tape drive at /dev/st0 xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=512 xfsrestore: recommended tape media file size set to 0x10000000 bytes xfsrestore: recommended tape media mark separation set to 0x1000000 bytes xfsrestore: determining tape record size: trying 512 (0x200) bytes xfsrestore: setting fixed block size to 512 xfsrestore: tape op: closing drive xfsrestore: tape op: opening drive xfsrestore: tape op: set block size 512 xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=512 xfsrestore: tape op: get status xfsrestore: tape status = bot wprot onl xfsrestore: tape positioned at BOT: doing redundant rewind xfsrestore: tape op: rewind 0 xfsrestore: tape op: get status xfsrestore: tape status = bot wprot onl xfsrestore: tape op: reading 512 bytes xfsrestore: tape op read of 512 bytes successful xfsrestore: tape op: get status xfsrestore: tape status = wprot onl xfsrestore: nread == selected blocksize on fixed blocksize drive indicates correct blocksize found xfsrestore: validating media file header xfsrestore: validate_media_file_hdr gh_magic xFSdump0 gh_version 33554432 gh_checksum 2981147653 gh_timestamp 1657055807 gh_ipaddr 144889965816315904 gh_hostname office gh_dumplabel xfsrestore: bad media file header checksum xfsrestore: bad media file header at BOT indicates foreign or corrupted tape xfsrestore: tape op: rewind 0 xfsrestore: tape op: get status xfsrestore: tape status = bot wprot onl xfsrestore: setting fixed block size to 512 xfsrestore: tape op: closing drive xfsrestore: tape op: opening drive xfsrestore: tape op: set block size 512 xfsrestore: tape op: get block size info xfsrestore: max=1048576 cur=512 xfsrestore: drive op: get device class xfsrestore: media object not useful xfsrestore: drive op: eject media xfsrestore: tape op: closing drive From owner-linux-xfs@oss.sgi.com Fri Nov 14 08:20:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 Nov 2003 08:21:23 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAEGKr25005739 for ; Fri, 14 Nov 2003 08:20:54 -0800 Received: from titanic (titanic.skynet.coplanar.net [192.168.7.98]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAEGKpAf009230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Nov 2003 11:20:52 -0500 Message-ID: <005f01c3aacb$653522d0$6207a8c0@titanic> From: "Jeremy Jackson" To: Subject: xfsdump fails to overwrite stream terminator - dumps lost Date: Fri, 14 Nov 2003 11:21:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1023 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 2027 Lines: 55 Hi, I was experimenting with xfsdump, when something odd happened. I have done dumps of the filesystems of 3 machines to a common tape drive, an Exabyte EXB-8500. One machine contains the tape drive, the other two use rmt. Five tapes were filled (5GB each), with a sixth only partly used. Next I wanted to test overwrite handling, as I was having problems with an earlier version of xfsdump. I started a dump of a 75GB filesystem, without using the -o flag. I began with the partly used sixth tape. The previously used dumps had apparently left a stream terminator at media file 12, and this is where the dump began. After the tape became full, a tape change was requested. I either felt like testing xfsdump, or I wasn't thinking clearly, so I accepted the tape change request without changing the tape. As I watched "xfsdump: preparing drive", the tape was rewound, and media files were examined. I was shocked to see it continue dumping at media file 12 *again*. It found a stream terminator, and that was all it was waiting for! I noticed a bug was fixed in 2.2.13 regarding handling multiple backups to a single tape, but I'm not sure what the exact problem was that was fixed. The earlier dumps on the tapes were with the older version, 2.2.11-1, and the *dump in question* was with 2.2.14-1. Examining the inventory records, it appears that several previous dumps had done the same thing: overwrite starting at media file 12. Checking the script output of the backups confirms this. This does not give me a warm fuzzy feeling. If anyone can help explain what is happening I would appreciate it. Could read-ahead or async-writes be causing problems? My tape drive configuration is as follows: Exabyte EXB-8500 stinit.conf: {buffer-writes read-ahead async-writes} manufacturer=EXABYTE model = EXB-8500SMBANXH1 { can-bsr mode1 blocksize= 245760 } command used: xfsdump -b 245760 -f /dev/tape -l 3 -p 600 -e -L series0day0 -T /backup/data /dev/tape -> /dev/tapes/tape0/mtn Thanks, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Sat Nov 15 13:17:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Nov 2003 13:17:32 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAFLGv25009897 for ; Sat, 15 Nov 2003 13:17:06 -0800 Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by flavatown.mail.pas.earthlink.net (8.11.7+Sun/8.11.6) with ESMTP id hAFL6Dd19234 for ; Sat, 15 Nov 2003 13:06:13 -0800 (PST) Received: from user-v7kajo1.dialup.mindspring.com ([207.69.79.1] helo=earthlink.net) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AL7UX-0007Nw-00 for linux-xfs@oss.sgi.com; Sat, 15 Nov 2003 12:58:01 -0800 Date: Sat, 15 Nov 2003 16:00:55 -0500 To: linux-xfs@oss.sgi.com Subject: XFS oops on 2.6.0-test9-bk20 Message-ID: <20031115210055.GA23038@rushmore> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i From: rwhron@earthlink.net X-archive-position: 1024 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rwhron@earthlink.net Precedence: bulk X-list: linux-xfs Content-Length: 1410 Lines: 39 I've seen the following error on 2.6.0-test9-bk13, bk16, and bk20: Linux version 2.6.0-test9-bk13 (root@rushmore) (gcc version 3.3.1) #3 Sat Nov 15 11:37:42 EST 2003 Filesystem "hda10": corrupt inode 34184782 ((a)extents = 18008). Unmount and run xfs_repair. 0x0: 49 4e 41 ed 01 02 00 02 00 00 46 58 00 00 46 58 Filesystem "hda10": XFS internal error xfs_iformat_extents(1) at line 678 of file fs/xfs/xfs_inode.c. Caller 0xc01b0fc6 Call Trace: [] xfs_iformat_extents+0x28b/0x300 [] xfs_iformat+0x586/0x630 [] xfs_iformat+0x586/0x630 [] xfs_itobp+0x106/0x260 [] xfs_iformat+0x586/0x630 [] xfs_xlate_dinode_core+0x140/0x760 [] xfs_iread+0x20b/0x260 [] xfs_iget_core+0xb6/0x4c0 [] xfs_iget+0x119/0x150 [] xfs_dir_lookup_int+0xb4/0x130 [] xfs_lookup+0x50/0x90 [] linvfs_lookup+0x67/0xa0 [] real_lookup+0xcc/0xf0 [] do_lookup+0x96/0xb0 [] link_path_walk+0x40c/0x7e0 [] __user_walk+0x49/0x60 [] vfs_lstat+0x1c/0x60 [] sys_lstat64+0x1b/0x40 [] syscall_call+0x7/0xb I haven't run xfs_repair yet. /dev/hda10 is the root filesystem. The error has come up while running ltp-full-20031106 and doing additional work like compiles and moving directories. -- Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html From owner-linux-xfs@oss.sgi.com Sat Nov 15 19:10:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Nov 2003 19:11:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAG3Au25016173 for ; Sat, 15 Nov 2003 19:10:56 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAG3AuIV016172 for linux-xfs@oss.sgi.com; Sat, 15 Nov 2003 19:10:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAG3Ar27016158 for ; Sat, 15 Nov 2003 19:10:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAG2KtQA015776; Sat, 15 Nov 2003 18:20:55 -0800 Date: Sat, 15 Nov 2003 18:20:55 -0800 Message-Id: <200311160220.hAG2KtQA015776@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 287] New: xfs kernel error: xfs_da_btree.c 2TB FS under load. X-Bugzilla-Reason: AssignedTo X-archive-position: 1025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4991 Lines: 122 http://oss.sgi.com/bugzilla/show_bug.cgi?id=287 Summary: xfs kernel error: xfs_da_btree.c 2TB FS under load. Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: greg@fqdn.com using the patches found on oss for a 2.4.21 kernel. version info from dmesg: SGI XFS snapshot-2.4.21-2003-08-06_04:46_UTC with ACLs, no debug enabled SGI XFS Quota Management subsystem Linux nova 2.4.21-xfs #13 SMP Tue Aug 26 06:11:09 EDT 2003 i686 i686 i386 GNU/Linux xfsprogs 2.3.5-1 xfsprogs-devel 2.3.5-1 xfsdump 2.2.3-1 Hardware: IBM S320 P4, 1G, FC HBA. The FS is 2TB over a hardware RAID 5 array of 14 disks. when under moderate load the kernel will throw this error a few times a week.This fileserfver is serving large files of 12 megs each (HD video store).Perhaps 10-20 users using the system when this happens. Please let me know if you require any further info. This is the output from ksymoops: [root@nova root]# ksymoops -m /boot/System.map-2.4.21-xfs /root/xfs-error2 ksymoops 2.4.9 on i686 2.4.21-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.21-xfs/ (default) -m /boot/System.map-2.4.21-xfs (specified) Warning (compare_maps): ksyms_base symbol create_bounce_R__ver_create_bounce not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol highmem_start_page_R__ver_highmem_start_page not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_high_R__ver_kmap_high not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_prot_R__ver_kmap_prot not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kmap_pte_R__ver_kmap_pte not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol kunmap_high_R__ver_kunmap_high not found in System.map. Ignoring ksyms_base entry d3ee7d08 c01d2839 c031a3ae 00000001 f767c400 c031a2b5 000008e9 c01d2cb7 c01d2cb7 d3ee7d70 00000001 c01ea8b1 ea8aa880 00001800 f68a8b00 24849120 00000018 00000000 00000000 00000001 00000000 f767c400 d3ee7d8c 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01d2839 Trace; c01d2cb7 Trace; c01d2cb7 Trace; c01ea8b1 Trace; c01eb8cc Trace; c01d2cb7 Trace; c01d6a3d Trace; c01d6a3d Trace; c01c49df Trace; c01e9b33 Trace; c01d5cd0 Trace; c01d5bf2 Trace; c01d5cd0 Trace; c01d5431 Trace; c01d5cd0 Trace; c020c2b5 Trace; c02154b0 Trace; c01eec48 Trace; c01ea1de Trace; c0127ba3 Trace; c014fe7e Trace; c01505b0 Trace; c015071b Trace; c01505b0 Trace; c0154ea0 Trace; c013d7ab Trace; c010770f 7 warnings issued. Results may not be reliable. [root@nova root]# This is the contents of the file: 0x0: 00 00 02 00 00 00 00 00 00 00 00 00 00 08 14 06 Filesystem "sd(8,32)": XFS internal error xfs_da_do_buf(2) at line 2281 of file xfs_da_btree.c. Caller 0xc01d2cb7 d3ee7d08 c01d2839 c031a3ae 00000001 f767c400 c031a2b5 000008e9 c01d2cb7 c01d2cb7 d3ee7d70 00000001 c01ea8b1 ea8aa880 00001800 f68a8b00 24849120 00000018 00000000 00000000 00000001 00000000 f767c400 d3ee7d8c 00000001 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 16 08:58:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Nov 2003 08:59:01 -0800 (PST) Received: from ping.ovh.net (ping.ovh.net [213.186.33.13]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAGGwf25009373 for ; Sun, 16 Nov 2003 08:58:41 -0800 Received: by ping.ovh.net (Postfix, from userid 502) id 18BCB3BB3D; Sun, 16 Nov 2003 17:49:35 +0100 (CET) Date: Sun, 16 Nov 2003 17:49:35 +0100 From: Octave To: linux-xfs@oss.sgi.com Subject: undelete Message-ID: <20031116164935.GE12546@ovh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 1026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: oles@ovh.net Precedence: bulk X-list: linux-xfs Content-Length: 205 Lines: 9 Hi Linux-xfs, I have a problem with a sun/cobalt raq550 (xfs) which was cleaned with rm -rf /*. How can I recovery data ? I was looking for an undelete but I found only ext2 version. Thanks a lot Octave From owner-linux-xfs@oss.sgi.com Sun Nov 16 09:48:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Nov 2003 09:49:04 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAGHmg25010079 for ; Sun, 16 Nov 2003 09:48:43 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 93FB6102701 for ; Sun, 16 Nov 2003 18:18:08 +0100 (CET) Received: from nx-01.sapienti-sat.org (pD9E7FAC0.dip.t-dialin.net [217.231.250.192]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 4B462102599 for ; Sun, 16 Nov 2003 18:18:08 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id DF7761B057 for ; Sun, 16 Nov 2003 18:18:05 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id AC8681B056 for ; Sun, 16 Nov 2003 18:18:05 +0100 (CET) Message-ID: <3FB7B14D.1040406@koschikode.com> Date: Sun, 16 Nov 2003 18:18:05 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: undelete References: <20031116164935.GE12546@ovh.net> In-Reply-To: <20031116164935.GE12546@ovh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1027 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 300 Lines: 12 Octave wrote: > Hi Linux-xfs, > I have a problem with a sun/cobalt raq550 (xfs) which was cleaned > with rm -rf /*. > How can I recovery data ? I was looking for an undelete but I found > only ext2 version. Use your backups. There is no 'undelete' for XFS (and no undelete for ext3). Cheers, Juri From owner-linux-xfs@oss.sgi.com Sun Nov 16 16:16:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 Nov 2003 16:16:58 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAH0Ga25020667 for ; Sun, 16 Nov 2003 16:16:36 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAGMMaOO024590 for ; Sun, 16 Nov 2003 14:22:37 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAH0GTEU2167863 for ; Mon, 17 Nov 2003 11:16:29 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAH0GSNE2166985 for linux-xfs@oss.sgi.com; Mon, 17 Nov 2003 11:16:28 +1100 (EST) Date: Mon, 17 Nov 2003 11:16:28 +1100 (EST) From: Nathan Scott Message-Id: <200311170016.hAH0GSNE2166985@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fsr man page X-archive-position: 1028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 Remove a section from xfs_fsr man page which is inappropriate for Linux. Found and fixed by Christoph. Date: Sun Nov 16 16:14:56 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:161897a cmd/xfsdump/man/man8/xfs_fsr.8 - 1.3 From owner-linux-xfs@oss.sgi.com Mon Nov 17 05:21:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 05:21:44 -0800 (PST) Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.8.70]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAHDLJ25022509 for ; Mon, 17 Nov 2003 05:21:20 -0800 Received: from 82-69-23-183.dsl.in-addr.zen.co.uk ([82.69.23.183] helo=ferrypath.org.uk) by heisenberg.zen.co.uk with esmtp (Exim 4.22) id 1ALjJd-00085U-RP for linux-xfs@oss.sgi.com; Mon, 17 Nov 2003 13:21:17 +0000 Received: from localhost ([127.0.0.1]) by ferrypath.org.uk with esmtp (Exim 3.36 #1 (Debian)) id 1ALjJb-0000Qw-00 for ; Mon, 17 Nov 2003 13:21:16 +0000 From: Jim Minter To: linux-xfs@oss.sgi.com Subject: XFS NULL pointer dereference at virtual address 0000005c Date: Mon, 17 Nov 2003 13:21:14 +0000 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311171321.14257.jim@minter.demon.co.uk> X-Originating-Heisenberg-IP: [82.69.23.183] X-archive-position: 1029 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jim@minter.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 5286 Lines: 126 I'm getting a kernel oops indicating a null pointer dereference in xfs_alloc_lookup(). The symptoms are similar in many respects to those indicated at http://lists.insecure.org/lists/linux-kernel/2003/Sep/6937.html. There doesn't seem to be any follow-up to that article, however. What seems to be happening is xfs_alloc_lookup() calls xfs_btree_read_bufs() to get a new buffer. xfs_btree_read_bufs() returns a null bp, but doesn't return an error. xfs_alloc_lookup(), doesn't check to see if bp is null, attempts to dereference it and oopses. in xfs_alloc_btree.c, xfs_alloc_lookup() ... /* * If the old buffer at this level is for a different block, * throw it away, otherwise just use it. */ bp = cur->bc_bufs[level]; if (bp && XFS_BUF_ADDR(bp) != d) bp = (xfs_buf_t *)0; if (!bp) { /* * Need to get a new buffer. Read it, then * set it in the cursor, releasing the old one. */ if ((error = xfs_btree_read_bufs(mp, cur->bc_tp, agno, agbno, 0, &bp, XFS_ALLOC_BTREE_REF))) return error; xfs_btree_setbuf(cur, level, bp); /* * Point to the btree block, now that we have the buffer */ OOPS HAPPENS HERE ==> block = XFS_BUF_TO_ALLOC_BLOCK(bp); if ((error = xfs_btree_check_sblock(cur, block, level, bp))) return error; } else block = XFS_BUF_TO_ALLOC_BLOCK(bp); ... The oops occurred on Linux i386 kernel 2.4.22 and "SGI XFS snapshot 2.4.22-2003-09-03_04:09_UTC with ACLs, no debug enabled". The code problem is quite evident in the current CVS, however. Does anyone have any comments/ideas on this? Are there any obvious work-arounds? Is the problem simply the lack of null-checking in xfs_alloc_lookup(), or should xfs_btree_read_bufs() not have handed back null in the first place? If it is simply the former, then I suspect there are several other places in the code which will need null-checking. The output of ksymoops follows. Jim Minter Nov 16 20:05:12 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000005c Nov 16 20:05:12 localhost kernel: c01eb539 Nov 16 20:05:12 localhost kernel: *pde = 00000000 Nov 16 20:05:12 localhost kernel: Oops: 0000 Nov 16 20:05:12 localhost kernel: CPU: 3 Nov 16 20:05:56 localhost kernel: EIP: 0010:[] Not tainted Nov 16 20:05:56 localhost kernel: EFLAGS: 00010286 Nov 16 20:05:56 localhost kernel: eax: 00000000 ebx: 00000000 ecx: f7ba372c edx: c86eeeec Nov 16 20:05:56 localhost kernel: esi: 059627d8 edi: 0002c4fb ebp: 00000000 esp: f7bd3940 Nov 16 20:05:56 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 16 20:05:56 localhost kernel: Process kswapd (pid: 7, stackpage=f7bd3000) Nov 16 20:06:55 localhost kernel: Stack: c86eeeec 00000000 00000000 0002c4fb 00000000 f7bd3980 00000002 c0255379 Nov 16 20:06:55 localhost kernel: c6262010 00000000 0000000b f7045400 0000000b 000027a5 0002c4fb f7ba3544 Nov 16 20:06:55 localhost kernel: 00000000 00000000 f7bd3b0c c86eef70 f7bd3a00 c01e71d8 c86eeeec 00000001 Nov 16 20:06:55 localhost kernel: Call Trace: [] [] [] [] [] [] [] [ ] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ Nov 16 20:06:55 localhost kernel: Code: 8b 70 5c 89 44 24 0c 89 14 24 89 6c 24 08 89 74 24 04 e8 10 >>EIP; c01eb539 <===== >>ecx; f7ba372c >>edx; c86eeeec >>esi; 059627d8 Before first symbol >>edi; 0002c4fb Before first symbol >>esp; f7bd3940 Trace; c0255379 Trace; c01e71d8 Trace; c03a0780 Trace; c01e6dbe Trace; c01e9a5c Trace; c01f8897 Trace; c03cdb58 Trace; c03cdeb5 Trace; c0203b2f Trace; c01fd23f Trace; c0203b2f Trace; c01fac38 Trace; c03b3940 Trace; c03a0780 Trace; c03b3940 Trace; c01fad67 Trace; c0229852 Code; c01eb539 00000000 <_EIP>: Code; c01eb539 <===== 0: 8b 70 5c mov 0x5c(%eax),%esi <===== Code; c01eb53c 3: 89 44 24 0c mov %eax,0xc(%esp,1) Code; c01eb540 7: 89 14 24 mov %edx,(%esp,1) Code; c01eb543 a: 89 6c 24 08 mov %ebp,0x8(%esp,1) Code; c01eb547 e: 89 74 24 04 mov %esi,0x4(%esp,1) Code; c01eb54b 12: e8 10 00 00 00 call 27 <_EIP+0x27> From owner-linux-xfs@oss.sgi.com Mon Nov 17 06:11:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 06:11:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHEB225024556 for ; Mon, 17 Nov 2003 06:11:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHEB1UI024555 for linux-xfs@oss.sgi.com; Mon, 17 Nov 2003 06:11:01 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHEB027024541 for ; Mon, 17 Nov 2003 06:11:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHDGKqg022458; Mon, 17 Nov 2003 05:16:20 -0800 Date: Mon, 17 Nov 2003 05:16:20 -0800 Message-Id: <200311171316.hAHDGKqg022458@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 288] New: XFS NULL pointer dereference at virtual address 0000005c X-Bugzilla-Reason: AssignedTo X-archive-position: 1030 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5832 Lines: 146 http://oss.sgi.com/bugzilla/show_bug.cgi?id=288 Summary: XFS NULL pointer dereference at virtual address 0000005c Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jim@minter.demon.co.uk I'm getting a kernel oops indicating a null pointer dereference in xfs_alloc_lookup(). The symptoms are similar in many respects to those indicated at http://lists.insecure.org/lists/linux-kernel/2003/Sep/6937.html. There doesn't seem to be any follow-up to that article, however. What seems to be happening is xfs_alloc_lookup() calls xfs_btree_read_bufs() to get a new buffer. xfs_btree_read_bufs() returns a null bp, but doesn't return an error. xfs_alloc_lookup(), doesn't check to see if bp is null, attempts to dereference it and oopses. in xfs_alloc_btree.c, xfs_alloc_lookup() ... /* * If the old buffer at this level is for a different block, * throw it away, otherwise just use it. */ bp = cur->bc_bufs[level]; if (bp && XFS_BUF_ADDR(bp) != d) bp = (xfs_buf_t *)0; if (!bp) { /* * Need to get a new buffer. Read it, then * set it in the cursor, releasing the old one. */ if ((error = xfs_btree_read_bufs(mp, cur->bc_tp, agno, agbno, 0, &bp, XFS_ALLOC_BTREE_REF))) return error; xfs_btree_setbuf(cur, level, bp); /* * Point to the btree block, now that we have the buffer */ OOPS HAPPENS HERE ==> block = XFS_BUF_TO_ALLOC_BLOCK(bp); if ((error = xfs_btree_check_sblock(cur, block, level, bp))) return error; } else block = XFS_BUF_TO_ALLOC_BLOCK(bp); ... The oops occurred on Linux i386 kernel 2.4.22 and "SGI XFS snapshot 2.4.22-2003-09-03_04:09_UTC with ACLs, no debug enabled". The code problem is quite evident in the current CVS, however. Does anyone have any comments/ideas on this? Are there any obvious work-arounds? Is the problem simply the lack of null-checking in xfs_alloc_lookup(), or should xfs_btree_read_bufs() not have handed back null in the first place? If it is simply the former, then I suspect there are several other places in the code which will need null-checking. The output of ksymoops follows. Jim Minter Nov 16 20:05:12 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000005c Nov 16 20:05:12 localhost kernel: c01eb539 Nov 16 20:05:12 localhost kernel: *pde = 00000000 Nov 16 20:05:12 localhost kernel: Oops: 0000 Nov 16 20:05:12 localhost kernel: CPU: 3 Nov 16 20:05:56 localhost kernel: EIP: 0010:[] Not tainted Nov 16 20:05:56 localhost kernel: EFLAGS: 00010286 Nov 16 20:05:56 localhost kernel: eax: 00000000 ebx: 00000000 ecx: f7ba372c edx: c86eeeec Nov 16 20:05:56 localhost kernel: esi: 059627d8 edi: 0002c4fb ebp: 00000000 esp: f7bd3940 Nov 16 20:05:56 localhost kernel: ds: 0018 es: 0018 ss: 0018 Nov 16 20:05:56 localhost kernel: Process kswapd (pid: 7, stackpage=f7bd3000) Nov 16 20:06:55 localhost kernel: Stack: c86eeeec 00000000 00000000 0002c4fb 00000000 f7bd3980 00000002 c0255379 Nov 16 20:06:55 localhost kernel: c6262010 00000000 0000000b f7045400 0000000b 000027a5 0002c4fb f7ba3544 Nov 16 20:06:55 localhost kernel: 00000000 00000000 f7bd3b0c c86eef70 f7bd3a00 c01e71d8 c86eeeec 00000001 Nov 16 20:06:55 localhost kernel: Call Trace: [] [] [] [] [] [] [] [ ] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ Nov 16 20:06:55 localhost kernel: Code: 8b 70 5c 89 44 24 0c 89 14 24 89 6c 24 08 89 74 24 04 e8 10 >>EIP; c01eb539 <===== >>ecx; f7ba372c >>edx; c86eeeec >>esi; 059627d8 Before first symbol >>edi; 0002c4fb Before first symbol >>esp; f7bd3940 Trace; c0255379 Trace; c01e71d8 Trace; c03a0780 Trace; c01e6dbe Trace; c01e9a5c Trace; c01f8897 Trace; c03cdb58 Trace; c03cdeb5 Trace; c0203b2f Trace; c01fd23f Trace; c0203b2f Trace; c01fac38 Trace; c03b3940 Trace; c03a0780 Trace; c03b3940 Trace; c01fad67 Trace; c0229852 Code; c01eb539 00000000 <_EIP>: Code; c01eb539 <===== 0: 8b 70 5c mov 0x5c(%eax),%esi <===== Code; c01eb53c 3: 89 44 24 0c mov %eax,0xc(%esp,1) Code; c01eb540 7: 89 14 24 mov %edx,(%esp,1) Code; c01eb543 a: 89 6c 24 08 mov %ebp,0x8(%esp,1) Code; c01eb547 e: 89 74 24 04 mov %esi,0x4(%esp,1) Code; c01eb54b 12: e8 10 00 00 00 call 27 <_EIP+0x27> ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 17 08:11:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 08:11:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHGB325000725 for ; Mon, 17 Nov 2003 08:11:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHGB21v000663 for linux-xfs@oss.sgi.com; Mon, 17 Nov 2003 08:11:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHGB027032625 for ; Mon, 17 Nov 2003 08:11:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHFHUi6029099; Mon, 17 Nov 2003 07:17:30 -0800 Date: Mon, 17 Nov 2003 07:17:30 -0800 Message-Id: <200311171517.hAHFHUi6029099@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] New: Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3321 Lines: 91 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 Summary: Data corruption on XFS Volume on Raid5 Array Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: stefan.hagendorn@lindy.cc Hi all, hopefully this is the right way to report a Bug. I use a box with 4 harddisks with Raid5 and XFS. After writing a File the File appears to change when reading it. I've done the following to demonstrate the issue: Created 2 files 100 MB each with /dev/zero as source and compared the files 3 times. [root@mss archive]# dd if=/dev/zero of=testfile1 bs=1M count=100 100+0 Records in 100+0 Records out [root@mss archive]# dd if=/dev/zero of=testfile2 bs=1M count=100 100+0 Records in 100+0 Records out [root@mss archive]# compare testfile1 testfile2 -a 14614544 (0xdf0010) 0x7f != 0x00 ^? ^@ 14614545 (0xdf0011) 0xff != 0x00 ~^? ^@ 71893008 (0x4490010) 0x00 != 0x7f ^@ ^? 71893009 (0x4490011) 0x00 != 0xff ^@ ~^? [root@mss archive]# compare testfile1 testfile2 -a 44630032 (0x2a90010) 0x7f != 0x00 ^? ^@ 44630033 (0x2a90011) 0xff != 0x00 ~^? ^@ 58785808 (0x3810010) 0x7f != 0x00 ^? ^@ 58785809 (0x3810011) 0xff != 0x00 ~^? ^@ [root@mss archive]# compare testfile1 testfile2 -a 8716304 (0x850010) 0x7f != 0x00 ^? ^@ 8716305 (0x850011) 0xff != 0x00 ~^? ^@ 31260688 (0x1dd0010) 0x7f != 0x00 ^? ^@ 31260689 (0x1dd0011) 0xff != 0x00 ~^? ^@ 31326224 (0x1de0010) 0x7f != 0x00 ^? ^@ 31326225 (0x1de0011) 0xff != 0x00 ~^? ^@ 85385232 (0x516e010) 0x7f != 0x00 ^? ^@ 85385233 (0x516e011) 0xff != 0x00 ~^? ^@ 104136720 (0x6350010) 0x00 != 0x7f ^@ ^? 104136721 (0x6350011) 0x00 != 0xff ^@ ~^? you can see this yields different problems every compare on both sides ... This looks to me like the data is written correctly to disk and the problem happens when reading the data. The Kerne I use is 2.4.22-ac3. Sometimes when performing reading operations on that array I also get the problem which is described in "[Bug 274] New: xfs_iunlink_remove: xfs_inotobp() returned error 22 " This only happends with operations on that drive/array. The box itself carries another array with raid5 and xfs without this strange behavior. xfs_info from that array : [root@mss root]# xfs_info /mnt/bigarray/ meta-data=/mnt/bigarray isize=256 agcount=86, agsize=1048576 blks data = bsize=4096 blocks=90040224, imaxpct=25 = sunit=16 swidth=48 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=10992 version=1 = sunit=0 blks realtime =none extsz=196608 blocks=0, rtextents=0 If you need anthing else or this is the wrong way to report an error, please infor me. Thanks Stefan Hagendorn ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 17 09:01:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 09:01:48 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAHH1O25005632 for ; Mon, 17 Nov 2003 09:01:25 -0800 Received: from titanic (titanic.skynet.coplanar.net [192.168.7.98]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAHH1NBG004334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Nov 2003 12:01:23 -0500 Message-ID: <008701c3ad2c$97517490$6207a8c0@titanic> From: "Jeremy Jackson" To: Subject: repeatable bug in xfsdump - dumps overwritten on tape Date: Mon, 17 Nov 2003 12:02:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1032 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 520 Lines: 15 Hi, I think I've found the problem with xfsdump. 2.2.14 when used on completely different hardware (IBM Netfinity - 20GB Seagate DAT) has the same problem. 2.2.11 does not. Looking at the changelog, I see a "fix" for multiple dumps on the same tape in 2.2.13. This fix appears to allow infinite dumps onto one tape, however only the first one and the last one are permanent ;-<. This is a pretty serious regression. It munges your backups and you won't find out until you try to restore. Cheers, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Nov 17 09:31:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 09:31:41 -0800 (PST) Received: from mx05.ca.mci.com (mx05.ca.mci.com [142.77.2.25]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAHHVF25007259 for ; Mon, 17 Nov 2003 09:31:16 -0800 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx05.ca.mci.com (Postfix) with ESMTP id 9CAD6F0BD; Mon, 17 Nov 2003 12:31:13 -0500 (EST) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id hAHHV6I13981; Mon, 17 Nov 2003 12:31:06 -0500 Message-ID: <3FB90619.5B853BC3@calibredigital.com> Date: Mon, 17 Nov 2003 12:32:09 -0500 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs barfing on TB fs. References: <3FAA9F75.7915E777@calibredigital.com> <11738.1068157873@ocs3.intra.ocs.com.au> <20031106233645.GD782@frodo> Content-Type: multipart/mixed; boundary="------------480239510F037DC09DE13966" X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 1033 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 21141 Lines: 391 This is a multi-part message in MIME format. --------------480239510F037DC09DE13966 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Nathen et al., I have submitted a bugzilla report (ticket 287) which may have have more details. I'll do my best here to depict the setup and config steps. The hardware: . IBM XSeries 335 Dual P4, 1G memory, mirror set root drives. . 1 dual port QLA2300 FC HBA. . 3 gigabit ethernet ports. 2 built in and bonded to switch(in cisco speak, etherchannel) the third an option. . 1 4TB JetStor III IDE hardware raid 5 connected to server via 2GB FC P2P. The Bits: . RH9 base with current updates excluding kernel. . manually compiled kernel (from kernel.org) with XFS patches applied (from oss.sgi) (same kernel/patch set used on other machines in production.) . manually compiled qla2300 module. . manually compiled samba. . Array has 2 partitions, created via hardware controller within the chassis. (RAID5 over 14 300GB disks) . Partitions formatted to 2TB and 1.6TB. . fdisk was not used at all in the process, not to further partition nor to tag the partitions. I ran mkfs_xfs on the raw partitions. . created xfs fs using default options. . As Keith correctly mentioned the kernel was recompiled to include high mem support without cleaning the build area up first. I know now why I'll not do that again. The 2 bonded interfaces are used on another network than the 1 gig interface sits in. All are linked at 1000Mbps FD. Lets call the bonded interface the backup interface and the other the production interface. Over the backup interface I run rsync jobs and the tape backups. rsync syncs a few large (several hundred gigs) production areas onto the 1.6 partition a few times a day. The production interface is the one clients hit to access the second 2TB partition. The error will happen (not consistently) when an rsync job(or two) has fired off during production hours and the clients are also accessing data. The majority of files are greater than 1.2 megs, 1.2 megs for NTSC and 12meg files for the HD projects. There is about a 60/40 split. The last time this happened while I was paying attention, there seemed to be 300 open files from samba clients (EXCLUSIVE+BATCH) according to smbstatus, as well as the rsync job running. I have included an attachment (foo.tar.gz) with some additional info, dmesg output, message logs showing the frequency of the error, modules loaded, and the kernel config used to build. If there is anything else I have missed please let me know. take care, greg Nathan Scott wrote: > And if you have a reproducible test case showing this problem, > I would _really_ like to hear the details, please -- an exact > recipe, from go (mkfs) to woe would be extremely helpful. > > Thanks for reporting the problem, btw. -- UNIX is user friendly, it's just selective about who its friends are. --------------480239510F037DC09DE13966 Content-Type: application/x-gzip; name="foo.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="foo.tar.gz" H4sICC4QuT8AA2Zvby50YXIA7Dzrc9u2k/2cvwLTfrhkprH50stzvhmKpCTU fIWgZDs3NxxKomw1suhKVBr//vpbkKL4Aig3l6R3c9WktYld7C4W+8IS8iqO L3/6zh9BUIRepwM/00/9Z/Z7r9fpSqIgSIAnCrLS+wl1vrdg9HPYJ+EOoZ92 cZy04Z2D/x/9rGD/P0W7bbR5v4i3q/XDd+AB+yl0FYWz/3K31+kd919QFGon oiwo3Z+Q8B1kaXz+n+//L29+QeohiZ/CZL0IN5sX9BBto12YREv0FH6KUGYV V2gZb/8tQdFynbz55Y3m2CM8Du763esXIHB8JMMpQes92sYJ2kdJjjXFukjx 3lBeWryMgHBy2K2TF7SJPkcbFD8n63i7L+gad67hYcuwfdXMJ5pxuAznG5gc Lw/wY394fo53JWEsR5+aBgH8YmBmeAQ7dmnwBkZzku4uXkT7fbxDyctzhMLt Eq0iKlq0z2Q90pH73fKyCoDCA3RaAD7RuDDLumPDujyCLigJTy2MMUPzOVQp 75J1wyF10+OM99njhqnabIjmTYljsGG32NYm2NU4QhzBUitU1jl87z18V1NF AZ1hVZMDiaEnsOPg1g1uHe+GBM5NYS0UgO2Z6Y6rY5rl3mmT2uCdquvVkSG5 Vd3qkOu4qp7xOEnm3RLDCsaGDUavBcTFtuloNww5M0TKGVgFqjl2POxPrCoH Uww0VZsYAZngkX/dK8MmKgnA/qoTxo4DxFxcG3bHRnVgSozAdT0nAOLaDZnW +I4EYcRRoaUZ5fX6Dog2VJm7hPs37N3Dmudojs62qpQJ8bgwzYUgxFCo7Uzw eGIZVlm845AyZpI7QrvtYPYaVH8SGNbUVH0ISmwU3/MYchLLLUtIl2RPLbYG KRD2ONAxUYemwTH3ihVM1JkR6IYWULvLo+M4zQMbOvHwXIRZ2/Br/uEwjAcI qWZt3NVweRHwCKY3xA5hLiMD69gzNJ+xhgys2vcV+gElVx3JKJQZg144BG3V ShPICdWo4ZZCDYvGxPFdczo+5RfN0rB6qYW75fCwL2Ws0iIpRpnScSJGkzh5 3hweEGnOOrKhIrNs5Z7MIL4WWhgSPQC31QxCAlXTStsHqJpvlpKj5nhGYJij sg6yQdWZsrZhiO2R5afQEsNsMKNTHbNwaneFAtieorpWgMc2ZQxRxwvIlEAq Y0d9iqs7gWHXrb2CAREgwHoLAriLa6r3wRCyGjsEUSzP18B+grHlc1FU03Ru IWv4bLtOqRjgHFCIQDx1bmF5zmjUsAEreop3L8iPFo/beBM/vCA9+ryGegW9 tXz9XaVA8fWmCYXguxsorqjxME1P9VzH85sTqdHRUsjdhC/H6u8A9SBUaEUQ cO1SWgMfoc9P2fzhJl58QstM1jLDoXkDMWYWjNjbSMGa+yHQ2Q6XgzUMVtyC QznoqjboCq0o01qMroFNx6ELakyzh3zhKdxT2fZM4cRXqyaRbfNhk6zfZ+rK twm99VRIV3QTzJn1rlTiluqLnCWMPRXwwMS2oXpl2WGQkmPr4wgUWcVjBurU aEH68rELmaxVESB3Y6l2lPwZ7z6ttw/Nit9VtRujEqWzkcCyVJfJCfIQrDXl xoOPsOkb7KKgCcoPKza+K5m2XRUKu9n6NZWwAwAgqPpMtTUDtAdBkcMe0MBl eHIDGLcBxx4njHku2zzpMgJDY5cc5N4ONMe5wQY7YGF3xq7Vbya+z2Go+mw/ mEFwDfqCJH5oWAcqxwrs3jH2RoXj4E0eZ9Tn502UhJtyrDniUQNUXdc0UvzS 9mmOS4PHvc2OHynYV22oxFm5Dru67hbOlj5C2tHKJX42CKWUWinYYAC2gO0x HtbHnKpW6jDHTdUdsgEm+2hJt1/HcBhmi2DAT450t7BfLXZMCY/AF1IULsbk NhhBToQRQDQbO/8hJjTWXcI5fBWud+iPQ3SIIEqUDYKSIXDuaCa6Y1RBSbRP GJPcGx+2szHLjzbR82O8fWHVV+4E9NGYAtZ3iXXj0hpZl55pNhsQAMyNE379 lU5IYzj8dHEjL9YCZmmyu4nCPSSDKEJ6vDg8RdskTb+X62V0kXxJ0Ao09Rht ni/X21WM4i1lh5a79Wd2wp3olHpruJ60pzWYDuURuyoq4WhnqYAm2gUBHDAV 170/h0U0wj7mAwx8mNzAuQRq28YuUk0sHtfPMJDv4OX88LBaf2ErT7P0riIw okFJltrBJoccD/Q8KemBg0xUKHGx96GdgW6px9NTDQaF49BRPZ3F/jhv5Hia wUkLJ8qBOvWdszJUMmEx95aTrPLJKiCKQns9phpaV7pjN79OOCYWO3dyO46l 95QzdNItbUfxPTwyjTNk7vuS1h20y6ORTkduX/rE9eUz4lCULjsJ5yguxu00 bNLvKSI7oZzMyfVxVxLbGemaJMBWBY7Z7u4nRNu4bS+aP4J1tOuIaKIktHkh md3eEJYXEIwtlZNfCxzYJbF9I4mpDQTjzCb4niUN2lcywyqYzR3HRI9eVffG OhzP2PmfwmzHZvcFSr6cnj2Z6oJclZ496mEzDbeNjEdH82ZHGSPrp79drvef fkVJ+Bz9ijT9veeUzzInxZbONEQPjDvfUymAXCtCPq5NvAzXLx9G8lGHcIrx EwtWoX+iOc7zLomfomwZy/ykHV08XIDo6PfDp2gef3l3WuATPbZBAYrMqb2v KgSoDqfj4MPUmJbfRqSg9PAQwJzKaxMKgd/hgMhrGqQopjMeY3vM3ptN/Of7 7G1KWgjsmMlMvg3A8u6C+hZX+fTAG6Go4yg1RVE1SDot4IkqdiS2iRcICrvJ f0LoKWxXyhBUrb6KChhrPVhpUa0fB2jwJ4FrpHuPNeNa6sh1FM8gtF42aDfI ItdiB/RROtocsVzPGRppgxBONexD0BFzOMWmDidOz7pVPVY/9iTxoC7xgCGx LNUxzgs8aBWjgZr10gJPB4/zOB26I2pm7M3mGxPNgrrsmiGaZ0DR7Rm+fw8/ sN1meEed8pJP5oAunJIldgTNqNAjOrlv8TVsS7yclFGwOrI26Cl8DMsYN0Jp FWM4JeDS1QKxEhLcDyPNJ+WQly3PupPFgdimAF+TpX6L+AY9m7RCaS45g+Hi FhWPpv4USlvdsVTM6TtQtLHOaSRl0OMrMVvzOnKflf+zzXJJI55iG/tt8gG8 XpSWwSlHTRG6auGQJUDvy5fGtpwgwf5lu+BzLvBGvC5SDQ/OXgCw2S9CUlxy T+2xD44h1eQtIGlhoesQLAhkkbQEuBZ5uMZIhVQFB6kxxJMuB8tS7zKMrlKT vcDBYACua3ADdbbKfjnwVSkw9d+QUeEgnUQsomYNg9zb2rUkMJXfz+L8CHPe G9RQWWvlkv0AQV1viUBlCS36WgtKBMtVWwzGVYnIrk8zsIbbYxpFkCSBfazO MAiWFIH50omCP6ThjJp1bdOOAExcNmCk8cZP+apWSB0RRIhyDUckhjpWOe2o DAFbPbFFEZntKW3K1DV5ILTshQ+S8aFTUQlkZdSCYEIVTHyH3XXL7IO4cksB lSbcRqk4OuzX8RZZro+qrxyKEnY0pTdmCnVnz8HQcfzGIPUuMjau+0INgIlh E6PY1OMwfdlYHzNVuxhL+4lafqTAhmEgUR4o6O1ovYtu4b+iAn9bviRUeR1G p6WzGr0fqAkayy6mVSuGSnORpyyQN6vKSC6z6mnbKGG9/wJIrcuan9qmlnVf 6GDo2DoE6Mpr6A9T1cQfOU1Yf8pOsIY/MTyf//okIMP6wTuV10ge6YVAUDE4 SbxDgGTN18m7ems1pV9bUoMA0M8n53rQDLt8LSB7DhwLQyzHY2o9lda5KbEb jwa3a2CTvtyX2LCJaqnahB3j7g366nbEqVe8vtgdsB3uZtA3q7PyraHrkcvL Gek6m/kEuy4b4rrsLSRmtfGW6p46ySba7xG9nPV2G2/fP4ZPu3C5jhv756k6 bpq8H3+Ktsijb+kYRuyzjtInry18yZ2oxOh0JHYI9bRai6JY00R1q2aerSrc ovU2iXarsCbQrdps7qtPYRIddsijy2a5OhgBe/F4p6vo7Xq72oW7aPmOGSY8 vXlhAxPdBuT5/mWfRE8VdAppoG+fDwlaxDt2ILJd5l2LdBzqtikxsp6YZxh2 cHctCpLSjnN/3ev2j/cvH8NduABNNl9FzEoBfuanHQnHLCdeCLeqWX8u4RW7 mEGMO9+wdV49lOHYWd9Dr/UTjkj0beygH7j+famTUgwC76ntwxm+W9rbmZaL xEgAGjvyaw1UC3RTaaFMSapVhpDpeBG/3QyxrI++pEHBETQIFC6uiQB3Vc69 xpueKDVnp+L9FoPJrRef9g0LCsaqZTCveDTNL0WJomW0TF8uPYRPER2mRF83 43eWGB+wJkgB950Pdi0MrmjrJtPjk8XjMn5A9PZUzeN9baI77Ot3RPsCRW4w 5p1NVXqrodpDO+nMN0wKK9eTFN21wHnYeWbGu+/h+ezXPrpvspOZJw+67GYC fZGNofRnL9ex76tZIyvzsp4rpGG02sTPzy9pEzavYrIGYVmlo/oe5bzHpYId HjIllVI3HeqLQtnW6dgMs3sHFAYqbYMFfbHDfgFBEQjmXKqik03WwSSdld5K rRQVnK4WHDVmTR9L7+g8Rct1yEqJM6wbTv0aSrYNa3pPPU0JVb+YOj7r+iBt +49IMCodn7IhJRsrrMWAAttLUdnq0FtgIz5swgcNjRZYA5SXaHe+TEU/Gcxv w8qrSnhsHlQKq1R9HscWYTTwSaYwvuWWRUnRqtdCnUG3K/Do/sZnaWHISGwN zO5qG2r7+UARRuiQx35HNnF5uqU3OoPqCsAGedgAcn1Sw/9g3yn8VXmO1bKv Uo0WvXXKozTVR2w604YuspHg1sM+8+byiFTsiT67DgHtq5pZuSFNVcoqoigg 9b8qEd1SXVwnwDdNVx0DbMQ5ZeenxtT/SdP/NUdXebqiEdazjI8fHbbK7JoG 6PNMrjzr1acMXFgbHfI1l0GbTG2vfHGY3gbXa4/BrPJlEmINeSuxNZcH+gi+ 1rCt/NpqsqaXXZD/8hxVLgh6Pu3o2qf7dZWkozmeXeAwmTpkdAZDtfBYPYfj qx4+gwMnTDZGDie6QwqMyntY2Bx61cZUhwb7rVIWbMh02C4D1L8gKMm+ydGK Sctp2mE7w9fUrdZFkTFmL4n2skDiM+JOz22fMTqndmqLtsl0GvPUn7HDBKof ZIbbh0P4EJWufxW4eWv5+uf1Pu73O4P34s8luzZpK1Y3aAwIFJn9pakKUu9V SD323YwKUr/D6XhUkdh9wRrSq9i9QvA+56p1DYld1NWQXiN4l31Ro4bELqZr SK9RAefKRw2J3RiqIA3kV1AavGaDB5zGbxVJeYVMfc4bTIoEMZrafsA5+5TJ iNJrxAYsvhHk3M5j8NeeY/ANJMc4v2q+aeQY/N3MMfjOk2Pwt+ikj/OLEc+v hnPvi6LcOLgfcG735uApFzz1RxX7OH7Hd7uPN1HpJkpeDUN61ZrtouwERQyz 9oazyHm6yu3pjHbhU/R+flitoh2ruTMaNqaQ+LBdlnGIM7Wbd56mZMgiSIfr qMPNIUriOHlkTRiaU+NjY8pN+qV79BguPtWuLWd3JW5ob715f9Vcz3fh7gXt 4kOy3pYrpI8mHkL5ODJVv9SNSkfppdpstPH9b/r9/83+KV5eAMHv9B3z9u// C4IkdIrv//cAT5QkSf7n+/8/4mNl36ZvfMj6XzA63UdLNH+hAzZYYRLSJvzy zR+bUJIFoTZFUpQ+ZCaEFPRm/9AkCR9Z6nS6FBWht+EhiRebKNy+a1rlP58f 9aH+/xTt91AL7y+k78Oj1f9FCcBK7v/wfzH1/47wj///iI8df0aoiwTliv7r o8/hYZOg7C/CXCHhiwD/E9J/Uv4L718fQSUidNGbdpq0K5I1RdHP++Xb/q9K /93PV+iOdgPoK75tuEHRbhfv0JfVPliGwTIOIL2/ld6hMEEbSHpIkvoiildo RRssR6x5souii8UFQhr94usOZF8I4lJazHtnBFouhdV8CcMpfl8ewC+yGMph hI6WKqJVtysu+7DKFCTNOxmoHw1QzuXcuo+fE3rGticUTAAUhf25iCJBUKSw n4HELrBd9SAj0it9coo7EF7J7Ui6nzMRGr+IxchpkZlo/UWBc4YbVTnyd+Ei ukL/+e+5Hv/jv1D+BAvmPKUrzp8kUZBXHd68bigveU/RQpifnhbKYLkqYJ3F Uig9zVcSF6bIIhsmCQvY9ULOjjIv5kXRQumXVgTinJ6k3jyUT0/KKuoVsI7Q KVHpCD1xzoMpUVg8ycteWGBC0BToak971LvqiFfit/VlNs2/0ZfZAkWdrtj5 lr7MZlP35Ywt25fnoaQMcl+WKr5Mb7AIofBKbl/ny5loTF9mc/vbfbnqvdFg Lsv/S3z5a71XWSndJd9fB1dy90rO92H3vLh4ghNqsgRz/pK+a99FfxyifYJW u/gJiT3poiteDKQLSXwNDaizH6Mt/ete6d/0oqNVgttoftiEF1AJXizipyva zKKv9C8z5pfhbhe+oLeVx3ffhTH4T8o4fk4un1dfgOfxtyo7MFvhLLvD9jUM 5b+40m/IWnnVWgdXcF76lnGcTfNvjONsgaJFZyV/yzjOZtOI4ylbZhxf9uai 0n1lHG/l9pVxPBWNGcfZ3P6J4z8+jisCRMNv7K8smn+rv7IEWizk+Tetu9hs 6v6ase1R7wADoAclpeJKUr9b86nSiPxKbl/nr5loHH9lcfsf+OvrfbLX7UaL 4gkEXXH89ft76Nd6oTRfLgetXji4Enrf2gsZNP9eL2QItOhHy2/thQw2DS9M 2TKz5krpiZ3o1VmzhdtXemEqGs8LGdz+yZo/Pmt2hCth8HVl9e/hMjoV1V1F +Wv1PDCWpK85udTY9v8yW7n3LdbbkZqML+fh4tPh+Rz/8/o+z52h7XPcReFK lK8guja5a+Hh4TFB+/UDjZti51fQwPtd9LCGALujX0ehf0sp+rKmf+Xp4ocR 3K72VyWqaP94SJbxn1u0PywW6f332sR6OwUIgCybcE9f4u4+Qzh/DPcp21dO PWwzVaYSQ3BanbLOnjM/lZlOfr20p2Xu/jjE/83e1Ta3iSzr/axfMbfyYe1z bIUZ3rnXp05iO7uujV/WdpK9lUq5ECCbiiS0gLz2/vrbPQN6gUGAjOKcXKdS WELd/TRDd0/3MMykblvOK6DmCnKWM+gA8VpxpjTEb6kEw9HtLrvoCpnP10VX KAQBlpoddtEVMKXClsPKC9tA9yylWRe9Hm2zLlqoJuuiK9Beuuhv3EXDfWDQ RbOO/VUm81n9VaZQYFvesFt/lcGU/JXD4oCo4QWWKylsWZPCdj3ahv7KVavw Vxnatylsf8BSVrTnPBXp0O9KMp/b70oKeZ49sDv3uxJMeUAJYU18BG4YxvBp fleFtpnfCdWq/a6E9uJ3T/A76tA8jiXJnb8zdcc3s0n4sPuZUt364kCCm/C1 NLxRlGQvwc4g6SU4T6ipINtoJYjpckFMM+mSoGgaTIqCcBLfziz0D5TdVZla nl25uJayQ6butCb5X2YaR/40jgZgYItPhy5uFDSKsIrMN+uZBOn+dLivr4qZ P0ubDKazSXybpHHODl+zQo1MonvX+RTFXxOxDO6//1EhJbsCQj5Mlqu8Ir+D qwyPipc0l/LNLgkEcI03up6cueZiMhr+Z+m2rucZTv3PYONoUp/Hbjjpe45l w5cT5827iyM3GGMbJisVH1jdvMwuiKUFVYa19sUcqjQy9DqPqRZEDbWN660R ZDKllSC9IhgwXVc282HD0awKmYZir5F5C1Y1l2lQahTEzi0ima0IZeuE5oqi 8ErBeRzDYY2xO3XyDzWGAZxWJWfqxulsKmc0HaV2PKfsE0Wu1RGVenrpcEo9 W+uxFJRgrEjAtkAJmzCvaF3TqCVG0URtufJbsZ6P1s+8kAxZTgM3Hs3HLClk hxsNWlbhezy0Y8+SzdUBLfxQLt8hZ7gajXcnUmTQAigDL8VtXrZxqZS2GJYG YFVv5vI1QU5THarX6l8/um2qbUbzM+CN5iEVYI3WsEzt5HpXTTPx/ZJhwrkS dv2ThFpkTWmNrFuLsNVVYSqT+ayFqUyhoUZZx4WpDKZYmApYKEw9XVVVBXwD iiE3sOHSPAqFlQsaBYqqBvlILuihET0wTXfgqQ3RNitMhWoVhakMbfPCVFzx /Jvv+YayQdH6Pc0P39qQLbQ8rSoYgXqjZFO3Hb34xDzxknCH7joEN80iR+ef zogfpNCvBX5/zkodhZanqOF7ZA+KwrkvghgUGGPacnJ1kfk0dI/RfQD94z65 cw/A5AaBpphendy5Sp9c/nSPXxqulpdGBAIebhwU9PsrUiDFr5RyyPedDRMI 4rgl3y1c2AozVR1N9gCyZY9tmG07ANpwRqoEOp4NHhezUXV1I2TaAXKrTp46 GpQ7sgtuPFN6jYy2E5ZtqyPl2wPrhfvlLd8ob0ugRtFIqq0DQPV6l5AmRfBz HE0fHcNqMzsbMZdqi40x297RzmaEQ2kimc3xzbCLAWCdQZmLiPtkXK2FTVXg tnL9Rro30bxdddUpMuv6XjVCLXURa+6UtRjj2dQT7bbtazu0vj9qYpWG0qoC 7BbabHFvO4QtZR7VN1dXNiyz81trKkqb9mX4dsN8RKSbWlMu8xlrTblC/lAx upzPWwFTejOZw8onC0F1NGj4NuN6tM1qTaGatNaUo71MFvrWlSfDtxtYp2/B VMh8Vn+VKbQFf5XB1PmrzIP4cT57gdkGyW26IdoW/FWG9oSxoW489Mf1SU3v 3idLMp/bJ0sKbccnSzBb9ckqtO34ZAntxSe35JN08fSmM5+UyHxen5Qo5Bu2 2ukzFDlMySc5bCc+WY22oU9y1ap8UoL24pPb8EnVYVrXtaZc5jP6pFyhINDM TvtJOUz5xRSEfbpPrkXbzCeFalKflKO9+OT2fLLbl8XkMp/dJ4sK+Wzo+937 ZN3LYgK2K5/s9GUxodoan+zuZbEXn1zrk/pi1lNnPimR+bw+KVEo8JnddT8p gSn1kxy2E5+sRtuwn+SqVfmkBO3FJ7fmk2q3L2nKZT63T5YU2o5PlmC26pNV aNvxyRLai09uzSelc8OaT1qoltH2Ib5htlnZMQOuf47fANgqTjCufKzdJWjj GQsCtNuhOLnM5w6dJYW2EzpLMFsNnVVo2wmdJbSX0Lml0GmU5+Q+2SclMp/X JyUKbcMnJTA1PgltpymKZ3q+tvASzzOoO4Bw7quu5prLH5qhbcMnJWhP8MmB T6spX3yyq7mfBms1vbdb6OKs03XpSIewxVnb6xKSCthWeWMj1Rsorraamdwl cONpyV2CNp6TDKBWZ3Mw9bb+0CF0G3/oELaFP6hG1wvhyGU+azIgU2gLyYAM ZnsJ+hq0LSQDMrSXBH07yYBa8aZ6mz6qSkbrt5O0Vu8LdAnc+HWMLkFbjG2o VpOXxJtEbJu2mrnfLTRt0cwdwhbv7pqG1lj1Ek2W1WTVlOIbt7pD4VJk3W1z H6uW0T4zarPQcafAdtOb3yFoeVWEqlsPoPZiJelu0hO5zGdMT+QKDQ2P+YNA 6yw9kcMU0xMO62lefXpis0WeUk5P1qJtlp4I1QxLkp7I0TpLT3TTtOkGycpK usAUwzP1Z0tkbEs1jIrUxVVVtkQ5GNi2/DcWuK6x0MxVhoFaJUU37GDpm76k 59A36XDpN21JF0W3vGU+ZirLyZH8TosFvSfRZD9J3Ynvxj466yRyyL5tK6vM VQuFqUqj9bfKPQnDFX46DlEymc8aomQK+Uxhnc6iksOUZ1Eh7NMrqLVom4Uo oZq0gpKjvVRQ26igRFt3uk9nhcxn98miQkNlaHa5v1sFTClt4LBd+WSn+3QK 1db4ZHf7dL74ZI1Pas363rUL4emOqi22eSkJsjdZsVd3dN3R1EYl5lrlDEdR q5ciXV0dqoEgrULQ6vqjRUG4ROiyIMtRZHWbWGLxNkjJXZSkE3ccYBhaqnU1 jTQQ06D29yIvWqxMRPU2xa4A3miWziosazXEArBLq0AUrYxqxgZWZjh8Tav2 gw6KuawYVR2lYtVcldpoYUstg/rh0qizOPhvMopu8TYfEK4YCcSfNH08ODs/ Ov4IwkiMV3BAYjSJA/chTAi/poOCcaIOFcaZ6bBB42gbzsZavc9a4yWcOGSD 1ZTqIYuLi1QOaBh8Mc0nLuBElXYLqRibL2e5gGz3VBnXTl7sAbfefdbGQXNl PbSiIKZrG5iaiS/j6hVrOxdk1iinscW0paIgVTE79MWx+/CQW5zMJ7kulQ0l dNmgoXQIv41k1jWUVTmEq6q6upFyOl1s9rle5lrlsHtp4pOyJfcmVDcWccBu 1cVwXOmIahwMZ0kDRIEmws0ujn/kHQm67WMBSa2yDW0j2xAyq2xfa24bXJAm 6xX92Xha1SdCKxSuT5dtOLi+Yy0K0RfznVqG5qIhtJoPzJEbLHVci2u3W+mO 46qd4Dae2WHhEJzWzbwf226VSXYLXVyzsTLL6Ba2caYB2SvbONNYWcXaNs02 zSyAu1io3DZL81hqVk8V2LJMp1WxI8TkbzzyLSbHEMrc2wC0nQZcfUbSEE4u 8zTK7OouulgeNbrojpCbRy2TQMSFClXLO5UOBtkqZT7XIFulQkOm0+4G2Sph SoNsHFa6fJxnDJji5svH8WGvfPk4plmaTZnSEG3DQTauWnmQrRKtq+XjaDCw PO/JQ27f0/JxzBy46pOH43QtcBffwGzcQcXgHNwjHNpZ5D7FZM5uP6aWy9Q6 XPKjUuYzxge5QgFlRnd70VbClKYWctjlQfg5yPyMoBlaC675T83QNosPAlYa H+RoXe2xxyilNmsfHxj1fE+tiBY/3gC9uA9sEacLMUBTVGuDGGA7irIYIHnq HuIlgU33EM8Z9WIvVL+HeA1r7R7iJf76PcTlLE32EJdzttn3SkigjtrhlPBK mc8Yt+UKdbsncSVMKW7nexKX8zrfAvhBk2WB69A2jNsVexJXor0sC/yt47aN cVvp8H3OSpnP668ShbbhrxKYOn+V5lmcZn2etRZtG/4qQfuu86zAdpfmEP6o 3rs09pt37MVtYDHRyjwvDgbz0fMSfzgJU+jw/wpT7w6Z04jEs8kouMdbbRSY 8tDt8qGi2vRpiSP2cC/MaDpFjK/BY4r7OFUlE/riwc/4Mflz5C/xnj5e/f6+ ASNmow4/kv3r48vTWob7ZJhOgUX8rb+ynM+LowmOFuKf5lyP00GIbOJvPV/u hD7w0H8qfDeu2E/g9jUkjGZFC5iPL0PeHI2hid17bGDxFRK+wF/TzMuD07jl pv/Z5o/PWiXpFTIhBR1F3ldnIbx5+2Bm3Wgb2xJnHt5+43/xYest6rszjSNv lyRof/Nd1BowE5/vzkzgssfhxJVd7/xJ2CNc761DvsKxwaXmbFkrrm74/NPL v//Yf8Moeu2Pg+R2ixgKzgTRtJ+yzr7wVzUo03+CHkc3mKIbKgN6qin6T0TZ ok7zfzPcdpiQn3BsYB1d3e//of8+43X9exLdu9B7R19eEQ9y4Nf3bvza9cfC MkjvfTiZPZD7IOajKqyv9Rndh7SY7My5d8nOrefNadQ+6zMChaCqMMbIzmXg k19BspDEf93Xd3fJK6qSq9MLcj0LyJvZLYHgpvD5Z4pNjo+uuYTe25Pzq30I ifchBCYyvXtMQg8iz+WbU4Jht0c4QWAxXkus/iP7y6dsnn3uzBLMBHarGAXV CqPLZe3EAR9/8StZgxImVZqx0qK66tDIWNepO6daZhwGHnhQHeacboV1KDDf HF6cQHeSupW8wwKslrd4DSyAFjSmioSVUuv0Lfn15JdfT49PiXvvhiNshX7P sg344f35p8L5YTSDbh6N6fRin6d6WM7x22lrSu9uvEem+GiUn0GwHIukf4Ue CFihCGopNpRxPiGTyAcCyHpTd4TEiUOYbuuW1vs7mgQ7yq5DNMU2uKCkL07i PqSM6TiisnyawWlwMagts7N43yCtCtzYuwNQfKwaB2SAuc0ezry5vDq6IH+5 CeHNldPzs0DDH8BCq819zPV9uIAEykMFykRP6QElubi+JOReIZ9P3p5CCfil d3Nz795ADncLyj+gWQ2HlrIHBbJhgX6h/3BgoadOhXAwHW60HJuIO8W14Xpc k3uaSyZXx5fnZ//7xwVR+tgiUiSFIzFtHVIlm7mWrazgOzjVUsFA20jBjM1m 7RR8c3FyuJmC65Hec8E7rjcNb0L/s/KA/vqFiI9fwM5QCf8z/bLbO7z4ANa9 I0h2858uIKUFS4IK8ZVCLtAuZ2Oi7aTjXfLH8fkZ/yCUz7oQavSkqDRDNcqo lKMaclTjSagsQ6VlVMZRqRyVPglVzVDNMqrKUU05qtkY9eRcwHKY4Evu8PAl j9NfyO0oGrijmzD+82bgJgG/47urnH6Rk1Zw0hKrV2RlFayMs55d31xdHt6c f7wkO4MZ8EATxX8KK1zwIPkXqMdGbhymj+LXNA5vb4M4U583983Z6UnZqKvZ cHQw5VZQLcB4qgD6VAFmUwEaAUtKREfUex9hwOc3Jo/6w4DnM7Lw5FsbRbWM TRu0jGpX7/4LopohC2v0S9aJfZgksymW4NjZcm5k6x2jd/BRprsAr/fnhLge jk9kI094eoHYO5mkUEyfQrEbLhzqahp44TCfHH1P+1oPtfgYxukMGu0T9rG4 sTj8PghH0O5kDH08dPaQopwcOQS1Pj67+kRApD/zUn7y+sPl7x8gPzrGnEW0 e4oj4u+Oj0Wrn7w+F+dfUY18zJ3W5GkNUB1yqv4ymSolo0UyJiVjnGzeXJwW LwN6vZGb9rMB3w8J/qiSXFzSmzcT5DFaDy917OK4XrDYB57MpfIR+Hg2TRPi z2KBcwpFx2gEyUs2kgEtOcYhGxyKd0gc8ee2B6/94P514rsUblGYhu4o/BvZ 4Y6+UnpHGRJhqs36qsHI6a9/k2muWb93GE2SCEf/vGgUzWLy8Zc3/yQWGLDe OwRRg9gVw5jByH2ETCia9vt9opkm7SuMvI1uo9OTi6veaTCO4keHUKhqNEv7 +poqqqWqxtdFIkp2mGJqX7PRGYDzgz1CdU0HojwX3CO6Zn3l6fUeseEHHBAF KsjjVPaV3IW3d+NgvAtXxSdIe9CcAT7yvcvsGk+HmDZSlSom9D9gzUHsEAtk KJqlmwYZPKZBAuGS55rVAgxdV405vwmKMY1ZVs5+yufiVbPrdAEOjs2z1oz1 7Qz8Pd5vCm3sQe3HqKbl/BeQz67hzoirrxzswhFPDIT+0FjsNzKLpskeeU/J UX7W+k2Qvmf5Gbio7NxFngYvIgE6rpIFidzMgcsDC4CMO0QrnEEwmEeivpQ2 DvKn8VnfjQNq3JL7Ahn/vRmm+JZcMAni0NsD7aZw3YNhMBgOhsPq5y3KQkL+ 7xAcCue3N5Ywd9chzjl4B+lG4t4HfBwVbDiN4gDdw4cKZClgzCZjN/kK13J1 cnrEmYIHL5jykJm1x4LrENsBuX6+G6U/gwMkaQyBEWiR5vy3fu/i/OrkD/Cf yTCKIRzAfYT7ytts8Eg+nJ28O/nj29/k7/3GgQQotbnmO5eQ9wXRZOf6dJfw PBUqgF8gKiZpIB5rKGZvCi6Kv/FJwqMQ23GWRsMhNKRmsL5l48QZD0JzfrnH DymkYPOr7h1fXZJ7dzSDGjOAGxWIdkHp9+AKUewsGdWc1OUNVE35FuI9/jCP 34S+piQIpzgepJTjP+1llreqHd2Oduv6C0vr06X+4vuxT/rd2CdtY59lS2Cv jTWWwOSWwH5kS1DbWQL7biyBPc0S1NfmGktQ5ZagvljC3BLU78YS1DaWcI3l Ks7O0RbGgDVdGt7z8csdalOmAuO8zXf7PW86u0lCfvduoOTEYYMDQkunKZ5W SqcZnlZLp1U8DbHl7M3b9ydnv5CT831eNZ1c/p70rgIxMwJqt3DCq0wcVYUi /WaKdcAkRRE9MBHvDipkpMzZ56OvQtgRVqkgBa0p+tpfCFY7EayWBbNOBLO5 YCxvgPZm0Thzzh13Gnqhvw83dxcuch+qCDiq/Kjxo86PJj/a/EiRSN2n/Kjx o86PpjgvfqBM/FHFH0GHkwMo4yiMC2D7jB9VftT4UdAY/Gjyo8WPtuDKmAU3 FexU8FMhgOpkEqWYu05E/QuNdn1yenzpZJHjQHlQKYFrpgcM/7CDfdqbzMYD 8EEw7NMLbCWSQKHKp79So7/0a950OCqQz3JYQ6Q2IWJFojzXRis4EZV+X/4P xxDnwxTZKTzMJZJXCj7+Oc7cPWPDUOEUDCf0kW6V4igYhfcBVMHXj9MA056V X99fXy0iT/7rMjLlQfqdolC6zAm0Y/cBCP0wDnjZsSgtkb5AewF3IxxPR8EY qHCOilIgyJsgG1pFIRngsjJM3gzA78aDMI358NK8CbgNLGso5i/1yNkleR/d YidATqGPg84kBFe8vCQX0YhcpW4KjZakvOXIR+DF+NwTkyj5REpC+cy9/KAs f8kOCtDjxL13BP4Xfp3T0/lBtXti/mZTegr0akt9tJb0ekt6o7n+GupvtpRv tZCP7Wm3lO+2pB/M9VkAK9mHgj46Xq/XXH8d9feb0xsoP2hBj/KHzelNuhyl 1DVR6qhhlDr6saOUpBlKUepoa1GqoVWadhal2lg9ay7fyqNUU3r7m0apWn3s p0Wpevl5lGpI/4ZmUaopvZ1FqTb6ey3p/Zb0QUv6YSv6pSjF1kSpw4ZR6vDH jlKSZihFqcPvJpdqG6Xa0H+PuVQb+k2iVBv6b5FL/f+JUuhMUOFD4cof30Od mDh4UiH7/yKKw/AzFZ8pfjbEZwM/W+KzxWlyIk4FRaj4JvjV7JvKv2nZN41/ 07NvOv/GxVOH60Ut8UXIsMUXLoIx8YVrwTTxhavBdPHF5l8yaXQeVtb+yx5n iafio8UUCnygEi897e73vKUhwiWSPMT3+XiXhxP1SDINAp+EiXiareCOVKe/ /p3T4cowZDBLisS23TcMmwpSbzrjj2Q5DQRi28bf9gh/yAMlvm2rqsUfF/3P tYLrBBmWtXdNHdM2VU3bO3KMvStHUO0dOoL7X0IqrZPKqdRGVKyBhnRVQ922 wFZBQ8pkKuK48iqDaluGbiCDVcGgrjIgCbOAQUrv5U8ur68OSfL4f+1dXXPa RhR916/YvsEUySsJsGHGnWJwYjXBIcZJk+l0GIEUoxokjT6C007/e8/ZFYIk tf3Wvug+MEh7tXd32bv3rPbsEq/WWRJHf2pqiL/KkjxXtBoEZD/P+fLnV7/e NLHD1wVfhy2igFwB7hY5F/IhbBujzeb4feaaC67sXKJWN2ZjD/Fz7ClaLcLZ 56giZNuyOktNkTk+BWf2qqP3i6OfnDv6Qd1HuaAa3ZU6PooCQEDYVcZZsqQG Daz9LNj5WWXSu4sTxdW4GN1I01WvjiaXzKrIEr0XUg7lJ6vKaBLlqwTRm2Tt EInsq/KpNFVA86f960GB6B3nXPYditaF7Hh2ZybbdEun/4yms9e0n9O0e7Wq /ZSqfWz+yYLax+bPnte0tebgKU3n2Hr3Gc3autOrKPvXl7ddS5/2p284Vte4 8HnKXZni55/vkEPoi3dxpNBW8YWv79OSEGuerKIQN5CHa0l38PUSy82tiMNi E8UYgOC/YWEALOlVhvt856eB4W/2hGLX0exkxR/AxXKdH2jRLBtfMlakF7FM yhg+YPySlNypy+WKCzXOTUIeBiCCjEXFUOtzl5IX5wWUlFl1WkFrlaRfgOHW hWiN2xxF+iK5j7Kft0nsB1a+W1pB2LaM+UtP7QjOYz/N10lhVrsauOHAlGem 7C943l9/8e52LHZRsRaj8etcUaiDcFnWayl1Rm955gEwZIyaEtmKvFzqvZAH ctJsfuKIaVLmIeBlVlhGWnwh97vPH+BhcCZwndceyszDDC2+r/Oet9mzZG9F npG0TXmK0rZ1Caej64+L2Zsb4Pj51ejmcsFOMr+88UavF3TqfZHrpZbZzZsT ksPEdVjskgxtrA2Zx6asrmve28b40K4r1a4D1VZ63Qa9JksTPaZYRlisj0kI 31kZ6/fi0DWKO9daDT/bVk+0pmTQCAchgBm3mQ1mHLfRXRK74rcUvStOWhfj 6aB3Kt2Ri66OEVAgZ0fMrj62eLf9u2ihph949izC4LDfNTEXQHElS6BKwd5/ Ky7R5TJ0YDVwDYb95bCv/p0rPKVZ5z83e2Ysk5iMRLaG6opSNa90HVm3jNy3 TKWrAkmrPRRhxHzFNoq48gaH8rN0obDHZ3L44XXqRrqAi/JsuW0SlIg+qJu/ DfnOX2xLxoqQYIJER1LUEua5i9BXK3PoZAhRXNjQvD6hvL86KTb/gbs396pW 8VAoz4Ym0oF+mCDr+Rt8gT02KQsx9TydEYoeFSrMdLj8RAcXS3/jxyu1JTIj E9RUIapdsSsfzXN0MzvKzpiP597BHffedFOFT0ANC5j2HnkOVW1IH+URpeFK nOQwd4IUBGa0jpkLE+PdKo8WBGF+4Kcw3NF/4qKWAl+Uym2ms1tB1vLeFkAc PEn++IgXOeI1Soh5aLQ69iRjmxbMhb7EoVeNrlGykmLJepWpwYuh6LljG12F G2FTX/FPMfc+/6t6KMn+PmRkq6JVBdfs2g5uRnoYJVg5qoFqtyuizW+rwSaQ mGpr+yh8VYSOeLFDu54rymko5bqjBrr8HE499R/enjsOEB+GJXwxBCbUccBl dGTw+s1LRDUMjgG3tDIv4SmmbyXIlbc5WaneXghgCc7mzdGKmEn8q4yuUQVV j6z+ueWx6YpPLGrTTm/mdgc9X8zpepwOadOC8/7a9GHd/VF5xPSoKHy1NYdt KIIoR4cKfAI31ajAw2s/JnMUX6OAn5syFlJ34kDHQDwwFKe2HPRZxp7tmCQ9 inWwy+CFXGDMRcvtdyV+7gtSKRGYFdxT2HVo6AzIpeWHY2x5ulAUh34GUJbl iJSKw3zkWX4u4gxAkZqZH8HtnlR0akX7aUW3Vuw9rdg1lNJQbEM/18RhVZm8 3G55oWZBJGWf4VHdGfA7OZjOWDyOZnpxgoZhuuvsFZBunzpnlvwqPfU8bwHc rtJd2+1+n77Ybh8ezT/tVck63R0cp1d1KBUS/wSgo19S1TZb3xhsq+bZkoye +ojwTzbRqVYO9t4qrYEE+JuOPiymk8Xk8v38HFADjjhZzC8WE2/+Cjf0Q6Oy SPSgrrDdyJsIdY4mBu6tPqAzydALOVflNWeh+3uTN9eXlkGgOaww5u14duLN OKqqEKAxqIE7cJoiWSUbTI288XTWEe8m+IA6EsnzLpX17zi/mG2c2QPAxpI4 Exis332lSL4GHh2Kq1rzGDqJVpjzZpTT1/bUYh57oHjH7arExF2YZW19RByN Y3MW/ISU/ANq1lWwjPs/NCiF81Zg19J8l6gQdbjt0QURmXLj8sOta/JoK3Xu F7Hu4WQaBdgUeRn3SQSvYtr7F/OhmFb66ryyVvhQuEePEn/4mBhuvmCwzsJQ U2/VQdwV53xbsdTJLP+U0S9YEgGQCmRholtYNqkMA+64ZdxXEYgkXR6WY7c7 h2Nyqvoao0ABAEwXUoyQGHe6pw7GLVyaeUomUyvNooQbToRpt5sDARpppJFG GmmkkUYaaaSRRhpppJFGGmmkkUYaaeT/lX8AjmI5xABAAQA= --------------480239510F037DC09DE13966-- From owner-linux-xfs@oss.sgi.com Mon Nov 17 10:11:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 10:11:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHIB325008916 for ; Mon, 17 Nov 2003 10:11:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHIB3PZ008914 for linux-xfs@oss.sgi.com; Mon, 17 Nov 2003 10:11:03 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAHIB027008900 for ; Mon, 17 Nov 2003 10:11:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAHHH06o006683; Mon, 17 Nov 2003 09:17:00 -0800 Date: Mon, 17 Nov 2003 09:17:00 -0800 Message-Id: <200311171717.hAHHH06o006683@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1034 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 484 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 ------- Additional Comments From sandeen@sgi.com 2003-17-11 09:17 PDT ------- If you could verify this on a cvs xfs kernel from oss.sgi.com, that would be helpful - the xfs code in ac3 is pretty old these days. If CVS is difficult, there are also snapshot patches on the oss.sgi.com ftp site. Thanks, -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 17 15:06:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 15:07:18 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAHN6n25018547 for ; Mon, 17 Nov 2003 15:06:50 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAHNQuHc006485 for ; Mon, 17 Nov 2003 17:26:56 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAHN6hP513723940 for ; Mon, 17 Nov 2003 17:06:43 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAHN6eRn320913324; Mon, 17 Nov 2003 17:06:40 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hAHN6TdK025815; Mon, 17 Nov 2003 17:06:29 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hAHN6T8Q025813; Mon, 17 Nov 2003 17:06:29 -0600 Date: Mon, 17 Nov 2003 17:06:29 -0600 From: Eric Sandeen Message-Id: <200311172306.hAHN6T8Q025813@penguin.americas.sgi.com> Subject: PARTIAL TAKE 904615 - fix up bh macros for < 2.4.22 X-archive-position: 1035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 682 Lines: 24 BH_Sync added in 2.4.22, put an #ifdef in for now so this still works on older kernels. These #ifdef KERNEL_VERSION_CODE lines will be weeded out eventually, for now it's convenient to be able to support 1 kernel version back without code modifications whenever possible. Date: Mon Nov 17 15:05:35 PST 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-oss Inspected by: felixb Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-kern:slinx:161964a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:161964a pagebuf/page_buf.h - 1.73 - Merge of 2.4.x-xfs-kern:slinx:161964a by sandeen. From owner-linux-xfs@oss.sgi.com Mon Nov 17 16:31:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 16:31:26 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAI0V325022860 for ; Mon, 17 Nov 2003 16:31:06 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAHMb7OO003875 for ; Mon, 17 Nov 2003 14:37:08 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAI0SXKe002128 for ; Tue, 18 Nov 2003 11:28:33 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAI0SXRr002127 for linux-xfs@oss.sgi.com; Tue, 18 Nov 2003 11:28:33 +1100 Date: Tue, 18 Nov 2003 11:28:33 +1100 From: Nathan Scott Message-Id: <200311180028.hAI0SXRr002127@bruce.melbourne.sgi.com> Subject: TAKE - set pagebuf lock tracking via debug X-archive-position: 1036 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 592 Lines: 20 Date: Mon Nov 17 16:28:45 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161981a linux/fs/xfs/linux/Makefile - 1.196 linux/fs/xfs/Makefile - 1.55 linux/fs/xfs/pagebuf/Makefile - 1.22 - Enable pagebuf lock tracking via debug. linux/fs/xfs/pagebuf/page_buf.h - 1.74 - Remove comment about pagebuf lock tracking - this is set via the debug config option now. Remove an unused type. linux/fs/xfs/xfsidbg.c - 1.245 - Simplify pagebuf lock tracking diagnostics. From owner-linux-xfs@oss.sgi.com Mon Nov 17 23:24:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Nov 2003 23:25:01 -0800 (PST) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAI7OP25001701 for ; Mon, 17 Nov 2003 23:24:25 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAI1YYq0012258 for ; Mon, 17 Nov 2003 17:34:35 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAI1W7Ke003014 for ; Tue, 18 Nov 2003 12:32:07 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAI1W6Gp003013 for linux-xfs@oss.sgi.com; Tue, 18 Nov 2003 12:32:06 +1100 Date: Tue, 18 Nov 2003 12:32:06 +1100 From: Nathan Scott Message-Id: <200311180132.hAI1W6Gp003013@bruce.melbourne.sgi.com> Subject: TAKE - backport some 2.6 changes and fixes X-archive-position: 1037 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2273 Lines: 87 Backport a couple of debugging changes from the 2.6 code base. Date: Mon Nov 17 16:54:21 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161984a linux/fs/xfs/xfsidbg.c - 1.246 Backport minor 2.6 changes to the iomap interface to keep code more in sync. Date: Mon Nov 17 17:02:59 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161987a linux/fs/xfs/pagebuf/page_buf.h - 1.75 linux/fs/xfs/linux/xfs_iomap.c - 1.18 Backport an unmerged bug fix from the 2.6 code base - if probe_unmapped_page fails while walking down the unmapped page list, do not attempt to probe the last page as well, just return. Date: Mon Nov 17 17:13:20 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161992a linux/fs/xfs/linux/xfs_aops.c - 1.56 Backport an unmerged bug fix from the 2.6 code base - only submit a convert_page page for IO if startio is set. Date: Mon Nov 17 17:15:47 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161993a linux/fs/xfs/linux/xfs_aops.c - 1.57 Backport some trivial changes from the 2.6 code base - page uptodate flag macro name changes. Date: Mon Nov 17 17:26:36 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161994a linux/fs/xfs/linux/xfs_linux.h - 1.117 linux/fs/xfs/linux/xfs_aops.c - 1.58 Move Linux-version-specific code out of xfs_iomap.c so that it can become part of the common XFS core code. Date: Mon Nov 17 17:30:09 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:161995a linux/fs/xfs/linux/xfs_super.h - 1.54 linux/fs/xfs/linux/xfs_super.c - 1.276 linux/fs/xfs/linux/xfs_iomap.c - 1.19 From owner-linux-xfs@oss.sgi.com Tue Nov 18 00:29:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 00:29:33 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAI8T825005754 for ; Tue, 18 Nov 2003 00:29:09 -0800 Received: from online.no (29.80-203-65.nextgentel.com [80.203.65.29]) by mail.broadpark.no (Postfix) with ESMTP id C9ED379287 for ; Tue, 18 Nov 2003 09:29:00 +0100 (MET) Message-ID: <3FB9D8A2.2030006@online.no> Date: Tue, 18 Nov 2003 09:30:26 +0100 From: Knut J Bjuland User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, nb MIME-Version: 1.0 To: XFS List Subject: redhat 9 installer is missing from 1.3.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs Content-Length: 230 Lines: 6 Is it possible to add respin the xfs installer for redhat 9 or upload the srpm and script to repsin the installer yourself? Can I replace the kernel in redhat 9 with the one from fedora test to gain support for sata hardisk? From owner-linux-xfs@oss.sgi.com Tue Nov 18 02:05:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 02:05:56 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIA5W25009868 for ; Tue, 18 Nov 2003 02:05:33 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id hAIA5Ss1001677 for ; Tue, 18 Nov 2003 11:05:28 +0100 (CET) Received: from gandoliere.imag.fr ([129.88.43.136] helo=gandoliere.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1AM2jg-0001Es-00 for ; Tue, 18 Nov 2003 11:05:28 +0100 To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown (when quota exceeded?) From: Nicolas Kowalski Mail-Copies-To: never Date: Tue, 18 Nov 2003 11:05:27 +0100 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 1039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 694 Lines: 22 Hello. On a NFS fileserver exporting users home directories, running SGI-XFS CVS-2003-09-24_05:00_UTC (2.4.22), I just experienced a filesystem shutdown: Nov 18 10:03:31 pave kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xc0205b9a Nov 18 10:03:31 pave kernel: Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Nov 18 10:03:31 pave kernel: Please umount the filesystem, and rectify the problem(s) It apparently happened when one user exceeded his quotas. I write "apparently", because I am unsure this is the real reason. Did someone faced something similar ? Thanks. -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Nov 18 05:56:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 05:56:55 -0800 (PST) Received: from star1.q4m.de ([62.116.137.9]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIDuC25021886 for ; Tue, 18 Nov 2003 05:56:14 -0800 Received: from office (pD9E62FF9.dip.t-dialin.net [217.230.47.249]) (authenticated bits=0) by star1.q4m.de (8.12.8/8.12.8) with ESMTP id hAIFCQuF027164 for ; Tue, 18 Nov 2003 15:12:27 GMT From: joerg@mayer-electronic.de To: linux-xfs@oss.sgi.com Date: Tue, 18 Nov 2003 14:56:11 +0100 MIME-Version: 1.0 Subject: XFS Filesystem recovery - urgent! Message-ID: <3FBA330B.27669.132A460@localhost> Priority: urgent X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=ISO-8859-1 Content-description: Mail message body Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id hAIDuE25021887 X-archive-position: 1040 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joerg@mayer-electronic.de Precedence: bulk X-list: linux-xfs Content-Length: 1258 Lines: 53 Hello, we had a major crash after data saving on a Redhat Linux machine. We need urgently some deeper information about the XFS filesystem. The log of the datasaving shows: session 2: mount point: server:/daten device: server:/dev/md1 time: Sat Nov 8 23:59:51 2003 session label: "Backup-daten" session id: aa74565f-341f-4967-9267-cb874453fcc0 level: 0 resumed: NO subtree: NO streams: 1 stream 0: pathname: /daten2/Backup/backup-daten start: ino 0 offset 0 end: ino 0 offset 0 interrupted: YES media files: 0 xfsdump: Dump Status: SUCCESS The xfsdump was running, but the whole INO table of the harddisk is completely gone. We have some detailed questions about the filesystem: How can we find the session ID aa74565f-341f-4967-9267-cb874453fcc0 on the deleted harddisk? How is the ID compressed on the disk? How is the filesystem info at the beginning of the dump compressed? (We can find the data, but we can't read the directory data of the dump) Are the INO's of the harddisk saved into the backup, too? Thanks a lot Best regards Joerg Mayer Mayer Electronic GbR Münchinger Str. 11 70825 Korntal Germanymailaddress: mayer@mayer-electronic.de internet address: http://www.mayer-electronic.de From owner-linux-xfs@oss.sgi.com Tue Nov 18 06:39:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 06:40:03 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIEdd25024706 for ; Tue, 18 Nov 2003 06:39:40 -0800 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id hAIEcusV024905 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 Nov 2003 00:38:58 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.10/8.12.10) with ESMTP id hAIEbwtD024651; Tue, 18 Nov 2003 09:37:58 -0500 Date: Tue, 18 Nov 2003 09:37:58 -0500 (EST) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: joerg@mayer-electronic.de cc: linux-xfs@oss.sgi.com Subject: Re: XFS Filesystem recovery - urgent! In-Reply-To: <3FBA330B.27669.132A460@localhost> Message-ID: References: <3FBA330B.27669.132A460@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 888 Lines: 24 On Tue, 18 Nov 2003 joerg@mayer-electronic.de wrote: > The xfsdump was running, but the whole INO table of the harddisk is If I had a crash like this I wouldn't trust the filesystem anymore. I'd be remaking the filesystem (mkfs.xfs) and recovering from backups. > Are the INO's of the harddisk saved into the backup, too? I'm no FS guru and I'm not sure what an INO is - is it some structure related to inodes? Anyway, SGI (I understand) official recommends doing backups with xfsdump. This stores extended attribute info as well as other info associated with the file. If you use another tool for the backups (eg, tar) then you should still get back basic file info. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Tue Nov 18 06:42:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 06:43:10 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIEgv25025115 for ; Tue, 18 Nov 2003 06:42:58 -0800 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id hAIEgesV024947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 Nov 2003 00:42:43 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.10/8.12.10) with ESMTP id hAIEfhtD024689; Tue, 18 Nov 2003 09:41:43 -0500 Date: Tue, 18 Nov 2003 09:41:43 -0500 (EST) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: joerg@mayer-electronic.de cc: linux-xfs@oss.sgi.com Subject: Re: XFS Filesystem recovery - urgent! In-Reply-To: <3FBA330B.27669.132A460@localhost> Message-ID: References: <3FBA330B.27669.132A460@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1042 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 1027 Lines: 30 On Tue, 18 Nov 2003 joerg@mayer-electronic.de wrote: > xfsdump: Dump Status: SUCCESS > > The xfsdump was running, but the whole INO table of the harddisk is > completely gone. We have some detailed questions about the Ok, I was half asleep when I posted a minute ago... Have you used xfsrestore -if $xfsdumpfile to look inside the file to see if the data is intact. It isn't enough to run backups, it is necessary to check them regularly to make sure you can get good data out. If the most recent xfsdump is corrupt then look at the one taken previously. > How is the filesystem info at the beginning of the dump compressed? > (We can find the data, but we can't read the directory data of the > dump) Developers looking at the problem will probably want the kernel version & version of xfs in use as well. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Tue Nov 18 06:48:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 06:48:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIEmL25025871 for ; Tue, 18 Nov 2003 06:48:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAIF8UHc013878 for ; Tue, 18 Nov 2003 09:08:30 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAIEmFP513645071; Tue, 18 Nov 2003 08:48:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAIEmCK26939014; Tue, 18 Nov 2003 08:48:12 -0600 (CST) Date: Tue, 18 Nov 2003 08:48:15 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: joerg@mayer-electronic.de cc: linux-xfs@oss.sgi.com Subject: Re: XFS Filesystem recovery - urgent! In-Reply-To: <3FBA330B.27669.132A460@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by tolkor.sgi.com id hAIF8UHc013878 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAIEmL25025872 X-archive-position: 1043 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1732 Lines: 69 I'm not an xfsdump wizard, but let me try to clarify what happened. Was the problem with xfsdump, or with the live filesystem? Did the filesystem crash -while- you were running xfsdump? Are you trying to restore a good backup after a system crash? I'm not exactly sure what problem you are having. -Eric On Tue, 18 Nov 2003 joerg@mayer-electronic.de wrote: > Hello, > > we had a major crash after data saving on a Redhat Linux machine. We > need urgently some deeper information about the XFS filesystem. > > The log of the datasaving shows: > > session 2: > mount point: server:/daten > device: server:/dev/md1 > time: Sat Nov 7 23:59:51 2003 > session label: "Backup-daten" > session id: aa74565f-341f-4967-9267-cb874453fcc0 > level: 0 > resumed: NO > subtree: NO > streams: 1 > stream 0: > pathname: /daten2/Backup/backup-daten > start: ino 0 offset 0 > end: ino 0 offset 0 > interrupted: YES > media files: 0 > xfsdump: Dump Status: SUCCESS > > The xfsdump was running, but the whole INO table of the harddisk is > completely gone. We have some detailed questions about the > filesystem: > > How can we find the session ID aa74565f-341f-4967-9267-cb874453fcc0 > on the deleted harddisk? > > How is the ID compressed on the disk? > > How is the filesystem info at the beginning of the dump compressed? > (We can find the data, but we can't read the directory data of the > dump) > > Are the INO's of the harddisk saved into the backup, too? > > > Thanks a lot > > Best regards > > Joerg Mayer > Mayer Electronic GbR > Münchinger Str. 11 > 70825 Korntal > Germanymailaddress: mayer@mayer-electronic.de > internet address: http://www.mayer-electronic.de > > > From owner-linux-xfs@oss.sgi.com Tue Nov 18 08:11:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 08:11:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAIGB725030448 for ; Tue, 18 Nov 2003 08:11:07 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAIGB7AY030447 for linux-xfs@oss.sgi.com; Tue, 18 Nov 2003 08:11:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAIGB527030433 for ; Tue, 18 Nov 2003 08:11:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAIFQ8dO026846; Tue, 18 Nov 2003 07:26:08 -0800 Date: Tue, 18 Nov 2003 07:26:08 -0800 Message-Id: <200311181526.hAIFQ8dO026846@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1366 Lines: 40 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 ------- Additional Comments From stefan.hagendorn@lindy.cc 2003-18-11 07:26 PDT ------- Hi, I just updated the Kernel to 2.4.23-rc1 with the xfs snapshot from 11/11/2003. The behavior changed a bit .. the errors are reduced but still there: [root@mss archive]# dd if=/dev/zero of=testfile1 bs=1M count=200 200+0 Records in 200+0 Records out [root@mss archive]# dd if=/dev/zero of=testfile2 bs=1M count=200 200+0 Records in 200+0 Records out [root@mss archive]# compare testfile1 testfile2 files differ at byte 59244560 (0x3880010) 0x7f != 0x00 ^? ^@ [root@mss archive]# compare testfile1 testfile2 files differ at byte 94699536 (0x5a50010) 0x7f != 0x00 ^? ^@ [root@mss archive]# compare testfile1 testfile2 files differ at byte 71237648 (0x43f0010) 0x7f != 0x00 ^? ^@ [root@mss archive]# compare testfile1 testfile2 files differ at byte 23658512 (0x1690010) 0x7f != 0x00 ^? ^@ [root@mss archive]# compare testfile1 testfile2 files differ at byte 23658512 (0x1690010) 0x7f != 0x00 ^? ^@ [root@mss archive]# uname -a Linux mss.lindy.cc 2.4.23-rc1-xfs #4 Die Nov 18 16:06:53 CET 2003 i686 unknown unknown GNU/Linux Thanks Stefan ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 18 09:20:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 09:21:05 -0800 (PST) Received: from mail.bardstown.com (IDENT:+po4YwPUbPGyrP/xQSBbekQbsRtxvMzg@www.bardstown.com [209.215.186.5]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIHKN25007164 for ; Tue, 18 Nov 2003 09:20:44 -0800 Received: from Debug (IDENT:ZseEESwCpQ2bAMckcQxcaiyHkyTgAHZB@mail.bardstown.com [209.215.186.5]) by mail.bardstown.com (8.11.6/8.11.6) with SMTP id hAIHKM221859 for ; Tue, 18 Nov 2003 12:20:22 -0500 Message-Id: <200311181720.hAIHKM221859@mail.bardstown.com> To: linux-xfs@oss.sgi.com From: owen@bardstown.com Subject: Question about mounting Indy disk Date: Tue, 18 Nov 2003 17:20:22 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.33 X-archive-position: 1045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: owen@bardstown.com Precedence: bulk X-list: linux-xfs Content-Length: 476 Lines: 14 You probably hear this thousands of times... sorry ;-(( I read the FAQ, and also another question about this, where it seemed like this may work... I have an old Indy I bought -- sans root password. I want to mount the XFS partition. I put the hard disc in, watch it spin up and Linux recognize the partition. I can mount the 1st and 3rd under EFS, and see nothing but /lost+found. However, when I mount the second, I get a bad magic number error! Any thoughts? -o From owner-linux-xfs@oss.sgi.com Tue Nov 18 09:57:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 09:57:28 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIHv725008085 for ; Tue, 18 Nov 2003 09:57:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAIIHGHc007859 for ; Tue, 18 Nov 2003 12:17:16 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAIHv1P513731643; Tue, 18 Nov 2003 11:57:01 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAIHuwRn350843015; Tue, 18 Nov 2003 11:56:58 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id hAIHv0qn030878; Tue, 18 Nov 2003 11:57:00 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAIHv0ER030879; Tue, 18 Nov 2003 11:57:00 -0600 (CST) Date: Tue, 18 Nov 2003 11:57:00 -0600 (CST) Message-Id: <200311181757.hAIHv0ER030879@zhadum.americas.sgi.com> From: Glen Overby To: owen@bardstown.com Cc: linux-xfs@oss.sgi.com Subject: Re: Question about mounting Indy disk In-Reply-To: message from owen@bardstown.com sent 18 November 2003 References: <200311181720.hAIHKM221859@mail.bardstown.com> X-archive-position: 1046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 895 Lines: 30 On November 18, owen@bardstown.com wrote: > You probably hear this thousands of times... sorry ;-(( > > I read the FAQ, and also another question about this, where it seemed like > this may work... I have an old Indy I bought -- sans root password. I want to > mount the XFS partition. > > I put the hard disc in, watch it spin up and Linux recognize the partition. I > can mount the 1st and 3rd under EFS, and see nothing but /lost+found. However, > when I mount the second, I get a bad magic number error! > > Any thoughts? sounds like slice 2 was your swap partition. By convention: 0 is root 2 is swap 7 is an option drive 8 is the fx volume header 10 is the entire volume I'm not sure what partition is used for split root and /usr. Are you sure that your old indy was using XFS for it's filesystems? It sounds like you have some very empty efs partitions on it. Glen Overby From owner-linux-xfs@oss.sgi.com Tue Nov 18 11:11:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 11:11:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAIJB725011268 for ; Tue, 18 Nov 2003 11:11:07 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAIJB7Hb011267 for linux-xfs@oss.sgi.com; Tue, 18 Nov 2003 11:11:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAIJB527011253 for ; Tue, 18 Nov 2003 11:11:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAIICRuT008715; Tue, 18 Nov 2003 10:12:27 -0800 Date: Tue, 18 Nov 2003 10:12:27 -0800 Message-Id: <200311181812.hAIICRuT008715@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 ------- Additional Comments From stefan.hagendorn@lindy.cc 2003-18-11 10:12 PDT ------- I made a mistake ! It still produces AS MANY ERRORS AS BEFORE .. I just forget to issue the '-a' switch to compare the whole file instead of compare till the first difference occoures ! Thanks Stefan ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 18 14:04:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 14:04:46 -0800 (PST) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIM4M25017944 for ; Tue, 18 Nov 2003 14:04:24 -0800 Received: by saytrin (Postfix, from userid 4004) id E1D011B5D; Wed, 19 Nov 2003 00:07:10 +0200 (EET) Date: Wed, 19 Nov 2003 00:07:10 +0200 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: xfs internals Message-ID: <20031118220710.GA8963@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 1048 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-xfs@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 829 Lines: 23 Hello, Is there somewhere a detailed explanation about the internals of xfs programming? I mean, the xfsctl(3) man page explains some concepts, but for others it ends with "The remainder of these operations will not be described further as they are not of general use to applications.". Currently, I'm not sure about the following: - XFS_GET_RESBLKS and XFS_SET_RESBLKS - are these equivalent to ext2's "-r" and "-m" options? - is there a possibility to walk the AGs and query each one in turn (about starting block number, number of blocks, etc.) so that I could find out for each AG the usage and what files have extents in it? - all xfsctl operations require root? Basically, I'm interested in some writing some read-only applications for querying the layout of the filesystem. Thanks, Iustin Pop From owner-linux-xfs@oss.sgi.com Tue Nov 18 14:08:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 14:08:55 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIM8i25018685 for ; Tue, 18 Nov 2003 14:08:44 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAIKEpOO009762 for ; Tue, 18 Nov 2003 12:14:51 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAIM8cP513707024 for ; Tue, 18 Nov 2003 16:08:38 -0600 (CST) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAIM8YRn344021457; Tue, 18 Nov 2003 16:08:34 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hAIM8bIp013687; Tue, 18 Nov 2003 16:08:37 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id hAIM8akL013685; Tue, 18 Nov 2003 16:08:36 -0600 Date: Tue, 18 Nov 2003 16:08:36 -0600 From: Russell Cattelan Message-Id: <200311182208.hAIM8akL013685@chuckle.americas.sgi.com> Subject: TAKE 904127 - Clean up pbmap X-archive-position: 1049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1414 Lines: 54 move the iomap data structures out of pagebuf Date: Tue Nov 18 14:04:32 PST 2003 Workarea: naboo.americas.sgi.com:/go/space/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162048a linux/fs/xfs/xfsidbg.c - 1.247 - Use the new iomap flags and data structures linux/fs/xfs/xfs_iocore.c - 1.46 - Use the new iomap flags and data structures linux/fs/xfs/pagebuf/page_buf.h - 1.76 - Remove old definitions linux/fs/xfs/linux/xfs_lrw.h - 1.39 - Use the new iomap flags and data structures linux/fs/xfs/linux/xfs_lrw.c - 1.205 - Use the new iomap flags and data structures linux/fs/xfs/linux/xfs_vnode.h - 1.87 - Use the new iomap flags and data structures linux/fs/xfs/linux/xfs_aops.c - 1.59 - Use the new flags and data structures linux/fs/xfs/linux/xfs_iomap.c - 1.20 - Use the new iomap flags and data structures Subject: TAKE 904127 - Add new file ... missed in orginal checkin Date: Tue Nov 18 14:07:48 PST 2003 Workarea: chuckle.americas.sgi.com:/go/space/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162050a linux/fs/xfs/xfs_iomap.h - 1.1 - Move iomap definitions to this location. Eventually xfs_iomap.c should move up from linux/xfs_iomap.c so create this file here so it doesn't have to be p_renamed later From owner-linux-xfs@oss.sgi.com Tue Nov 18 14:15:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 14:16:08 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIMFq25019219 for ; Tue, 18 Nov 2003 14:15:57 -0800 Received: (qmail 31663 invoked from network); 18 Nov 2003 21:58:16 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.52.117]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 18 Nov 2003 21:58:16 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AME8U-0005Cl-00; Tue, 18 Nov 2003 23:15:50 +0100 Message-ID: <3FBA9A15.8090203@berdmann.de> Date: Tue, 18 Nov 2003 23:15:49 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: <1068164684.1405.42.camel@stout.americas.sgi.com> In-Reply-To: <1068164684.1405.42.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 1479 Lines: 46 Eric Sandeen wrote: > So I was feeling charitable today... > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > seems to more or less pass our QA suite. It's a hurry-up job though, so > give it some cautious testing if you'd like. [...] Thanks for your work, Eric! This SRPM does not build on FC1: [root@specko root]# rpmbuild --rebuild --target i686 /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.nptl.xfs.src.rpm [...] Building target platforms: i686 Building for target i686 error: Failed build dependencies: gcc32 is needed by kernel-2.4.22-1.2115.nptl.xfs root@specko root]# rpmbuild --nodeps --rebuild --target i686 /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.nptl.xfs.src.rpm [...] CRC32 functions (CONFIG_CRC32) [Y/m/n/?] Hotplug firmware loading support (EXPERIMENTAL) (CONFIG_FW_LOADER) [M/n/y/?] *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you must run 'make dep'. + make -s dep make: gcc32: Command not found make: *** [scripts/mkdep] Error 127 error: Bad exit status from /var/tmp/rpm-tmp.40885 (%build) [...] [root@specko root]# gcc --version gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. From owner-linux-xfs@oss.sgi.com Tue Nov 18 14:47:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 14:47:34 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIMlK25020239 for ; Tue, 18 Nov 2003 14:47:20 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAIKrSOO013244 for ; Tue, 18 Nov 2003 12:53:28 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAIMlEP513756575; Tue, 18 Nov 2003 16:47:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAIMlBK17012617; Tue, 18 Nov 2003 16:47:11 -0600 (CST) Subject: Re: FC1 + XFS 1.3.1: test SRPM available From: Eric Sandeen To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FBA9A15.8090203@berdmann.de> References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FBA9A15.8090203@berdmann.de> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1069195633.14727.177.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 18 Nov 2003 16:47:14 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1051 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1939 Lines: 58 > This SRPM does not build on FC1: Sure it does, just install the gcc32 package... http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/Fedora/RPMS/gcc32-3.2.3-6.i386.rpm -Eric On Tue, 2003-11-18 at 16:15, Bernhard Erdmann wrote: > Eric Sandeen wrote: > > So I was feeling charitable today... > > > > You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > > seems to more or less pass our QA suite. It's a hurry-up job though, so > > give it some cautious testing if you'd like. > [...] > > Thanks for your work, Eric! > > This SRPM does not build on FC1: > > > [root@specko root]# rpmbuild --rebuild --target i686 > /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.nptl.xfs.src.rpm > [...] > Building target platforms: i686 > Building for target i686 > error: Failed build dependencies: > gcc32 is needed by kernel-2.4.22-1.2115.nptl.xfs > > > root@specko root]# rpmbuild --nodeps --rebuild --target i686 > /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.nptl.xfs.src.rpm > [...] > CRC32 functions (CONFIG_CRC32) [Y/m/n/?] > Hotplug firmware loading support (EXPERIMENTAL) (CONFIG_FW_LOADER) > [M/n/y/?] > > *** End of Linux kernel configuration. > *** Check the top-level Makefile for additional configuration. > *** Next, you must run 'make dep'. > > + make -s dep > make: gcc32: Command not found > make: *** [scripts/mkdep] Error 127 > error: Bad exit status from /var/tmp/rpm-tmp.40885 (%build) > [...] > > > [root@specko root]# gcc --version > gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 18 14:51:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 14:51:26 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAIMp225020654 for ; Tue, 18 Nov 2003 14:51:03 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hAIMowp6029028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Nov 2003 23:50:59 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.10/Submit) id hAIMov91029709; Tue, 18 Nov 2003 23:50:57 +0100 Date: Tue, 18 Nov 2003 23:50:57 +0100 From: Axel Thimm To: Bernhard Erdmann Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available Message-ID: <20031118225057.GB26527@puariko.nirvana> References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FBA9A15.8090203@berdmann.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <3FBA9A15.8090203@berdmann.de> User-Agent: Mutt/1.4.1i X-archive-position: 1052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2340 Lines: 76 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2003 at 11:15:49PM +0100, Bernhard Erdmann wrote: > Eric Sandeen wrote: > >So I was feeling charitable today... > > > >You'll find an SRPM in ftp://oss.sgi.com/projects/xfs/testing/FC1 that > >seems to more or less pass our QA suite. It's a hurry-up job though, so > >give it some cautious testing if you'd like. > [...] >=20 > Thanks for your work, Eric! >=20 > This SRPM does not build on FC1: >=20 >=20 > [root@specko root]# rpmbuild --rebuild --target i686=20 > /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.n= ptl.xfs.src.rpm > [...] > Building target platforms: i686 > Building for target i686 > error: Failed build dependencies: > gcc32 is needed by kernel-2.4.22-1.2115.nptl.xfs Please install gcc32-3.2.3-6.i386.rpm found on your third CD. You can also try an rpm from http://atrpms.physik.fu-berlin.de/dist/fc1/kernel/. (there are some additional patches, that cooperate well with XFS). > root@specko root]# rpmbuild --nodeps --rebuild --target i686=20 > /mnt/software/oss.sgi.com/projects/xfs/testing/FC1/kernel-2.4.22-1.2115.n= ptl.xfs.src.rpm > [...] > CRC32 functions (CONFIG_CRC32) [Y/m/n/?] > Hotplug firmware loading support (EXPERIMENTAL) (CONFIG_FW_LOADER)=20 > [M/n/y/?] >=20 > *** End of Linux kernel configuration. > *** Check the top-level Makefile for additional configuration. > *** Next, you must run 'make dep'. >=20 > + make -s dep > make: gcc32: Command not found > make: *** [scripts/mkdep] Error 127 > error: Bad exit status from /var/tmp/rpm-tmp.40885 (%build) > [...] >=20 >=20 > [root@specko root]# gcc --version > gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOS= E. >=20 --=20 Axel.Thimm@physik.fu-berlin.de --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/uqJQQBVS1GOamfERAjmPAKCDYoOXX6ZNk2NY91yUI3yzT4LPlACfW4Af dgVomeMEFfx/jpaHtBjHHyA= =vJ9B -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-linux-xfs@oss.sgi.com Tue Nov 18 15:10:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 15:10:41 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAINAR25021408 for ; Tue, 18 Nov 2003 15:10:30 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hAINALhl025063; Wed, 19 Nov 2003 00:10:21 +0100 Message-ID: <3FBAA769.4000005@stesmi.com> Date: Wed, 19 Nov 2003 00:12:41 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernhard Erdmann CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FBA9A15.8090203@berdmann.de> In-Reply-To: <3FBA9A15.8090203@berdmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 559 Lines: 19 Hi Bernhard. > This SRPM does not build on FC1: > error: Failed build dependencies: > gcc32 is needed by kernel-2.4.22-1.2115.nptl.xfs > make: gcc32: Command not found The error message seems pretty clear to me, but if you DO however have the gcc32 RPM installed then something else is terribly wrong. Maybe you installed it and relocated it elsewhere and the RPM database is nuked? If you did, then symlink the gcc32 starter to the relocated position. However, I do believe it's a simple "read what the error message says" problem... // Stefan From owner-linux-xfs@oss.sgi.com Tue Nov 18 22:11:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Nov 2003 22:11:18 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAJ6B625005489 for ; Tue, 18 Nov 2003 22:11:07 -0800 Received: (qmail 521 invoked from network); 19 Nov 2003 05:53:25 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.52.117]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 19 Nov 2003 05:53:25 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AMLYP-0006ag-00; Wed, 19 Nov 2003 07:11:05 +0100 Message-ID: <3FBB0978.2050106@berdmann.de> Date: Wed, 19 Nov 2003 07:11:04 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: FC1 + XFS 1.3.1: test SRPM available References: <1068164684.1405.42.camel@stout.americas.sgi.com> <3FBA9A15.8090203@berdmann.de> <1069195633.14727.177.camel@stout.americas.sgi.com> In-Reply-To: <1069195633.14727.177.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 179 Lines: 8 Eric Sandeen wrote: [...] > Sure it does, just install the gcc32 package... [...] Thanks for the hint. I did not notice this file before. Now your SRPM builds properly on FC1. From owner-linux-xfs@oss.sgi.com Wed Nov 19 01:11:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 01:11:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJ9BA25011453 for ; Wed, 19 Nov 2003 01:11:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJ9BANT011452 for linux-xfs@oss.sgi.com; Wed, 19 Nov 2003 01:11:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJ9B827011438 for ; Wed, 19 Nov 2003 01:11:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJ8BLPq008004; Wed, 19 Nov 2003 00:11:21 -0800 Date: Wed, 19 Nov 2003 00:11:21 -0800 Message-Id: <200311190811.hAJ8BLPq008004@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 506 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 ------- Additional Comments From olaf@sgi.com 2003-19-11 00:11 PDT ------- To be honest, this smells like a problem with the raid array. If you dd data directly off the device (instead of going through the XFS layers) do you also get inconsistent data back? (Unmount the filesystem first so it doesn't change between the reads.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Nov 19 03:11:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 03:11:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJBBB25015522 for ; Wed, 19 Nov 2003 03:11:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJBBBIP015521 for linux-xfs@oss.sgi.com; Wed, 19 Nov 2003 03:11:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJBB827015507 for ; Wed, 19 Nov 2003 03:11:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJADIXr013147; Wed, 19 Nov 2003 02:13:18 -0800 Date: Wed, 19 Nov 2003 02:13:18 -0800 Message-Id: <200311191013.hAJADIXr013147@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 1056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1960 Lines: 45 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From ja@mail.upjs.sk 2003-19-11 02:13 PDT ------- For your information I catched this bug on 2.6.0-test9 too. I tested CVS snapshot 20031030 and 20031118. Both are affected. I used small (512MB) loop device. # xfs_info /mnt/mnt2 meta-data=/mnt/mnt2 isize=256 agcount=8, agsize=16384 blks = sectsz=512 data = bsize=4096 blocks=131072, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # ./bonnie++ -d /mnt/mnt2 -u 0:0 -s 0 -n 500 Using uid:0, gid:0. Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...Can't delete file UhB4yf70045318 Cleaning up test directory after error. Bonnie: drastic I/O error (rmdir): Input/output error # dmesg Filesystem "loop0": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(loop0,0x8) called from line 1715 of file fs/xfs/xfs_log.c. Return address = 0xc02366ec Filesystem "loop0": Corruption of in-memory data detected. Shutting down filesystem: loop0 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(loop0,0x2) called from line 1297 of file fs/xfs/xfs_log.c. Return address = 0xc02366ec ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Nov 19 11:11:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 11:11:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJJBD25020446 for ; Wed, 19 Nov 2003 11:11:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJJBD7E020445 for linux-xfs@oss.sgi.com; Wed, 19 Nov 2003 11:11:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJJBB27020431 for ; Wed, 19 Nov 2003 11:11:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJIOD8V019207; Wed, 19 Nov 2003 10:24:13 -0800 Date: Wed, 19 Nov 2003 10:24:13 -0800 Message-Id: <200311191824.hAJIOD8V019207@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1057 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 882 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 stefan.hagendorn@lindy.cc changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stefan.hagendorn@lindy.cc 2003-19-11 10:24 PDT ------- OK Olaf was right. I finaly managed to get my testfiles via dd back directly from the array device. The dd'd files show the same problems .. this means it's NOT xfs fault .. The bug can be closed .. Stefan P.S. If anyone who read this have a clue what this can cause and how I may get my data back please let me know .. thanks ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Nov 19 13:11:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 13:11:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJLBC25027317 for ; Wed, 19 Nov 2003 13:11:12 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJLBCcc027316 for linux-xfs@oss.sgi.com; Wed, 19 Nov 2003 13:11:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAJLBA27027302 for ; Wed, 19 Nov 2003 13:11:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAJKw2f7027144; Wed, 19 Nov 2003 12:58:02 -0800 Date: Wed, 19 Nov 2003 12:58:02 -0800 Message-Id: <200311192058.hAJKw2f7027144@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 289] Data corruption on XFS Volume on Raid5 Array X-Bugzilla-Reason: AssignedTo X-archive-position: 1058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1308 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=289 ------- Additional Comments From olaf@sgi.com 2003-19-11 12:58 PDT ------- My guess would be that one of the drives contains bad data, which is somehow not detected by the raid driver. (Lost redundancy?) Check whatever logs are available to see if problems are/were reported for the raid device or disks. If it is a single disk that's "polluting" your reads, you may be able to determine which one and remove it from the raid. At that point you should be able to salvage whatever of your data can be rescued. Basically, you'd have to find ways to remove and place back each disk in turn _without_ having the raid start rebuilding, then do read-only accesses to check whether your data is good for that combination of disks. I don't have enough experience with linux software raid to give concrete instructions for this. Note that even if the raid seems to function fine after removing a disk, you should re-initialize it once you've got your data off. Also note that if you want to mount the XFS filesystem for the tests, use 'ro,norecovery' for the mount options: norecovery means no attempt is made to replay the XFS log. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Nov 19 14:44:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 14:44:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAJMiL25029909 for ; Wed, 19 Nov 2003 14:44:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAJN4YHc008440 for ; Wed, 19 Nov 2003 17:04:35 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAJMgvEU2703115 for ; Thu, 20 Nov 2003 09:42:57 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAJMguft2692418 for linux-xfs@oss.sgi.com; Thu, 20 Nov 2003 09:42:56 +1100 (EST) Date: Thu, 20 Nov 2003 09:42:56 +1100 (EST) From: Nathan Scott Message-Id: <200311192242.hAJMguft2692418@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.23-rc2 X-archive-position: 1059 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1781 Lines: 50 Date: Wed Nov 19 14:37:21 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162136a linux/include/asm-i386/checksum.h - 1.7 linux/fs/inode.c - 1.70 linux/drivers/char/synclink.c - 1.24 linux/arch/i386/kernel/setup.c - 1.71 linux/arch/i386/kernel/io_apic.c - 1.40 linux/Makefile - 1.195 linux/MAINTAINERS - 1.96 linux/drivers/sound/cmpci.c - 1.34 linux/Documentation/kernel-parameters.txt - 1.19 linux/include/linux/pci_ids.h - 1.68 linux/drivers/char/agp/agpgart_be.c - 1.39 linux/arch/i386/kernel/acpi.c - 1.25 linux/arch/i386/kernel/mpparse.c - 1.20 linux/include/asm-i386/io_apic.h - 1.9 linux/drivers/net/tulip/tulip_core.c - 1.45 linux/net/ipv4/netfilter/ip_nat_core.c - 1.15 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.12 linux/arch/i386/kernel/pci-irq.c - 1.27 linux/arch/i386/kernel/dmi_scan.c - 1.18 linux/drivers/net/tg3.c - 1.12 linux/arch/x86_64/defconfig - 1.5 linux/arch/x86_64/ia32/sys_ia32.c - 1.5 linux/arch/x86_64/kernel/Makefile - 1.3 linux/arch/x86_64/kernel/e820.c - 1.5 linux/arch/x86_64/kernel/head.S - 1.5 linux/arch/x86_64/kernel/io_apic.c - 1.5 linux/arch/x86_64/kernel/mpparse.c - 1.4 linux/arch/x86_64/kernel/pci-pc.c - 1.4 linux/arch/x86_64/kernel/setup.c - 1.5 linux/arch/x86_64/mm/fault.c - 1.5 linux/include/asm-x86_64/io_apic.h - 1.4 linux/include/asm-x86_64/checksum.h - 1.3 linux/include/asm-x86_64/apic.h - 1.4 linux/arch/x86_64/kernel/acpi.c - 1.3 linux/drivers/acpi/bus.c - 1.3 linux/drivers/acpi/pci_link.c - 1.3 linux/drivers/acpi/system.c - 1.3 linux/include/asm-x86_64/acpi.h - 1.3 linux/include/asm-i386/acpi.h - 1.3 linux/include/acpi/acpi_bus.h - 1.2 linux/drivers/scsi/megaraid2.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Nov 19 15:50:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 15:50:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAJNoW25030903 for ; Wed, 19 Nov 2003 15:50:33 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAK0AiHc025277 for ; Wed, 19 Nov 2003 18:10:45 -0600 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 KAA03557; Thu, 20 Nov 2003 10:50:23 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAJNoLUc1566386; Thu, 20 Nov 2003 10:50:22 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAJNoTKJ001251; Thu, 20 Nov 2003 10:50:29 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAJNoREN001249; Thu, 20 Nov 2003 10:50:27 +1100 Date: Thu, 20 Nov 2003 10:50:27 +1100 From: Nathan Scott To: Jim Minter Cc: linux-xfs@oss.sgi.com Subject: Re: XFS NULL pointer dereference at virtual address 0000005c Message-ID: <20031119235027.GB930@frodo> References: <200311171321.14257.jim@minter.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311171321.14257.jim@minter.demon.co.uk> User-Agent: Mutt/1.5.3i X-archive-position: 1060 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1621 Lines: 39 On Mon, Nov 17, 2003 at 01:21:14PM +0000, Jim Minter wrote: > I'm getting a kernel oops indicating a null pointer dereference in > xfs_alloc_lookup(). The symptoms are similar in many respects to those > indicated at > http://lists.insecure.org/lists/linux-kernel/2003/Sep/6937.html. There > doesn't seem to be any follow-up to that article, however. That one is quite different. That's a 2.6 kernel, and memory allocation there is done quite differently. Not sure why that one didn't land in my mailbox, but that one is xfs_trans_alloc allocating with __GFP_NOFAIL set, and its returned NULL. So, on first pass that looks like it might be a VM issue. Its on a relatively old 2.6 now too, so possibly its been resolved by other folks already. > What seems to be happening is xfs_alloc_lookup() calls > xfs_btree_read_bufs() to get a new buffer. xfs_btree_read_bufs() returns a > null bp, but doesn't return an error. xfs_alloc_lookup(), doesn't check to > see if bp is null, attempts to dereference it and oopses. Yes, thats does indeed look like it. The simple "put NULL checks all over the place" is not going to be the right fix though, we should be indicating to pagebuf that an allocation is not allowed to fail, and I think it should be making use of support/kmem code in some places that its not. That's going to take some detailed analysis though, I'll need to spend some time on that. > Does anyone have any comments/ideas on this? Are there any obvious > work-arounds? Is the problem simply the lack of null-checking in Unfortunately no obvious work-arounds. Thanks Jim. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 19 18:30:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 18:31:04 -0800 (PST) Received: from sparky.polarisimages.com ([204.193.147.98]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK2UH25007632 for ; Wed, 19 Nov 2003 18:30:38 -0800 Received: (qmail 25649 invoked from network); 20 Nov 2003 02:30:18 -0000 Received: from trane.saiph.com (HELO saiph.com) (204.193.147.16) by sparky.polarisimages.com with SMTP; 20 Nov 2003 02:30:18 -0000 Message-ID: <3FBC281B.30105@saiph.com> Date: Wed, 19 Nov 2003 21:34:03 -0500 From: Laurent Imbaud User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: It just begs the question everywhere: how to move a journaling log to a new device? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1061 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: laurent@saiph.com Precedence: bulk X-list: linux-xfs Content-Length: 1740 Lines: 43 Hello, First, thank you for your excellent software and documentation. I have poured over the white paper, the docs, read the man pages several times and I think I understand well enough what the issues and possibilities are. But I see nowhere a single way of moving the log, say to an external device if disk seek is suspected to be a performance issue, short of backing up the data, doing a new mkfs.xfs and copying back. I tried using the logdev option of mount in the hope that the location could be moved at that point but that was not accepted, given the xfs was created with an internal log. On a related issue, some idea of how big the log should be would be worth documenting more precisely. mkfs.xfs complained the logdev partition was too big in one manipulation, stating a maximum of 12k blocks (forgive me if this is not entirely accurate, I did not write down the exact message). It would seem simple, convenient and desirable for administrators to move the location of the log at anytime, even, while the system is mounted. Solid state disks come cheap nowadays and would make great log devices, especially if one could point and xfs to log there after it has been in production for a while. I would appreciate very much hearing what you think. Hopefully, I have simply missed an obvious thing somewhere. Thank you. -- ============================================================== | Laurent Imbaud, | laurent@PolarisImages.com | | Polaris Images, | (718) 361 6590 | | 259 West 30th Street | www.PolarisImages.com | | New York, NY 10001 | | ============================================================== From owner-linux-xfs@oss.sgi.com Wed Nov 19 19:09:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 19:09:21 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK38u25009787 for ; Wed, 19 Nov 2003 19:08:59 -0800 Received: (qmail 5112 invoked from network); 20 Nov 2003 03:08:55 -0000 Received: from unknown (HELO [192.168.1.100]) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 20 Nov 2003 03:08:55 -0000 Subject: Re: It just begs the question everywhere: how to move a journaling log to a new device? From: Steve Lord Reply-To: lord@xfs.org To: Laurent Imbaud Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FBC281B.30105@saiph.com> References: <3FBC281B.30105@saiph.com> Content-Type: text/plain Message-Id: <1069297762.11773.22.camel@fubar> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 19 Nov 2003 21:09:22 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 5124 Lines: 139 On Wed, 2003-11-19 at 20:34, Laurent Imbaud wrote: > Hello, > > First, thank you for your excellent software and documentation. > > I have poured over the white paper, the docs, read the man pages several > times and I think I understand well enough what the issues and > possibilities are. > > But I see nowhere a single way of moving the log, say to an external > device if disk seek is suspected to be a performance issue, short of > backing up the data, doing a new mkfs.xfs and copying back. > > I tried using the logdev option of mount in the hope that the location > could be moved at that point but that was not accepted, given the xfs > was created with an internal log. > > On a related issue, some idea of how big the log should be would be > worth documenting more precisely. mkfs.xfs complained the logdev > partition was too big in one manipulation, stating a maximum of 12k > blocks (forgive me if this is not entirely accurate, I did not write > down the exact message). > > It would seem simple, convenient and desirable for administrators to > move the location of the log at anytime, even, while the system is > mounted. Solid state disks come cheap nowadays and would make great > log devices, especially if one could point and xfs to log there after it > has been in production for a while. > > I would appreciate very much hearing what you think. Hopefully, I have > simply missed an obvious thing somewhere. > > Thank you. > No, you did not miss the obvious, getting from an internal to an external log and back again is possible, but is somewhat of an arcane art form. First, the XFS superblock contains two bits of information about the log, its block offset and its size. It does not indicate which device it is on. Second, the log does contain some format information which must match up for a log to be recognized as such. Third, xfs_repair can overwrite a log and reformat it to the same state as mkfs would have created. Four, there is a maximum size of log, 32768 filesystem blocks I think - I am writing this without looking at the code... So, when a filesystem is made with the default internal log, the space is carved off one end of an allocation group near the middle of the filesystem. This space is always going to be log space, there is no code to free the space and turn it back into just plain old disk space. So, getting from the internal log to an eternal one: First you should make sure you cleanly unmounted the filesystem. Run xfs_db -r /dev/xxx, inside db do > sb > p this will dump the superblock out, there are two fields in there which represent the start and length of the log in filesystem blocks. Save these numbers. logblocks is the size and logstart is the start offset. Now pick your external log device, choose a starting offset (mkfs for external logs always picks zero), for a solid state device there is no reason not to put several on a single device, but it is probably simplest to partition the device and use small partitions for the logs. The latter would make it easier to keep track of things. Next you need to update the superblock with the new length and offset for the log. xfs_db -x /dev/xxx sb 0 p write logstart XXX write logblocks YYY The -x gives you write access. Now exit xfs_db and run this: xfs_repair -L -l /dev/logdev /dev/xxx This will assume /dev/logdev is where the log lives and initialize it, issuing a stern warning that you are trashing log data. Now mount the filesystem with mount -o logdev=/dev/logdev If I remembered all of that correctly, you should be up and running with an external log. Now for the big fat warning: PRACTICE THIS ON A DEVICE YOU DO NOT CARE ABOUT FIRST!!! You cannot grow the internal log despite what the growfs man page might tell you. You could in theory use a variation on the above to shrink it. You can get back to the internal log by reinserting the old log values, running repair without the -l option and then mounting without the external log option. As for sizing the log, it always seems to be like asking how long a piece of string is. A bigger log means you can keep more metadata in flight before you have to wait for metadata to be flushed before you can write more log records. We refer to this mode of operation as tail pushing - think of the log as being a small train on a circular toy train track. When you are tail pushing, the you have added carriages until the engine is pushing against the caboose (I have a three year old, can you tell ;-) In more technical terms, the amount of metadata update you want to be able to deal with in a burst without the slowdown in throughput caused by tail pushing is the governing factor here. In reality, you can always get into tail pushing mode if you give the fs enough work to do, but for non sustained metadata ops, a larger log should help throughput. The downside of this is recovery time during mount, the larger the log, the longer mount will take. So if you want really fast recovery after a crash, you want a small log. Phew, thats probably more answer than you were expecting. Steve From owner-linux-xfs@oss.sgi.com Wed Nov 19 19:12:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 19:12:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK3Cf25010218 for ; Wed, 19 Nov 2003 19:12:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAK3WuHc003207 for ; Wed, 19 Nov 2003 21:32:56 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAK3CaP513764078; Wed, 19 Nov 2003 21:12:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAK3CXK27189361; Wed, 19 Nov 2003 21:12:33 -0600 (CST) Date: Wed, 19 Nov 2003 21:12:36 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Laurent Imbaud cc: linux-xfs@oss.sgi.com Subject: Re: It just begs the question everywhere: how to move a journaling log to a new device? In-Reply-To: <3FBC281B.30105@saiph.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1293 Lines: 30 On Wed, 19 Nov 2003, Laurent Imbaud wrote: > But I see nowhere a single way of moving the log, say to an external > device if disk seek is suspected to be a performance issue, short of > backing up the data, doing a new mkfs.xfs and copying back. xfs_growfs could gain this feature, patches gladly accepted... :) But, some xfs_db trickery can also do this. I'll follow up with a recipe. > On a related issue, some idea of how big the log should be would be > worth documenting more precisely. mkfs.xfs complained the logdev > partition was too big in one manipulation, stating a maximum of 12k > blocks (forgive me if this is not entirely accurate, I did not write > down the exact message). Yes, there is max log size, if your device is too large you can still use it, just limit the size of the log at mkfs time. > It would seem simple, convenient and desirable for administrators to > move the location of the log at anytime, even, while the system is > mounted. Solid state disks come cheap nowadays and would make great > log devices, especially if one could point and xfs to log there after it > has been in production for a while. I was playing with this once; it is certainly technically possible. However, it's not very high on the priority list at the moment. -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 19 19:55:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 19:55:43 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK3tT25010981 for ; Wed, 19 Nov 2003 19:55:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAK4FhHc000329 for ; Wed, 19 Nov 2003 22:15:43 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAK3tNP513808619; Wed, 19 Nov 2003 21:55:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAK3tKK27174399; Wed, 19 Nov 2003 21:55:20 -0600 (CST) Date: Wed, 19 Nov 2003 21:55:23 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Steve Lord cc: Laurent Imbaud , Subject: Re: It just begs the question everywhere: how to move a journaling log to a new device? In-Reply-To: <1069297762.11773.22.camel@fubar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1007 Lines: 38 On Wed, 19 Nov 2003, Steve Lord wrote: > Next you need to update the superblock with the new length > and offset for the log. > > xfs_db -x /dev/xxx > sb 0 > p > write logstart XXX > write logblocks YYY > > The -x gives you write access. > > Now exit xfs_db and run this: > > xfs_repair -L -l /dev/logdev /dev/xxx > > This will assume /dev/logdev is where the log lives and initialize > it, issuing a stern warning that you are trashing log data. You probably will need to use xfs_db to modify more of the superblocks, or the xfs_repair step will probably revert logstart back to an internal log. The algorithm for which secondary sb's are checked is tricky, so just modify all superblocks by repeating: sb X write logstart 0 write logblocks YYY for all superblocks ("p agcount") will tell you how many to do. Also, I think that steve's suggestion of writing multiple logs to one partition may not work; if logstart!=0 it's assumed to be external, and the logdev option will be rejected. -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 19 20:02:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 20:02:42 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK42V25011430 for ; Wed, 19 Nov 2003 20:02:31 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAK28fOO019005 for ; Wed, 19 Nov 2003 18:08:42 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAK3xwbp018023 for ; Thu, 20 Nov 2003 14:59:59 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAK3xwgi018022 for linux-xfs@oss.sgi.com; Thu, 20 Nov 2003 14:59:58 +1100 Date: Thu, 20 Nov 2003 14:59:58 +1100 From: Nathan Scott Message-Id: <200311200359.hAK3xwgi018022@bruce.melbourne.sgi.com> Subject: TAKE - pagebuf X-archive-position: 1065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1204 Lines: 38 Merge page_buf_locking routines in with the rest of page_buf. Date: Wed Nov 19 18:11:31 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162155a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.40 linux/fs/xfs/pagebuf/Makefile - 1.23 linux/fs/xfs/pagebuf/page_buf.c - 1.140 Change pagebuf to use the same ktrace implementation as XFS, instead of reinventing that wheel. This cleans up a bunch of things - the xfs_buf.h interface becomes now much tidier, and the debugging code that interprets pbtraces is readable now. Date: Wed Nov 19 19:58:20 PST 2003 Workarea: bruce.melbourne.sgi.com:/source1/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162159a linux/fs/xfs/xfsidbg.c - 1.249 linux/fs/xfs/xfs_buf.h - 1.112 linux/fs/xfs/support/debug.h - 1.9 linux/fs/xfs/support/ktrace.c - 1.19 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.30 linux/fs/xfs/pagebuf/page_buf_trace.h - 1.8 linux/fs/xfs/pagebuf/page_buf.c - 1.141 linux/fs/xfs/pagebuf/page_buf.h - 1.77 linux/fs/xfs/linux/xfs_linux.h - 1.118 From owner-linux-xfs@oss.sgi.com Wed Nov 19 20:10:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Nov 2003 20:10:44 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAK4AC25011887 for ; Wed, 19 Nov 2003 20:10:33 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAK4A82e001018 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Nov 2003 23:10:10 -0500 Message-ID: <3FBC3DDB.2060204@coplanar.net> Date: Wed, 19 Nov 2003 23:06:51 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: lord@xfs.org CC: Laurent Imbaud , linux-xfs@oss.sgi.com Subject: Re: It just begs the question everywhere: how to move a journaling log to a new device? References: <3FBC281B.30105@saiph.com> <1069297762.11773.22.camel@fubar> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 2660 Lines: 59 Steve Lord wrote: > As for sizing the log, it always seems to be like asking how > long a piece of string is. > > A bigger log means you can keep more metadata in flight before > you have to wait for metadata to be flushed before you can write > more log records. We refer to this mode of operation as tail > pushing - think of the log as being a small train on a circular > toy train track. When you are tail pushing, the you have added > carriages until the engine is pushing against the caboose (I have > a three year old, can you tell ;-) > > In more technical terms, the amount of metadata update you want > to be able to deal with in a burst without the slowdown in > throughput caused by tail pushing is the governing factor here. > In reality, you can always get into tail pushing mode if you > give the fs enough work to do, but for non sustained metadata > ops, a larger log should help throughput. > > The downside of this is recovery time during mount, the larger > the log, the longer mount will take. So if you want really > fast recovery after a crash, you want a small log. > > Phew, thats probably more answer than you were expecting. Perhaps, but this is really good stuff to know. I'm saving this email in my bag of tricks until such time as it becomes part of the standard documentation. Are you saying the log space is unaccounted space between two AGs, or does it get an extent or is marked in some kind of block bitmap (I really don't know much about XFS data structures). If so, something that comes to mind is, could the log get allocated as an inode or extent? It would make it possible to shift it around and reclaim the space. I guess it would be hard to have an extent on another device (realtime ss excluded) for and external log. xfs_fsr when unmounted? Say an fs grows so much that the log is no longer in the middle, or its size needs to be changed. As for tail pushing, the continuous throughput could be improved by using a ping-pong buffer. 2 log devices, on separate disks. One is written to until it becomes full, then logging switches to the other while the first is read and flushed. This way each device is written then read sequentially, rather than each process fighting the other and the head seeking back and forth to service them. Actually, now that I think of it, the ping-pong thing make it easy to move the log around, resize it (to a different location), etc. while mounted. Setup the new log, wait till old one fills up or force a switch to the new one, flush the old one, then de-allocate it. Now if I only I didn't have to work for a living... Cheers, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Thu Nov 20 09:16:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 09:16:37 -0800 (PST) Received: from mx05.ca.mci.com (mx05.ca.mci.com [142.77.2.25]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKHGD25015402 for ; Thu, 20 Nov 2003 09:16:14 -0800 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx05.ca.mci.com (Postfix) with ESMTP id F021E24800 for ; Thu, 20 Nov 2003 12:16:12 -0500 (EST) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id hAKHFxI27776 for ; Thu, 20 Nov 2003 12:15:59 -0500 Message-ID: <3FBCF711.CBEFC5EE@calibredigital.com> Date: Thu, 20 Nov 2003 12:17:05 -0500 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: immutable bits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 1067 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 12 We converted all our file systems to XFS. On the ext3 file systems we would set the immutable bit on some dirs. Is there something similar I can set on a directory within an XFS filesystem? We don't want folks with root to be able to delete dirs and files without a few extra steps taken. thanks folks, greg From owner-linux-xfs@oss.sgi.com Thu Nov 20 09:33:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 09:33:31 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKHXJ25016461 for ; Thu, 20 Nov 2003 09:33:19 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hAKHaEuW003623; Thu, 20 Nov 2003 12:36:14 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hAKHaE48012355; Thu, 20 Nov 2003 12:36:14 -0500 Date: Thu, 20 Nov 2003 12:36:14 -0500 (EST) From: Net Llama! To: Greg Whynott cc: "linux-xfs@oss.sgi.com" Subject: Re: immutable bits In-Reply-To: <3FBCF711.CBEFC5EE@calibredigital.com> Message-ID: References: <3FBCF711.CBEFC5EE@calibredigital.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 1068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 547 Lines: 16 On Thu, 20 Nov 2003, Greg Whynott wrote: > > We converted all our file systems to XFS. On the ext3 file systems we > would set the immutable bit on some dirs. Is there something similar I > can set on a directory within an XFS filesystem? > > We don't want folks with root to be able to delete dirs and files > without a few extra steps taken. Would chattr work? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Nov 20 09:46:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 09:46:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKHk825017023 for ; Thu, 20 Nov 2003 09:46:09 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAKI6PHc024061 for ; Thu, 20 Nov 2003 12:06:25 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAKHk3P513841288; Thu, 20 Nov 2003 11:46:03 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAKHk0K17088654; Thu, 20 Nov 2003 11:46:00 -0600 (CST) Subject: Re: immutable bits From: Eric Sandeen To: Greg Whynott Cc: "linux-xfs@oss.sgi.com" In-Reply-To: <3FBCF711.CBEFC5EE@calibredigital.com> References: <3FBCF711.CBEFC5EE@calibredigital.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1069350362.29090.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 20 Nov 2003 11:46:03 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 658 Lines: 21 Yes, the latest snapshot code (but not XFS 1.3.1) has this code, courtesy of Ethan Benson. A scan of the archives should turn up more info. -Eric On Thu, 2003-11-20 at 11:17, Greg Whynott wrote: > We converted all our file systems to XFS. On the ext3 file systems we > would set the immutable bit on some dirs. Is there something similar I > can set on a directory within an XFS filesystem? > > We don't want folks with root to be able to delete dirs and files > without a few extra steps taken. > > thanks folks, > > greg -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 20 09:54:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 09:54:30 -0800 (PST) Received: from mx02.ca.mci.com (mx02.ca.mci.com [142.77.2.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKHsH25017506 for ; Thu, 20 Nov 2003 09:54:19 -0800 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx02.ca.mci.com (Postfix) with ESMTP id 9CB955B40C; Thu, 20 Nov 2003 12:54:11 -0500 (EST) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id hAKHrpI31123; Thu, 20 Nov 2003 12:53:51 -0500 Message-ID: <3FBCFFF2.6F8C3F1A@calibredigital.com> Date: Thu, 20 Nov 2003 12:54:58 -0500 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: "Net Llama!" Cc: "linux-xfs@oss.sgi.com" Subject: Re: immutable bits References: <3FBCF711.CBEFC5EE@calibredigital.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 1070 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 1399 Lines: 50 thanks for the reply. chattr works wonders on an ext file system, it is what i spoke of actually. issuing "chattr +i foo" would cause foo to be 'unlinkable' until you issued a "chattr -i foo". i believe this command is only for ext file systems, but i could be wrong. the man page: [root@nova sdc]# man -k chattr chattr (1) - change file attributes on a Linux second extended file system [root@nova sdc]# chattr +i foo/ chattr: Inappropriate ioctl for device while reading flags on test/ [root@nova sdc]# mount |grep sdc /dev/sdc on /export/sdc type xfs (rw) i am looking into the ACL bits now, i was thinking perhaps there was a similar command. thanks Llama, greg "Net Llama!" wrote: > > On Thu, 20 Nov 2003, Greg Whynott wrote: > > > > We converted all our file systems to XFS. On the ext3 file systems we > > would set the immutable bit on some dirs. Is there something similar I > > can set on a directory within an XFS filesystem? > > > > We don't want folks with root to be able to delete dirs and files > > without a few extra steps taken. > > Would chattr work? > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Lonni J Friedman netllama@linux-sxs.org > Linux Step-by-step & TyGeMo http://netllama.ipfox.com -- UNIX is user friendly, it's just selective about who its friends are. From owner-linux-xfs@oss.sgi.com Thu Nov 20 11:08:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 11:09:05 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKJ8X25019215 for ; Thu, 20 Nov 2003 11:08:34 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hAKJ8VrF013691 for ; Thu, 20 Nov 2003 20:08:32 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Nov 2003 20:08:31 +0100 (CET) Received: (qmail 7870 invoked from network); 20 Nov 2003 20:08:31 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 20 Nov 2003 20:08:31 +0100 Subject: Re: immutable bits From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Greg Whynott Cc: Net Llama! , "linux-xfs@oss.sgi.com" In-Reply-To: <3FBCFFF2.6F8C3F1A@calibredigital.com> References: <3FBCF711.CBEFC5EE@calibredigital.com> <3FBCFFF2.6F8C3F1A@calibredigital.com> Content-Type: text/plain Message-Id: <1069355316.1412.1.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 20 Nov 2003 20:08:36 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1071 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 451 Lines: 18 On Thu, 2003-11-20 at 18:54, Greg Whynott wrote: > thanks for the reply. > > chattr works wonders on an ext file system, it is what i spoke of > actually. > > issuing "chattr +i foo" would cause foo to be 'unlinkable' until you > issued a "chattr -i foo". i believe this command is only for ext file > systems, but i could be wrong. > this should definitly work on a xfs filesystem, too - at least it does so here on my system... christian From owner-linux-xfs@oss.sgi.com Thu Nov 20 11:25:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 11:25:31 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAKJP725019715 for ; Thu, 20 Nov 2003 11:25:08 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hAKJP6rF020962 for ; Thu, 20 Nov 2003 20:25:06 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Nov 2003 20:25:06 +0100 (CET) Received: (qmail 8076 invoked from network); 20 Nov 2003 20:25:05 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 20 Nov 2003 20:25:05 +0100 Subject: Re: immutable bits From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Greg Whynott Cc: Net Llama! , "linux-xfs@oss.sgi.com" In-Reply-To: <1069355316.1412.1.camel@bonnie79> References: <3FBCF711.CBEFC5EE@calibredigital.com> <3FBCFFF2.6F8C3F1A@calibredigital.com> <1069355316.1412.1.camel@bonnie79> Content-Type: text/plain Message-Id: <1069356310.1412.4.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 20 Nov 2003 20:25:10 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 660 Lines: 22 On Thu, 2003-11-20 at 20:08, Christian Guggenberger wrote: > On Thu, 2003-11-20 at 18:54, Greg Whynott wrote: > > thanks for the reply. > > > > chattr works wonders on an ext file system, it is what i spoke of > > actually. > > > > issuing "chattr +i foo" would cause foo to be 'unlinkable' until you > > issued a "chattr -i foo". i believe this command is only for ext file > > systems, but i could be wrong. > > > > this should definitly work on a xfs filesystem, too - at least it does > so here on my system... > oops, sorry. Eric is of course right - recent xfs code is needed - , I have had tested this on 2.6 and 2.4.23rc only... Christian From owner-linux-xfs@oss.sgi.com Thu Nov 20 17:52:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 17:52:42 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAL1qM25000445 for ; Thu, 20 Nov 2003 17:52:22 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAKNwPOO005706 for ; Thu, 20 Nov 2003 15:58:33 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id hAL1nddG017246; Fri, 21 Nov 2003 12:49:39 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id hAL1ncBd017245; Fri, 21 Nov 2003 12:49:38 +1100 Date: Fri, 21 Nov 2003 12:49:38 +1100 From: Nathan Scott Message-Id: <200311210149.hAL1ncBd017245@bruce.melbourne.sgi.com> Subject: TAKE 905022 - refcache X-archive-position: 1073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 797 Lines: 26 Seperate the NFS reference cache code out from xfs_rw.c to simplify management of different kernel versions. Date: Thu Nov 20 17:49:22 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162241a linux/fs/xfs/xfs_refcache.c - 1.1 linux/fs/xfs/xfs_refcache.h - 1.1 linux/fs/xfs/Makefile - 1.56 linux/fs/xfs/xfs_rw.h - 1.75 linux/fs/xfs/xfs_rw.c - 1.387 linux/fs/xfs/xfs_vnodeops.c - 1.618 linux/fs/xfs/xfs_vfsops.c - 1.437 linux/fs/xfs/xfs_inode.h - 1.189 linux/fs/xfs/xfs_fsops.c - 1.95 linux/fs/xfs/xfs_rename.c - 1.56 linux/fs/xfs/linux/xfs_lrw.c - 1.206 linux/fs/xfs/linux/xfs_globals.c - 1.62 linux/fs/xfs/linux/xfs_linux.h - 1.119 linux/fs/xfs/linux/xfs_sysctl.c - 1.29 From owner-linux-xfs@oss.sgi.com Thu Nov 20 22:35:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 Nov 2003 22:35:53 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAL6ZW25006228 for ; Thu, 20 Nov 2003 22:35:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAL4fgOO005565 for ; Thu, 20 Nov 2003 20:41:47 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAL6ZGEU1808911; Fri, 21 Nov 2003 17:35:16 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAL6ZBnU2966616; Fri, 21 Nov 2003 17:35:11 +1100 (EST) Date: Fri, 21 Nov 2003 17:35:11 +1100 (EST) From: Nathan Scott Message-Id: <200311210635.hAL6ZBnU2966616@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@engr.sgi.com Subject: TAKE 903908 - fix some quota asserts X-archive-position: 1074 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 435 Lines: 15 Remove assertion that we do not hold a lock - no lock ownership state available. (IRIX-specific stuff) Date: Thu Nov 20 22:33:46 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162250a linux/fs/xfs/quota/xfs_trans_dquot.c - 1.5 linux/fs/xfs/quota/xfs_dquot.c - 1.6 linux/fs/xfs/quota/xfs_qm.c - 1.8 From owner-linux-xfs@oss.sgi.com Fri Nov 21 13:28:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 13:29:06 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALLSi25025935 for ; Fri, 21 Nov 2003 13:28:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hALLn4Hc019624 for ; Fri, 21 Nov 2003 15:49:05 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hALLRcP513936090 for ; Fri, 21 Nov 2003 15:27:38 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hALLRXRn353980666; Fri, 21 Nov 2003 15:27:33 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hALLQZdK025307; Fri, 21 Nov 2003 15:26:36 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hALLQZhq025305; Fri, 21 Nov 2003 15:26:35 -0600 Date: Fri, 21 Nov 2003 15:26:35 -0600 From: Eric Sandeen Message-Id: <200311212126.hALLQZhq025305@penguin.americas.sgi.com> Subject: PARTIAL TAKE 905113 - Fix a few sysctl handlers X-archive-position: 1075 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 682 Lines: 24 Fix a few sysctls - values are all ints, but sysctl table was setting up for longs. Date: Fri Nov 21 13:26:46 PST 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-oss Inspected by: nathans Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-kern:slinx:162285a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:162285a pagebuf/page_buf.c - 1.142 - Merge of 2.4.x-xfs-kern:slinx:162285a by sandeen. Set up sysctl table properly for int values linux/xfs_sysctl.c - 1.30 - Merge of 2.4.x-xfs-kern:slinx:162285a by sandeen. Set up sysctl table and handlers properly for int values From owner-linux-xfs@oss.sgi.com Fri Nov 21 13:33:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 13:33:50 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALLXc25026335 for ; Fri, 21 Nov 2003 13:33:38 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hALLrxHc022844 for ; Fri, 21 Nov 2003 15:53:59 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hALLWWP513997646 for ; Fri, 21 Nov 2003 15:32:33 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hALLWSRn349526181; Fri, 21 Nov 2003 15:32:28 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hALLVUdK025711; Fri, 21 Nov 2003 15:31:31 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hALLVUU7025709; Fri, 21 Nov 2003 15:31:30 -0600 Date: Fri, 21 Nov 2003 15:31:30 -0600 From: Eric Sandeen Message-Id: <200311212131.hALLVUU7025709@penguin.americas.sgi.com> Subject: PARTIAL TAKE 905113 - Fix one more handler in pagebuf X-archive-position: 1076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 534 Lines: 20 Fix the pb stats clear handler, value is int but handler was using ulong Date: Fri Nov 21 13:31:49 PST 2003 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-kern-oss Inspected by: nathans Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-kern:slinx:162287a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:162287a pagebuf/page_buf.c - 1.143 - Merge of 2.4.x-xfs-kern:slinx:162287a by sandeen. Set up pb clear handler properly for int value From owner-linux-xfs@oss.sgi.com Fri Nov 21 13:55:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 13:55:36 -0800 (PST) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALLt425027080 for ; Fri, 21 Nov 2003 13:55:24 -0800 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id 7D2B125537 for ; Fri, 21 Nov 2003 14:54:39 -0700 (MST) Date: Fri, 21 Nov 2003 14:54:40 -0700 From: Michael Loftis To: linux-xfs@oss.sgi.com Subject: logbufs size? Message-ID: <44770656.1069426480@[10.1.2.77]> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 1077 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 629 Lines: 17 OK I see mentions of using a larger log(can't do that...fs is already created...unless there is a way to grow the log area?) and to using more logbufs....but how to tell how many logbufs are currently used/default? I need to do some stopgap measures on our mailserver running XFS until we get our new hardware in. (Yes the box really does need new hardware, I'm not just throwing money at the problem.) TIA! -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Fri Nov 21 13:58:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 13:59:03 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALLwq25027508 for ; Fri, 21 Nov 2003 13:58:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hALMJDHc006193 for ; Fri, 21 Nov 2003 16:19:13 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hALLvkP513988661 for ; Fri, 21 Nov 2003 15:57:46 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hALLvhRn342444505; Fri, 21 Nov 2003 15:57:43 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hALLujdK027211; Fri, 21 Nov 2003 15:56:45 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id hALLujJ6027209; Fri, 21 Nov 2003 15:56:45 -0600 Date: Fri, 21 Nov 2003 15:56:45 -0600 From: Eric Sandeen Message-Id: <200311212156.hALLujJ6027209@penguin.americas.sgi.com> Subject: PARTIAL TAKE 905164 - Document new sysctls X-archive-position: 1078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 474 Lines: 18 Document a few new sysctls Date: Fri Nov 21 13:57:03 PST 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.4.x-xfs/workarea-alwaysclean Author: sandeen Merged by: sandeen Merged mods: 2.4.x-xfs-dev:slinx:162291a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162291a linux/Documentation/filesystems/xfs.txt - 1.16 - Merge of 2.4.x-xfs-dev:slinx:162291a by sandeen. Document a few new sysctls From owner-linux-xfs@oss.sgi.com Fri Nov 21 14:49:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 14:49:49 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALMnX25031196 for ; Fri, 21 Nov 2003 14:49:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hALKtfOO001495 for ; Fri, 21 Nov 2003 12:55:50 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hALMnGEU3122418 for ; Sat, 22 Nov 2003 09:49:16 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hALMnGpo3126336 for linux-xfs@oss.sgi.com; Sat, 22 Nov 2003 09:49:16 +1100 (EST) Date: Sat, 22 Nov 2003 09:49:16 +1100 (EST) From: Nathan Scott Message-Id: <200311212249.hALMnGpo3126336@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.23-rc3 X-archive-position: 1079 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1210 Lines: 35 Date: Fri Nov 21 14:48:42 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162295a linux/drivers/char/serial.c - 1.64 linux/arch/sparc64/kernel/check_asm.sh - 1.7 linux/arch/sparc/kernel/check_asm.sh - 1.8 linux/arch/i386/kernel/setup.c - 1.72 linux/Makefile - 1.196 linux/arch/i386/kernel/pci-pc.c - 1.37 linux/arch/i386/kernel/acpi.c - 1.26 linux/arch/i386/kernel/dmi_scan.c - 1.19 linux/drivers/net/tg3.c - 1.13 linux/arch/ppc64/vmlinux.lds - 1.4 linux/arch/ppc64/mm/fault.c - 1.5 linux/arch/ppc64/kernel/sys_ppc32.c - 1.5 linux/arch/ppc64/kernel/setup.c - 1.5 linux/include/asm-ppc64/unistd.h - 1.3 linux/arch/ppc64/kernel/iSeries_setup.c - 1.5 linux/arch/ppc64/kernel/head.S - 1.5 linux/arch/ppc64/boot/addRamDisk.c - 1.4 linux/arch/x86_64/kernel/e820.c - 1.6 linux/arch/x86_64/kernel/pci-pc.c - 1.5 linux/arch/x86_64/kernel/setup.c - 1.6 linux/arch/ppc64/kernel/cputable.c - 1.2 linux/arch/x86_64/kernel/acpi.c - 1.4 linux/drivers/acpi/pci_root.c - 1.2 linux/include/asm-x86_64/acpi.h - 1.4 linux/drivers/net/bonding/bond_main.c - 1.3 linux/include/asm-i386/acpi.h - 1.4 From owner-linux-xfs@oss.sgi.com Fri Nov 21 15:20:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 15:20:49 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALNKQ25032005 for ; Fri, 21 Nov 2003 15:20:26 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hALLQgOO004383 for ; Fri, 21 Nov 2003 13:26:43 -0800 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 KAA08035; Sat, 22 Nov 2003 10:19:44 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hALNJWUc1647568; Sat, 22 Nov 2003 10:19:33 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hALNJLm71625033; Sat, 22 Nov 2003 10:19:21 +1100 (EST) Date: Sat, 22 Nov 2003 10:19:21 +1100 From: Nathan Scott To: Michael Loftis Cc: linux-xfs@oss.sgi.com Subject: Re: logbufs size? Message-ID: <20031122101921.B1582457@wobbly.melbourne.sgi.com> References: <44770656.1069426480@[10.1.2.77]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44770656.1069426480@[10.1.2.77]>; from mloftis@wgops.com on Fri, Nov 21, 2003 at 02:54:40PM -0700 X-archive-position: 1080 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 615 Lines: 18 On Fri, Nov 21, 2003 at 02:54:40PM -0700, Michael Loftis wrote: > OK I see mentions of using a larger log(can't do that...fs is already > created...unless there is a way to grow the log area?) and to using more No way to do this "online" - would need to dump, mkfs, restore. > logbufs....but how to tell how many logbufs are currently used/default? I 2 is the default, although nowadays its automatically bumped up if you have oodles of memory (iirc). If you are using a non- default value it will show up in /proc/mounts -- e.g. /dev/sdb2 /home xfs rw,usrquota,grpquota,logbufs=8 0 0 cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 21 15:29:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 15:30:14 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALNTp25000371 for ; Fri, 21 Nov 2003 15:29:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hALNoCHc027145 for ; Fri, 21 Nov 2003 17:50:12 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hALNTjP513982634; Fri, 21 Nov 2003 17:29:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hALNTgK27332063; Fri, 21 Nov 2003 17:29:42 -0600 (CST) Date: Fri, 21 Nov 2003 17:29:45 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Michael Loftis cc: linux-xfs@oss.sgi.com Subject: Re: logbufs size? In-Reply-To: <44770656.1069426480@[10.1.2.77]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 818 Lines: 26 Take a look at Documentation/filesystems/xfs.txt for a primer on all the xfs options/sysctls/etc. -Eric On Fri, 21 Nov 2003, Michael Loftis wrote: > OK I see mentions of using a larger log(can't do that...fs is already > created...unless there is a way to grow the log area?) and to using more > logbufs....but how to tell how many logbufs are currently used/default? I > need to do some stopgap measures on our mailserver running XFS until we get > our new hardware in. (Yes the box really does need new hardware, I'm not > just throwing money at the problem.) > > > TIA! > > -- > Undocumented Features quote of the moment... > "It's not the one bullet with your name on it that you > have to worry about; it's the twenty thousand-odd rounds > labeled `occupant.'" > --Murphy's Laws of Combat > > From owner-linux-xfs@oss.sgi.com Fri Nov 21 15:59:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 15:59:34 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hALNxB25001191 for ; Fri, 21 Nov 2003 15:59:13 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:64264 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1ANLAd-0001hc-Co by VAauthid with fixed_plain; Fri, 21 Nov 2003 15:58:39 -0800 Message-ID: <3FBEA6A3.9090706@linux-sxs.org> Date: Fri, 21 Nov 2003 15:58:27 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Michael Loftis , linux-xfs@oss.sgi.com Subject: Re: logbufs size? References: <44770656.1069426480@[10.1.2.77]> <20031122101921.B1582457@wobbly.melbourne.sgi.com> In-Reply-To: <20031122101921.B1582457@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1ANLAd-0001hc-Co 4c47c42e96dfae8ed8a747c1b6ef6d61 X-Spam-Score: -102.6 (---------------------------------------------------) X-archive-position: 1082 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1022 Lines: 30 On 11/21/03 15:19, Nathan Scott wrote: > On Fri, Nov 21, 2003 at 02:54:40PM -0700, Michael Loftis wrote: > >>OK I see mentions of using a larger log(can't do that...fs is already >>created...unless there is a way to grow the log area?) and to using more > > > No way to do this "online" - would need to dump, mkfs, restore. > > >>logbufs....but how to tell how many logbufs are currently used/default? I > > > 2 is the default, although nowadays its automatically bumped up > if you have oodles of memory (iirc). If you are using a non- > default value it will show up in /proc/mounts -- e.g. > /dev/sdb2 /home xfs rw,usrquota,grpquota,logbufs=8 0 0 Just curious, how much is oodles? I've got a box with 12GB that doesn't show any logbufs. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 3:55pm up 23:36, 1 user, load average: 0.15, 0.31, 0.44 From owner-linux-xfs@oss.sgi.com Fri Nov 21 17:34:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 17:35:12 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAM1Yp25006140 for ; Fri, 21 Nov 2003 17:34:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hALNf4OO016521 for ; Fri, 21 Nov 2003 15:41:05 -0800 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 MAA09154; Sat, 22 Nov 2003 12:34:06 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAM1XsUc1690646; Sat, 22 Nov 2003 12:33:55 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAM1XXK41687823; Sat, 22 Nov 2003 12:33:33 +1100 (EST) Date: Sat, 22 Nov 2003 12:33:33 +1100 From: Nathan Scott To: Net Llama! Cc: Michael Loftis , linux-xfs@oss.sgi.com Subject: Re: logbufs size? Message-ID: <20031122123333.A1676816@wobbly.melbourne.sgi.com> References: <44770656.1069426480@[10.1.2.77]> <20031122101921.B1582457@wobbly.melbourne.sgi.com> <3FBEA6A3.9090706@linux-sxs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3FBEA6A3.9090706@linux-sxs.org>; from netllama@linux-sxs.org on Fri, Nov 21, 2003 at 03:58:27PM -0800 X-archive-position: 1083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 20 On Fri, Nov 21, 2003 at 03:58:27PM -0800, Net Llama! wrote: > On 11/21/03 15:19, Nathan Scott wrote: > > > > 2 is the default, although nowadays its automatically bumped up > > if you have oodles of memory (iirc). If you are using a non- > > default value it will show up in /proc/mounts -- e.g. > > /dev/sdb2 /home xfs rw,usrquota,grpquota,logbufs=8 0 0 > > Just curious, how much is oodles? I've got a box with 12GB that doesn't > show any logbufs. > I don't remember off the top of my head - Andi wrote this patch - have a look in xfs_log.c. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 21 18:59:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Nov 2003 18:59:50 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAM2xY25007961 for ; Fri, 21 Nov 2003 18:59:38 -0800 Received: (qmail 10696447 invoked from network); 22 Nov 2003 02:59:28 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 22 Nov 2003 02:59:28 -0000 Message-ID: <3FBECF7E.6010509@kasenna.com> Date: Fri, 21 Nov 2003 18:52:46 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: direct-IO writes strange behavior Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 1383 Lines: 45 Hi, I'm seeing a very strange behavior when I write to a file using 512k direct-io writes. The filesystem is XFS and the kernel is 2.6.0-test9. The first time I do it the 512k writes are broken down into 4k requests and the drives only see these small requests ( a lot of them). The second time (after the data is been written once) the 512k writes are preserved all the way to the drives. Preallocating the space for the file have little impact on this behavior. Here is a more detail description of the two situations first time: - rm /content/file - touch /content/file - xfs_io -c 'resvsp 0 1048576000' /content/file - xfs_bmap /content/file /content/file: 0: [0..2047999]: 348456960..350504959 - perform 2000 sequential direct IO writes onto the file starting from 0 - all the BIOs that are passed to the io-scheduler are 4k long second time: - xfs_bmap /content/file /content/file: 0: [0..2047999]: 348456960..350504959 - perform 2000 sequential direct IO writes onto the file starting from 0 - all the BIOs that are passed to the io-scheduler are 512k long Is this behavior expected on XFS or is this a generic direct-IO related issued? Any information or suggestions would be greatly appreciated? Thanks beto From owner-linux-xfs@oss.sgi.com Sat Nov 22 09:00:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Nov 2003 09:01:08 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAMH0a25028448 for ; Sat, 22 Nov 2003 09:00:37 -0800 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 39FF01830D02; Sat, 22 Nov 2003 17:35:59 +0100 (CET) Date: Sat, 22 Nov 2003 17:35:57 +0100 From: Andi Kleen To: Nathan Scott Cc: netllama@linux-sxs.org, mloftis@wgops.com, linux-xfs@oss.sgi.com Subject: Re: logbufs size? Message-Id: <20031122173557.55913ff0.ak@suse.de> In-Reply-To: <20031122123333.A1676816@wobbly.melbourne.sgi.com> References: <44770656.1069426480@[10.1.2.77]> <20031122101921.B1582457@wobbly.melbourne.sgi.com> <3FBEA6A3.9090706@linux-sxs.org> <20031122123333.A1676816@wobbly.melbourne.sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1086 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 847 Lines: 25 On Sat, 22 Nov 2003 12:33:33 +1100 Nathan Scott wrote: > On Fri, Nov 21, 2003 at 03:58:27PM -0800, Net Llama! wrote: > > On 11/21/03 15:19, Nathan Scott wrote: > > > > > > 2 is the default, although nowadays its automatically bumped up > > > if you have oodles of memory (iirc). If you are using a non- > > > default value it will show up in /proc/mounts -- e.g. > > > /dev/sdb2 /home xfs rw,usrquota,grpquota,logbufs=8 0 0 > > > > Just curious, how much is oodles? I've got a box with 12GB that doesn't > > show any logbufs. > > > > I don't remember off the top of my head - Andi wrote this > patch - have a look in xfs_log.c. Machines with more than 400MB get 8 logbufs with 256K You won't see it in /proc/mounts though because the mechanism is internal in XFS and not visible in the linux mount arguments. -Andi From owner-linux-xfs@oss.sgi.com Sat Nov 22 14:11:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Nov 2003 14:12:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAMMBS25001942 for ; Sat, 22 Nov 2003 14:11:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAMMBSSH001941 for linux-xfs@oss.sgi.com; Sat, 22 Nov 2003 14:11:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAMMBR25001929 for ; Sat, 22 Nov 2003 14:11:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAMM5r0u001905; Sat, 22 Nov 2003 14:05:53 -0800 Date: Sat, 22 Nov 2003 14:05:53 -0800 Message-Id: <200311222205.hAMM5r0u001905@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] New: XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2480 Lines: 80 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 Summary: XFS Kernel Memory Leak Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: condor-sgi@condordes.net This may (or may not) be related to bug 209, but here's what I have... There is a memory leak in the opendir()/readdir()/closedir() code. I've tested this on the following kernels: 2.6.0-test9 2.6.0-test9-mm2 2.6.0-test9-mm5 I noticed this first when locate was updating its database every night... the next morning nearly all available memory would be used and I'd have to reboot the machine to reclaim it. I wrote the following Perl script to test this: ---------------------------------------------- #!/usr/bin/perl open_dir("/"); sub open_dir { my $pwd = shift; opendir(DIR, $pwd); my @dentries = readdir(DIR); closedir(DIR); foreach my $de (@dentries) { next if $de =~ /^\./; print "$pwd$de\n"; if (! -l "$pwd$de" && -d "$pwd$de") { open_dir("$pwd$de/"); } } } ---------------------------------------------- I ran this script on my machine on a fresh boot, and vmstat at the same time, and came up with a very gradual loss of memory (it looks linear in nature to my untrained eye). You can get the entire vmstat log from http://www.condordes.net/~condor/vmstat.log . As a contrast, here's a vmstat row from near the beginning: procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 453992 11056 21288 0 0 776 50 1111 299 1 3 97 0 And here's one towards the end: procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 0 3440 111464 7456 0 0 14 67 1010 42 1 98 1 0 During the run I also ran 'top' to make sure there weren't other processes eating up RAM, so I'm fairly sure most of this lost memory is in kernel space. If you have any additional tests you want me to run, please let me know. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 22 15:28:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Nov 2003 15:28:29 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAMNS825002927 for ; Sat, 22 Nov 2003 15:28:09 -0800 Received: (qmail 10658659 invoked from network); 22 Nov 2003 23:28:02 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 22 Nov 2003 23:28:02 -0000 Message-ID: <3FBFEF6A.3000609@kasenna.com> Date: Sat, 22 Nov 2003 15:21:14 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Nava CC: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> In-Reply-To: <3FBECF7E.6010509@kasenna.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1088 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 2124 Lines: 76 Hi, I've done some more digging on this issue. The reason the request is going in 4k pages is that the direct-io code is giving up in do_direct_IO() and the request is issued as buffer IO :-(. The reason do_direct_IO gives up is because the first call to get_more_blocks() is returning an unmapped buffer header. This is a snip of the code that's failing (look for XXXXX) static int do_direct_IO(struct dio *dio) { const unsigned blkbits = dio->blkbits; const unsigned blocks_per_page = PAGE_SIZE >> blkbits; struct page *page; unsigned block_in_page; struct buffer_head *map_bh = &dio->map_bh; int ret = 0; /* The I/O can start at any block offset within the first page*/ block_in_page = dio->first_block_in_page; while (dio->block_in_file < dio->final_block_in_request) { page = dio_get_page(dio); if (IS_ERR(page)) { ret = PTR_ERR(page); goto out; } while (block_in_page < blocks_per_page) { unsigned offset_in_page = block_in_page << blkbits; unsigned this_chunk_bytes; /* # of bytes mapped */ unsigned this_chunk_blocks; /* # of blocks */ unsigned u; if (dio->blocks_available == 0) { /* * Need to go and map some more disk */ unsigned long blkmask; unsigned long dio_remainder; ret = get_more_blocks(dio); if (ret) { page_cache_release(page); goto out; } if (!buffer_mapped(map_bh)) goto do_holes; XXXXXX ..... do_holes: /* Handle holes */ if (!buffer_mapped(map_bh)) { char *kaddr; /* AKPM: eargh, -ENOTBLK is a hack */ if (dio->rw == WRITE) return -ENOTBLK; XXXXXX Even if I reserve space for the file, the directio IO fails. I tried the same with ext3 and it does perform the directIO on the new file. However, I really disklike the sizes that it's using, it's all over the place 8k, 160, 200k, etc. I really like the 512K requests I'm getting with XFS specially with the 320 SCSI controller I'm using. I'll try looking at the XFS code to see why is returning an unmapped bh, but some help here would be greatly appreciate as I'm not familiar with XFS code. Thanks beto From owner-linux-xfs@oss.sgi.com Sat Nov 22 19:11:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Nov 2003 19:11:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAN3BT25007932 for ; Sat, 22 Nov 2003 19:11:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAN3BT2F007931 for linux-xfs@oss.sgi.com; Sat, 22 Nov 2003 19:11:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAN3BS27007917 for ; Sat, 22 Nov 2003 19:11:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAN35b4N007889; Sat, 22 Nov 2003 19:05:37 -0800 Date: Sat, 22 Nov 2003 19:05:37 -0800 Message-Id: <200311230305.hAN35b4N007889@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 392 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From sandeen@sgi.com 2003-22-11 19:05 PDT ------- Any chance you can try this same test on a non-xfs box? Just to narrow down whether it's xfs that's causing the problem... Thanks, -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 22 20:11:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Nov 2003 20:11:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAN4BT25008771 for ; Sat, 22 Nov 2003 20:11:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAN4BToL008770 for linux-xfs@oss.sgi.com; Sat, 22 Nov 2003 20:11:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAN4BS25008758 for ; Sat, 22 Nov 2003 20:11:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAN43Z7d008698; Sat, 22 Nov 2003 20:03:35 -0800 Date: Sat, 22 Nov 2003 20:03:35 -0800 Message-Id: <200311230403.hAN43Z7d008698@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1090 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 698 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From condor-sgi@condordes.net 2003-22-11 20:03 PDT ------- Sadly (:p), all my machines are XFS. I'll ask around and see if I can find someone who is running 2.6 without XFS and is willing to test this. I think I can also confirm this bug on 2.4.20-xfs-r3 (a Gentoo kernel), as my server has now started exhibiting signs of memory leakage. If I don't find anyone to test this weekend, I'll see about putting a mini-install on my laptop without XFS (I have a spare 1GB partition to play with). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 23 09:34:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Nov 2003 09:35:04 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hANHYb25003390 for ; Sun, 23 Nov 2003 09:34:37 -0800 Received: (qmail 16186 invoked from network); 23 Nov 2003 17:34:35 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 23 Nov 2003 17:34:35 -0000 Message-ID: <3FC0EFEA.5070108@xfs.org> Date: Sun, 23 Nov 2003 11:35:38 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alberto Nava CC: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> In-Reply-To: <3FBFEF6A.3000609@kasenna.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 2807 Lines: 84 Alberto Nava wrote: > Hi, > > I've done some more digging on this issue. The reason the > request is going in 4k pages is that the direct-io code is > giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > The reason do_direct_IO gives up is because the first call to > get_more_blocks() is returning an unmapped buffer header. > This is a snip of the code that's failing (look for XXXXX) > > static int do_direct_IO(struct dio *dio) > { > const unsigned blkbits = dio->blkbits; > const unsigned blocks_per_page = PAGE_SIZE >> blkbits; > struct page *page; > unsigned block_in_page; > struct buffer_head *map_bh = &dio->map_bh; > int ret = 0; > > /* The I/O can start at any block offset within the first page*/ > block_in_page = dio->first_block_in_page; > > while (dio->block_in_file < dio->final_block_in_request) { > page = dio_get_page(dio); > if (IS_ERR(page)) { > ret = PTR_ERR(page); > goto out; > } > > while (block_in_page < blocks_per_page) { > unsigned offset_in_page = block_in_page << blkbits; > unsigned this_chunk_bytes; /* # of bytes mapped */ > unsigned this_chunk_blocks; /* # of blocks */ > unsigned u; > > if (dio->blocks_available == 0) { > /* > * Need to go and map some more disk > */ > unsigned long blkmask; > unsigned long dio_remainder; > > ret = get_more_blocks(dio); > if (ret) { > page_cache_release(page); > goto out; > } > if (!buffer_mapped(map_bh)) > goto do_holes; XXXXXX > > ..... > do_holes: > /* Handle holes */ > if (!buffer_mapped(map_bh)) { > char *kaddr; > > /* AKPM: eargh, -ENOTBLK is a hack */ > if (dio->rw == WRITE) > return -ENOTBLK; XXXXXX > > > Even if I reserve space for the file, the directio IO fails. > > I tried the same with ext3 and it does perform the directIO on the new > file. However, I really disklike the sizes that it's using, it's all > over the place 8k, 160, 200k, etc. I really like the 512K requests I'm > getting with XFS specially with the 320 SCSI controller I'm using. > > I'll try looking at the XFS code to see why is returning an unmapped bh, > but some help here would be greatly appreciate as I'm not familiar with > XFS code. > > Thanks > beto > > This may be an interaction with the unwritten extent handling code. Try this on a file system made with the mkfs option -d unwritten=0. Steve From owner-linux-xfs@oss.sgi.com Sun Nov 23 10:11:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Nov 2003 10:12:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hANIBW25004517 for ; Sun, 23 Nov 2003 10:11:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hANIBWqu004516 for linux-xfs@oss.sgi.com; Sun, 23 Nov 2003 10:11:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hANIBV27004502 for ; Sun, 23 Nov 2003 10:11:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hANHT5kg003353; Sun, 23 Nov 2003 09:29:05 -0800 Date: Sun, 23 Nov 2003 09:29:05 -0800 Message-Id: <200311231729.hANHT5kg003353@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 373 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From sandeen@sgi.com 2003-23-11 09:29 PDT ------- No problem, I can test this on an ext3 box. Just figured if you had one handy you could give it a whirl Thanks, -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 23 15:06:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Nov 2003 15:06:43 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hANN6N25014422 for ; Sun, 23 Nov 2003 15:06:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hANLCkOO029481 for ; Sun, 23 Nov 2003 13:12:47 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hANN6FEU3207947 for ; Mon, 24 Nov 2003 10:06:15 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hANN6EJP3179194 for linux-xfs@oss.sgi.com; Mon, 24 Nov 2003 10:06:14 +1100 (EST) Date: Mon, 24 Nov 2003 10:06:14 +1100 (EST) From: Nathan Scott Message-Id: <200311232306.hANN6EJP3179194@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904566 - backport some 2.6 XFS changes to 2.4 X-archive-position: 1093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2934 Lines: 110 Trivial/whitespace changes to sync up different trees a bit. Date: Thu Nov 20 19:39:35 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162244a linux/fs/xfs/xfs_arch.h - 1.42 linux/fs/xfs/xfs_vfsops.c - 1.438 Move the stack trace wrapper into a kernel-version-specific location. Date: Sat Nov 22 14:07:18 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162318a linux/fs/xfs/xfs_error.h - 1.37 linux/fs/xfs/linux/xfs_linux.h - 1.120 Switch from using dev_t to xfs_buftarg_t for representing the devices underneath XFS. Date: Sat Nov 22 14:22:46 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162319a linux/fs/xfs/xfs_log.h - 1.71 linux/fs/xfs/xfs_log.c - 1.285 linux/fs/xfs/xfs_rw.c - 1.388 linux/fs/xfs/xfs_buf.h - 1.113 linux/fs/xfs/xfs_buf_item.c - 1.146 linux/fs/xfs/xfs_log_priv.h - 1.99 linux/fs/xfs/xfs_da_btree.c - 1.148 linux/fs/xfs/xfs_da_btree.h - 1.57 linux/fs/xfs/xfs_log_recover.c - 1.282 linux/fs/xfs/xfs_vfsops.c - 1.439 linux/fs/xfs/xfs_mount.c - 1.339 linux/fs/xfs/xfs_inode.c - 1.393 linux/fs/xfs/xfs_error.h - 1.38 linux/fs/xfs/xfs_trans_buf.c - 1.116 Merge find_next_zero_bit casting fixes back from 2.6 code. Date: Sat Nov 22 14:44:08 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162321a linux/fs/xfs/xfs_bit.c - 1.25 Abstract sendfile operation out, supporting multiple kernels more easily. Date: Sun Nov 23 13:53:15 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162328a linux/fs/xfs/xfs_vnodeops.c - 1.619 linux/fs/xfs/linux/xfs_linux.h - 1.121 Use xfs_statfs type to statfs operation, to support multiple kernel versions more easily. Date: Sun Nov 23 13:55:17 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162330a linux/fs/xfs/xfs_vfsops.c - 1.440 linux/fs/xfs/linux/xfs_vfs.h - 1.46 linux/fs/xfs/linux/xfs_vfs.c - 1.49 Switch debug quota code to use xfs_buftarg interface instead of dev_t. Date: Sun Nov 23 15:02:53 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162332a linux/fs/xfs/quota/xfs_dquot.c - 1.7 From owner-linux-xfs@oss.sgi.com Sun Nov 23 19:30:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Nov 2003 19:31:09 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAO3Uk25023911 for ; Sun, 23 Nov 2003 19:30:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAO1b8OO020642 for ; Sun, 23 Nov 2003 17:37:11 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAO3UMEU3248504 for ; Mon, 24 Nov 2003 14:30:28 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAO3UMIL3212460 for linux-xfs@oss.sgi.com; Mon, 24 Nov 2003 14:30:22 +1100 (EST) Date: Mon, 24 Nov 2003 14:30:22 +1100 (EST) From: Nathan Scott Message-Id: <200311240330.hAO3UMIL3212460@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Merge up to 2.6.0-test10 X-archive-position: 1094 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 11849 Lines: 330 Date: Sun Nov 23 19:25:17 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:162336a linux/net/socket.c - 1.63 linux/net/sched/sch_tbf.c - 1.16 linux/net/sched/sch_red.c - 1.13 linux/net/sched/sch_prio.c - 1.13 linux/net/sched/sch_generic.c - 1.18 linux/net/sched/sch_fifo.c - 1.9 linux/net/sched/sch_cbq.c - 1.18 linux/net/netlink/af_netlink.c - 1.37 linux/net/irda/irttp.c - 1.28 linux/net/irda/irlmp.c - 1.31 linux/net/irda/irlap.c - 1.28 linux/net/irda/iriap.c - 1.26 linux/net/irda/discovery.c - 1.13 linux/net/irda/af_irda.c - 1.50 linux/net/ipx/af_ipx.c - 1.44 linux/net/ipv6/udp.c - 1.50 linux/net/ipv6/tcp_ipv6.c - 1.62 linux/net/ipv6/sysctl_net_ipv6.c - 1.8 linux/net/ipv6/route.c - 1.42 linux/net/ipv6/mcast.c - 1.36 linux/net/ipv6/ip6_output.c - 1.32 linux/net/ipv6/icmp.c - 1.36 linux/net/ipv6/addrconf.c - 1.47 linux/net/ipv4/udp.c - 1.52 linux/net/ipv4/tcp_ipv4.c - 1.70 linux/net/ipv4/tcp_input.c - 1.57 linux/net/ipv4/tcp.c - 1.62 linux/net/ipv4/route.c - 1.56 linux/net/ipv4/ipmr.c - 1.35 linux/net/ipv4/ip_gre.c - 1.40 linux/net/ipv4/igmp.c - 1.35 linux/net/ipv4/arp.c - 1.35 linux/net/core/sysctl_net_core.c - 1.10 linux/net/core/sock.c - 1.38 linux/net/core/skbuff.c - 1.40 linux/net/core/dev.c - 1.88 linux/net/appletalk/ddp.c - 1.34 linux/mm/swap.c - 1.40 linux/mm/memory.c - 1.115 linux/mm/filemap.c - 1.166 linux/lib/Makefile - 1.27 linux/kernel/signal.c - 1.64 linux/kernel/sched.c - 1.115 linux/kernel/resource.c - 1.28 linux/kernel/module.c - 1.51 linux/kernel/exit.c - 1.77 linux/include/net/tcp.h - 1.52 linux/include/net/if_inet6.h - 1.15 linux/include/linux/udp.h - 1.9 linux/include/linux/times.h - 1.6 linux/include/linux/sysctl.h - 1.79 linux/include/linux/socket.h - 1.16 linux/include/linux/signal.h - 1.16 linux/include/linux/serial.h - 1.20 linux/include/linux/sched.h - 1.115 linux/include/linux/netdevice.h - 1.59 linux/include/linux/ipv6.h - 1.13 linux/include/linux/ip.h - 1.12 linux/include/linux/init.h - 1.29 linux/include/linux/in.h - 1.10 linux/include/linux/blkdev.h - 1.93 linux/include/asm-sparc64/unistd.h - 1.35 linux/include/asm-sparc64/spinlock.h - 1.15 linux/include/asm-sparc64/pgtable.h - 1.44 linux/include/asm-sparc64/namei.h - 1.5 linux/include/asm-sparc64/ioctl.h - 1.4 linux/include/asm-sparc64/hardirq.h - 1.22 linux/include/asm-sparc64/floppy.h - 1.19 linux/include/asm-sparc64/ebus.h - 1.6 linux/include/asm-sparc/unistd.h - 1.33 linux/include/asm-sparc/pcic.h - 1.4 linux/include/asm-sparc/namei.h - 1.5 linux/include/asm-sparc/ioctl.h - 1.5 linux/include/asm-i386/checksum.h - 1.9 linux/include/asm-i386/bitops.h - 1.21 linux/fs/ntfs/Makefile - 1.28 linux/fs/nfsd/vfs.c - 1.73 linux/fs/minix/inode.c - 1.44 linux/fs/lockd/clntlock.c - 1.16 linux/fs/fat/inode.c - 1.64 linux/fs/ext2/ialloc.c - 1.40 linux/fs/ext2/balloc.c - 1.30 linux/fs/dquot.c - 1.75 linux/fs/binfmt_misc.c - 1.32 linux/drivers/scsi/st.c - 1.73 linux/drivers/scsi/sg.c - 1.61 linux/drivers/scsi/scsi_syms.c - 1.38 linux/drivers/scsi/scsi_proc.c - 1.25 linux/drivers/scsi/scsi.c - 1.85 linux/drivers/scsi/megaraid.h - 1.24 linux/drivers/scsi/megaraid.c - 1.54 linux/drivers/scsi/ide-scsi.c - 1.60 linux/drivers/scsi/hosts.h - 1.45 linux/drivers/scsi/hosts.c - 1.53 linux/drivers/scsi/fcal.c - 1.19 linux/drivers/scsi/esp.c - 1.40 linux/drivers/scsi/constants.c - 1.19 linux/drivers/scsi/NCR53C9x.c - 1.30 linux/drivers/pci/quirks.c - 1.45 linux/drivers/net/tlan.c - 1.40 linux/drivers/net/pcnet32.c - 1.49 linux/drivers/net/ethertap.c - 1.16 linux/drivers/net/Space.c - 1.51 linux/drivers/net/3c527.c - 1.27 linux/drivers/net/3c509.c - 1.51 linux/drivers/block/ll_rw_blk.c - 1.144 linux/arch/sparc64/kernel/time.c - 1.42 linux/arch/sparc64/kernel/systbls.S - 1.50 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.65 linux/arch/sparc64/kernel/signal32.c - 1.36 linux/arch/sparc64/kernel/signal.c - 1.34 linux/arch/sparc64/kernel/rtrap.S - 1.20 linux/arch/sparc64/kernel/entry.S - 1.36 linux/arch/sparc64/kernel/ebus.c - 1.23 linux/arch/sparc/kernel/time.c - 1.32 linux/arch/sparc/kernel/systbls.S - 1.35 linux/arch/sparc/kernel/sparc_ksyms.c - 1.42 linux/arch/sparc/kernel/signal.c - 1.37 linux/arch/sparc/kernel/pcic.c - 1.32 linux/arch/sparc/kernel/entry.S - 1.23 linux/arch/ppc/kernel/signal.c - 1.26 linux/arch/i386/mm/ioremap.c - 1.24 linux/arch/i386/kernel/vm86.c - 1.31 linux/arch/i386/kernel/time.c - 1.48 linux/arch/i386/kernel/signal.c - 1.38 linux/arch/i386/kernel/entry.S - 1.87 linux/arch/arm/kernel/signal.c - 1.34 linux/arch/alpha/kernel/setup.c - 1.41 linux/Makefile - 1.263 linux/MAINTAINERS - 1.154 linux/Documentation/networking/irda.txt - 1.5 linux/Documentation/filesystems/ntfs.txt - 1.24 linux/net/decnet/dn_route.c - 1.30 linux/arch/sparc64/lib/rwlock.S - 1.5 linux/fs/partitions/msdos.c - 1.30 linux/drivers/net/sis900.c - 1.52 linux/arch/ppc/kernel/entry.S - 1.39 linux/net/irda/ircomm/ircomm_tty.c - 1.33 linux/net/irda/ircomm/ircomm_core.c - 1.22 linux/drivers/net/starfire.c - 1.36 linux/drivers/net/tokenring/ibmtr.c - 1.27 linux/include/linux/pci_ids.h - 1.100 linux/drivers/scsi/sim710.c - 1.19 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.30 linux/mm/bootmem.c - 1.32 linux/kernel/timer.c - 1.57 linux/drivers/scsi/scsi_lib.c - 1.73 linux/fs/cramfs/inode.c - 1.42 linux/net/sched/sch_gred.c - 1.16 linux/net/sched/sch_dsmark.c - 1.13 linux/arch/i386/kernel/mpparse.c - 1.46 linux/drivers/pci/setup-res.c - 1.20 linux/drivers/pci/setup-bus.c - 1.15 linux/drivers/scsi/scsi_scan.c - 1.58 linux/arch/ia64/ia32/ia32_signal.c - 1.18 linux/arch/ia64/ia32/ia32_entry.S - 1.28 linux/arch/ia64/kernel/irq.c - 1.35 linux/arch/ia64/kernel/signal.c - 1.28 linux/arch/ia64/kernel/traps.c - 1.26 linux/arch/ia64/kernel/perfmon.c - 1.34 linux/arch/ia64/mm/tlb.c - 1.19 linux/include/asm-ia64/pgtable.h - 1.27 linux/drivers/net/8139too.c - 1.59 linux/drivers/net/tulip/tulip_core.c - 1.52 linux/drivers/ide/ide-tape.c - 1.49 linux/net/ipv4/netfilter/ipt_REDIRECT.c - 1.10 linux/net/ipv4/netfilter/ip_queue.c - 1.22 linux/net/ipv4/netfilter/ip_nat_core.c - 1.26 linux/net/ipv4/netfilter/ip_fw_compat_masq.c - 1.14 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.21 linux/drivers/usb/serial/digi_acceleport.c - 1.42 linux/drivers/usb/storage/usb.c - 1.45 linux/drivers/usb/storage/scsiglue.c - 1.38 linux/drivers/acpi/ec.c - 1.23 linux/drivers/acpi/dispatcher/dsopcode.c - 1.23 linux/arch/sparc64/lib/dec_and_lock.S - 1.6 linux/net/ipv4/tcp_minisocks.c - 1.32 linux/drivers/media/video/tuner-3036.c - 1.11 linux/drivers/media/video/saa5249.c - 1.19 linux/drivers/media/video/bttv-if.c - 1.17 linux/drivers/media/video/bttv-cards.c - 1.24 linux/drivers/md/raid1.c - 1.40 linux/net/irda/irnet/irnet_ppp.c - 1.15 linux/drivers/scsi/osst_options.h - 1.3 linux/include/asm-ia64/sn/nodepda.h - 1.10 linux/fs/reiserfs/super.c - 1.39 linux/include/linux/compiler.h - 1.14 linux/fs/char_dev.c - 1.15 linux/drivers/net/wireless/airo.c - 1.37 linux/Documentation/video4linux/meye.txt - 1.8 linux/drivers/char/sonypi.h - 1.15 linux/drivers/media/video/meye.h - 1.11 linux/drivers/ieee1394/sbp2.c - 1.32 linux/drivers/video/radeonfb.c - 1.20 linux/drivers/scsi/53c700.c - 1.25 linux/drivers/scsi/lasi700.c - 1.14 linux/drivers/net/8139cp.c - 1.30 linux/fs/jbd/journal.c - 1.31 linux/fs/ext3/ialloc.c - 1.25 linux/fs/jbd/transaction.c - 1.24 linux/net/ipv6/netfilter/ip6_queue.c - 1.12 linux/arch/x86_64/kernel/entry.S - 1.14 linux/arch/x86_64/kernel/io_apic.c - 1.15 linux/arch/x86_64/kernel/setup64.c - 1.17 linux/arch/x86_64/kernel/smp.c - 1.16 linux/arch/x86_64/kernel/time.c - 1.20 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.17 linux/arch/x86_64/mm/extable.c - 1.6 linux/arch/x86_64/mm/fault.c - 1.14 linux/include/asm-x86_64/processor.h - 1.22 linux/include/asm-x86_64/pci.h - 1.12 linux/include/asm-x86_64/irq.h - 1.4 linux/include/asm-x86_64/hw_irq.h - 1.7 linux/include/asm-x86_64/desc.h - 1.12 linux/include/asm-x86_64/checksum.h - 1.5 linux/include/asm-x86_64/smp.h - 1.12 linux/arch/ppc64/kernel/signal.c - 1.17 linux/arch/ppc64/kernel/signal32.c - 1.18 linux/fs/jfs/namei.c - 1.24 linux/fs/jfs/jfs_metapage.c - 1.16 linux/drivers/net/tg3.c - 1.29 linux/drivers/net/tulip/de4x5.c - 1.18 linux/drivers/media/video/video-buf.c - 1.11 linux/drivers/usb/host/ehci-hcd.c - 1.26 linux/drivers/usb/net/usbnet.c - 1.31 linux/drivers/usb/net/kaweth.c - 1.22 linux/fs/ntfs/attrib.c - 1.12 linux/fs/ntfs/ChangeLog - 1.11 linux/fs/ntfs/attrib.h - 1.3 linux/arch/i386/pci/irq.c - 1.10 linux/drivers/acpi/pci_root.c - 1.12 linux/arch/i386/kernel/cpu/intel.c - 1.19 linux/include/linux/llc.h - 1.4 linux/net/llc/llc_sap.c - 1.13 linux/net/llc/llc_conn.c - 1.14 linux/drivers/input/keyboard/atkbd.c - 1.15 linux/fs/direct-io.c - 1.21 linux/drivers/char/agp/sis-agp.c - 1.15 linux/include/linux/preempt.h - 1.5 linux/fs/aio.c - 1.19 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.7 linux/drivers/base/class.c - 1.16 linux/drivers/ide/pci/amd74xx.h - 1.9 linux/drivers/ide/pci/amd74xx.c - 1.17 linux/drivers/ide/pci/alim15x3.c - 1.11 linux/arch/i386/mm/hugetlbpage.c - 1.17 linux/arch/i386/mach-visws/visws_apic.c - 1.7 linux/include/asm-x86_64/topology.h - 1.6 linux/net/llc/af_llc.c - 1.12 linux/net/llc/llc_proc.c - 1.12 linux/arch/i386/kernel/timers/timer_tsc.c - 1.19 linux/arch/x86_64/kernel/pci-gart.c - 1.16 linux/drivers/pnp/system.c - 1.6 linux/arch/i386/mach-voyager/voyager_smp.c - 1.10 linux/drivers/md/dm-table.c - 1.12 linux/drivers/scsi/Kconfig - 1.20 linux/net/ipv4/netfilter/Kconfig - 1.8 linux/arch/sparc64/Kconfig - 1.25 linux/drivers/ide/Kconfig - 1.19 linux/crypto/api.c - 1.8 linux/net/Kconfig - 1.14 linux/drivers/usb/serial/Kconfig - 1.9 linux/fs/ext3/xattr.c - 1.13 linux/fs/ext2/xattr.c - 1.10 linux/drivers/net/b44.c - 1.9 linux/drivers/scsi/scsi_sysfs.c - 1.18 linux/drivers/video/console/Kconfig - 1.8 linux/fs/compat.c - 1.12 linux/net/core/link_watch.c - 1.6 linux/drivers/net/r8169.c - 1.10 linux/drivers/media/video/bt832.c - 1.4 linux/arch/ia64/kernel/fsys.S - 1.10 linux/arch/x86_64/mm/k8topology.c - 1.5 linux/arch/x86_64/mm/numa.c - 1.7 linux/arch/i386/kernel/acpi/boot.c - 1.8 linux/kernel/posix-timers.c - 1.13 linux/net/compat.c - 1.7 linux/net/ipv6/ah6.c - 1.12 linux/net/ipv6/xfrm6_policy.c - 1.10 linux/net/xfrm/xfrm_state.c - 1.10 linux/net/xfrm/xfrm_policy.c - 1.9 linux/arch/x86_64/kernel/acpi/boot.c - 1.7 linux/arch/h8300/kernel/time.c - 1.4 linux/net/ipv4/ipcomp.c - 1.8 linux/include/asm-sparc/bitext.h - 1.2 linux/drivers/net/arm/ether1.c - 1.4 linux/drivers/net/arm/ether3.c - 1.4 linux/drivers/net/arm/etherh.c - 1.4 linux/drivers/net/bonding/bond_main.c - 1.7 linux/drivers/scsi/arm/acornscsi.c - 1.6 linux/net/ipv6/ipcomp6.c - 1.6 linux/net/core/flow.c - 1.6 linux/net/ipv6/ip6_tunnel.c - 1.8 linux/net/ipv4/ah4.c - 1.5 linux/drivers/input/mouse/psmouse-base.c - 1.4 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.5 linux/drivers/pcmcia/yenta_socket.c - 1.10 linux/fs/Kconfig.binfmt - 1.5 linux/include/scsi/scsi_host.h - 1.6 linux/include/scsi/scsi_device.h - 1.8 linux/arch/ia64/kernel/patch.c - 1.4 linux/include/scsi/scsi_driver.h - 1.2 linux/net/ipv4/netfilter/arpt_mangle.c - 1.3 linux/drivers/block/as-iosched.c - 1.10 linux/lib/div64.c - 1.2 linux/net/ipv4/ipvs/ip_vs_conn.c - 1.6 linux/sound/oss/ali5455.c - 1.7 linux/net/ipv4/ipvs/ip_vs_xmit.c - 1.4 linux/arch/ppc/kernel/vmlinux.lds.S - 1.3 linux/drivers/net/sis190.c - 1.4 linux/drivers/serial/serial_core.c - 1.3 linux/net/llc/llc_input.c - 1.2 linux/net/bridge/netfilter/ebt_limit.c - 1.2 linux/drivers/scsi/sata_svw.c - 1.2 linux/drivers/scsi/ata_piix.c - 1.2 linux/drivers/scsi/libata-core.c - 1.2 linux/drivers/scsi/sata_promise.c - 1.2 linux/drivers/scsi/libata.h - 1.2 linux/drivers/scsi/sata_via.c - 1.2 linux/drivers/scsi/sata_sil.c - 1.2 linux/include/linux/libata.h - 1.2 From owner-linux-xfs@oss.sgi.com Sun Nov 23 19:38:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Nov 2003 19:38:43 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAO3cV25024328 for ; Sun, 23 Nov 2003 19:38:32 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAO1irOO021126 for ; Sun, 23 Nov 2003 17:44:56 -0800 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 OAA02301; Mon, 24 Nov 2003 14:38:21 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAO3cJUc1710631; Mon, 24 Nov 2003 14:38:19 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAO3cL6A001867; Mon, 24 Nov 2003 14:38:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAO3cIrQ001865; Mon, 24 Nov 2003 14:38:18 +1100 Date: Mon, 24 Nov 2003 14:38:18 +1100 From: Nathan Scott To: Alberto Nava Cc: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-ID: <20031124033818.GG764@frodo> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBFEF6A.3000609@kasenna.com> User-Agent: Mutt/1.5.3i X-archive-position: 1095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1741 Lines: 43 Hi Alberto, On Sat, Nov 22, 2003 at 03:21:14PM -0800, Alberto Nava wrote: > I've done some more digging on this issue. The reason the > request is going in 4k pages is that the direct-io code is > giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > The reason do_direct_IO gives up is because the first call to > get_more_blocks() is returning an unmapped buffer header. > This is a snip of the code that's failing (look for XXXXX) Hmm... I don't see a way that we would pass back a buffer that is not mapped for a direct write. linvfs_get_block_core is the place to be concentrating if you're digging in the source, that and xfs_write of course. > Even if I reserve space for the file, the directio IO fails. > > I tried the same with ext3 and it does perform the directIO on the new > file. However, I really disklike the sizes that it's using, it's all > over the place 8k, 160, 200k, etc. I really like the 512K requests I'm > getting with XFS specially with the 320 SCSI controller I'm using. > > I'll try looking at the XFS code to see why is returning an unmapped bh, > but some help here would be greatly appreciate as I'm not familiar with > XFS code. Well, this doesn't sound like expected behaviour on our part. We do use the generic direct IO code in 2.6, so we may not be interacting with that correctly. Can you figure out whether we are passed in a >4K "blocks" value there (with direct set) and maybe put a trap in there to see if the buffer_head we've been asked to setup is mapped or not. It might also be worth putting a printk in that "if (blocks)" at the end of linvfs_get_block_core too to see if we are restricting b_size there on each get_block request. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 24 10:02:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 10:02:37 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOI2G25000766 for ; Mon, 24 Nov 2003 10:02:16 -0800 Received: (qmail 10814941 invoked from network); 24 Nov 2003 18:02:10 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 24 Nov 2003 18:02:10 -0000 Message-ID: <3FC24602.5010904@kasenna.com> Date: Mon, 24 Nov 2003 09:55:14 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <3FC0EFEA.5070108@xfs.org> In-Reply-To: <3FC0EFEA.5070108@xfs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 244 Lines: 11 > This may be an interaction with the unwritten extent handling code. > Try this on a file system made with the mkfs option -d unwritten=0. > Thanks. I tried it but made not difference. We got an unmapped bh and reverted to buffered-IO. From owner-linux-xfs@oss.sgi.com Mon Nov 24 11:44:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 11:45:18 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOJiu25014522 for ; Mon, 24 Nov 2003 11:44:57 -0800 Received: (qmail 10808725 invoked from network); 24 Nov 2003 19:44:50 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 24 Nov 2003 19:44:50 -0000 Message-ID: <3FC25E14.80001@kasenna.com> Date: Mon, 24 Nov 2003 11:37:56 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <3FC0EFEA.5070108@xfs.org> <3FC24602.5010904@kasenna.com> In-Reply-To: <3FC24602.5010904@kasenna.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 19 Alberto Nava wrote: > >> This may be an interaction with the unwritten extent handling code. >> Try this on a file system made with the mkfs option -d unwritten=0. >> > Thanks. > > I tried it but made not difference. We got an unmapped bh and reverted > to buffered-IO. opps.... It does work. I didn't preallocate enough space for the file as I was testing it. It works great now :-). Are there any concerns when setting unwritten=0? Thanks for your help. beto From owner-linux-xfs@oss.sgi.com Mon Nov 24 12:36:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 12:36:55 -0800 (PST) Received: from cyber1hq.adic.com (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOKag25021421 for ; Mon, 24 Nov 2003 12:36:43 -0800 X-Authentication-Warning: localhost.localdomain: slord set sender to lord@adic.com using -f Subject: Re: direct-IO writes strange behavior From: Steve Lord Reply-To: lord@adic.com To: Alberto Nava Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FC25E14.80001@adic.com> References: <3FBECF7E.6010509@adic.com> <3FBFEF6A.3000609@kasenna.com> <3FC0EFEA.5070108@xfs.org> <3FC24602.5010904@kasenna.com> <3FC25E14.80001@kasenna.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1069706184.19242.226.camel@adic.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 24 Nov 2003 14:36:24 -0600 X-archive-position: 1098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Content-Length: 819 Lines: 25 On Mon, 2003-11-24 at 13:37, Alberto Nava wrote: > Alberto Nava wrote: > > > > >> This may be an interaction with the unwritten extent handling code. > >> Try this on a file system made with the mkfs option -d unwritten=0. > >> > > Thanks. > > > > I tried it but made not difference. We got an unmapped bh and reverted > > to buffered-IO. > opps.... It does work. I didn't preallocate enough space for the > file as I was testing it. It works great now :-). > > Are there any concerns when setting unwritten=0? unwritten = 0 was the only supported mode on linux (and originally irix) for a long time. The issue was that using preallocation meant you could go read old data off the disk. On linux now an unwritten=0 filesystem should restrict the preallocation calls to root. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Mon Nov 24 12:43:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 12:43:31 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOKhJ25021832 for ; Mon, 24 Nov 2003 12:43:20 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Mon, 24 Nov 2003 14:44:11 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 14:43:10 -0600 Message-ID: From: Gustavo Rincon To: "'linux-xfs@oss.sgi.com'" Date: Mon, 24 Nov 2003 14:43:06 -0600 Subject: XFS and LBD patch on 2.4.20 or 2.4.22 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 897 Lines: 20 Hi guys, I have a XFS 1.3.1 version compile on linux kernel-2.4.20 (Red Hat version) and kernel-2.4.22 (Vanilla) and i was wonder what changes I have to do to xfsprogs in order to create and support filesystem greater than 2 Terabytes. The kernel that I compiled with the gelato LBD patch and I tested with EXT3 and REISERFS on a MD device, the size of the Device is 2.7 Terabytes, and everything looks OKAY, but when i try to tested with XFS sometime after i perform xfs_repair some files are erased by the xfs_repair utility. All this testing was done in a PENTIUM 4 XEION and gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) to compile the Kernel and the xfsprogs. The xfsprogs utility (2.5.6) was compiled with the xfs_types.h file modified (The XFS_BIG_FILESYSTEMS #define was turned ON). Do I have to compile the xfsprogs using or modifying more #defines? Thank you Gustavo Rincon From owner-linux-xfs@oss.sgi.com Mon Nov 24 13:05:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 13:05:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOL5M25022504 for ; Mon, 24 Nov 2003 13:05:23 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAOLPpHc029613 for ; Mon, 24 Nov 2003 15:25:53 -0600 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 IAA13961; Tue, 25 Nov 2003 08:03:57 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAOL3uUc1773601; Tue, 25 Nov 2003 08:03:56 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAOL3v6o000748; Tue, 25 Nov 2003 08:03:57 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAOL3uJK000746; Tue, 25 Nov 2003 08:03:56 +1100 Date: Tue, 25 Nov 2003 08:03:56 +1100 From: Nathan Scott To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS and LBD patch on 2.4.20 or 2.4.22 Message-ID: <20031124210356.GA717@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 1100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1328 Lines: 38 hi there, On Mon, Nov 24, 2003 at 02:43:06PM -0600, Gustavo Rincon wrote: > Hi guys, I have a XFS 1.3.1 version compile on linux kernel-2.4.20 (Red Hat > version) and kernel-2.4.22 (Vanilla) and > i was wonder what changes I have to do to xfsprogs in order to create and > support filesystem greater than 2 Terabytes. None. > The kernel that I compiled with the gelato LBD patch and I tested with EXT3 > and REISERFS on a MD device, the size of the Device is 2.7 Terabytes, > and everything looks OKAY, but when i try to tested with XFS sometime after > i perform xfs_repair some files are erased by the xfs_repair utility. There are changes in this area in CVS - could you try a current CVS kernel. Also, can you describe your tests in detail, and if the problem reproducible for you? (if so, hopefully it is for me too, so I can fix it ;) > All this testing was done in a PENTIUM 4 XEION and gcc (GCC) 3.2 20020903 > (Red Hat Linux 8.0 3.2-7) to compile the Kernel and the xfsprogs. > > The xfsprogs utility (2.5.6) was compiled with the xfs_types.h file > modified (The XFS_BIG_FILESYSTEMS #define was turned ON). Thats unnecessary - it is always "on" during an xfsprogs build; see xfsprogs/include/builddefs.in. > Do I have to compile the xfsprogs using or modifying more #defines? No. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 24 13:19:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 13:19:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOLJA25023567 for ; Mon, 24 Nov 2003 13:19:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAOLdgHc002501 for ; Mon, 24 Nov 2003 15:39:42 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAOLJ2P514185417; Mon, 24 Nov 2003 15:19:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAOLIwK17907966; Mon, 24 Nov 2003 15:18:58 -0600 (CST) Subject: Re: XFS and LBD patch on 2.4.20 or 2.4.22 From: Eric Sandeen To: Nathan Scott Cc: Gustavo Rincon , "'linux-xfs@oss.sgi.com'" In-Reply-To: <20031124210356.GA717@frodo> References: <20031124210356.GA717@frodo> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1069708741.20806.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 24 Nov 2003 15:19:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 10 Also, please make sure your LBD patch defines HAVE_SECTOR_T - Peter's patch link was out of date for a while, the XFS code keys off that in 2.4 to know whether the LBD patch is present. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Nov 24 14:13:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 14:13:36 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAOMDO25024764 for ; Mon, 24 Nov 2003 14:13:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAOMXsHc026994 for ; Mon, 24 Nov 2003 16:33:55 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAOMDFEU3295560 for ; Tue, 25 Nov 2003 09:13:15 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAOMDELB3294847 for linux-xfs@oss.sgi.com; Tue, 25 Nov 2003 09:13:14 +1100 (EST) Date: Tue, 25 Nov 2003 09:13:14 +1100 (EST) From: Nathan Scott Message-Id: <200311242213.hAOMDELB3294847@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.23-rc4 X-archive-position: 1102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 866 Lines: 27 Date: Mon Nov 24 14:12:34 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162370a linux/drivers/ide/ide-probe-mini.c - 1.1 linux/Makefile - 1.197 linux/MAINTAINERS - 1.97 linux/Documentation/Configure.help - 1.151 linux/arch/sh/kernel/traps.c - 1.13 linux/arch/sh/kernel/ptrace.c - 1.14 linux/arch/sh/kernel/irq.c - 1.13 linux/arch/sh/kernel/entry.S - 1.23 linux/arch/sh/config.in - 1.25 linux/arch/sh/Makefile - 1.11 linux/include/asm-sh/ptrace.h - 1.9 linux/include/asm-sh/processor.h - 1.20 linux/drivers/ide/ide-probe.c - 1.24 linux/drivers/ide/Makefile - 1.20 linux/Documentation/networking/bonding.txt - 1.6 linux/arch/sh64/boot/compressed/head.S - 1.2 linux/arch/sh64/defconfig - 1.3 linux/arch/sh64/kernel/irq.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 24 15:11:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 15:12:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAONBc25025754 for ; Mon, 24 Nov 2003 15:11:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAONBcvE025753 for linux-xfs@oss.sgi.com; Mon, 24 Nov 2003 15:11:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAONBa27025739 for ; Mon, 24 Nov 2003 15:11:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAON5PMJ025646; Mon, 24 Nov 2003 15:05:25 -0800 Date: Mon, 24 Nov 2003 15:05:25 -0800 Message-Id: <200311242305.hAON5PMJ025646@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From sandeen@sgi.com 2003-24-11 15:05 PDT ------- Actually, what makes you certain that this is a leak, rather than normal caching, etc? My hunch is that the inode_cache is just getting filled up. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 24 16:03:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 16:03:40 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hAP03J25028428 for ; Mon, 24 Nov 2003 16:03:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAOM9kOO024913 for ; Mon, 24 Nov 2003 14:09:46 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAP037EU3349099 for ; Tue, 25 Nov 2003 11:03:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAP036FP3312365 for linux-xfs@oss.sgi.com; Tue, 25 Nov 2003 11:03:06 +1100 (EST) Date: Tue, 25 Nov 2003 11:03:06 +1100 (EST) From: Nathan Scott Message-Id: <200311250003.hAP036FP3312365@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - shake (your tailfeather) X-archive-position: 1104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 828 Lines: 29 Use Russells iomap abstraction consistently. Date: Sun Nov 23 13:37:44 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162327a linux/fs/xfs/linux/xfs_aops.c - 1.60 Implement a memory shaking interface for 2.4 which is much more like the 2.6 one. No functional change here, just getting XFS interfaces aligned for different kernel versions (backporting 2.6 bits mainly). Date: Mon Nov 24 15:58:38 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162377a linux/fs/xfs/support/kmem.h - 1.20 linux/fs/xfs/support/kmem.c - 1.28 linux/fs/xfs/quota/xfs_qm.c - 1.9 From owner-linux-xfs@oss.sgi.com Mon Nov 24 18:11:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Nov 2003 18:11:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAP2Bd25008000 for ; Mon, 24 Nov 2003 18:11:39 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAP2BdRI007999 for linux-xfs@oss.sgi.com; Mon, 24 Nov 2003 18:11:39 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hAP2Ba25007987 for ; Mon, 24 Nov 2003 18:11:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hAP1GMRu032335; Mon, 24 Nov 2003 17:16:22 -0800 Date: Mon, 24 Nov 2003 17:16:22 -0800 Message-Id: <200311250116.hAP1GMRu032335@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1377 Lines: 32 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From condor-sgi@condordes.net 2003-24-11 17:16 PDT ------- Well, I think it's a leak largely because it eats non-buffer, non-cached RAM, and when I try to load up programs that consume RAM (Mozilla or KDE, for instance), it starts swapping, sometimes quite a lot. On a fresh boot before running this test, it doesn't need to swap at all. Plus, in this test, most of the used RAM doesn't show up under buffers or cache... it just sort of disappears from free. If you take the vmstat output, dump it into a spreadsheet and add up all the free/buffers/cache RAM for each vmstat line, you'd expect that number to remain mostly constant. (Instead it steadily decreases.) The Perl program uses a fairly constant amount of RAM, there's nothing else running (single-user mode), and since there's little change in userspace RAM usage, what's subtracted/added from the free gets added/subtracted to the buffers and cache. (This is on a machine with 512MB RAM, btw.) I'm assuming here that the inode cache is included in the "cache" statistic. Sadly I know very little about kernel programming (or internals, for that matter, beyond general ideas), so I could easily be wrong. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 25 06:32:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 06:33:15 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPEWWTa014135 for ; Tue, 25 Nov 2003 06:32:45 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Tue, 25 Nov 2003 08:33:18 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 08:32:16 -0600 Message-ID: From: Gustavo Rincon To: "'Nathan Scott'" , Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" Date: Tue, 25 Nov 2003 08:32:15 -0600 Subject: RE: XFS and LBD patch on 2.4.20 or 2.4.22 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_NextPart_ST_08_33_19_Tuesday_November_25_2003_26309" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 39893 Lines: 1640 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ----=_NextPart_ST_08_33_19_Tuesday_November_25_2003_26309 Content-Type: text/plain; charset="iso-8859-1" Well for this test I'm using kernel-2.4.22 plus a version of the lbd patch (linux-2.4.28-18-rh-lbd.path took from the SGI ftp, i don't know if this patch is still available on the SGI ftp) and SGI XFS snapshot-2.4.22-2003-11-10_23:49_UTC I did some modification to the lbd patch to make it suitable for 2.4.22, this patch has #define HAVE_SECTOR_T on include/linux/type.h. I compiled the kernel with XFS builded as module and the LBD option enable. (used gcc (GCC) 3.2 20020903) and It was installed in the target machine. I modified the include/xfs_types.h on the xfsprogs-2.5.6 directory, the #define XFS_BIG_FILESYSTEMS 0 was changed to #define XFS_BIG_FILESYSTEMS 1 on line 221. The xfsprogs was compiled and installed in the target machine. #if defined(CONFIG_LBD) || (defined(HAVE_SECTOR_T) && (BITS_PER_LONG == 64)) # ifndef XFS_BIG_FILESYSTEMS # define XFS_BIG_FILESYSTEMS 1 # endif #else # ifndef XFS_BIG_FILESYSTEMS # define XFS_BIG_FILESYSTEMS 1 # endif #endif Hardware used: A DUAL PENTIUM 4 XEON motherboard with 1 GBytes of RAM. 3ware raid controller 7000 series with 12 Serial ATA 250Gbytes disk and two raid0 luns were defined (each one with 6 disks or 1.5 Terabyte LUNS) Testing performed 1.- Using the raidtools a md0 device was created. The following raidtab file was used. raiddev /dev/md0 raid-level 0 nr-raid-disks 2 chunk-size 512 device /dev/sda3 raid-disk 0 device /dev/sdb3 raid-disk 1 2.- mkfs.xfs -f /dev/md0 was executed. 3.- mount -t xfs /dev/md0 /mnt was executed. the dmesg output was : SGI XFS snapshot-2.4.22-2003-11-10_23:49_UTC with ACLs, large block numbers, no debug enabled SGI XFS Quota Management subsystem 4.- cd /mnt was executed. 5.- xfs_mkfile 600G test1 was executed sucessfully. 6.- xfs_mkfile 500G test2 was executed sucessfully. 7.- xfs_mkfile 400G test3 was executed sucessfully. 8.- xfs_mkfile 400G test4 was executed sucessfully. 9.- xfs_mkfile 500G test5 was executed sucessfully. 10.- xfs_mkfile 500G test6 was executed sucessfully. 11.- ls -l /mnt was executed and all the created files were presented in the list. 12.- cd / and umount /mnt 13.- xfs_repair /dev/md0 (look in attachment log1 to see the output of xfs_repair) Partial output of xfs_repair 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 bad fwd (right) sibling pointer (saw 5888878 should be NULLDFSBNO) in inode 2057 (data fork) bmap btree block 695161421 bad data fork in inode 2057 cleared inode 2057 bad fwd (right) sibling pointer (saw 5888944 should be NULLDFSBNO) in inode 2058 (data fork) bmap btree block 695161487 bad data fork in inode 2058 cleared inode 2058 . . . Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 entry "test5" in shortform directory 2048 references free inode 2057 junking entry "test5" in directory inode 2048 entry "test6" in shortform directory 2048 references free inode 2058 junking entry "test6" in directory inode 2048 14.- mount -t xfs /dev/md0 /mnt 15.- ls -l /mnt was executed and test5 and test6 were not in the directory. Now will try to use xfsprogs-2.6.0 version and try to reproduce the problem, something that I noticed in the new version of xfsprogs is that on xfs_types.h was changed from the 2.5.6 version. #if defined(CONFIG_LBD) || (defined(HAVE_SECTOR_T) && (BITS_PER_LONG == 64)) # define XFS_BIG_BLKNOS 1 # if BITS_PER_LONG == 64 # define XFS_BIG_INUMS 1 # else # define XFS_BIG_INUMS 0 # endif #else # define XFS_BIG_BLKNOS 0 # define XFS_BIG_INUMS 0 #endif Thank you Gustavo Rincon -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Monday, November 24, 2003 4:04 PM To: Gustavo Rincon Cc: 'linux-xfs@oss.sgi.com' Subject: Re: XFS and LBD patch on 2.4.20 or 2.4.22 hi there, On Mon, Nov 24, 2003 at 02:43:06PM -0600, Gustavo Rincon wrote: > Hi guys, I have a XFS 1.3.1 version compile on linux kernel-2.4.20 (Red Hat > version) and kernel-2.4.22 (Vanilla) and > i was wonder what changes I have to do to xfsprogs in order to create and > support filesystem greater than 2 Terabytes. None. > The kernel that I compiled with the gelato LBD patch and I tested with EXT3 > and REISERFS on a MD device, the size of the Device is 2.7 Terabytes, > and everything looks OKAY, but when i try to tested with XFS sometime after > i perform xfs_repair some files are erased by the xfs_repair utility. There are changes in this area in CVS - could you try a current CVS kernel. Also, can you describe your tests in detail, and if the problem reproducible for you? (if so, hopefully it is for me too, so I can fix it ;) > All this testing was done in a PENTIUM 4 XEION and gcc (GCC) 3.2 20020903 > (Red Hat Linux 8.0 3.2-7) to compile the Kernel and the xfsprogs. > > The xfsprogs utility (2.5.6) was compiled with the xfs_types.h file > modified (The XFS_BIG_FILESYSTEMS #define was turned ON). Thats unnecessary - it is always "on" during an xfsprogs build; see xfsprogs/include/builddefs.in. > Do I have to compile the xfsprogs using or modifying more #defines? No. cheers. -- Nathan ----=_NextPart_ST_08_33_19_Tuesday_November_25_2003_26309 Content-Type: application/octet-stream; name="log1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="log1" 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 =3D 0 bad fwd (right) sibling pointer (saw 5888878 should be NULLDFSBNO) in inode 2057 (data fork) bmap btree block 695161421 bad data fork in inode 2057 cleared inode 2057 bad fwd (right) sibling pointer (saw 5888944 should be NULLDFSBNO) in inode 2058 (data fork) bmap btree block 695161487 bad data fork in inode 2058 cleared inode 2058 - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 - agno =3D 38 - agno =3D 39 - agno =3D 40 - agno =3D 41 - agno =3D 42 - agno =3D 43 - agno =3D 44 - agno =3D 45 - agno =3D 46 - agno =3D 47 - agno =3D 48 - agno =3D 49 - agno =3D 50 - agno =3D 51 - agno =3D 52 - agno =3D 53 - agno =3D 54 - agno =3D 55 - agno =3D 56 - agno =3D 57 - agno =3D 58 - agno =3D 59 - agno =3D 60 - agno =3D 61 - agno =3D 62 - agno =3D 63 - agno =3D 64 - agno =3D 65 - agno =3D 66 - agno =3D 67 - agno =3D 68 - agno =3D 69 - agno =3D 70 - agno =3D 71 - agno =3D 72 - agno =3D 73 - agno =3D 74 - agno =3D 75 - agno =3D 76 - agno =3D 77 - agno =3D 78 - agno =3D 79 - agno =3D 80 - agno =3D 81 - agno =3D 82 - agno =3D 83 - agno =3D 84 - agno =3D 85 - agno =3D 86 - agno =3D 87 - agno =3D 88 - agno =3D 89 - agno =3D 90 - agno =3D 91 - agno =3D 92 - agno =3D 93 - agno =3D 94 - agno =3D 95 - agno =3D 96 - agno =3D 97 - agno =3D 98 - agno =3D 99 - agno =3D 100 - agno =3D 101 - agno =3D 102 - agno =3D 103 - agno =3D 104 - agno =3D 105 - agno =3D 106 - agno =3D 107 - agno =3D 108 - agno =3D 109 - agno =3D 110 - agno =3D 111 - agno =3D 112 - agno =3D 113 - agno =3D 114 - agno =3D 115 - agno =3D 116 - agno =3D 117 - agno =3D 118 - agno =3D 119 - agno =3D 120 - agno =3D 121 - agno =3D 122 - agno =3D 123 - agno =3D 124 - agno =3D 125 - agno =3D 126 - agno =3D 127 - agno =3D 128 - agno =3D 129 - agno =3D 130 - agno =3D 131 - agno =3D 132 - agno =3D 133 - agno =3D 134 - agno =3D 135 - agno =3D 136 - agno =3D 137 - agno =3D 138 - agno =3D 139 - agno =3D 140 - agno =3D 141 - agno =3D 142 - agno =3D 143 - agno =3D 144 - agno =3D 145 - agno =3D 146 - agno =3D 147 - agno =3D 148 - agno =3D 149 - agno =3D 150 - agno =3D 151 - agno =3D 152 - agno =3D 153 - agno =3D 154 - agno =3D 155 - agno =3D 156 - agno =3D 157 - agno =3D 158 - agno =3D 159 - agno =3D 160 - agno =3D 161 - agno =3D 162 - agno =3D 163 - agno =3D 164 - agno =3D 165 - agno =3D 166 - agno =3D 167 - agno =3D 168 - agno =3D 169 - agno =3D 170 - agno =3D 171 - agno =3D 172 - agno =3D 173 - agno =3D 174 - agno =3D 175 - agno =3D 176 - agno =3D 177 - agno =3D 178 - agno =3D 179 - agno =3D 180 - agno =3D 181 - agno =3D 182 - agno =3D 183 - agno =3D 184 - agno =3D 185 - agno =3D 186 - agno =3D 187 - agno =3D 188 - agno =3D 189 - agno =3D 190 - agno =3D 191 - agno =3D 192 - agno =3D 193 - agno =3D 194 - agno =3D 195 - agno =3D 196 - agno =3D 197 - agno =3D 198 - agno =3D 199 - agno =3D 200 - agno =3D 201 - agno =3D 202 - agno =3D 203 - agno =3D 204 - agno =3D 205 - agno =3D 206 - agno =3D 207 - agno =3D 208 - agno =3D 209 - agno =3D 210 - agno =3D 211 - agno =3D 212 - agno =3D 213 - agno =3D 214 - agno =3D 215 - agno =3D 216 - agno =3D 217 - agno =3D 218 - agno =3D 219 - agno =3D 220 - agno =3D 221 - agno =3D 222 - agno =3D 223 - agno =3D 224 - agno =3D 225 - agno =3D 226 - agno =3D 227 - agno =3D 228 - agno =3D 229 - agno =3D 230 - agno =3D 231 - agno =3D 232 - agno =3D 233 - agno =3D 234 - agno =3D 235 - agno =3D 236 - agno =3D 237 - agno =3D 238 - agno =3D 239 - agno =3D 240 - agno =3D 241 - agno =3D 242 - agno =3D 243 - agno =3D 244 - agno =3D 245 - agno =3D 246 - agno =3D 247 - agno =3D 248 - agno =3D 249 - agno =3D 250 - agno =3D 251 - agno =3D 252 - agno =3D 253 - agno =3D 254 - agno =3D 255 - agno =3D 256 - agno =3D 257 - agno =3D 258 - agno =3D 259 - agno =3D 260 - agno =3D 261 - agno =3D 262 - agno =3D 263 - agno =3D 264 - agno =3D 265 - agno =3D 266 - agno =3D 267 - agno =3D 268 - agno =3D 269 - agno =3D 270 - agno =3D 271 - agno =3D 272 - agno =3D 273 - agno =3D 274 - agno =3D 275 - agno =3D 276 - agno =3D 277 - agno =3D 278 - agno =3D 279 - agno =3D 280 - agno =3D 281 - agno =3D 282 - agno =3D 283 - agno =3D 284 - agno =3D 285 - agno =3D 286 - agno =3D 287 - agno =3D 288 - agno =3D 289 - agno =3D 290 - agno =3D 291 - agno =3D 292 - agno =3D 293 - agno =3D 294 - agno =3D 295 - agno =3D 296 - agno =3D 297 - agno =3D 298 - agno =3D 299 - agno =3D 300 - agno =3D 301 - agno =3D 302 - agno =3D 303 - agno =3D 304 - agno =3D 305 - agno =3D 306 - agno =3D 307 - agno =3D 308 - agno =3D 309 - agno =3D 310 - agno =3D 311 - agno =3D 312 - agno =3D 313 - agno =3D 314 - agno =3D 315 - agno =3D 316 - agno =3D 317 - agno =3D 318 - agno =3D 319 - agno =3D 320 - agno =3D 321 - agno =3D 322 - agno =3D 323 - agno =3D 324 - agno =3D 325 - agno =3D 326 - agno =3D 327 - agno =3D 328 - agno =3D 329 - agno =3D 330 - agno =3D 331 - agno =3D 332 - agno =3D 333 - agno =3D 334 - agno =3D 335 - agno =3D 336 - agno =3D 337 - agno =3D 338 - agno =3D 339 - agno =3D 340 - agno =3D 341 - agno =3D 342 - agno =3D 343 - agno =3D 344 - agno =3D 345 - agno =3D 346 - agno =3D 347 - agno =3D 348 - agno =3D 349 - agno =3D 350 - agno =3D 351 - agno =3D 352 - agno =3D 353 - agno =3D 354 - agno =3D 355 - agno =3D 356 - agno =3D 357 - agno =3D 358 - agno =3D 359 - agno =3D 360 - agno =3D 361 - agno =3D 362 - agno =3D 363 - agno =3D 364 - agno =3D 365 - agno =3D 366 - agno =3D 367 - agno =3D 368 - agno =3D 369 - agno =3D 370 - agno =3D 371 - agno =3D 372 - agno =3D 373 - agno =3D 374 - agno =3D 375 - agno =3D 376 - agno =3D 377 - agno =3D 378 - agno =3D 379 - agno =3D 380 - agno =3D 381 - agno =3D 382 - agno =3D 383 - agno =3D 384 - agno =3D 385 - agno =3D 386 - agno =3D 387 - agno =3D 388 - agno =3D 389 - agno =3D 390 - agno =3D 391 - agno =3D 392 - agno =3D 393 - agno =3D 394 - agno =3D 395 - agno =3D 396 - agno =3D 397 - agno =3D 398 - agno =3D 399 - agno =3D 400 - agno =3D 401 - agno =3D 402 - agno =3D 403 - agno =3D 404 - agno =3D 405 - agno =3D 406 - agno =3D 407 - agno =3D 408 - agno =3D 409 - agno =3D 410 - agno =3D 411 - agno =3D 412 - agno =3D 413 - agno =3D 414 - agno =3D 415 - agno =3D 416 - agno =3D 417 - agno =3D 418 - agno =3D 419 - agno =3D 420 - agno =3D 421 - agno =3D 422 - agno =3D 423 - agno =3D 424 - agno =3D 425 - agno =3D 426 - agno =3D 427 - agno =3D 428 - agno =3D 429 - agno =3D 430 - agno =3D 431 - agno =3D 432 - agno =3D 433 - agno =3D 434 - agno =3D 435 - agno =3D 436 - agno =3D 437 - agno =3D 438 - agno =3D 439 - agno =3D 440 - agno =3D 441 - agno =3D 442 - agno =3D 443 - agno =3D 444 - agno =3D 445 - agno =3D 446 - agno =3D 447 - agno =3D 448 - agno =3D 449 - agno =3D 450 - agno =3D 451 - agno =3D 452 - agno =3D 453 - agno =3D 454 - agno =3D 455 - agno =3D 456 - agno =3D 457 - agno =3D 458 - agno =3D 459 - agno =3D 460 - agno =3D 461 - agno =3D 462 - agno =3D 463 - agno =3D 464 - agno =3D 465 - agno =3D 466 - agno =3D 467 - agno =3D 468 - agno =3D 469 - agno =3D 470 - agno =3D 471 - agno =3D 472 - agno =3D 473 - agno =3D 474 - agno =3D 475 - agno =3D 476 - agno =3D 477 - agno =3D 478 - agno =3D 479 - agno =3D 480 - agno =3D 481 - agno =3D 482 - agno =3D 483 - agno =3D 484 - agno =3D 485 - agno =3D 486 - agno =3D 487 - agno =3D 488 - agno =3D 489 - agno =3D 490 - agno =3D 491 - agno =3D 492 - agno =3D 493 - agno =3D 494 - agno =3D 495 - agno =3D 496 - agno =3D 497 - agno =3D 498 - agno =3D 499 - agno =3D 500 - agno =3D 501 - agno =3D 502 - agno =3D 503 - agno =3D 504 - agno =3D 505 - agno =3D 506 - agno =3D 507 - agno =3D 508 - agno =3D 509 - agno =3D 510 - agno =3D 511 - agno =3D 512 - agno =3D 513 - agno =3D 514 - agno =3D 515 - agno =3D 516 - agno =3D 517 - agno =3D 518 - agno =3D 519 - agno =3D 520 - agno =3D 521 - agno =3D 522 - agno =3D 523 - agno =3D 524 - agno =3D 525 - agno =3D 526 - agno =3D 527 - agno =3D 528 - agno =3D 529 - agno =3D 530 - agno =3D 531 - agno =3D 532 - agno =3D 533 - agno =3D 534 - agno =3D 535 - agno =3D 536 - agno =3D 537 - agno =3D 538 - agno =3D 539 - agno =3D 540 - agno =3D 541 - agno =3D 542 - agno =3D 543 - agno =3D 544 - agno =3D 545 - agno =3D 546 - agno =3D 547 - agno =3D 548 - agno =3D 549 - agno =3D 550 - agno =3D 551 - agno =3D 552 - agno =3D 553 - agno =3D 554 - agno =3D 555 - agno =3D 556 - agno =3D 557 - agno =3D 558 - agno =3D 559 - agno =3D 560 - agno =3D 561 - agno =3D 562 - agno =3D 563 - agno =3D 564 - agno =3D 565 - agno =3D 566 - agno =3D 567 - agno =3D 568 - agno =3D 569 - agno =3D 570 - agno =3D 571 - agno =3D 572 - agno =3D 573 - agno =3D 574 - agno =3D 575 - agno =3D 576 - agno =3D 577 - agno =3D 578 - agno =3D 579 - agno =3D 580 - agno =3D 581 - agno =3D 582 - agno =3D 583 - agno =3D 584 - agno =3D 585 - agno =3D 586 - agno =3D 587 - agno =3D 588 - agno =3D 589 - agno =3D 590 - agno =3D 591 - agno =3D 592 - agno =3D 593 - agno =3D 594 - agno =3D 595 - agno =3D 596 - agno =3D 597 - agno =3D 598 - agno =3D 599 - agno =3D 600 - agno =3D 601 - agno =3D 602 - agno =3D 603 - agno =3D 604 - agno =3D 605 - agno =3D 606 - agno =3D 607 - agno =3D 608 - agno =3D 609 - agno =3D 610 - agno =3D 611 - agno =3D 612 - agno =3D 613 - agno =3D 614 - agno =3D 615 - agno =3D 616 - agno =3D 617 - agno =3D 618 - agno =3D 619 - agno =3D 620 - agno =3D 621 - agno =3D 622 - agno =3D 623 - agno =3D 624 - agno =3D 625 - agno =3D 626 - agno =3D 627 - agno =3D 628 - agno =3D 629 - agno =3D 630 - agno =3D 631 - agno =3D 632 - agno =3D 633 - agno =3D 634 - agno =3D 635 - agno =3D 636 - agno =3D 637 - agno =3D 638 - agno =3D 639 - agno =3D 640 - agno =3D 641 - agno =3D 642 - agno =3D 643 - agno =3D 644 - agno =3D 645 - agno =3D 646 - agno =3D 647 - agno =3D 648 - agno =3D 649 - agno =3D 650 - agno =3D 651 - agno =3D 652 - agno =3D 653 - agno =3D 654 - agno =3D 655 - agno =3D 656 - agno =3D 657 - agno =3D 658 - agno =3D 659 - agno =3D 660 - agno =3D 661 - agno =3D 662 - agno =3D 663 - agno =3D 664 - agno =3D 665 - agno =3D 666 - agno =3D 667 - agno =3D 668 - agno =3D 669 - agno =3D 670 - agno =3D 671 - agno =3D 672 - agno =3D 673 - agno =3D 674 - agno =3D 675 - agno =3D 676 - agno =3D 677 - agno =3D 678 - agno =3D 679 - agno =3D 680 - agno =3D 681 - agno =3D 682 - agno =3D 683 - agno =3D 684 - agno =3D 685 - agno =3D 686 - agno =3D 687 - agno =3D 688 - agno =3D 689 - agno =3D 690 - agno =3D 691 - agno =3D 692 - agno =3D 693 - agno =3D 694 - agno =3D 695 - agno =3D 696 - agno =3D 697 - agno =3D 698 - 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 - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno =3D 0 entry "test5" in shortform directory 2048 references free inode 2057 junking entry "test5" in directory inode 2048 entry "test6" in shortform directory 2048 references free inode 2058 junking entry "test6" in directory inode 2048 - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 - agno =3D 38 - agno =3D 39 - agno =3D 40 - agno =3D 41 - agno =3D 42 - agno =3D 43 - agno =3D 44 - agno =3D 45 - agno =3D 46 - agno =3D 47 - agno =3D 48 - agno =3D 49 - agno =3D 50 - agno =3D 51 - agno =3D 52 - agno =3D 53 - agno =3D 54 - agno =3D 55 - agno =3D 56 - agno =3D 57 - agno =3D 58 - agno =3D 59 - agno =3D 60 - agno =3D 61 - agno =3D 62 - agno =3D 63 - agno =3D 64 - agno =3D 65 - agno =3D 66 - agno =3D 67 - agno =3D 68 - agno =3D 69 - agno =3D 70 - agno =3D 71 - agno =3D 72 - agno =3D 73 - agno =3D 74 - agno =3D 75 - agno =3D 76 - agno =3D 77 - agno =3D 78 - agno =3D 79 - agno =3D 80 - agno =3D 81 - agno =3D 82 - agno =3D 83 - agno =3D 84 - agno =3D 85 - agno =3D 86 - agno =3D 87 - agno =3D 88 - agno =3D 89 - agno =3D 90 - agno =3D 91 - agno =3D 92 - agno =3D 93 - agno =3D 94 - agno =3D 95 - agno =3D 96 - agno =3D 97 - agno =3D 98 - agno =3D 99 - agno =3D 100 - agno =3D 101 - agno =3D 102 - agno =3D 103 - agno =3D 104 - agno =3D 105 - agno =3D 106 - agno =3D 107 - agno =3D 108 - agno =3D 109 - agno =3D 110 - agno =3D 111 - agno =3D 112 - agno =3D 113 - agno =3D 114 - agno =3D 115 - agno =3D 116 - agno =3D 117 - agno =3D 118 - agno =3D 119 - agno =3D 120 - agno =3D 121 - agno =3D 122 - agno =3D 123 - agno =3D 124 - agno =3D 125 - agno =3D 126 - agno =3D 127 - agno =3D 128 - agno =3D 129 - agno =3D 130 - agno =3D 131 - agno =3D 132 - agno =3D 133 - agno =3D 134 - agno =3D 135 - agno =3D 136 - agno =3D 137 - agno =3D 138 - agno =3D 139 - agno =3D 140 - agno =3D 141 - agno =3D 142 - agno =3D 143 - agno =3D 144 - agno =3D 145 - agno =3D 146 - agno =3D 147 - agno =3D 148 - agno =3D 149 - agno =3D 150 - agno =3D 151 - agno =3D 152 - agno =3D 153 - agno =3D 154 - agno =3D 155 - agno =3D 156 - agno =3D 157 - agno =3D 158 - agno =3D 159 - agno =3D 160 - agno =3D 161 - agno =3D 162 - agno =3D 163 - agno =3D 164 - agno =3D 165 - agno =3D 166 - agno =3D 167 - agno =3D 168 - agno =3D 169 - agno =3D 170 - agno =3D 171 - agno =3D 172 - agno =3D 173 - agno =3D 174 - agno =3D 175 - agno =3D 176 - agno =3D 177 - agno =3D 178 - agno =3D 179 - agno =3D 180 - agno =3D 181 - agno =3D 182 - agno =3D 183 - agno =3D 184 - agno =3D 185 - agno =3D 186 - agno =3D 187 - agno =3D 188 - agno =3D 189 - agno =3D 190 - agno =3D 191 - agno =3D 192 - agno =3D 193 - agno =3D 194 - agno =3D 195 - agno =3D 196 - agno =3D 197 - agno =3D 198 - agno =3D 199 - agno =3D 200 - agno =3D 201 - agno =3D 202 - agno =3D 203 - agno =3D 204 - agno =3D 205 - agno =3D 206 - agno =3D 207 - agno =3D 208 - agno =3D 209 - agno =3D 210 - agno =3D 211 - agno =3D 212 - agno =3D 213 - agno =3D 214 - agno =3D 215 - agno =3D 216 - agno =3D 217 - agno =3D 218 - agno =3D 219 - agno =3D 220 - agno =3D 221 - agno =3D 222 - agno =3D 223 - agno =3D 224 - agno =3D 225 - agno =3D 226 - agno =3D 227 - agno =3D 228 - agno =3D 229 - agno =3D 230 - agno =3D 231 - agno =3D 232 - agno =3D 233 - agno =3D 234 - agno =3D 235 - agno =3D 236 - agno =3D 237 - agno =3D 238 - agno =3D 239 - agno =3D 240 - agno =3D 241 - agno =3D 242 - agno =3D 243 - agno =3D 244 - agno =3D 245 - agno =3D 246 - agno =3D 247 - agno =3D 248 - agno =3D 249 - agno =3D 250 - agno =3D 251 - agno =3D 252 - agno =3D 253 - agno =3D 254 - agno =3D 255 - agno =3D 256 - agno =3D 257 - agno =3D 258 - agno =3D 259 - agno =3D 260 - agno =3D 261 - agno =3D 262 - agno =3D 263 - agno =3D 264 - agno =3D 265 - agno =3D 266 - agno =3D 267 - agno =3D 268 - agno =3D 269 - agno =3D 270 - agno =3D 271 - agno =3D 272 - agno =3D 273 - agno =3D 274 - agno =3D 275 - agno =3D 276 - agno =3D 277 - agno =3D 278 - agno =3D 279 - agno =3D 280 - agno =3D 281 - agno =3D 282 - agno =3D 283 - agno =3D 284 - agno =3D 285 - agno =3D 286 - agno =3D 287 - agno =3D 288 - agno =3D 289 - agno =3D 290 - agno =3D 291 - agno =3D 292 - agno =3D 293 - agno =3D 294 - agno =3D 295 - agno =3D 296 - agno =3D 297 - agno =3D 298 - agno =3D 299 - agno =3D 300 - agno =3D 301 - agno =3D 302 - agno =3D 303 - agno =3D 304 - agno =3D 305 - agno =3D 306 - agno =3D 307 - agno =3D 308 - agno =3D 309 - agno =3D 310 - agno =3D 311 - agno =3D 312 - agno =3D 313 - agno =3D 314 - agno =3D 315 - agno =3D 316 - agno =3D 317 - agno =3D 318 - agno =3D 319 - agno =3D 320 - agno =3D 321 - agno =3D 322 - agno =3D 323 - agno =3D 324 - agno =3D 325 - agno =3D 326 - agno =3D 327 - agno =3D 328 - agno =3D 329 - agno =3D 330 - agno =3D 331 - agno =3D 332 - agno =3D 333 - agno =3D 334 - agno =3D 335 - agno =3D 336 - agno =3D 337 - agno =3D 338 - agno =3D 339 - agno =3D 340 - agno =3D 341 - agno =3D 342 - agno =3D 343 - agno =3D 344 - agno =3D 345 - agno =3D 346 - agno =3D 347 - agno =3D 348 - agno =3D 349 - agno =3D 350 - agno =3D 351 - agno =3D 352 - agno =3D 353 - agno =3D 354 - agno =3D 355 - agno =3D 356 - agno =3D 357 - agno =3D 358 - agno =3D 359 - agno =3D 360 - agno =3D 361 - agno =3D 362 - agno =3D 363 - agno =3D 364 - agno =3D 365 - agno =3D 366 - agno =3D 367 - agno =3D 368 - agno =3D 369 - agno =3D 370 - agno =3D 371 - agno =3D 372 - agno =3D 373 - agno =3D 374 - agno =3D 375 - agno =3D 376 - agno =3D 377 - agno =3D 378 - agno =3D 379 - agno =3D 380 - agno =3D 381 - agno =3D 382 - agno =3D 383 - agno =3D 384 - agno =3D 385 - agno =3D 386 - agno =3D 387 - agno =3D 388 - agno =3D 389 - agno =3D 390 - agno =3D 391 - agno =3D 392 - agno =3D 393 - agno =3D 394 - agno =3D 395 - agno =3D 396 - agno =3D 397 - agno =3D 398 - agno =3D 399 - agno =3D 400 - agno =3D 401 - agno =3D 402 - agno =3D 403 - agno =3D 404 - agno =3D 405 - agno =3D 406 - agno =3D 407 - agno =3D 408 - agno =3D 409 - agno =3D 410 - agno =3D 411 - agno =3D 412 - agno =3D 413 - agno =3D 414 - agno =3D 415 - agno =3D 416 - agno =3D 417 - agno =3D 418 - agno =3D 419 - agno =3D 420 - agno =3D 421 - agno =3D 422 - agno =3D 423 - agno =3D 424 - agno =3D 425 - agno =3D 426 - agno =3D 427 - agno =3D 428 - agno =3D 429 - agno =3D 430 - agno =3D 431 - agno =3D 432 - agno =3D 433 - agno =3D 434 - agno =3D 435 - agno =3D 436 - agno =3D 437 - agno =3D 438 - agno =3D 439 - agno =3D 440 - agno =3D 441 - agno =3D 442 - agno =3D 443 - agno =3D 444 - agno =3D 445 - agno =3D 446 - agno =3D 447 - agno =3D 448 - agno =3D 449 - agno =3D 450 - agno =3D 451 - agno =3D 452 - agno =3D 453 - agno =3D 454 - agno =3D 455 - agno =3D 456 - agno =3D 457 - agno =3D 458 - agno =3D 459 - agno =3D 460 - agno =3D 461 - agno =3D 462 - agno =3D 463 - agno =3D 464 - agno =3D 465 - agno =3D 466 - agno =3D 467 - agno =3D 468 - agno =3D 469 - agno =3D 470 - agno =3D 471 - agno =3D 472 - agno =3D 473 - agno =3D 474 - agno =3D 475 - agno =3D 476 - agno =3D 477 - agno =3D 478 - agno =3D 479 - agno =3D 480 - agno =3D 481 - agno =3D 482 - agno =3D 483 - agno =3D 484 - agno =3D 485 - agno =3D 486 - agno =3D 487 - agno =3D 488 - agno =3D 489 - agno =3D 490 - agno =3D 491 - agno =3D 492 - agno =3D 493 - agno =3D 494 - agno =3D 495 - agno =3D 496 - agno =3D 497 - agno =3D 498 - agno =3D 499 - agno =3D 500 - agno =3D 501 - agno =3D 502 - agno =3D 503 - agno =3D 504 - agno =3D 505 - agno =3D 506 - agno =3D 507 - agno =3D 508 - agno =3D 509 - agno =3D 510 - agno =3D 511 - agno =3D 512 - agno =3D 513 - agno =3D 514 - agno =3D 515 - agno =3D 516 - agno =3D 517 - agno =3D 518 - agno =3D 519 - agno =3D 520 - agno =3D 521 - agno =3D 522 - agno =3D 523 - agno =3D 524 - agno =3D 525 - agno =3D 526 - agno =3D 527 - agno =3D 528 - agno =3D 529 - agno =3D 530 - agno =3D 531 - agno =3D 532 - agno =3D 533 - agno =3D 534 - agno =3D 535 - agno =3D 536 - agno =3D 537 - agno =3D 538 - agno =3D 539 - agno =3D 540 - agno =3D 541 - agno =3D 542 - agno =3D 543 - agno =3D 544 - agno =3D 545 - agno =3D 546 - agno =3D 547 - agno =3D 548 - agno =3D 549 - agno =3D 550 - agno =3D 551 - agno =3D 552 - agno =3D 553 - agno =3D 554 - agno =3D 555 - agno =3D 556 - agno =3D 557 - agno =3D 558 - agno =3D 559 - agno =3D 560 - agno =3D 561 - agno =3D 562 - agno =3D 563 - agno =3D 564 - agno =3D 565 - agno =3D 566 - agno =3D 567 - agno =3D 568 - agno =3D 569 - agno =3D 570 - agno =3D 571 - agno =3D 572 - agno =3D 573 - agno =3D 574 - agno =3D 575 - agno =3D 576 - agno =3D 577 - agno =3D 578 - agno =3D 579 - agno =3D 580 - agno =3D 581 - agno =3D 582 - agno =3D 583 - agno =3D 584 - agno =3D 585 - agno =3D 586 - agno =3D 587 - agno =3D 588 - agno =3D 589 - agno =3D 590 - agno =3D 591 - agno =3D 592 - agno =3D 593 - agno =3D 594 - agno =3D 595 - agno =3D 596 - agno =3D 597 - agno =3D 598 - agno =3D 599 - agno =3D 600 - agno =3D 601 - agno =3D 602 - agno =3D 603 - agno =3D 604 - agno =3D 605 - agno =3D 606 - agno =3D 607 - agno =3D 608 - agno =3D 609 - agno =3D 610 - agno =3D 611 - agno =3D 612 - agno =3D 613 - agno =3D 614 - agno =3D 615 - agno =3D 616 - agno =3D 617 - agno =3D 618 - agno =3D 619 - agno =3D 620 - agno =3D 621 - agno =3D 622 - agno =3D 623 - agno =3D 624 - agno =3D 625 - agno =3D 626 - agno =3D 627 - agno =3D 628 - agno =3D 629 - agno =3D 630 - agno =3D 631 - agno =3D 632 - agno =3D 633 - agno =3D 634 - agno =3D 635 - agno =3D 636 - agno =3D 637 - agno =3D 638 - agno =3D 639 - agno =3D 640 - agno =3D 641 - agno =3D 642 - agno =3D 643 - agno =3D 644 - agno =3D 645 - agno =3D 646 - agno =3D 647 - agno =3D 648 - agno =3D 649 - agno =3D 650 - agno =3D 651 - agno =3D 652 - agno =3D 653 - agno =3D 654 - agno =3D 655 - agno =3D 656 - agno =3D 657 - agno =3D 658 - agno =3D 659 - agno =3D 660 - agno =3D 661 - agno =3D 662 - agno =3D 663 - agno =3D 664 - agno =3D 665 - agno =3D 666 - agno =3D 667 - agno =3D 668 - agno =3D 669 - agno =3D 670 - agno =3D 671 - agno =3D 672 - agno =3D 673 - agno =3D 674 - agno =3D 675 - agno =3D 676 - agno =3D 677 - agno =3D 678 - agno =3D 679 - agno =3D 680 - agno =3D 681 - agno =3D 682 - agno =3D 683 - agno =3D 684 - agno =3D 685 - agno =3D 686 - agno =3D 687 - agno =3D 688 - agno =3D 689 - agno =3D 690 - agno =3D 691 - agno =3D 692 - agno =3D 693 - agno =3D 694 - agno =3D 695 - agno =3D 696 - agno =3D 697 - agno =3D 698 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 / ...=20 - traversal finished ...=20 - traversing all unattached subtrees ...=20 - traversals finished ...=20 - moving disconnected inodes to lost+found ...=20 Phase 7 - verify and correct link counts... done ----=_NextPart_ST_08_33_19_Tuesday_November_25_2003_26309-- From owner-linux-xfs@oss.sgi.com Tue Nov 25 06:34:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 06:34:56 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPEYiTa014346 for ; Tue, 25 Nov 2003 06:34:44 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Tue, 25 Nov 2003 08:35:38 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 08:34:36 -0600 Message-ID: From: Gustavo Rincon To: "'Nathan Scott'" Cc: "'linux-xfs@oss.sgi.com'" Date: Tue, 25 Nov 2003 08:34:33 -0600 Subject: RE: XFS and LBD patch on 2.4.20 or 2.4.22 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 5726 Lines: 185 Well for this test I'm using kernel-2.4.22 plus a version of the lbd patch (linux-2.4.28-18-rh-lbd.path took from the SGI ftp, i don't know if this patch is still available on the SGI ftp) and SGI XFS snapshot-2.4.22-2003-11-10_23:49_UTC I did some modification to the lbd patch to make it suitable for 2.4.22, this patch has #define HAVE_SECTOR_T on include/linux/type.h. I compiled the kernel with XFS builded as module and the LBD option enable. (used gcc (GCC) 3.2 20020903) and It was installed in the target machine. I modified the include/xfs_types.h on the xfsprogs-2.5.6 directory, the #define XFS_BIG_FILESYSTEMS 0 was changed to #define XFS_BIG_FILESYSTEMS 1 on line 221. The xfsprogs was compiled and installed in the target machine. #if defined(CONFIG_LBD) || (defined(HAVE_SECTOR_T) && (BITS_PER_LONG == 64)) # ifndef XFS_BIG_FILESYSTEMS # define XFS_BIG_FILESYSTEMS 1 # endif #else # ifndef XFS_BIG_FILESYSTEMS # define XFS_BIG_FILESYSTEMS 1 # endif #endif Hardware used: A DUAL PENTIUM 4 XEON motherboard with 1 GBytes of RAM. 3ware raid controller 7000 series with 12 Serial ATA 250Gbytes disk and two raid0 luns were defined (each one with 6 disks or 1.5 Terabyte LUNS) Testing performed 1.- Using the raidtools a md0 device was created. The following raidtab file was used. raiddev /dev/md0 raid-level 0 nr-raid-disks 2 chunk-size 512 device /dev/sda3 raid-disk 0 device /dev/sdb3 raid-disk 1 2.- mkfs.xfs -f /dev/md0 was executed. 3.- mount -t xfs /dev/md0 /mnt was executed. the dmesg output was : SGI XFS snapshot-2.4.22-2003-11-10_23:49_UTC with ACLs, large block numbers, no debug enabled SGI XFS Quota Management subsystem 4.- cd /mnt was executed. 5.- xfs_mkfile 600G test1 was executed sucessfully. 6.- xfs_mkfile 500G test2 was executed sucessfully. 7.- xfs_mkfile 400G test3 was executed sucessfully. 8.- xfs_mkfile 400G test4 was executed sucessfully. 9.- xfs_mkfile 500G test5 was executed sucessfully. 10.- xfs_mkfile 500G test6 was executed sucessfully. 11.- ls -l /mnt was executed and all the created files were presented in the list. 12.- cd / and umount /mnt 13.- xfs_repair /dev/md0 (look in attachment log1 to see the output of xfs_repair) Partial output of xfs_repair 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 bad fwd (right) sibling pointer (saw 5888878 should be NULLDFSBNO) in inode 2057 (data fork) bmap btree block 695161421 bad data fork in inode 2057 cleared inode 2057 bad fwd (right) sibling pointer (saw 5888944 should be NULLDFSBNO) in inode 2058 (data fork) bmap btree block 695161487 bad data fork in inode 2058 cleared inode 2058 . . . Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 entry "test5" in shortform directory 2048 references free inode 2057 junking entry "test5" in directory inode 2048 entry "test6" in shortform directory 2048 references free inode 2058 junking entry "test6" in directory inode 2048 14.- mount -t xfs /dev/md0 /mnt 15.- ls -l /mnt was executed and test5 and test6 were not in the directory. Now will try to use xfsprogs-2.6.0 version and try to reproduce the problem, something that I noticed in the new version of xfsprogs is that on xfs_types.h was changed from the 2.5.6 version. #if defined(CONFIG_LBD) || (defined(HAVE_SECTOR_T) && (BITS_PER_LONG == 64)) # define XFS_BIG_BLKNOS 1 # if BITS_PER_LONG == 64 # define XFS_BIG_INUMS 1 # else # define XFS_BIG_INUMS 0 # endif #else # define XFS_BIG_BLKNOS 0 # define XFS_BIG_INUMS 0 #endif Thank you Gustavo Rincon -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Monday, November 24, 2003 4:04 PM To: Gustavo Rincon Cc: 'linux-xfs@oss.sgi.com' Subject: Re: XFS and LBD patch on 2.4.20 or 2.4.22 hi there, On Mon, Nov 24, 2003 at 02:43:06PM -0600, Gustavo Rincon wrote: > Hi guys, I have a XFS 1.3.1 version compile on linux kernel-2.4.20 (Red Hat > version) and kernel-2.4.22 (Vanilla) and > i was wonder what changes I have to do to xfsprogs in order to create and > support filesystem greater than 2 Terabytes. None. > The kernel that I compiled with the gelato LBD patch and I tested with EXT3 > and REISERFS on a MD device, the size of the Device is 2.7 Terabytes, > and everything looks OKAY, but when i try to tested with XFS sometime after > i perform xfs_repair some files are erased by the xfs_repair utility. There are changes in this area in CVS - could you try a current CVS kernel. Also, can you describe your tests in detail, and if the problem reproducible for you? (if so, hopefully it is for me too, so I can fix it ;) > All this testing was done in a PENTIUM 4 XEION and gcc (GCC) 3.2 20020903 > (Red Hat Linux 8.0 3.2-7) to compile the Kernel and the xfsprogs. > > The xfsprogs utility (2.5.6) was compiled with the xfs_types.h file > modified (The XFS_BIG_FILESYSTEMS #define was turned ON). Thats unnecessary - it is always "on" during an xfsprogs build; see xfsprogs/include/builddefs.in. > Do I have to compile the xfsprogs using or modifying more #defines? No. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 25 07:08:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 07:08:32 -0800 (PST) Received: from imo-m07.mx.aol.com (imo-m07.mx.aol.com [64.12.136.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPF8BTa016394 for ; Tue, 25 Nov 2003 07:08:11 -0800 Received: from AndyLiebman@aol.com by imo-m07.mx.aol.com (mail_out_v36_r1.1.) id x.1e2.143843bf (3964); Tue, 25 Nov 2003 10:07:57 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <1e2.143843bf.2cf4ca4c@aol.com> Date: Tue, 25 Nov 2003 10:07:56 EST Subject: XFS RAID only writing half the time To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5002 X-archive-position: 1108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1632 Lines: 36 A puzzle. I am writing uncompressed video (18 MB/sec) to a RAID 5 array through a Gigabit network. I am using the xfs filesystem on the array with a block size of 4096 and an internal log. The RAID has a chunk size of 128K. Otherwise, all settings are the default (i.e., left symetric algorithm). I have a P4-3.06 with 1 GB RAM. I have hyperthreading enabled -- and Mandrake 9.2 (2.4.22 kernel) shows that I have 2 CPUs. While capturing video, I am running a monitoring program, XOSVIEW -- which shows usage of memory, cpu, ints (interrupts?), and disk read/write/idle activity. Although data is coming into my Linux machine at a rate of 18 MB/sec, I don't see any disk activity for as much as 30 or 40 seconds after I begin recording video. Looking at XOSVIEW, I can see on the memory display that the cache fills up until my memory is almost entirely full, and ONLY THEN does the disk writing activity begin. Usually this is fine, but once in a while -- after capturing video for 20 minutes or so, the system will have a "hiccup" and fail to write data fast enough. My video editing application will then stop capturing. I don' It seems to me that there must be a way to tell my system not to cache so much data before beginning to write so that there is more margin for delays. It also seems there should be a way to tell my system to spend more time writing to the RAID array. When I test out my RAID with Bonnie++, it looks as if sequential writes are about 30 MB/sec -- so the RAID itself is fast enough to keep up with the video. And so is the gigabit network. Does anybody have any ideas? From owner-linux-xfs@oss.sgi.com Tue Nov 25 07:40:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 07:41:05 -0800 (PST) Received: from hvs.envisage.co.za (hvs.envisage.co.za [196.36.161.89]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPFeoTa017605 for ; Tue, 25 Nov 2003 07:40:53 -0800 Received: from hvisage by hvs.envisage.co.za with local (Exim 4.24) id 1AOfIx-0005M0-7e; Tue, 25 Nov 2003 17:40:43 +0200 Date: Tue, 25 Nov 2003 17:40:43 +0200 From: Hendrik Visage To: AndyLiebman@aol.com Cc: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS RAID only writing half the time Message-ID: <20031125154043.GK17908@hvs.envisage.co.za> References: <1e2.143843bf.2cf4ca4c@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e2.143843bf.2cf4ca4c@aol.com> User-Agent: Mutt/1.4.1i X-message-flag: Outlook is Exploitable! -- http://www.rodos.net/outlook/ X-archive-position: 1109 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hvisage@envisage.co.za Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 27 On Tue, Nov 25, 2003 at 10:07:56AM -0500, AndyLiebman@aol.com wrote: > A puzzle. > I have a P4-3.06 with 1 GB RAM. I have hyperthreading enabled -- and Mandrake > 9.2 (2.4.22 kernel) shows that I have 2 CPUs. I've seen similar troubles with the SuSE kernels. I believe it has something to do with some of the desktop/interactive patches that fills up memory too much before flushing caches. > Although data is coming into my Linux machine at a rate of 18 MB/sec, I don't > see any disk activity for as much as 30 or 40 seconds after I begin recording > video. Looking at XOSVIEW, I can see on the memory display that the cache > fills up until my memory is almost entirely full, and ONLY THEN does the disk > writing activity begin. > > Usually this is fine, but once in a while -- after capturing video for 20 > minutes or so, the system will have a "hiccup" and fail to write data fast > enough. My video editing application will then stop capturing. I don' Play with the settings of: sysctl -a | grep vm.bdflush vm.bdflush = 30 500 0 0 500 3000 60 20 0 I've found the right settings would alleviate this hiccup issue. HEndrik From owner-linux-xfs@oss.sgi.com Tue Nov 25 07:58:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 07:58:32 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPFwJTa018479 for ; Tue, 25 Nov 2003 07:58:20 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hAPG19uW003072; Tue, 25 Nov 2003 11:01:09 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hAPG18Bo016725; Tue, 25 Nov 2003 11:01:08 -0500 Date: Tue, 25 Nov 2003 11:01:08 -0500 (EST) From: Net Llama! To: Hendrik Visage cc: AndyLiebman@aol.com, linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS RAID only writing half the time In-Reply-To: <20031125154043.GK17908@hvs.envisage.co.za> Message-ID: References: <1e2.143843bf.2cf4ca4c@aol.com> <20031125154043.GK17908@hvs.envisage.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 1110 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1493 Lines: 33 On Tue, 25 Nov 2003, Hendrik Visage wrote: > On Tue, Nov 25, 2003 at 10:07:56AM -0500, AndyLiebman@aol.com wrote: > > A puzzle. > > I have a P4-3.06 with 1 GB RAM. I have hyperthreading enabled -- and Mandrake > > 9.2 (2.4.22 kernel) shows that I have 2 CPUs. > > I've seen similar troubles with the SuSE kernels. I believe it has > something to do with some of the desktop/interactive patches that fills > up memory too much before flushing caches. > > > Although data is coming into my Linux machine at a rate of 18 MB/sec, I don't > > see any disk activity for as much as 30 or 40 seconds after I begin recording > > video. Looking at XOSVIEW, I can see on the memory display that the cache > > fills up until my memory is almost entirely full, and ONLY THEN does the disk > > writing activity begin. > > > > Usually this is fine, but once in a while -- after capturing video for 20 > > minutes or so, the system will have a "hiccup" and fail to write data fast > > enough. My video editing application will then stop capturing. I don' > > Play with the settings of: > sysctl -a | grep vm.bdflush > vm.bdflush = 30 500 0 0 500 3000 60 20 0 > > I've found the right settings would alleviate this hiccup issue. Is there any guidance or documentation on how to set those values? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Nov 25 08:20:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 08:20:45 -0800 (PST) Received: from web21004.mail.yahoo.com (web21004.mail.yahoo.com [216.136.227.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPGKMTa021944 for ; Tue, 25 Nov 2003 08:20:34 -0800 Message-ID: <20031125162021.47229.qmail@web21004.mail.yahoo.com> Received: from [198.253.30.157] by web21004.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 08:20:21 PST Date: Tue, 25 Nov 2003 08:20:21 -0800 (PST) From: Anubis922 Subject: Boot Partition To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: anubis922@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 304 Lines: 10 I have just downloaded Mandrake 9.2 and I am thinking about using the XFS filesystem. My question is can I use the XFS filesystem on /boot partition? If not what filesystem do you suggest? __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From owner-linux-xfs@oss.sgi.com Tue Nov 25 08:23:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 08:23:11 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPGMxTa022355 for ; Tue, 25 Nov 2003 08:23:00 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hAPGPu0A030244; Tue, 25 Nov 2003 11:25:56 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hAPGPujt016306; Tue, 25 Nov 2003 11:25:56 -0500 Date: Tue, 25 Nov 2003 11:25:56 -0500 (EST) From: Net Llama! To: Anubis922 cc: linux-xfs@oss.sgi.com Subject: Re: Boot Partition In-Reply-To: <20031125162021.47229.qmail@web21004.mail.yahoo.com> Message-ID: References: <20031125162021.47229.qmail@web21004.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 12 On Tue, 25 Nov 2003, Anubis922 wrote: > I have just downloaded Mandrake 9.2 and I am thinking > about using the XFS filesystem. My question is can I > use the XFS filesystem on /boot partition? If not yes. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Nov 25 08:48:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 08:48:41 -0800 (PST) Received: from cyber1hq.adic.com (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPGmSTa023410 for ; Tue, 25 Nov 2003 08:48:29 -0800 X-Authentication-Warning: localhost.localdomain: slord set sender to lord@adic.com using -f Subject: Re: Boot Partition From: Steve Lord Reply-To: lord@adic.com To: Anubis922 Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031125162021.47229.qmail@adic.com> References: <20031125162021.47229.qmail@adic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1069778898.2640.11.camel@adic.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 25 Nov 2003 10:48:18 -0600 X-archive-position: 1113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Content-Length: 547 Lines: 18 On Tue, 2003-11-25 at 10:20, Anubis922 wrote: > I have just downloaded Mandrake 9.2 and I am thinking > about using the XFS filesystem. My question is can I > use the XFS filesystem on /boot partition? If not > what filesystem do you suggest? > XFS works, just keep your boot record and xfs partitions seperate. XFS uses block zero of a partition and if you install lilo on the same partition as xfs for example, you end up trashing the filesystem. Put the boot record in the MBR or on your swap device. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Tue Nov 25 08:52:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 08:52:19 -0800 (PST) Received: from community16.interfree.it (community16.interfree.it [213.158.72.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPGq5Ta023844 for ; Tue, 25 Nov 2003 08:52:06 -0800 Received: (qmail 3015 invoked by uid 320); 25 Nov 2003 16:52:04 -0000 Received: from alessandrobottoni@interfree.it by community16 by uid 712 with qmail-scanner-1.20rc3 (clamuko: 0.60. Clear:RC:1:. Processed in 0.708212 secs); 25 Nov 2003 16:52:04 -0000 Received: from unknown (HELO host41-140.pool80104.interbusiness.it) (80.104.140.41) by mail.interfree.it with SMTP; 25 Nov 2003 16:52:03 -0000 From: Alessandro Bottoni To: linux-xfs@oss.sgi.com Subject: Newbie questions Date: Tue, 25 Nov 2003 17:49:45 +0000 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311251749.45683.alessandrobottoni@interfree.it> X-archive-position: 1114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alessandrobottoni@interfree.it Precedence: bulk X-list: linux-xfs Content-Length: 1612 Lines: 36 Well, I'm a newbie, so here is the usual list of newbie questions :-) - Is there any (readable/understandable) example of the use of EA and/or ACL from within a C or C++ client program? - Is there any other C++ (or even a "simplified C") wrapper for the C/ioctl XFS API beside the one supplied by libferris? - Is there any Python/Perl/Ruby binding of the XFS EA/ACL API? - Is there any programmer's guide or any tutorial? Just to reassure you I read the available docu before bothering you: - "Some functionality specific to the XFS filesystem is accessible to applications through the Linux ioctl(2) interface." (from "man 5 xfs"). => Any example for mere mortals? - "The http://witme.sourceforge.net/libferris.web/ has tools for accessing Extended Attributes including writing to XFS Extended Attributes." (from XFS FAQ page) => The link to "what are ACL" and other pages are broken... Any other docu available? And... - So far, I found just one client program that uses XFS EAs: DoXFS (a document management program that is available at sourceforge.net). Is there any other program that uses EA and/or ACL? - I found a whirlwind intro to XFS at IBM developerworks, as well. Nice but very introductory. BTW: does anybody know if there is any SCM (CVS-like or, more precisely, ClearCase-like) program based on XFS? I would have expected that the ClearCase-clone "Katie" (http://www.netcraft.com.au/geoffrey/katie/) used it but, apparently, it uses its own EA/ACL technology. Many thanks in advance. ---------------------------------- Alessandro Bottoni alessandrobottoni@interfree.it From owner-linux-xfs@oss.sgi.com Tue Nov 25 09:41:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 09:42:12 -0800 (PST) Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPHfmTa030093 for ; Tue, 25 Nov 2003 09:41:48 -0800 Received: from AndyLiebman@aol.com by imo-r01.mx.aol.com (mail_out_v36_r1.1.) id u.114.2c0b3fa3 (3964); Tue, 25 Nov 2003 12:41:23 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <114.2c0b3fa3.2cf4ee43@aol.com> Date: Tue, 25 Nov 2003 12:41:23 EST Subject: Re: XFS RAID only writing half the time To: hvisage@envisage.co.za CC: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5002 X-archive-position: 1115 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 2549 Lines: 60 Hendrik, Thanks for that suggestion. I tried it. Went to Google and under "vm.bdflush" found some documentation (http://www.faqs.org/docs/securing/chap6sec68.html) that explained what the various numbers mean. I didn't understand them all, but when I experimented and put in: 10 1200 0 0 500 3000 60 20 0 (Just changed the first two figures) I noticed when looking at XOSVIEW that now I was writing to the disks about two or three times more often, and I guess writing smaller amounts of information each time. And the video capture lasted much longer than it did with the default Mandrake 9.2 setting (exactly the numbers you typed below, by the way). So now, do you know of any logical way to tweak these different values? I'm not sure that the second value of 1200 makes too much sense for what I'm trying to do. It seems like the higher the number in that position, the more "bursty" the writes are. I'm going to want to try to come up with some settings that allow capturing uncompressed video (18 MB/sec) while one or two other users are trying to read DV video (3.5 MB/sec) from the same drives. I guess that means I will want get the cache written to disk as soon as possible (leaving margin for difficult moments) while allowing other users to read from the disk on demand. In some ways, reading video files is more demanding than writing -- because what is read MUST arrive at the client computer exactly when needed. Also, do you know how Samba settings and TCP/IP settings could interact with this bdflush setting? I am using Samba 3.0.0 by the way. It's exciting that you can do all this tweaking in Linux. I'm a total newbie. But it's also a little daunting. Thanks again Andy Liebman > Although data is coming into my Linux machine at a rate of 18 MB/sec, I don't > see any disk activity for as much as 30 or 40 seconds after I begin recording > video. Looking at XOSVIEW, I can see on the memory display that the cache > fills up until my memory is almost entirely full, and ONLY THEN does the disk > writing activity begin. > > Usually this is fine, but once in a while -- after capturing video for 20 > minutes or so, the system will have a "hiccup" and fail to write data fast > enough. My video editing application will then stop capturing. I don' Play with the settings of: sysctl -a | grep vm.bdflush vm.bdflush = 30 500 0 0 500 3000 60 20 0 I've found the right settings would alleviate this hiccup issue. HEndrik From owner-linux-xfs@oss.sgi.com Tue Nov 25 09:44:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 09:44:38 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPHiQTa030501 for ; Tue, 25 Nov 2003 09:44:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPFovOO012359 for ; Tue, 25 Nov 2003 07:50:57 -0800 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAPHiKP514292360; Tue, 25 Nov 2003 11:44:20 -0600 (CST) Message-ID: <3FC394F4.4030305@sgi.com> Date: Tue, 25 Nov 2003 11:44:20 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump feature request References: <002a01c3a7ad$ff260b50$6207a8c0@titanic> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4907 Lines: 104 Hi Jeremy, Jeremy Jackson wrote: > 1) xfsdump -J ... it is required when /var is mounted read-only. This > inhibits writing the dump session to /var/lib/xfsdump/inventory, as well as > writing the dump session to a tape file. Yet when booted from cd/network > and root is read-only, it is often desirable to make a dump while doing > system repairs (xfs_repair needs to boot from somewhere else to run even). > Also related is the "miniroot" environment in the xfsdump man page... this > could use some more explanation. miniroot is an IRIX installation tool used when fundamental IRIX services, such as filesystem management, are unavailable. It's used to transfer installation tools from the source distribution to the target system using PROM (programmable read-only memory) and the swap partition of the disk. The Linux xfsdump man page should NOT be making any references to miniroot. This must have been overlooked when porting the xfsdump man page from IRIX to Linux. It will be fixed in an upcoming release. Thanks! > It would be nice if -J or some other option would allow the user to bypass > the update of /var/lib/xfsdump/inventory, but still write the session > inventory to a tape file, since xfsrestore can later be used to merge (or > inspect?) it when listing/restore a session. (related to #2) This would be a nice-to-have feature but I'm not sure how high of a priority this is right now. I'll open an internal RFE (requested feature enhancement) but I can't guarantee that we'll be able to get to it right away. Would you settle for a workaround in the meantime? Depending on how much memory you have and how big your inventory files are, you could use tmpfs to mount a temporary writeable directory on /var/lib/xfsdump/inventory. This will trick xfsdump so it doesn't force you to use the -J option (since /var/lib/xfsdump/inventory will appear writeable). The inventory will then be written to the tmpfs swap space as well as to the tape. When the dump has completed you can unmount tmpfs, discarding any inventory file(s) written to memory. tmpfs grows dynamically so you may want to set a size limit on it. # mount -t tmpfs tmpfs /dev/shm # mount -w -t tmpfs tmpfs /var/lib/xfsdump/inventory # Or, add these lines to /etc/fstab: tmpfs /dev/shm tmpfs defaults 0 0 tmpfs /var/lib/xfsdump/inventory tmpfs size=750M,mode=2777 0 0 See the tmpfs documentation in the kernel source tree for more info on tmpfs: "linux/Documentation/filesystems/tmpfs.txt". > 2) The man page for xfsdump states that the inventory written to tape is > currently not used, however I was able to merge it into > /var/lib/xfsdump/inventory when using xfsrestore to list a session on tape. > It would be nice if the man pages stated exactly when and how the inventory > file on the tape is used/not used. I think when the man page says the inventory file on the tape isn't used, it means that xfsdump neither looks at it nor depends upon it. xfsdump only looks at inventory files in /var/lib/xfsdump/inventory when searching for a specific dump. The inventory file that gets added to the tape at the end of each dump session is for the user's benefit only, in order to query the dump sessions on a given tape. Does this make sense? Perhaps a better explanation in the xfsdump man page is needed. > 3) This has been mentioned before on the list... What is the difference > between "mt erase" and "xfsdump -o" and "xfsdump -E". mt erase Erases tape from CURRENT position to end of tape (EOT) xfsdump -o Overwrites tape without checking contents xfsdump -E Pre-Erases ENTIRE tape from BOT to EOT > Is there a way to erase a tape but keep it's media object UUID. Unforchunately, no. All three of the options above cause a new media objec UUID to be created when the next (first) dump begins. > It would be ideal to allow this, and prune the inventory of that > media object's UUID automatically. If this is possible, then adding > a counter to how many times that media object has been used would > give it all the features of Veritas. Would be nice. You can use the 'mobjid=' option with -I to prune out the inventory of a specific media object's UUID, but (as you mentioned) the media id is not constant for a given tape. I agree, it would be really nice if xfsdump could associate a constant media id for each tape, where the id remained constant accross erases, overwrites, etc.. I'll open an RFE for this as well. I'm not all that familiar with the Veritas products, maybe you can help me out here. Would the purpose of a counter be to keep track of the life span of each tape? Would it include the number of dumps (writes) AND the number of restores (reads), or just the dumps? Thanks, Mandy -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 25 10:00:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 10:01:03 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPI0eTa031624 for ; Tue, 25 Nov 2003 10:00:40 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPG7BOO013922 for ; Tue, 25 Nov 2003 08:07:11 -0800 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAPI0YP514336304; Tue, 25 Nov 2003 12:00:34 -0600 (CST) Message-ID: <3FC398C2.8010407@sgi.com> Date: Tue, 25 Nov 2003 12:00:34 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump fails to overwrite stream terminator - dumps lost References: <005f01c3aacb$653522d0$6207a8c0@titanic> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2582 Lines: 53 Jeremy Jackson wrote: > I have done dumps of the filesystems of 3 machines to a common tape drive, > an Exabyte EXB-8500. One machine contains the tape drive, the other two use > rmt. Five tapes were filled (5GB each), with a sixth only partly used. > > Next I wanted to test overwrite handling, as I was having problems with an > earlier version of xfsdump. I started a dump of a 75GB filesystem, without > using the -o flag. I began with the partly used sixth tape. The previously > used dumps had apparently left a stream terminator at media file 12, and > this is where the dump began. > > After the tape became full, a tape change was requested. I either felt like > testing xfsdump, or I wasn't thinking clearly, so I accepted the tape change > request without changing the tape. As I watched "xfsdump: preparing drive", > the tape was rewound, and media files were examined. I was shocked to see > it continue dumping at media file 12 *again*. It found a stream terminator, > and that was all it was waiting for! > > I noticed a bug was fixed in 2.2.13 regarding handling multiple backups to a > single tape, but I'm not sure what the exact problem was that was fixed. > The earlier dumps on the tapes were with the older version, 2.2.11-1, and > the *dump in question* was with 2.2.14-1. As you suspected, this is caused by the problem that got fixed in 2.2.13. It's a nasty one! Any tape backups written with 2.2.12 or earlier are not reliable when multiple dump sessions are involved. The problem was introduced when xfsdump was ported from IRIX to Linux. On IRIX, the TS tape driver sets EOF whether it is to the left OR right of a tape mark. On Linux, the ST tape driver ONLY sets EOF when positioned to the right of a tape mark. On IRIX, the MTBSF,1 (backward space 1 filemark) ioctl moves backward along the tape until it finds a filemark, then positions the tape to the RIGHT of (after) the filemark. On Linux, the MTBSF,1 ioctl moves back one filemark and positions the tape to the LEFT of (before) the filemark. These differences are very important!! These filemark positioning differences were causing the tape to be rewound before each dump and the next dump would begin at the exact same start position of the last dump. The result of this was that each new dump would always overwrite the previous dump, so a tape would only ever contain one full (most recent) dump session at a time!! Please use 2.2.13 or later for any new backups. Thanks, Mandy -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 25 10:58:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 10:58:25 -0800 (PST) Received: from hvs.envisage.co.za (hvs.envisage.co.za [196.36.161.89]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPIw1Ta001147 for ; Tue, 25 Nov 2003 10:58:04 -0800 Received: from hvisage by hvs.envisage.co.za with local (Exim 4.24) id 1AOiNl-0005dI-Hp; Tue, 25 Nov 2003 20:57:53 +0200 Date: Tue, 25 Nov 2003 20:57:53 +0200 From: Hendrik Visage To: AndyLiebman@aol.com Cc: hvisage@envisage.co.za, linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS RAID only writing half the time Message-ID: <20031125185753.GM17908@hvs.envisage.co.za> References: <114.2c0b3fa3.2cf4ee43@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <114.2c0b3fa3.2cf4ee43@aol.com> User-Agent: Mutt/1.4.1i X-message-flag: Outlook is Exploitable! -- http://www.rodos.net/outlook/ X-archive-position: 1118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hvisage@envisage.co.za Precedence: bulk X-list: linux-xfs Content-Length: 657 Lines: 18 On Tue, Nov 25, 2003 at 12:41:23PM -0500, AndyLiebman@aol.com wrote: > Hendrik, > > Thanks for that suggestion. I tried it. Went to Google and under "vm.bdflush" > found some documentation (http://www.faqs.org/docs/securing/chap6sec68.html) > that explained what the various numbers mean. I didn't understand them all, > but when I experimented and put in: > > 10 1200 0 0 500 3000 60 20 0 (Just changed the first > two figures) More Documentation is in /usr/src/linux/Documentation/filesystems/proc.txt, look for "Table 2-2: Parameters in /proc/sys/vm/bdflush " I recall also fixing some values in the middle.. HEndrik From owner-linux-xfs@oss.sgi.com Tue Nov 25 11:27:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 11:27:28 -0800 (PST) Received: from campbell.mps.ohio-state.edu (campbell.mps.ohio-state.edu [128.146.38.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPJRGTa001720 for ; Tue, 25 Nov 2003 11:27:17 -0800 Received: from mps.ohio-state.edu (babar3.mps.ohio-state.edu [128.146.38.46]) by campbell.mps.ohio-state.edu (8.12.10/8.12.10) with ESMTP id hAPJQnId002019; Tue, 25 Nov 2003 14:26:49 -0500 (EST) Message-ID: <3FC3ACF9.4000509@mps.ohio-state.edu> Date: Tue, 25 Nov 2003 14:26:49 -0500 From: Dirk Hufnagel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: AndyLiebman@aol.com CC: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS RAID only writing half the time References: <114.2c0b3fa3.2cf4ee43@aol.com> In-Reply-To: <114.2c0b3fa3.2cf4ee43@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hufnagel@mps.ohio-state.edu Precedence: bulk X-list: linux-xfs Content-Length: 1458 Lines: 31 AndyLiebman@aol.com wrote: > Hendrik, > I'm going to want to try to come up with some settings that allow capturing > uncompressed video (18 MB/sec) while one or two other users are trying to read > DV video (3.5 MB/sec) from the same drives. I guess that means I will want get > the cache written to disk as soon as possible (leaving margin for difficult > moments) while allowing other users to read from the disk on demand. In some > ways, reading video files is more demanding than writing -- because what is read > MUST arrive at the client computer exactly when needed. Could be problematic since you can't just add bandwidth requierements and compare it to the maximum bandwidth. Multiple active disk access jobs means that the disk will be seeking, which means that the read accesses will interfere with your write stream, possible to a point where the writing will skip. If you are not writing 24/7 and it's in your budget, I would put two RAID arrays into the machine, one to write to and the other one for reading. You can synchronize them whenever you are not writing. Of course, that only works if you don't need to read the written data immediatly. For the read array I would use Raid5 for the data security and for the write array you can either use Raid5 or Raid0. Raid0 is faster compared to Raid5, especially for writes, but it would mean your data isn't secure until it has been copied to the other Raid5 array. Dirk From owner-linux-xfs@oss.sgi.com Tue Nov 25 11:33:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 11:33:29 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPJXHTa002179 for ; Tue, 25 Nov 2003 11:33:17 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAPJX9KN002462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Nov 2003 14:33:15 -0500 Message-ID: <3FC3AD4D.7070603@coplanar.net> Date: Tue, 25 Nov 2003 14:28:13 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: Mandy Kirkconnell CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump feature request References: <002a01c3a7ad$ff260b50$6207a8c0@titanic> <3FC394F4.4030305@sgi.com> In-Reply-To: <3FC394F4.4030305@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 4361 Lines: 109 Hi Mandy, Thanks for looking into this. I see XFS as the Linux filesystem with the greatest potential. I hope contribute ideas that help integrate it fully. See my comments below. Mandy Kirkconnell wrote: > Hi Jeremy, > > Jeremy Jackson wrote: > -miniroot explanation omitted-- >> It would be nice if -J or some other option would allow the user to >> bypass >> the update of /var/lib/xfsdump/inventory, but still write the session >> inventory to a tape file, since xfsrestore can later be used to merge (or >> inspect?) it when listing/restore a session. (related to #2) > > > This would be a nice-to-have feature but I'm not sure how high of a > priority this is right now. I'll open an internal RFE (requested > feature enhancement) but I can't guarantee that we'll be able to get to > it right away. > > Would you settle for a workaround in the meantime? --tmpfs solution omitted-- This will do. > I think when the man page says the inventory file on the tape isn't > used, it means that xfsdump neither looks at it nor depends upon it. > xfsdump only looks at inventory files in /var/lib/xfsdump/inventory when > searching for a specific dump. The inventory file that gets added to > the tape at the end of each dump session is for the user's benefit only, > in order to query the dump sessions on a given tape. > > Does this make sense? Perhaps a better explanation in the xfsdump man > page is needed. Pointing to the xfsrestore man page for a possible use would do the trick. Also missing from the xfsrestore man page is how to use these inventory files, and how they are/are not merged into the inventory database. >> Is there a way to erase a tape but keep it's media object UUID. > > > Unforchunately, no. All three of the options above cause a new media > objec UUID to be created when the next (first) dump begins. > >> It would be ideal to allow this, and prune the inventory of that >> media object's UUID automatically. If this is possible, then adding >> a counter to how many times that media object has been used would >> give it all the features of Veritas. Would be nice. > > > You can use the 'mobjid=' option with -I to prune out the inventory of a > specific media object's UUID, but (as you mentioned) the media id is not > constant for a given tape. I agree, it would be really nice if xfsdump > could associate a constant media id for each tape, where the id remained > constant accross erases, overwrites, etc.. I'll open an RFE for this as > well. > > I'm not all that familiar with the Veritas products, maybe you can help > me out here. Would the purpose of a counter be to keep track of the > life span of each tape? Would it include the number of dumps (writes) > AND the number of restores (reads), or just the dumps? I have not used Veritas Backup Exec personally. The idea came out of a discussion with an admin that uses Veritas. We were comparing the features of xfsdump and Veritas. You are correct - the count is used to determine when a tape should be replaced. I'm not sure if it tracks the restores, but as these are hopefully infrequent tracking the writes should give a reasonable estimate of the tape's life. I'm thinking about making a separate erase utility that can optionally copy the UUID from the tape and create a dummy media file or stream terminator after erasing the tape (optional quick erase - just a rewind and overwrite). It could track tape life separate from inventory database for now. Since tapes must be erased before being reused anyhow due to the way xfsdump -o works, this seems logical. That actually reminds me of another issue. When appending a dump session to a tape with other dump sessions, you don't use the -o flag. But if the session fills the tape, the new tape inserted must not have any xfsdump sessions, or the dump aborts (can't choose overwrite in middle of a dump). "mt erase" takes 3 hours on this Exabyte drive, so I came up with a shortcut: mt rewind ; dd if=/dev/zero of=/dev/tape count=1 bs=245760 (where bs= is the -b size used with xfsdump). It thinks the tape is a corrupt xfsdump tape or a foreign tape, and allows overwrite. I'm not sure what the recomendation for xfsdump is in this scenario... if there is one perhaps it could go in the manpage. Regards, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Tue Nov 25 11:40:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 11:40:13 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPJe0Ta002673 for ; Tue, 25 Nov 2003 11:40:01 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAPJduKN002504 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Nov 2003 14:39:59 -0500 Message-ID: <3FC3AEE3.2080107@coplanar.net> Date: Tue, 25 Nov 2003 14:34:59 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: Mandy Kirkconnell CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump fails to overwrite stream terminator - dumps lost References: <005f01c3aacb$653522d0$6207a8c0@titanic> <3FC398C2.8010407@sgi.com> In-Reply-To: <3FC398C2.8010407@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 3162 Lines: 80 Hi Mandy, I'm a bit confused. The problem occurs on multiple systems when using xfsdump 2.2.14 on a blank tape. The first fs dumps ok, but the rest just keep overwriting the second session. The *older* versions seem to work, in fact I have switched 7 or so systems to the 2.2.11 since it's the only way I can do backups. Sorry if my post was a bit confusing... I made a second post with some newer information. It looks to me like 2.2.12 was a regression, not a fix. Regards, Jeremy Jackson Mandy Kirkconnell wrote: > Jeremy Jackson wrote: > >> I have done dumps of the filesystems of 3 machines to a common tape >> drive, >> an Exabyte EXB-8500. One machine contains the tape drive, the other >> two use >> rmt. Five tapes were filled (5GB each), with a sixth only partly used. >> >> Next I wanted to test overwrite handling, as I was having problems >> with an >> earlier version of xfsdump. I started a dump of a 75GB filesystem, >> without >> using the -o flag. I began with the partly used sixth tape. The >> previously >> used dumps had apparently left a stream terminator at media file 12, and >> this is where the dump began. >> >> After the tape became full, a tape change was requested. I either >> felt like >> testing xfsdump, or I wasn't thinking clearly, so I accepted the tape >> change >> request without changing the tape. As I watched "xfsdump: preparing >> drive", >> the tape was rewound, and media files were examined. I was shocked to >> see >> it continue dumping at media file 12 *again*. It found a stream >> terminator, >> and that was all it was waiting for! >> >> I noticed a bug was fixed in 2.2.13 regarding handling multiple >> backups to a >> single tape, but I'm not sure what the exact problem was that was fixed. >> The earlier dumps on the tapes were with the older version, 2.2.11-1, and >> the *dump in question* was with 2.2.14-1. > > > As you suspected, this is caused by the problem that got fixed in > 2.2.13. It's a nasty one! Any tape backups written with 2.2.12 or > earlier are not reliable when multiple dump sessions are involved. > > The problem was introduced when xfsdump was ported from IRIX to Linux. > On IRIX, the TS tape driver sets EOF whether it is to the left OR right > of a tape mark. On Linux, the ST tape driver ONLY sets EOF when > positioned to the right of a tape mark. On IRIX, the MTBSF,1 (backward > space 1 filemark) ioctl moves backward along the tape until it finds a > filemark, then positions the tape to the RIGHT of (after) the filemark. > On Linux, the MTBSF,1 ioctl moves back one filemark and positions the > tape to the LEFT of (before) the filemark. These differences are very > important!! > > These filemark positioning differences were causing the tape to be > rewound before each dump and the next dump would begin at the exact same > start position of the last dump. The result of this was that each new > dump would always overwrite the previous dump, so a tape would only ever > contain one full (most recent) dump session at a time!! > > Please use 2.2.13 or later for any new backups. > > Thanks, > Mandy > From owner-linux-xfs@oss.sgi.com Tue Nov 25 12:56:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 12:57:16 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPKutTa008158 for ; Tue, 25 Nov 2003 12:56:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPLHSHc020759 for ; Tue, 25 Nov 2003 15:17:29 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAPKulEU3445360 for ; Wed, 26 Nov 2003 07:56:47 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAPKukbe3442163 for linux-xfs@oss.sgi.com; Wed, 26 Nov 2003 07:56:46 +1100 (EST) Date: Wed, 26 Nov 2003 07:56:46 +1100 (EST) From: Nathan Scott Message-Id: <200311252056.hAPKukbe3442163@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - direct IO cleanup X-archive-position: 1122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 927 Lines: 32 Fix up the way we hook into the generic direct IO code a little, so we export fewer symbols specifically for XFS, and make a bit more use of the generic code in XFS. Date: Tue Nov 25 12:48:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162444a linux/mm/filemap.c - 1.123 linux/kernel/ksyms.c - 1.150 linux/include/linux/fs.h - 1.169 Update the way we hook into the generic direct IO code so we share more code. This means we no longer need to dup remove_suid within xfs_write_clear_setuid. Date: Tue Nov 25 12:53:06 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162446a linux/fs/xfs/xfs_rw.c - 1.389 linux/fs/xfs/linux/xfs_lrw.c - 1.207 From owner-linux-xfs@oss.sgi.com Tue Nov 25 13:30:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 13:30:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPLUBTa009192 for ; Tue, 25 Nov 2003 13:30:11 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPLoiHc005844 for ; Tue, 25 Nov 2003 15:50:45 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAPLU3EU3359933 for ; Wed, 26 Nov 2003 08:30:03 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAPLU3go3447351 for linux-xfs@oss.sgi.com; Wed, 26 Nov 2003 08:30:03 +1100 (EST) Date: Wed, 26 Nov 2003 08:30:03 +1100 (EST) From: Nathan Scott Message-Id: <200311252130.hAPLU3go3447351@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Merge up to 2.4.23-rc5 X-archive-position: 1123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 13 Date: Tue Nov 25 13:29:39 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162453a linux/Makefile - 1.198 linux/drivers/char/agp/agpgart_fe.c - 1.13 linux/arch/x86_64/ia32/ia32entry.S - 1.4 linux/arch/x86_64/ia32/sys_ia32.c - 1.6 From owner-linux-xfs@oss.sgi.com Tue Nov 25 14:00:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 14:00:37 -0800 (PST) Received: from fruit.eu.org (daemon@fruit.eu.org [80.126.184.204]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPM05Ta009894 for ; Tue, 25 Nov 2003 14:00:25 -0800 Received: from klere.zo.oi (klere.zo.oi [fec0::2:200:f8ff:fe23:681a]) (IDENT: wsl) by fruit.eu.org with esmtp; Tue, 25 Nov 2003 22:59:59 +0100 Received: by klere.zo.oi (sSMTP sendmail emulation); Tue, 25 Nov 2003 22:59:58 +0100 Date: Tue, 25 Nov 2003 22:59:58 +0100 From: Wessel Dankers To: Anubis922 Cc: linux-xfs@oss.sgi.com Subject: Re: Boot Partition Message-ID: <20031125215958.GF10257@fruit.eu.org> Mail-Followup-To: Anubis922 , linux-xfs@oss.sgi.com References: <20031125162021.47229.qmail@web21004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20031125162021.47229.qmail@web21004.mail.yahoo.com> X-oi: oi User-Agent: Mutt/1.5.4i X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.42.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAPM0QTa009943 X-archive-position: 1124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 16 On 2003–11–25 08:20:21-0800, Anubis922 wrote: > I have just downloaded Mandrake 9.2 and I am thinking > about using the XFS filesystem. My question is can I > use the XFS filesystem on /boot partition? If not > what filesystem do you suggest? ...but don't make a seperate /boot unless you can't fit the / filesystem under 1024 cylinders and your BIOS is old (< Pentium 2). Cheers, -- Wessel Dankers “Reformatting Page. Wait...” From owner-linux-xfs@oss.sgi.com Tue Nov 25 14:00:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 14:00:57 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPM0jTa009968 for ; Tue, 25 Nov 2003 14:00:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPMLKHc021944 for ; Tue, 25 Nov 2003 16:21:20 -0600 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAPM0dP514382746; Tue, 25 Nov 2003 16:00:39 -0600 (CST) Message-ID: <3FC3D107.9070109@sgi.com> Date: Tue, 25 Nov 2003 16:00:39 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump feature request References: <002a01c3a7ad$ff260b50$6207a8c0@titanic> <3FC394F4.4030305@sgi.com> <3FC3AD4D.7070603@coplanar.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4983 Lines: 111 Jeremy Jackson wrote: > > Mandy Kirkconnell wrote: >> >> I think when the man page says the inventory file on the tape isn't >> used, it means that xfsdump neither looks at it nor depends upon it. >> xfsdump only looks at inventory files in /var/lib/xfsdump/inventory >> when searching for a specific dump. The inventory file that gets >> added to the tape at the end of each dump session is for the user's >> benefit only, in order to query the dump sessions on a given tape. >> >> Does this make sense? Perhaps a better explanation in the xfsdump man >> page is needed. > > Pointing to the xfsrestore man page for a possible use would do the > trick. Also missing from the xfsrestore man page is how to use these > inventory files, and how they are/are not merged into the inventory > database. Good point. I'll add a better description of the tape inventory files to the xfsrestore man page. This will include instructions on how (and why) to merge the tape inventory files into the inventory database directory. I'll also point the xfsdump man page to this description, as you suggested. >>> Is there a way to erase a tape but keep it's media object UUID. >> >> Unforchunately, no. All three of the options above cause a new media >> objec UUID to be created when the next (first) dump begins. >> >>> It would be ideal to allow this, and prune the inventory of that >>> media object's UUID automatically. If this is possible, then adding >>> a counter to how many times that media object has been used would >>> give it all the features of Veritas. Would be nice. >> >> You can use the 'mobjid=' option with -I to prune out the inventory of >> a specific media object's UUID, but (as you mentioned) the media id is >> not constant for a given tape. I agree, it would be really nice if >> xfsdump could associate a constant media id for each tape, where the >> id remained constant accross erases, overwrites, etc.. I'll open an >> RFE for this as well. >> >> I'm not all that familiar with the Veritas products, maybe you can >> help me out here. Would the purpose of a counter be to keep track of >> the life span of each tape? Would it include the number of dumps >> (writes) AND the number of restores (reads), or just the dumps? > > I have not used Veritas Backup Exec personally. The idea came out of a > discussion with an admin that uses Veritas. We were comparing the > features of xfsdump and Veritas. > > You are correct - the count is used to determine when a tape should be > replaced. I'm not sure if it tracks the restores, but as these are > hopefully infrequent tracking the writes should give a reasonable > estimate of the tape's life. This sounds reasonable if the tapes are ONLY used for xfsdump backups. However, if the tapes are also available to other applications the counts would be 1) overwritten and 2) inaccurate. I think people generally use a fixed group of tapes for a particular application but if the tapes ever got moved around the counts wouldn't reflect the true life of the tape. > I'm thinking about making a separate erase utility that can optionally > copy the UUID from the tape and create a dummy media file or stream > terminator after erasing the tape (optional quick erase - just a rewind > and overwrite). It could track tape life separate from inventory > database for now. Is that a volunteer? I'll make a note of this idea so it doesn't slip through the cracks. If you'd like to look into it, please feel free ;) > Since tapes must be erased before being reused anyhow > due to the way xfsdump -o works, this seems logical. Can you elaborate on this? See my comments below about the -o flag. > That actually reminds me of another issue. When appending a dump > session to a tape with other dump sessions, you don't use the -o flag. > But if the session fills the tape, the new tape inserted must not have > any xfsdump sessions, or the dump aborts (can't choose overwrite in > middle of a dump). You *should* be able to add the -o when you resume the dump on a new tape. Do you get errors when you try to do this? If so, can you send me the xfsdump command that you are using to resume on a new tape? > "mt erase" takes 3 hours on this Exabyte drive, so I came up with a > shortcut: > > mt rewind ; dd if=/dev/zero of=/dev/tape count=1 bs=245760 > (where bs= is the -b size used with xfsdump). > > It thinks the tape is a corrupt xfsdump tape or a foreign tape, and > allows overwrite. > > I'm not sure what the recomendation for xfsdump is in this scenario... > if there is one perhaps it could go in the manpage. If you truely can't specify -o when you resume on a new tape, the only options would be to 1) erase the entire tape (2-3 hours!!) or 2) find some way to corrupt the first few blocks of the old dump, like you did with your dd workaround above. Mandy -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 25 15:31:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 15:32:08 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPNVkTa012230 for ; Tue, 25 Nov 2003 15:31:47 -0800 Received: from [192.168.1.100] (mdsnwi11-vlan423-228.wi.tds.net [66.222.60.228]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hAPNVdJ3030182 for ; Tue, 25 Nov 2003 17:31:41 -0600 Mime-Version: 1.0 (Apple Message framework v606) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-xfs@oss.sgi.com From: Stephan L Jansen Subject: kernel RPMs for RHEL? Date: Tue, 25 Nov 2003 17:33:15 -0600 X-Mailer: Apple Mail (2.606) X-archive-position: 1126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 210 Lines: 13 Hi, Has anyone compiled XFS enabled kernel RPMs for RedHat Enterprise Linux 3? How much trouble was it? Sorry if this has been covered before. I don't recall seeing anything about this. ------- Stephan From owner-linux-xfs@oss.sgi.com Tue Nov 25 15:50:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 15:50:29 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAPNo6Ta012800 for ; Tue, 25 Nov 2003 15:50:06 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAPLubOO011615 for ; Tue, 25 Nov 2003 13:56:37 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hAPNo0P514377721; Tue, 25 Nov 2003 17:50:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hAPNntK17999069; Tue, 25 Nov 2003 17:49:55 -0600 (CST) Subject: Re: kernel RPMs for RHEL? From: Eric Sandeen To: Stephan L Jansen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1069804199.1453.142.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 25 Nov 2003 17:49:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 593 Lines: 22 This is something I'm playing with, and I"d be happy to have some community testing of the result, so when I get it going (probably next week) I'll toss it out onto oss.sgi.com. -Eric On Tue, 2003-11-25 at 17:33, Stephan L Jansen wrote: > Hi, > > Has anyone compiled XFS enabled kernel RPMs for RedHat Enterprise Linux > 3? > How much trouble was it? > > Sorry if this has been covered before. I don't recall seeing anything > about this. > > > ------- Stephan -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 25 17:13:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 17:13:21 -0800 (PST) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQ1CxTa021213 for ; Tue, 25 Nov 2003 17:12:59 -0800 Received: (qmail 9049 invoked by uid 89); 26 Nov 2003 01:12:53 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 26 Nov 2003 01:12:53 -0000 Received: (qmail 9043 invoked by uid 89); 26 Nov 2003 01:12:52 -0000 Received: from unknown (HELO david.internal.NorcrossGroup.com) (66.23.219.114) by duchess.speedfactory.net with SMTP; 26 Nov 2003 01:12:52 -0000 Subject: Re: Newbie questions From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Alessandro Bottoni Cc: linux-xfs@oss.sgi.com In-Reply-To: <200311251749.45683.alessandrobottoni@interfree.it> References: <200311251749.45683.alessandrobottoni@interfree.it> Content-Type: text/plain Message-Id: <1069808985.18969.20.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Tue, 25 Nov 2003 20:09:45 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 2205 Lines: 57 On Tue, 2003-11-25 at 12:49, Alessandro Bottoni wrote: > Well, I'm a newbie, so here is the usual list of newbie questions :-) > > - Is there any (readable/understandable) example of the use of EA and/or ACL > from within a C or C++ client program? > - Is there any other C++ (or even a "simplified C") wrapper for the C/ioctl > XFS API beside the one supplied by libferris? > - Is there any Python/Perl/Ruby binding of the XFS EA/ACL API? > - Is there any programmer's guide or any tutorial? > > Just to reassure you I read the available docu before bothering you: > - "Some functionality specific to the XFS filesystem is accessible to > applications through the Linux ioctl(2) interface." (from "man 5 xfs"). => > Any example for mere mortals? > - "The http://witme.sourceforge.net/libferris.web/ has tools for accessing > Extended Attributes including writing to XFS Extended Attributes." (from XFS > FAQ page) => The link to "what are ACL" and other pages are broken... Any > other docu available? > > And... > - So far, I found just one client program that uses XFS EAs: DoXFS (a document > management program that is available at sourceforge.net). Is there any other > program that uses EA and/or ACL? > - I found a whirlwind intro to XFS at IBM developerworks, as well. Nice but > very introductory. > > BTW: does anybody know if there is any SCM (CVS-like or, more precisely, > ClearCase-like) program based on XFS? I would have expected that the > ClearCase-clone "Katie" (http://www.netcraft.com.au/geoffrey/katie/) used it > but, apparently, it uses its own EA/ACL technology. > > Many thanks in advance. > > ---------------------------------- > Alessandro Bottoni > alessandrobottoni@interfree.it > > You should look into libacl.a and libattr.a They provide a nice C callable api. Normally http://acl.bestbits.at has more info, but the sub-pages are either gone or temporarily offline. Also, there are python wrappers for both of the above, but I don't remember their names. Maybe pyxattr from http://sourceforge.net/project/showfiles.php?group_id=69931 If not, checkout rdiff-backup 0.13.x. That is a python project that uses them. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Nov 25 22:09:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Nov 2003 22:09:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQ69TTa009608 for ; Tue, 25 Nov 2003 22:09:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAQ6U4Hc022077 for ; Wed, 26 Nov 2003 00:30:05 -0600 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 RAA09403; Wed, 26 Nov 2003 17:09:20 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAQ69JUc1794174; Wed, 26 Nov 2003 17:09:19 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAQ69HDB002351; Wed, 26 Nov 2003 17:09:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAQ69F4q002349; Wed, 26 Nov 2003 17:09:15 +1100 Date: Wed, 26 Nov 2003 17:09:15 +1100 From: Nathan Scott To: Alessandro Bottoni Cc: linux-xfs@oss.sgi.com Subject: Re: Newbie questions Message-ID: <20031126060915.GC2262@frodo> References: <200311251749.45683.alessandrobottoni@interfree.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311251749.45683.alessandrobottoni@interfree.it> User-Agent: Mutt/1.5.3i X-archive-position: 1129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1338 Lines: 41 On Tue, Nov 25, 2003 at 05:49:45PM +0000, Alessandro Bottoni wrote: > Well, I'm a newbie, so here is the usual list of newbie questions :-) > > - Is there any (readable/understandable) example of the use of EA and/or ACL > from within a C or C++ client program? There are examples of C programs in the attr package - e.g. getfattr(1) and setfattr(1). > - Is there any other C++ (or even a "simplified C") wrapper for the C/ioctl > XFS API beside the one supplied by libferris? Not AFAIK. > - Is there any Python/Perl/Ruby binding of the XFS EA/ACL API? Hmm... dunno. If you do it, you should just wrap the *xattr syscalls and then it'll work for any filesystem not only XFS. > - Is there any programmer's guide or any tutorial? Just the man pages, AFAIK. > - "Some functionality specific to the XFS filesystem is accessible to > applications through the Linux ioctl(2) interface." (from "man 5 xfs"). => > Any example for mere mortals? The XFS tools - esp. xfs_io(8) - provide a command line interface to a number of these system calls. > - "The http://witme.sourceforge.net/libferris.web/ has tools for accessing > Extended Attributes including writing to XFS Extended Attributes." (from XFS > FAQ page) => The link to "what are ACL" and other pages are broken... Any Seth, still around? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 26 02:01:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 02:01:57 -0800 (PST) Received: from community14.interfree.it (community14.interfree.it [213.158.72.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQA1gTa030689 for ; Wed, 26 Nov 2003 02:01:45 -0800 Received: (qmail 21086 invoked by uid 508); 26 Nov 2003 09:00:21 -0000 Received: from alessandrobottoni@interfree.it by community14.interfree.it by uid 712 with qmail-scanner-1.20rc3 (iscan: v3.1/v5.600-1011/329/46849. Clear:RC:1:. Processed in 0.558942 secs); 26 Nov 2003 09:00:21 -0000 Received: from unknown (HELO host144-140.pool80104.interbusiness.it) (80.104.140.144) by mail.interfree.it with SMTP; 26 Nov 2003 09:00:20 -0000 From: Alessandro Bottoni To: linux-xfs@oss.sgi.com Subject: Re: Newbie questions Date: Wed, 26 Nov 2003 09:45:15 +0000 User-Agent: KMail/1.5 References: <200311251749.45683.alessandrobottoni@interfree.it> <1069808985.18969.20.camel@david.internal.NorcrossGroup.com> In-Reply-To: <1069808985.18969.20.camel@david.internal.NorcrossGroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200311260945.15674.alessandrobottoni@interfree.it> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAQA1jTa030690 X-archive-position: 1130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alessandrobottoni@interfree.it Precedence: bulk X-list: linux-xfs Content-Length: 643 Lines: 18 Alle 01:09, mercoledĂŹ 26 novembre 2003, hai scritto: > Also, there are python wrappers for both of the above, but I don't > remember their names. Maybe pyxattr from > http://sourceforge.net/project/showfiles.php?group_id=69931 Many thanks for the info. Following your direction, I just found a couple of python wrappers. I report their links here below for the other people interested in them: http://pyxattr.sourceforge.net/ http://pubweb.northwestern.edu/~omh221/software_projects/python-e2fs/e2fs.html Many thanks again to everybody for the help. ---------------------------------- Alessandro Bottoni alessandrobottoni@interfree.it From owner-linux-xfs@oss.sgi.com Wed Nov 26 03:18:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 03:18:51 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQBINTa001606 for ; Wed, 26 Nov 2003 03:18:23 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00174DA0@mailhub2.arup.com>; Tue, 25 Nov 2003 23:13:42 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Tue, 25 Nov 2003 23:13:41 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Wed, 26 Nov 2003 10:11:56 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Wed, 26 Nov 2003 10:09:11 +1100 From: "Scott Fagg" To: Subject: Re: Newbie questions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAQBIOTa001661 X-archive-position: 1131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1960 Lines: 48 I once wrote a small KDE app to manipulate ACLs, i don't recall where i got the documentation from to get started, but you can get somewhere with 'man -k acl'. That covered ACLs, but not EAs. Scott Fagg Arup Brisbane (07) 3023 6000 >>> Alessandro Bottoni 26/11/2003 3:49:45 AM >>> Well, I'm a newbie, so here is the usual list of newbie questions :-) - Is there any (readable/understandable) example of the use of EA and/or ACL from within a C or C++ client program? - Is there any other C++ (or even a "simplified C") wrapper for the C/ioctl XFS API beside the one supplied by libferris? - Is there any Python/Perl/Ruby binding of the XFS EA/ACL API? - Is there any programmer's guide or any tutorial? Just to reassure you I read the available docu before bothering you: - "Some functionality specific to the XFS filesystem is accessible to applications through the Linux ioctl(2) interface." (from "man 5 xfs"). => Any example for mere mortals? - "The http://witme.sourceforge.net/libferris.web/ has tools for accessing Extended Attributes including writing to XFS Extended Attributes." (from XFS FAQ page) => The link to "what are ACL" and other pages are broken... Any other docu available? And... - So far, I found just one client program that uses XFS EAs: DoXFS (a document management program that is available at sourceforge.net). Is there any other program that uses EA and/or ACL? - I found a whirlwind intro to XFS at IBM developerworks, as well. Nice but very introductory. BTW: does anybody know if there is any SCM (CVS-like or, more precisely, ClearCase-like) program based on XFS? I would have expected that the ClearCase-clone "Katie" (http://www.netcraft.com.au/geoffrey/katie/) used it but, apparently, it uses its own EA/ACL technology. Many thanks in advance. ---------------------------------- Alessandro Bottoni alessandrobottoni@interfree.it From owner-linux-xfs@oss.sgi.com Wed Nov 26 12:49:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 12:49:25 -0800 (PST) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQKn4Ta021280 for ; Wed, 26 Nov 2003 12:49:11 -0800 Received: by saytrin (Postfix, from userid 4004) id 95CCA2184; Wed, 26 Nov 2003 22:52:09 +0200 (EET) Date: Wed, 26 Nov 2003 22:52:09 +0200 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: Re: Newbie questions Message-ID: <20031126205209.GB6728@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200311251749.45683.alessandrobottoni@interfree.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311251749.45683.alessandrobottoni@interfree.it> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 1132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-xfs@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 338 Lines: 9 On Tue, Nov 25, 2003 at 05:49:45PM +0000, Alessandro Bottoni wrote: > - Is there any Python/Perl/Ruby binding of the XFS EA/ACL API? My (small) projects for Python: - for extended attributes: https://sourceforge.net/projects/pyxattr/ - for ACLs (needs the above): https://sourceforge.net/projects/pylibacl/ Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Wed Nov 26 14:35:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 14:35:34 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAQMZDTa025616 for ; Wed, 26 Nov 2003 14:35:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAQMtoHc002397 for ; Wed, 26 Nov 2003 16:55:51 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAQMZ4EU4092089 for ; Thu, 27 Nov 2003 09:35:04 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAQMZ3w44085545 for linux-xfs@oss.sgi.com; Thu, 27 Nov 2003 09:35:03 +1100 (EST) Date: Thu, 27 Nov 2003 09:35:03 +1100 (EST) From: Nathan Scott Message-Id: <200311262235.hAQMZ3w44085545@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Merge up to 2.6.0-test11 X-archive-position: 1133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1492 Lines: 44 Date: Wed Nov 26 14:15:16 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:162573a linux/net/irda/irttp.c - 1.29 linux/net/ipv6/mcast.c - 1.37 linux/net/ipv6/addrconf.c - 1.48 linux/net/bridge/br.c - 1.30 linux/kernel/fork.c - 1.103 linux/include/net/sock.h - 1.51 linux/fs/proc/proc_tty.c - 1.11 linux/drivers/video/igafb.c - 1.23 linux/drivers/scsi/scsi_error.c - 1.50 linux/drivers/scsi/scsi.c - 1.86 linux/arch/sparc/kernel/time.c - 1.33 linux/Makefile - 1.264 linux/drivers/scsi/scsi_lib.c - 1.74 linux/drivers/ieee1394/ieee1394_types.h - 1.25 linux/drivers/ieee1394/ieee1394_transactions.c - 1.21 linux/drivers/ieee1394/hosts.c - 1.22 linux/drivers/ieee1394/csr.c - 1.17 linux/drivers/ieee1394/highlevel.c - 1.15 linux/drivers/scsi/scsi_scan.c - 1.59 linux/arch/ia64/kernel/unwind.c - 1.20 linux/include/asm-ia64/pgtable.h - 1.28 linux/net/econet/af_econet.c - 1.26 linux/drivers/net/pppoe.c - 1.34 linux/drivers/ieee1394/nodemgr.c - 1.24 linux/drivers/ieee1394/nodemgr.h - 1.11 linux/fs/jfs/jfs_logmgr.c - 1.29 linux/drivers/scsi/scsi_sysfs.c - 1.19 linux/drivers/net/irda/smsc-ircc2.c - 1.3 linux/drivers/scsi/scsi_priv.h - 1.9 linux/include/scsi/scsi_device.h - 1.9 linux/drivers/scsi/sata_svw.c - 1.3 linux/drivers/scsi/libata-core.c - 1.3 linux/drivers/scsi/sata_promise.c - 1.3 linux/drivers/scsi/libata.h - 1.3 linux/include/linux/libata.h - 1.3 From owner-linux-xfs@oss.sgi.com Wed Nov 26 16:31:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 16:31:24 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAR0VCTa005172 for ; Wed, 26 Nov 2003 16:31:12 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAR0pnHc004752 for ; Wed, 26 Nov 2003 18:51:50 -0600 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 LAA21757; Thu, 27 Nov 2003 11:31:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAR0V1Uc1835103; Thu, 27 Nov 2003 11:31:01 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hAR0UvNh001173; Thu, 27 Nov 2003 11:30:58 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hAR0UuKQ001171; Thu, 27 Nov 2003 11:30:56 +1100 Date: Thu, 27 Nov 2003 11:30:56 +1100 From: Nathan Scott To: Alberto Nava , Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-ID: <20031127003056.GB658@frodo> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <3FC0EFEA.5070108@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC0EFEA.5070108@xfs.org> User-Agent: Mutt/1.5.3i X-archive-position: 1134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3922 Lines: 103 On Sun, Nov 23, 2003 at 11:35:38AM -0600, Steve Lord wrote: > Alberto Nava wrote: > >Hi, > > > >I've done some more digging on this issue. The reason the > >request is going in 4k pages is that the direct-io code is > >giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > > >The reason do_direct_IO gives up is because the first call to > >get_more_blocks() is returning an unmapped buffer header. > >This is a snip of the code that's failing (look for XXXXX) > > > >static int do_direct_IO(struct dio *dio) > >{ > > const unsigned blkbits = dio->blkbits; > > const unsigned blocks_per_page = PAGE_SIZE >> blkbits; > > struct page *page; > > unsigned block_in_page; > > struct buffer_head *map_bh = &dio->map_bh; > > int ret = 0; > > > > /* The I/O can start at any block offset within the first page*/ > > block_in_page = dio->first_block_in_page; > > > > while (dio->block_in_file < dio->final_block_in_request) { > > page = dio_get_page(dio); > > if (IS_ERR(page)) { > > ret = PTR_ERR(page); > > goto out; > > } > > > > while (block_in_page < blocks_per_page) { > > unsigned offset_in_page = block_in_page << blkbits; > > unsigned this_chunk_bytes; /* # of bytes mapped */ > > unsigned this_chunk_blocks; /* # of blocks */ > > unsigned u; > > > > if (dio->blocks_available == 0) { > > /* > > * Need to go and map some more disk > > */ > > unsigned long blkmask; > > unsigned long dio_remainder; > > > > ret = get_more_blocks(dio); > > if (ret) { > > page_cache_release(page); > > goto out; > > } > > if (!buffer_mapped(map_bh)) > > goto do_holes; XXXXXX > > > > ..... > >do_holes: > > /* Handle holes */ > > if (!buffer_mapped(map_bh)) { > > char *kaddr; > > > > /* AKPM: eargh, -ENOTBLK is a hack */ > > if (dio->rw == WRITE) > > return -ENOTBLK; XXXXXX > > > > > >Even if I reserve space for the file, the directio IO fails. > > > >I tried the same with ext3 and it does perform the directIO on the new > >file. However, I really disklike the sizes that it's using, it's all > >over the place 8k, 160, 200k, etc. I really like the 512K requests I'm > >getting with XFS specially with the 320 SCSI controller I'm using. > > > >I'll try looking at the XFS code to see why is returning an unmapped bh, > >but some help here would be greatly appreciate as I'm not familiar with > >XFS code. Hi Alberto, I spent some time this morning looking into this. Firstly, the fs/direct-io.c code has moved on from what you were looking at in test9 -- I've been testing using test11 this morning and the code snippet you've pasted above is no longer the same (Andrews comment above has modified - ENOTBLK is never returned now). Secondly, I cannot reproduce the behaviour you've described -- direct IO into both unwritten and newly allocated extents works correctly, and using your test case I got nice big 512k chunks every time. There have been no changes in XFS in this area that could have affected this, so I wonder what led you to suspect the buffer was unmapped (your first "XXXXXX" above) originally? Did you put a printk in there that was being triggered? (I did, and it didn't, using -test11). I also put the printks into XFS as I described in my previous mail, and we are definately giving large IOs back to the generic direct IO code, for both cases - pre-allocated and and not-pre-allocated cases. Any chance you could retry your tests on the current kernel just to verify that there is no problem here for me? thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 26 16:49:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Nov 2003 16:50:03 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAR0nlTa005741 for ; Wed, 26 Nov 2003 16:49:51 -0800 Received: (qmail 10930068 invoked from network); 27 Nov 2003 00:49:42 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 27 Nov 2003 00:49:42 -0000 Message-ID: <3FC5487D.8020800@kasenna.com> Date: Wed, 26 Nov 2003 16:42:37 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <3FC0EFEA.5070108@xfs.org> <20031127003056.GB658@frodo> In-Reply-To: <20031127003056.GB658@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 1568 Lines: 42 Nathan Scott wrote: > Hi Alberto, > > I spent some time this morning looking into this. Firstly, the > fs/direct-io.c code has moved on from what you were looking at > in test9 -- I've been testing using test11 this morning and the > code snippet you've pasted above is no longer the same (Andrews > comment above has modified - ENOTBLK is never returned now). > > Secondly, I cannot reproduce the behaviour you've described -- > direct IO into both unwritten and newly allocated extents works > correctly, and using your test case I got nice big 512k chunks > every time. There have been no changes in XFS in this area that > could have affected this, so I wonder what led you to suspect > the buffer was unmapped (your first "XXXXXX" above) originally? > > Did you put a printk in there that was being triggered? (I did, > and it didn't, using -test11). I also put the printks into XFS > as I described in my previous mail, and we are definately giving > large IOs back to the generic direct IO code, for both cases - > pre-allocated and and not-pre-allocated cases. thanks for looking into this. Yes I had some printk on the "XXXXX" lines, plus I've added some traces to test9 that allow you to get information about BIO that are submitted to the scheduler. This showed a 4k vs 512k requests. I'll try to reproduce it with test11. It might take me some time as I need to merge my trace gathering code. Thanks beto > > Any chance you could retry your tests on the current kernel just > to verify that there is no problem here for me? > > thanks! > From owner-linux-xfs@oss.sgi.com Thu Nov 27 00:14:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 00:14:58 -0800 (PST) Received: from ncircle.nullnet.fi (ncircle.nullnet.fi [62.236.96.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAR8EPTa028854 for ; Thu, 27 Nov 2003 00:14:27 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with ESMTP id 32FA31CEC09E for ; Thu, 27 Nov 2003 10:14:24 +0200 (EET) Received: from ncircle.nullnet.fi ([127.0.0.1]) by localhost (alderan.ncircle.nullnet.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23699-06 for ; Thu, 27 Nov 2003 10:14:22 +0200 (EET) Received: from ncircle.nullnet.fi (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with SMTP for ; Thu, 27 Nov 2003 10:14:22 +0200 (EET) Received: from cacher1-ext.wise.edt.ericsson.se ([194.237.142.5]) (SquirrelMail authenticated user tomimo) by ncircle.nullnet.fi with HTTP; Thu, 27 Nov 2003 10:14:22 +0200 (EET) Message-ID: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> Date: Thu, 27 Nov 2003 10:14:22 +0200 (EET) Subject: 2.4.23-rc3+XFS internal error From: "Tomi Orava" To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at ncircle.nullnet.fi Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hAR8ESTa028855 X-archive-position: 1136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomimo+linux-xfs@ncircle.nullnet.fi Precedence: bulk X-list: linux-xfs Content-Length: 3832 Lines: 82 Hi, I received the following error message last night, which obviously resulted lots of problems while running xfs_repair, as the xfs_repair was unable to get some inodes fixed properly, even though the repair command was ran several times. In the end I found that the problematic inodes belong to some directories which had been already moved to lost+found directory and by renaming and the old lost+found directory to other name and recreating the dir finally fixed those problems. However, the xfs_repair still complains about "rebuilding directory inode 128" which belongs to "/" ... That one is still not fixed. Unfortunately, the system is a production machine and I was unable to properly investigate the error message, as it was important to get the host back running ASAP. The software configuration: kernel-2.4.23-rc3+fullXFS (from bk) The filesystem is on top of RAID1. The xfsprogs I used in cleaning up the system were from the RH9+XFS rescue-cd. I have now booted the system back to 2.4.23-pre5+XFS which has been working quite OK in the past weeks. It would of course be nice to be able to get rid of this still remaining xfs_repair error message, without having to reformat the partition ... I know that there is not much detailed information in here, but perhaps I can be provide it later if needed. Regards, Tomi Orava Nov 27 00:10:30 alderan kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. Caller 0xc01d7da4 Nov 27 00:10:30 alderan kernel: c1c2f950 c01d6cbf c03a0841 00000001 00000000 c03a0835 00000136 c01d7da4 Nov 27 00:10:30 alderan kernel: 00000000 00000000 00000000 00000000 c1c2fb08 e6d50144 c1c2f9f8 c01d7da4 Nov 27 00:10:30 alderan kernel: e6d50144 e6d500c0 000092a5 00000005 000092a5 00000002 00000002 000092a5 Nov 27 00:10:30 alderan kernel: Call Trace: [xfs_alloc_fixup_trees+511/880] [xfs_alloc_ag_vextent_near+2964/3232] [xfs_alloc_ag_vextent_near+2964/3232] [xfs_alloc_ag_vextent+291/304] [xfs_alloc_vextent+747/912] [xfs_bmap_alloc+2185/4880] [scsi_done+0/160] [xfs_bmbt_get_state+47/64] [xfs_bmapi+3714/5456] [xfs_bmbt_get_state+47/64] [xfs_bmap_do_search_extents+184/976] [xfs_buf_item_unlock+162/208] [xfs_trans_tail_ail+18/48] [xfs_bmap_search_extents+111/144] [xfs_log_reserve+192/208] [xfs_iomap_write_allocate+679/1216] [xfs_imap_to_bmap+57/528] [xfs_iunlock+61/128] [xfs_iomap+1013/1328] [map_blocks+94/208] [page_state_convert+1032/1280] [ide_build_sglist+363/528] [ide_dma_intr+0/192] [dma_timer_expiry+0/160] [linvfs_release_page+126/144] [try_to_release_page+82/112] [shrink_cache+727/896] [shrink_caches+61/96] [try_to_free_pages_zone+83/240] [kswapd_balance_pgdat+94/160] [kswapd_balance+25/48] [kswapd+146/176] [kswapd+0/176] [_stext+0/64] [arch_kernel_thread+46/64] [kswapd+0/176] Nov 27 00:10:30 alderan kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Nov 27 00:10:30 alderan kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. Caller 0xc01d7da4 Nov 27 00:10:30 alderan kernel: c1c2f950 c01d6cbf c03a0841 00000001 00000000 c03a0835 00000136 c01d7da4 Nov 27 00:10:30 alderan kernel: 00000000 00000000 00000000 00000000 c1c2fb08 e6d500c0 c1c2f9f8 c01d7da4 Nov 27 00:10:30 alderan kernel: e6d500c0 e6d50144 000092a5 00000005 000092a5 00000002 00000002 000092a5 From owner-linux-xfs@oss.sgi.com Thu Nov 27 00:37:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 00:37:54 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAR8bUTa032559 for ; Thu, 27 Nov 2003 00:37:30 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hAR8bNC11641; Thu, 27 Nov 2003 00:37:24 -0800 Date: Thu, 27 Nov 2003 00:44:20 -0800 From: Andrew Morton To: Alberto Nava Cc: beto@kasenna.com, linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-Id: <20031127004420.77f31a9c.akpm@osdl.org> In-Reply-To: <3FBFEF6A.3000609@kasenna.com> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1137 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 543 Lines: 13 Alberto Nava wrote: > > I've done some more digging on this issue. The reason the > request is going in 4k pages is that the direct-io code is > giving up in do_direct_IO() and the request is issued as buffer IO :-(. You seem to be using a -mm kernel. It has extensive and not-quite-complete and not-really-tested-at-all-with-XFS direct-io changes. It would be best to concentrate on stock Linus direct-io for now - wait until we think we've completed the direct-io rework in -mm and have tested it decently with XFS. From owner-linux-xfs@oss.sgi.com Thu Nov 27 07:16:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 07:17:13 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARFGOTa026945 for ; Thu, 27 Nov 2003 07:16:44 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:64041 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1APNs2-0005Yy-4f by VAauthid with fixed_plain; Thu, 27 Nov 2003 07:15:54 -0800 Message-ID: <3FC61516.3070603@linux-sxs.org> Date: Thu, 27 Nov 2003 07:15:34 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomi Orava CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.23-rc3+XFS internal error References: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> In-Reply-To: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1APNs2-0005Yy-4f 393c25746d1dcb706380ae053a8cb367 X-Spam-Score: -102.1 (---------------------------------------------------) X-archive-position: 1138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 606 Lines: 17 On 11/27/03 00:14, Tomi Orava wrote: > kernel-2.4.23-rc3+fullXFS (from bk) > The filesystem is on top of RAID1. > The xfsprogs I used in cleaning up the system were from > the RH9+XFS rescue-cd. > > I have now booted the system back to 2.4.23-pre5+XFS I do have to ask. Why are you running pre & rc kernels on production servers? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 7:10am up 3 days, 19:36, 1 user, load average: 0.00, 0.00, 0.00 From owner-linux-xfs@oss.sgi.com Thu Nov 27 09:44:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 09:45:18 -0800 (PST) Received: from ncircle.nullnet.fi (ncircle.nullnet.fi [62.236.96.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARHiuTa001443 for ; Thu, 27 Nov 2003 09:44:56 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with ESMTP id D64631C366DB; Thu, 27 Nov 2003 19:44:54 +0200 (EET) Received: from ncircle.nullnet.fi ([127.0.0.1]) by localhost (alderan.ncircle.nullnet.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09174-03; Thu, 27 Nov 2003 19:44:53 +0200 (EET) Received: from ncircle.nullnet.fi (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with SMTP; Thu, 27 Nov 2003 19:44:53 +0200 (EET) Received: from alderan.ncircle.nullnet.fi ([192.168.9.10]) (SquirrelMail authenticated user tomimo) by ncircle.nullnet.fi with HTTP; Thu, 27 Nov 2003 19:44:53 +0200 (EET) Message-ID: <35132.192.168.9.10.1069955093.squirrel@ncircle.nullnet.fi> In-Reply-To: <3FC61516.3070603@linux-sxs.org> References: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> <3FC61516.3070603@linux-sxs.org> Date: Thu, 27 Nov 2003 19:44:53 +0200 (EET) Subject: Re: 2.4.23-rc3+XFS internal error From: "Tomi Orava" To: "Net Llama!" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at ncircle.nullnet.fi Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hARHivTa001444 X-archive-position: 1139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomimo+linux-xfs@ncircle.nullnet.fi Precedence: bulk X-list: linux-xfs Content-Length: 928 Lines: 24 > On 11/27/03 00:14, Tomi Orava wrote: >> kernel-2.4.23-rc3+fullXFS (from bk) >> The filesystem is on top of RAID1. >> The xfsprogs I used in cleaning up the system were from >> the RH9+XFS rescue-cd. >> >> I have now booted the system back to 2.4.23-pre5+XFS > > I do have to ask. Why are you running pre & rc kernels on production > servers? Mostly because I've had some problems with standard kernels & MD-raid & ext3 in the past (filesystem corruption) and therefore I switched into using XFS instead (seems to handle error situations little bit better). In addition there has been some problems with the system slowing down into crawl in the long run with previous kernels. I hope that when the 2.4.23 will be released, I'll be able to add the XFS-patches into that and stay there. Better hardware might also help, but what can you do ... you've got to deal with what you have. -- tomimo+linux-xfs@ncircle.nullnet.fi From owner-linux-xfs@oss.sgi.com Thu Nov 27 13:17:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 13:17:40 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARLHGTa008558 for ; Thu, 27 Nov 2003 13:17:16 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hARLbuHc018110 for ; Thu, 27 Nov 2003 15:37:57 -0600 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 IAA04430; Fri, 28 Nov 2003 08:17:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hARLH2Uc1642794; Fri, 28 Nov 2003 08:17:02 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hARLGvkx000789; Fri, 28 Nov 2003 08:16:57 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hARLGrwx000787; Fri, 28 Nov 2003 08:16:53 +1100 Date: Fri, 28 Nov 2003 08:16:53 +1100 From: Nathan Scott To: Tomi Orava Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.23-rc3+XFS internal error Message-ID: <20031127211653.GA708@frodo> References: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> User-Agent: Mutt/1.5.3i X-archive-position: 1140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1095 Lines: 26 On Thu, Nov 27, 2003 at 10:14:22AM +0200, Tomi Orava wrote: > > Hi, > > I received the following error message last night, which obviously > resulted lots of problems while running xfs_repair, as the xfs_repair > was unable to get some inodes fixed properly, even though the repair > command was ran several times. In the end I found that the problematic > inodes belong to some directories which had been already moved to > lost+found directory and by renaming and the old lost+found > directory to other name and recreating the dir finally fixed those problems. > However, the xfs_repair still complains about "rebuilding directory inode > 128" which belongs to "/" ... That one is still not fixed. Not clear what caused the original problem (h/ware or s/ware) but it looks like xfs_repair has fixed things up for you -- 128 will be your root inode, and it will continually be rebuilt when you run repair if you don't remove "/lost+found" between each invocation. For more details see the archives, eg: http://marc.theaimsgroup.com/?l=linux-xfs&m=102981254408403&w=2 cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 27 13:20:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 13:20:13 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARLK1Ta008930 for ; Thu, 27 Nov 2003 13:20:02 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hARLegHc020450 for ; Thu, 27 Nov 2003 15:40:42 -0600 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 IAA04460; Fri, 28 Nov 2003 08:18:34 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hARLIXUc1862816; Fri, 28 Nov 2003 08:18:33 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hARLISkx000807; Fri, 28 Nov 2003 08:18:28 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hARLIRIY000805; Fri, 28 Nov 2003 08:18:27 +1100 Date: Fri, 28 Nov 2003 08:18:27 +1100 From: Nathan Scott To: Andrew Morton Cc: Alberto Nava , linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-ID: <20031127211827.GB708@frodo> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <20031127004420.77f31a9c.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031127004420.77f31a9c.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 1141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 662 Lines: 23 hi Andrew, On Thu, Nov 27, 2003 at 12:44:20AM -0800, Andrew Morton wrote: > Alberto Nava wrote: > > > > I've done some more digging on this issue. The reason the > > request is going in 4k pages is that the direct-io code is > > giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > You seem to be using a -mm kernel. It has extensive and not-quite-complete > and not-really-tested-at-all-with-XFS direct-io changes. Alberto's original mail said: > I'm seeing a very strange behavior when I write to a file using 512k > direct-io writes. The filesystem is XFS and the kernel is 2.6.0-test9. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 27 13:23:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 13:23:52 -0800 (PST) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARLNSTa009432 for ; Thu, 27 Nov 2003 13:23:36 -0800 Received: by saytrin (Postfix, from userid 4004) id 8CAD82143; Thu, 27 Nov 2003 23:25:20 +0200 (EET) Date: Thu, 27 Nov 2003 23:25:20 +0200 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: problem with xfsdump/xfsrestore Message-ID: <20031127212520.GA5013@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 1142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 2054 Lines: 50 Hello, I needed to migrate a filesystem to a bigger RAID array (~60GB on old, slow disks to ~90GB on a faster one) with minium of downtime. The old filesystem was created with old xfsprogs (2.5.3) and the new one with 2.6.0. I wanted to do this: - first night: xfsdump -l0 - /old | xfsrestore -r - /new which went OK - second night remount read-only /old xfsdump -l1 - /old | xfsrestore -r - /new (which should bring the differences, ~1GB), but xfsrestore died: xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.14 (dump format 3.0) - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: xxxxxxxxxxxx xfsrestore: mount point: /old xfsrestore: volume: /dev/vg01/store xfsrestore: session time: Thu Nov 27 20:25:36 2003 xfsrestore: level: 1 xfsrestore: session label: "" xfsrestore: media label: "" xfsrestore: file system id: e4b3cb15-7927-4bb9-8445-5a0ca8d8798a xfsrestore: session id: f689b1f9-30f7-46e3-a1af-1cb124916883 xfsrestore: media id: 0f55ae04-8c33-472b-b3b4-7b5907fd2ed9 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: node.c:669: node_map: Assertion `nodegen == hdlgen' failed. In the end, I skipped the -l1 dump/restore and went with "rsync -v -aH /old/ /new/" My questions are, if anybody can help me: - was that migration plan a valid one? I mean, a -l0 dump with a r/w filesystem + a -l1 dump on a readonly filesystem does a complete copy? - is it allowed to do incremental restores when using pipes (i.e. not a real file/tape)? - what really happened with xfsrestore? was my old filesystem corrupted? I have the stderr from xfsdump and stdout from all xfsrestore sessions available, if anybody is interested. I tried some more xfsdump -R -l1 - /old|xfsrestore -r - /new (which complained about -R on xfsrestore, which afterwards complained about mismatch on ids between inventory and file) Thanks, Iustin Pop From owner-linux-xfs@oss.sgi.com Thu Nov 27 13:26:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 13:26:17 -0800 (PST) Received: from ncircle.nullnet.fi (ncircle.nullnet.fi [62.236.96.207]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARLQ5Ta009861 for ; Thu, 27 Nov 2003 13:26:06 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with ESMTP id BB9421C366DD for ; Thu, 27 Nov 2003 23:26:03 +0200 (EET) Received: from ncircle.nullnet.fi ([127.0.0.1]) by localhost (alderan.ncircle.nullnet.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12573-07 for ; Thu, 27 Nov 2003 23:26:02 +0200 (EET) Received: from ncircle.nullnet.fi (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with SMTP for ; Thu, 27 Nov 2003 23:26:02 +0200 (EET) Received: from alderan.ncircle.nullnet.fi ([192.168.9.10]) (SquirrelMail authenticated user tomimo) by ncircle.nullnet.fi with HTTP; Thu, 27 Nov 2003 23:26:02 +0200 (EET) Message-ID: <37809.192.168.9.10.1069968362.squirrel@ncircle.nullnet.fi> In-Reply-To: <20031127211653.GA708@frodo> References: <34891.194.237.142.5.1069920862.squirrel@ncircle.nullnet.fi> <20031127211653.GA708@frodo> Date: Thu, 27 Nov 2003 23:26:02 +0200 (EET) Subject: Re: 2.4.23-rc3+XFS internal error From: "Tomi Orava" To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at ncircle.nullnet.fi Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hARLQ6Ta009868 X-archive-position: 1143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomimo+linux-xfs@ncircle.nullnet.fi Precedence: bulk X-list: linux-xfs Content-Length: 1457 Lines: 37 > On Thu, Nov 27, 2003 at 10:14:22AM +0200, Tomi Orava wrote: >> >> Hi, >> >> I received the following error message last night, which obviously >> resulted lots of problems while running xfs_repair, as the xfs_repair >> was unable to get some inodes fixed properly, even though the repair >> command was ran several times. In the end I found that the problematic >> inodes belong to some directories which had been already moved to >> lost+found directory and by renaming and the old lost+found >> directory to other name and recreating the dir finally fixed those >> problems. >> However, the xfs_repair still complains about "rebuilding directory >> inode >> 128" which belongs to "/" ... That one is still not fixed. > > Not clear what caused the original problem (h/ware or s/ware) > but it looks like xfs_repair has fixed things up for you -- > 128 will be your root inode, and it will continually be rebuilt > when you run repair if you don't remove "/lost+found" between > each invocation. For more details see the archives, eg: > http://marc.theaimsgroup.com/?l=linux-xfs&m=102981254408403&w=2 Thats great! I was little bit worried that I couldn't get rid of that one particular message while running xfs_repair as I couldn't figure what the message actually ment. So it seems that everything got cleaned up and the system has been running nicely after the crash with older kernel. Thanks! Tomi Orava -- tomimo+linux-xfs@ncircle.nullnet.fi From owner-linux-xfs@oss.sgi.com Thu Nov 27 14:09:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 14:09:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARM9UTa011201 for ; Thu, 27 Nov 2003 14:09:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hARMUBHc026978 for ; Thu, 27 Nov 2003 16:30:12 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hARM9MrA1172394 for ; Fri, 28 Nov 2003 09:09:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hARM9LGU1172985 for linux-xfs@oss.sgi.com; Fri, 28 Nov 2003 09:09:21 +1100 (EST) Date: Fri, 28 Nov 2003 09:09:21 +1100 (EST) From: Nathan Scott Message-Id: <200311272209.hARM9LGU1172985@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests X-archive-position: 1144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 361 Lines: 15 Update xfs_io filter to exclude some additional output being added shortly. Date: Thu Nov 27 14:08:54 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:162602a cmd/xfstests/071 - 1.4 cmd/xfstests/078 - 1.3 From owner-linux-xfs@oss.sgi.com Thu Nov 27 14:19:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 14:19:25 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hARMJ4Ta012088 for ; Thu, 27 Nov 2003 14:19:04 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id hARMIrC11145; Thu, 27 Nov 2003 14:18:53 -0800 Date: Thu, 27 Nov 2003 14:25:55 -0800 From: Andrew Morton To: Nathan Scott Cc: beto@kasenna.com, linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-Id: <20031127142555.3e0142c5.akpm@osdl.org> In-Reply-To: <20031127211827.GB708@frodo> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <20031127004420.77f31a9c.akpm@osdl.org> <20031127211827.GB708@frodo> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 779 Lines: 23 Nathan Scott wrote: > > hi Andrew, > > On Thu, Nov 27, 2003 at 12:44:20AM -0800, Andrew Morton wrote: > > Alberto Nava wrote: > > > > > > I've done some more digging on this issue. The reason the > > > request is going in 4k pages is that the direct-io code is > > > giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > > > You seem to be using a -mm kernel. It has extensive and not-quite-complete > > and not-really-tested-at-all-with-XFS direct-io changes. > > > Alberto's original mail said: > > > I'm seeing a very strange behavior when I write to a file using 512k > > direct-io writes. The filesystem is XFS and the kernel is 2.6.0-test9. > I know. But the code which he quoted had -mm stuff in it. From owner-linux-xfs@oss.sgi.com Thu Nov 27 21:56:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Nov 2003 21:57:15 -0800 (PST) Received: from smtp1.iitb.ac.in ([203.199.51.149]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAS5upTa028038 for ; Thu, 27 Nov 2003 21:56:53 -0800 Received: (qmail 7919 invoked by uid 505); 28 Nov 2003 05:57:26 -0000 Received: from soumen@cse.iitb.ac.in by smtp1.iitb.ac.in by uid 502 with qmail-scanner-1.16 (clamscan: 0.54. spamassassin: 2.54. Clear:. Processed in 0.221334 secs); 28 Nov 2003 05:57:26 -0000 Received: from unknown (HELO cse.iitb.ac.in) (10.165.31.156) by smtp1.iitb.ac.in with SMTP; 28 Nov 2003 05:57:26 -0000 Message-ID: <3FC6E5C4.2080009@cse.iitb.ac.in> Date: Fri, 28 Nov 2003 11:35:56 +0530 From: Soumen Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soumen@cse.iitb.ac.in Precedence: bulk X-list: linux-xfs Content-Length: 1226 Lines: 28 Eric Sandeen wrote: > On Sun, 26 Oct 2003, Soumen Chakrabarti wrote: >>Repeatable bug, here's how to create the situation: >>1. Start with a fresh install of stock RedHat 9. >>2. Download kernel 2.4.22. >>3. Patch in XFS 1.3.1 and build new kernel. > > Ok, for starters, i don't think we shipped patches specifically > for xfs 1.3.1 + kernel 2.4.22, and the patches we did ship for 2.4.21 > do not apply cleanly to 2.4.22. I downloaded the patch around 10/15, from this URL: ftp://oss.sgi.com/projects/xfs/patches/2.4.22 which seems to indicate that even on that date, there was a patch available for 2.4.22 (maybe I looked where I should not). Today (11/28), I can't even find a patch for 2.4.21 (at least not by moving up to the parent dir ...patches/). Some other people seem to have confirmed in the meantime that the problem shown by bonnie on 2.4.22 + 1.3.1 is a real one. I have some time now to either roll back to 2.4.21 if that is known to fix the problem, OR to rebuild a 2.4.22 kenel, given that the "all" patch file has changed in size and is now timestamped 11/10. I'd appreciate it very much if a XFS developer can confirm what has happened to this bug and if the 11/10 patch fixes it. Thanks. From owner-linux-xfs@oss.sgi.com Fri Nov 28 05:11:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 05:12:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hASDBbTa023264 for ; Fri, 28 Nov 2003 05:11:37 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hASDBbFY023263 for linux-xfs@oss.sgi.com; Fri, 28 Nov 2003 05:11:37 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hASDBZTa023249 for ; Fri, 28 Nov 2003 05:11:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hASCqJsJ023007; Fri, 28 Nov 2003 04:52:19 -0800 Date: Fri, 28 Nov 2003 04:52:19 -0800 Message-Id: <200311281252.hASCqJsJ023007@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 293] New: mount process crashes while replaying transaction log X-Bugzilla-Reason: AssignedTo X-archive-position: 1147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4297 Lines: 99 http://oss.sgi.com/bugzilla/show_bug.cgi?id=293 Summary: mount process crashes while replaying transaction log Product: Linux XFS Version: 1.3.x Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: rlewczuk@pronet.pl CC: rlewczuk@pronet.pl The following test always screws transaction log on my machine: Filesystem mounted at /mnt/xfstest. Directory /mnt/xfstest/bonnie exists. # bonnie++ -d /mnt/xfstest/bonnie -s 512 -n 512 -r 0 -n nobody & # bonnie++ -d /mnt/xfstest/bonnie -s 512 -n 512 -r 0 -n nobody & # bonnie++ -d /mnt/xfstest/bonnie -s 512 -n 512 -r 0 -n nobody & 3 processes are working. Wait until bonnie++ finishes working on big files and creates enough small files (directory size will exceed 2MB, many thousands files inside :-) ). Press reset button on test machine. After reboot filesystem won't mount. Mount process crashes with SEGV and device becomes locked somehow, so next mount will hang forever. xfs_repair indicates that transaction log is broken, so it's only possible to repair filesystem with discarding transaction log. mkfs options: mkfs -t xfs -l size=32768b -f /dev/sdy fstab entry: /dev/sdy /mnt/xfstest xfs noauto,defaults,logbufs=8,grpquota 1 0 While crashing mount process kernel logs the following things: Nov 26 17:37:56 file-comm-adm SGI XFS 1.3.1 with ACLs, debug enabled Nov 26 17:37:56 file-comm-adm SGI XFS Quota Management subsystem Nov 26 17:37:56 file-comm-adm XFS mounting filesystem sd(65,128) Nov 26 17:37:56 file-comm-adm Starting XFS recovery on filesystem: sd(65,128) (dev: 65/128) Nov 26 17:37:59 file-comm-adm Unable to handle kernel NULL pointer dereference at virtual address 00000058 Nov 26 17:37:59 file-comm-adm printing eip: Nov 26 17:37:59 file-comm-adm f94a5d5e Nov 26 17:37:59 file-comm-adm *pde = 00000000 Nov 26 17:37:59 file-comm-adm Oops: 0000 Nov 26 17:37:59 file-comm-adm CPU: 2 Nov 26 17:37:59 file-comm-adm EIP: 0010:[] Not tainted Nov 26 17:37:59 file-comm-adm EFLAGS: 00010206 Nov 26 17:37:59 file-comm-adm eax: 00000000 ebx: 00000000 ecx: f69e0000 edx: 0021f520 Nov 26 17:37:59 file-comm-adm esi: f69e0000 edi: 0021f520 ebp: 00000000 esp: f69ddaa8 Nov 26 17:37:59 file-comm-adm ds: 0018 es: 0018 ss: 0018 Nov 26 17:37:59 file-comm-adm Process mount (pid: 1573, stackpage=f69dd000) Nov 26 17:37:59 file-comm-adm Stack: 00000000 0000000c f948aefb f94e8286 f69e0000 00000000 0021f520 00000000 Nov 26 17:37:59 file-comm-adm 00000000 f69e0000 00000246 00000246 f69dc000 f948bd35 00000000 000001f0 Nov 26 17:37:59 file-comm-adm f948a261 f6be5924 f6b521c0 f6869e80 f6be5900 f948a2ba 00000000 f6869900 Nov 26 17:37:59 file-comm-adm Call Trace: [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] [] [] [] [] Nov 26 17:37:59 file-comm-adm [] [] Nov 26 17:37:59 file-comm-adm Nov 26 17:37:59 file-comm-adm Code: 8b 58 58 85 c0 8b 4c 24 1c 53 bb 0c 00 00 00 74 07 0f b7 98 Sorry for not providing symbol names here :) Need to make syslog work with kernel symbols :) Machine: IBM xSeries 360 with 2 Xeons (HT, so it is seen by system as 4-way machine) + 4GB RAM. It uses external storage array connected via two Fibre Channel HBA cards (QLogic 2300, via FC switches, failover compiled in). # uname -a Linux file-comm-adm 2.4.21-11fo1-SMP #1 SMP śro lis 26 17:02:35 CET 2003 i686 unknown Don't know how to set up rest of those bugzilla fileds, so left these empty/default :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Nov 28 10:18:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 10:18:26 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hASII5Ta001528 for ; Fri, 28 Nov 2003 10:18:06 -0800 Received: (qmail 10980690 invoked from network); 28 Nov 2003 18:17:59 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 28 Nov 2003 18:17:59 -0000 Message-ID: <3FC78FA4.2090000@kasenna.com> Date: Fri, 28 Nov 2003 10:10:44 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: linux-xfs@oss.sgi.com, Nathan Scott Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <20031127004420.77f31a9c.akpm@osdl.org> In-Reply-To: <20031127004420.77f31a9c.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 961 Lines: 28 Andrew Morton wrote: > Alberto Nava wrote: > >>I've done some more digging on this issue. The reason the >> request is going in 4k pages is that the direct-io code is >> giving up in do_direct_IO() and the request is issued as buffer IO :-(. > > > You seem to be using a -mm kernel. It has extensive and not-quite-complete > and not-really-tested-at-all-with-XFS direct-io changes. > > It would be best to concentrate on stock Linus direct-io for now - wait > until we think we've completed the direct-io rework in -mm and have tested > it decently with XFS. thanks for the information. I didn't know that XFS was not well tested on the -mm kernels. I'm using test2.6.0-test9-mm1. I didn't put this on the original email. I can't remembered right now why we moved to --mm. I think it had to do with it having some of the patches we were interested on..... I'll try this again on test9 or test11. Thanks a lot for your help beto From owner-linux-xfs@oss.sgi.com Fri Nov 28 13:38:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 13:39:16 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.167] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hASLcsTa007209 for ; Fri, 28 Nov 2003 13:38:56 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.019) (authenticated as rainer.traut@epost.de) id 3FC5183F0000E107 for linux-xfs@oss.sgi.com; Thu, 27 Nov 2003 08:51:12 +0100 Message-ID: <3FC5ACF0.1000200@epost.de> Date: Thu, 27 Nov 2003 08:51:12 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: kernel RPMs for RHEL? References: <1069804199.1453.142.camel@stout.americas.sgi.com> In-Reply-To: <1069804199.1453.142.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 29 Hi, yes I will test this when it's ready and give you feedback about it. Gruss Rainer Eric Sandeen wrote: > This is something I'm playing with, and I"d be happy to have some > community testing of the result, so when I get it going (probably next > week) I'll toss it out onto oss.sgi.com. > > -Eric > > On Tue, 2003-11-25 at 17:33, Stephan L Jansen wrote: > >>Hi, >> >>Has anyone compiled XFS enabled kernel RPMs for RedHat Enterprise Linux >>3? >>How much trouble was it? >> >>Sorry if this has been covered before. I don't recall seeing anything >>about this. >> >> >>------- Stephan From owner-linux-xfs@oss.sgi.com Fri Nov 28 13:44:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 13:45:06 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hASLitTa007624 for ; Fri, 28 Nov 2003 13:44:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hASM5dHc009318 for ; Fri, 28 Nov 2003 16:05:40 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hASLilrA1430830 for ; Sat, 29 Nov 2003 08:44:47 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hASLikoH1432239 for linux-xfs@oss.sgi.com; Sat, 29 Nov 2003 08:44:46 +1100 (EST) Date: Sat, 29 Nov 2003 08:44:46 +1100 (EST) From: Nathan Scott Message-Id: <200311282144.hASLikoH1432239@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.23 X-archive-position: 1150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 245 Lines: 10 Date: Fri Nov 28 13:44:19 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:162606a linux/Makefile - 1.199 From owner-linux-xfs@oss.sgi.com Fri Nov 28 13:58:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 13:59:20 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hASLwwTa008176 for ; Fri, 28 Nov 2003 13:58:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hASMJgHc015498 for ; Fri, 28 Nov 2003 16:19:42 -0600 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 IAA18131; Sat, 29 Nov 2003 08:57:30 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hASLvSUc1792436; Sat, 29 Nov 2003 08:57:29 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hASLvG0C1861929; Sat, 29 Nov 2003 08:57:16 +1100 (EST) Date: Sat, 29 Nov 2003 08:57:15 +1100 From: Nathan Scott To: Soumen Chakrabarti Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: <20031129085715.A1872948@wobbly.melbourne.sgi.com> References: <3FC6E5C4.2080009@cse.iitb.ac.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3FC6E5C4.2080009@cse.iitb.ac.in>; from soumen@cse.iitb.ac.in on Fri, Nov 28, 2003 at 11:35:56AM +0530 X-archive-position: 1151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 338 Lines: 13 On Fri, Nov 28, 2003 at 11:35:56AM +0530, Soumen Chakrabarti wrote: > ... > Some other people seem to have confirmed in the meantime that the > problem shown by bonnie on 2.4.22 + 1.3.1 is a real one. Can anyone confirm whether or not this log reservation message still occurs when using the "ikeep" mount option? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 28 17:20:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 17:21:13 -0800 (PST) Received: from kasenna.com (mail.kasenna.com [208.253.201.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAT1KYTa013314 for ; Fri, 28 Nov 2003 17:20:47 -0800 Received: (qmail 11052107 invoked from network); 29 Nov 2003 01:20:28 -0000 Received: from unknown (HELO kasenna.com) (10.10.4.210) by mail.kasenna.wan with SMTP; 29 Nov 2003 01:20:28 -0000 Message-ID: <3FC7F2E1.6070202@kasenna.com> Date: Fri, 28 Nov 2003 17:14:09 -0800 From: Alberto Nava User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <20031127004420.77f31a9c.akpm@osdl.org> <3FC78FA4.2090000@kasenna.com> In-Reply-To: <3FC78FA4.2090000@kasenna.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: beto@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 24 Alberto Nava wrote: > > I'll try this again on test9 or test11. > I tried this with the 2.6.0-test11 and it works fine. The 512k writes to a new file are propagaded all the way to the drives. It work without having to use '-d unwritten' or preallocation. Here is a snip of the proc file I used to verify it. (8,16)@85886 b=f24f0d80 r=ef9c49b0 s=140288(size=524288) prio=0 rw 1 (8,32)@85886 b=ef891680 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 (8,48)@85895 b=ef891680 r=ef9c49b0 s=140288(size=524288) prio=0 rw 1 (8,64)@85895 b=f24f0d80 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 (8,80)@85903 b=ef891680 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 I'll use stock Linus until the direct-io rework is completed/tested. Thanks a lot for your help beto From owner-linux-xfs@oss.sgi.com Fri Nov 28 17:41:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Nov 2003 17:41:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAT1fBTa013865 for ; Fri, 28 Nov 2003 17:41:11 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAT21tHc008047 for ; Fri, 28 Nov 2003 20:01:56 -0600 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 MAA19921; Sat, 29 Nov 2003 12:39:44 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAT1dNUc1900451; Sat, 29 Nov 2003 12:39:33 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAT1dMbb1877204; Sat, 29 Nov 2003 12:39:22 +1100 (EST) Date: Sat, 29 Nov 2003 12:39:22 +1100 From: Nathan Scott To: Alberto Nava Cc: linux-xfs@oss.sgi.com Subject: Re: direct-IO writes strange behavior Message-ID: <20031129123922.B1819165@wobbly.melbourne.sgi.com> References: <3FBECF7E.6010509@kasenna.com> <3FBFEF6A.3000609@kasenna.com> <20031127004420.77f31a9c.akpm@osdl.org> <3FC78FA4.2090000@kasenna.com> <3FC7F2E1.6070202@kasenna.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3FC7F2E1.6070202@kasenna.com>; from beto@kasenna.com on Fri, Nov 28, 2003 at 05:14:09PM -0800 X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 842 Lines: 30 On Fri, Nov 28, 2003 at 05:14:09PM -0800, Alberto Nava wrote: > Alberto Nava wrote: > > > > > I'll try this again on test9 or test11. > > > I tried this with the 2.6.0-test11 and it works fine. The 512k > writes to a new file are propagaded all the way to the drives. It > work without having to use '-d unwritten' or preallocation. > > Here is a snip of the proc file I used to verify it. > > (8,16)@85886 b=f24f0d80 r=ef9c49b0 s=140288(size=524288) prio=0 rw 1 > (8,32)@85886 b=ef891680 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 > (8,48)@85895 b=ef891680 r=ef9c49b0 s=140288(size=524288) prio=0 rw 1 > (8,64)@85895 b=f24f0d80 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 > (8,80)@85903 b=ef891680 r=ef9c47b8 s=140288(size=524288) prio=0 rw 1 > thanks for checking. > Thanks a lot for your help no problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Nov 29 10:14:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Nov 2003 10:14:34 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hATIEJTa002143 for ; Sat, 29 Nov 2003 10:14:20 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hATIEHZm001070 for ; Sat, 29 Nov 2003 19:14:17 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 29 Nov 2003 19:14:17 +0100 (CET) Received: (qmail 9177 invoked from network); 29 Nov 2003 19:14:17 +0100 Received: from pc9391.physik.uni-regensburg.de (mail@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 29 Nov 2003 19:14:17 +0100 Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 1AQ9bl-0005fz-00; Sat, 29 Nov 2003 19:14:17 +0100 Date: Sat, 29 Nov 2003 19:14:17 +0100 From: Christian Guggenberger To: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: <20031129181417.GB21726@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de References: <3FC6E5C4.2080009@cse.iitb.ac.in> <20031129085715.A1872948@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129085715.A1872948@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1155 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 547 Lines: 18 On Sat, Nov 29, 2003 at 08:57:15AM +1100, Nathan Scott wrote: > On Fri, Nov 28, 2003 at 11:35:56AM +0530, Soumen Chakrabarti wrote: > > ... > > Some other people seem to have confirmed in the meantime that the > > problem shown by bonnie on 2.4.22 + 1.3.1 is a real one. > > Can anyone confirm whether or not this log reservation message > still occurs when using the "ikeep" mount option? > Nathan, indeed, the 'ikeep' option works around the log reservation problems seen previously. (I also made new comment on bugzilla) thanks Christian From owner-linux-xfs@oss.sgi.com Sat Nov 29 10:11:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Nov 2003 10:12:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hATIBhTa001967 for ; Sat, 29 Nov 2003 10:11:43 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hATIBhM1001966 for linux-xfs@oss.sgi.com; Sat, 29 Nov 2003 10:11:43 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hATIBfTc001952 for ; Sat, 29 Nov 2003 10:11:41 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hATI8A1l001930; Sat, 29 Nov 2003 10:08:10 -0800 Date: Sat, 29 Nov 2003 10:08:10 -0800 Message-Id: <200311291808.hATI8A1l001930@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 1154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 638 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-29-11 10:08 PDT ------- Nathan, your suggestion, to use the 'ikeep' mount options really does help here. This was tested with CVS 2.4.23-rc1 (SGI-XFS CVS-2003-11-11_06:00_UTC with ACLs, no debug enabled) - no log reservation problem observed anylonger when mounting with '-o ikeep'. Sorry, my mail relay seems to be broken, so I could'n't respond to your message on the list. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 29 10:23:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Nov 2003 10:23:15 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hATIN2Ta002826 for ; Sat, 29 Nov 2003 10:23:03 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hATIN1Zm005190 for ; Sat, 29 Nov 2003 19:23:02 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 29 Nov 2003 19:23:01 +0100 (CET) Received: (qmail 9258 invoked from network); 29 Nov 2003 19:23:01 +0100 Received: from pc9391.physik.uni-regensburg.de (mail@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 29 Nov 2003 19:23:01 +0100 Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 1AQ2lv-00031G-00 for ; Sat, 29 Nov 2003 11:56:19 +0100 Date: Sat, 29 Nov 2003 11:56:18 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: <20031129105618.GB11474@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 598 Lines: 19 On Sat, Nov 29, 2003 at 08:57:15AM +1100, Nathan Scott wrote: > On Fri, Nov 28, 2003 at 11:35:56AM +0530, Soumen Chakrabarti wrote: > > ... > > Some other people seem to have confirmed in the meantime that the > > problem shown by bonnie on 2.4.22 + 1.3.1 is a real one. > > Can anyone confirm whether or not this log reservation message > still occurs when using the "ikeep" mount option? > Hi Nathan, indeed, this fixes the log reservation problem here. (at least for first test) another bonnie++ run is currently running - I'll let you know, if something bad happens... thanks. Christian From owner-linux-xfs@oss.sgi.com Sat Nov 29 15:40:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Nov 2003 15:41:15 -0800 (PST) Received: from alienAngel.upjs.sk (gprs145-81.eurotel.cz [160.218.145.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hATNejTa015820 for ; Sat, 29 Nov 2003 15:40:51 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id F28A718D; Sun, 30 Nov 2003 00:41:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id EE46E18C; Sun, 30 Nov 2003 00:41:45 +0100 (CET) Date: Sun, 30 Nov 2003 00:41:45 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: <20031129085715.A1872948@wobbly.melbourne.sgi.com> Message-ID: References: <3FC6E5C4.2080009@cse.iitb.ac.in> <20031129085715.A1872948@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1157 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 25 On Sat, 29 Nov 2003, Nathan Scott wrote: > Can anyone confirm whether or not this log reservation message > still occurs when using the "ikeep" mount option? Seem that you hit the problem. I tested 2.6.0-test11 with SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, realtime, no debug enabled. With ikeep bonnie worked without error. Interesting is that before test df showed: /dev/loop0 519488 144 519344 1% /mnt/mnt2 After test: /dev/loop0 519488 131340 388148 26% /mnt/mnt2 And there wasn't any file on the disk. Was the space consumed by inode table? BTW when we talking about ikeep there is duplicated section about ikeep in linux-2.6-xfs/Documentation/filesystems/xfs.txt in CVS. jan -- From owner-linux-xfs@oss.sgi.com Sun Nov 30 02:39:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Nov 2003 02:39:22 -0800 (PST) Received: from zoidberg.canadatux.org (zoidberg@[207.35.33.175]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAUAd1Ta032104 for ; Sun, 30 Nov 2003 02:39:01 -0800 Received: from localhost (zoidberg.canadatux.org [127.0.0.1]) by zoidberg.canadatux.org (Postfix) with ESMTP id 4E60D8091 for ; Sun, 30 Nov 2003 02:39:00 -0800 (PST) Received: from zoidberg.canadatux.org ([127.0.0.1]) by localhost (zoidberg [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21154-07 for ; Sun, 30 Nov 2003 02:38:59 -0800 (PST) Received: from kridder.de (ip-190.hilton.RWTH-Aachen.DE [134.130.55.190]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by zoidberg.canadatux.org (Postfix) with ESMTP id 3786D808C for ; Sun, 30 Nov 2003 02:38:59 -0800 (PST) Message-ID: <3FC9C8C0.6060002@kridder.de> Date: Sun, 30 Nov 2003 11:38:56 +0100 From: Klaus Ridder User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xlog_clear_stale_blocks crashes in line 1242 (suse 9) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at canadatux.org X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mails.2003__contact-me-at__klaus@kridder.de Precedence: bulk X-list: linux-xfs Content-Length: 934 Lines: 33 You should have a look at the function xlog_clear_stale_blocks( in file xfs_log_recover.c especially at the line 1242: + XFS_ERROR_REPORT("xlog_clear_stale_blocks(1)", Suse 9 reports an error while trying to mount the file system with wrong password: Filesystem "loop(7,0)": XFS internal error xlog_clear_stale_blocks(1) at line 1242 of file xfs_log_recover.c This error message comes after approx. 30 Seconds of waiting time. It is absolutely reproducable, it is always the line 1242. It is a 1 TB partition (8 x 160 GB IDE) which is encrypted. I guess suse swapped the harddisks or somethiong is wrong with the encryption, so XFS only gets junk data. Probably it scans for something and runs out of INT range? I am not on the XFS list (and wil not subscribe), so it would be kind of you to send me a cc when you figured out the problem or need further information. Regards, Klaus From owner-linux-xfs@oss.sgi.com Sun Nov 30 15:22:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Nov 2003 15:23:22 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAUNMrTa032131 for ; Sun, 30 Nov 2003 15:22:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAUNhjHc029982 for ; Sun, 30 Nov 2003 17:43:45 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAUNMirA2846672 for ; Mon, 1 Dec 2003 10:22:45 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAUNMi1W2843727 for linux-xfs@oss.sgi.com; Mon, 1 Dec 2003 10:22:44 +1100 (EST) Date: Mon, 1 Dec 2003 10:22:44 +1100 (EST) From: Nathan Scott Message-Id: <200311302322.hAUNMi1W2843727@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - noikeep mount option X-archive-position: 1159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 461 Lines: 19 Add a noikeep mount option, make ikeep the default for now, until this last transaction reservation issue is sorted out. Date: Sun Nov 30 15:18:10 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162621a linux/fs/xfs/xfs_vfsops.c - 1.441 Modid: 2.4.x-xfs:slinx:162621b linux/Documentation/filesystems/xfs.txt - 1.17 From owner-linux-xfs@oss.sgi.com Sun Nov 30 15:28:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Nov 2003 15:28:59 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hAUNSlTa032552 for ; Sun, 30 Nov 2003 15:28:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hAULZYOO022039 for ; Sun, 30 Nov 2003 13:35:35 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hAUNSerA2846234 for ; Mon, 1 Dec 2003 10:28:40 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hAUNSdx82842250 for linux-xfs@oss.sgi.com; Mon, 1 Dec 2003 10:28:39 +1100 (EST) Date: Mon, 1 Dec 2003 10:28:39 +1100 (EST) From: Nathan Scott Message-Id: <200311302328.hAUNSdx82842250@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix ikeep docs on 2.6 X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 12 Remove duplicate documentation for the XFS ikeep mount option. Date: Sun Nov 30 15:27:54 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:162622a linux/Documentation/filesystems/xfs.txt - 1.20 From owner-linux-xfs@oss.sgi.com Sun Nov 30 17:06:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Nov 2003 17:06:56 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB116ZTa004714 for ; Sun, 30 Nov 2003 17:06:35 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hAUNDMOO029908 for ; Sun, 30 Nov 2003 15:13:23 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12350 for ; Mon, 1 Dec 2003 12:06:27 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id DA633C00AE; Mon, 1 Dec 2003 12:06:26 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id DAF5D14009D; Mon, 1 Dec 2003 12:06:26 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.23 Date: Mon, 01 Dec 2003 12:06:25 +1100 Message-ID: <2663.1070240785@kao2.melbourne.sgi.com> X-archive-position: 1161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 888 Lines: 26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.24/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/ypQRi4UHNye0ZOoRAuCrAKCBsTaF2+HnSkFAoDOpcdaZgC70agCfbv60 b7mjlxoJfo5lJgbQ3C2o0iY= =K+j2 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Nov 30 22:22:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 Nov 2003 22:22:56 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB16MiTa016123 for ; Sun, 30 Nov 2003 22:22:44 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB16hYHc022772 for ; Mon, 1 Dec 2003 00:43:35 -0600 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 RAA03390; Mon, 1 Dec 2003 17:21:14 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB16LCUc1974993; Mon, 1 Dec 2003 17:21:13 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB16L2ou002143; Mon, 1 Dec 2003 17:21:03 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB16KqpX002141; Mon, 1 Dec 2003 17:20:52 +1100 Date: Mon, 1 Dec 2003 17:20:52 +1100 From: Nathan Scott To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: XFS for 2.4 Message-ID: <20031201062052.GA2022@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2965 Lines: 79 Hi Marcelo, Please do a bk pull http://xfs.org:8090/linux-2.4+coreXFS This will merge the core 2.4 kernel changes required for supporting the XFS filesystem, as listed below. If this all looks acceptable, then please also pull the filesystem-specific code (fs/xfs/*) bk pull http://xfs.org:8090/linux-2.4+justXFS cheers. -- Nathan linux-2.4+coreXFS updates the following files: Documentation/Changes | 16 ++ Documentation/Configure.help | 84 +++++++++++++ Documentation/filesystems/00-INDEX | 2 Documentation/filesystems/xfs.txt | 226 +++++++++++++++++++++++++++++++++++-- MAINTAINERS | 8 + drivers/block/ll_rw_blk.c | 3 fs/Config.in | 7 + fs/Makefile | 4 fs/buffer.c | 59 ++++++++- fs/inode.c | 46 +++---- fs/namei.c | 13 +- fs/open.c | 13 ++ include/linux/dqblk_xfs.h | 9 - include/linux/fs.h | 50 +++++++- include/linux/posix_acl_xattr.h | 67 ++++++++++ include/linux/sched.h | 1 kernel/ksyms.c | 12 + mm/filemap.c | 63 +++++++++- 18 files changed, 618 insertions(+), 65 deletions(-) through these ChangeSets: (03/11/24 1.1183.1.1) VFS support for filesystems which implement POSIX ACLs. This involves an inode flag which directs the VFS to skip application of the umask so that the filesystem ACL code can do this according to the POSIX rules, and a new header file defining the contents of the 2 system ACL extended attributes. This is a backport from 2.6. (03/11/25 1.1194) Fix utimes(2) and immutable/append-only files. (03/11/25 1.1195) Remove some unused macros and related comment from the XFS quota header. (03/11/25 1.1196) Add a process flag to identify a process performing a transaction. Used by XFS and backported from 2.6. (03/11/25 1.1197) Support for delayed allocation. Used by XFS and backported from 2.6. (03/11/25 1.1198) Provide a simple try-lock based dirty page flushing routine. (03/11/25 1.1199) Provide an iget variant without unlocking the inode and without the read_inode call (iget_locked). Used by XFS and backported from 2.6. (03/11/26 1.1200) Export several kernel symbols used by the XFS filesystem. (03/11/26 1.1201) Add XFS documentation and incorporate XFS into the kernel build. (03/12/01 1.1202.1.1) [XFS] Document the XFS noikeep option, make ikeep the default.