From vapier@gentoo.org Sun Mar 1 01:59:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_92, URIBL_SBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n217x54i144744 for ; Sun, 1 Mar 2009 01:59:06 -0600 X-ASG-Debug-ID: 1235894310-420d01cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.gentoo.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 965A816178A for ; Sat, 28 Feb 2009 23:58:30 -0800 (PST) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by cuda.sgi.com with ESMTP id zjbhTYNmDAnGuIPc for ; Sat, 28 Feb 2009 23:58:30 -0800 (PST) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 9DD1364CE8; Sun, 1 Mar 2009 07:58:29 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: Greg Banks X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Date: Sun, 1 Mar 2009 02:58:27 -0500 User-Agent: KMail/1.11.0 (Linux/2.6.28; KDE/4.2.0; x86_64; ; ) Cc: Andreas Gruenbacher , Christoph Hellwig , Eric Sandeen , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <200902271055.51564.agruen@suse.de> <49A9E555.7040607@sgi.com> In-Reply-To: <49A9E555.7040607@sgi.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1781653.3Hb6ZSkffo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903010258.28930.vapier@gentoo.org> X-Barracuda-Connect: smtp.gentoo.org[140.211.166.183] X-Barracuda-Start-Time: 1235894317 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart1781653.3Hb6ZSkffo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 28 February 2009 20:31:01 Greg Banks wrote: > Andreas Gruenbacher wrote: > > Jumping between different versions of the auto* tools would become quite > > ugly, > > Absolutely, you want to avoid that. But conversely you can't rely on > everybody who ever needs to change configure.ac having exactly the same > version of autoconf as the maintainer. that isnt to say we should attempt to support every random version out ther= e. =20 if people want to make with autotools, it's reasonable to require them to h= ave=20 recent versions. =2Dmike --nextPart1781653.3Hb6ZSkffo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iQIcBAABAgAGBQJJqkAkAAoJEEFjO5/oN/WBT0AQAL8DWySdOmxByXqN6JMEhOtW U9G1xhhO9jYxBMq76tdqnL4ZOE0p6BbcMUg8HEbe2qBZfIlp08z86X+uxkQfDupJ do6JJfV+j+y7rqB1nRJEbzjnED3uILmZOmdkwfLCwy4Nn5inHHZQaIg4ywdacBeH ICQsFxAX4NEQM/VTZisWQxqQ+EJRg7OrESUfrIENTAhVhajZSSYMzqiOOuN0VHP1 zPgwrZ1w5LxmkrZcf6PHIOWIfuuIZaGyvMY0UiPlAqT8gobg0NCHEiLZgVRDeIk+ 77/bdLgp9T3fAegyoZ3kdvrPQDMEzkqMQydHtKITGcDmCreT2d3zRGslpIfjayqf X7rt9ssiXv84YoD9jSn3QPk5UC+5IbSYxs6TExzp8oZzx2DVPiQFtqxZ30TB5HjX jEXdgKpq7xRjozsXlFEkys28bkyGz6Sd0S2hL7ks1zdunFkjecezhowpyMYpDaSl T/vykLJFBJHMaGLGkuCi82xhL6KcGU6Pc3C4bqmoFgKVZL/BpCver7ajeM7qwu2g 4W/KGAG1JWDANxyVdG8fXBA4EBuzlsXOEJuQTg62azufj+TnOSDrU6aVdGF66jUf 3A0ysbJv7zy4rZbfNDUml9PD/u3jmF2WCKPLBTctN4mq4cOWu4Bj3owHd14hIQoC 7ljnldUhcSvfDUb2LOVW =fX6K -----END PGP SIGNATURE----- --nextPart1781653.3Hb6ZSkffo-- From agruen@suse.de Sun Mar 1 11:24:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n21HOKir167924 for ; Sun, 1 Mar 2009 11:24:21 -0600 X-ASG-Debug-ID: 1235928231-27dd02db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C28AA16248A for ; Sun, 1 Mar 2009 09:23:51 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id s9VNN1h5eEuGtAls for ; Sun, 01 Mar 2009 09:23:51 -0800 (PST) Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 3E124483BB; Sun, 1 Mar 2009 18:23:17 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: Eric Sandeen X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Date: Sun, 1 Mar 2009 18:23:09 +0100 User-Agent: KMail/1.9.9 Cc: Christoph Hellwig , Mike Frysinger , "xfs-oss" , Greg Banks References: <200902240010.25434.vapier@gentoo.org> <200902280107.06699.agruen@suse.de> <49A9BA50.7050101@sandeen.net> In-Reply-To: <49A9BA50.7050101@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903011823.09613.agruen@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1235928232 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19186 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Saturday, 28 February 2009 23:27:28 Eric Sandeen wrote: > Andreas Gruenbacher wrote: > > On Friday, 27 February 2009 0:03:00 Christoph Hellwig wrote: > >> Do you plan to take over nfs4acl, too? > > > > I can sure copy the repository over from you if that is any help. How > > that project will proceed is still unclear though, so don't expect a lot > > to happen there anytime soon. > > > > Andreas > > I'd check in w/ Greg on that too, maybe? Yes, makes sense. I've copied Christoph's tree over and set up permissions; you should have access now. Greg doesn't have a kernel.org account yet, so I can't give him access at the moment. git://git.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git Would you like write access to the attr.git and acl.git trees as well? Thanks, Andreas From jack@suse.cz Mon Mar 2 07:36:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n22DafMU213253 for ; Mon, 2 Mar 2009 07:36:42 -0600 X-ASG-Debug-ID: 1236000973-64bf027d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 30EDC164755 for ; Mon, 2 Mar 2009 05:36:13 -0800 (PST) Received: from mx1.suse.de (mail.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id iHH66FxnG1BiEf2L for ; Mon, 02 Mar 2009 05:36:13 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id D242E455AF; Mon, 2 Mar 2009 14:36:11 +0100 (CET) Received: from duck.suse.cz (duck.suse.cz [10.20.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suse.cz (Postfix) with ESMTP id 1433362807F; Mon, 2 Mar 2009 14:36:11 +0100 (CET) Received: by duck.suse.cz (Postfix, from userid 10005) id 9E1941F1E2F; Mon, 2 Mar 2009 14:36:10 +0100 (CET) Date: Mon, 2 Mar 2009 14:36:10 +0100 From: Jan Kara To: Alessandro Bono Cc: Dave Chinner , Christoph Hellwig , linux-xfs , linux-kernel X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Message-ID: <20090302133609.GD23880@duck.suse.cz> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <20090209075308.GA7360@infradead.org> <20090210104304.GP8830@disturbed> <1234432077.9204.15.camel@champagne.cantina> <20090226165838.GA9602@atrey.karlin.mff.cuni.cz> <1235763895.5743.3.camel@champagne> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1235763895.5743.3.camel@champagne> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: mail.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1236000974 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri 27-02-09 20:44:55, Alessandro Bono wrote: > On Thu, 2009-02-26 at 17:58 +0100, Jan Kara wrote: > .... > > > any suggestion? > > Hmm, are you still able to reproduce the problem? As I'm looking into > > registers in your dump, no register really seems to contain sensible pa= ge > > flags so it could be some corruption of page pointer. If you are still > > able to reproduce, could you please do so with the attached patch > > applied? It will dump us much more information... Thanks. > >=20 > > Honza > >=20 >=20 > this time with plain xfs, no lvm no dm_crypt > just to add some info > xfs fs created with this command >=20 > mkfs.xfs -f -l lazy-count=3D1,version=3D2,size=3D128m -i attr=3D2 -d agco= unt=3D4 > -L store /dev/sdb1 OK, thanks for the data. I've looked at both your traces and I think the most likely cause is a bit-flip in memory. Look: The page address (we got =66rom bh->b_page) is ffffe20000885604. IMHO it should be ffffe20000885600 because if you look e.g. at mapping, it is 000ac69affff8800, which is a bogus value but it would look like a valid pointer if we shift it by 32 bits to the left. The same with private pointer. Index also looks absurdly high but low 32-bits are actually 0 and previous 4 bytes in the page structure (we have them shown in the upper 4 bytes of mapping pointer) contain 0x000ac69a =3D> so given together page index would be 706202 - perfectly sensible value. And in the second report it is the same. Also buffer head looks perfectly valid in both cases. Such bit flips are usually caused by faulty memory or other HW (io controler etc.) so I suggest trying to shuffle the hardware somehow - change memory DIMMs as a starter, running memtest if you don't have a spare DIMMs but it is not an exception that even though memtest runs just fine for a long time, memory is really at fault. Honza > Feb 27 19:20:28 champagne kernel: [ 2664.993272] Buffer ffff8800371e7e70 = of page ffffe20000885604 not private! Some data to debug: > Feb 27 19:20:28 champagne kernel: [ 2664.993282] flags: 240000000, mappin= g: 000ac69affff8800, index: 54276223274057728, private: 2489e50ffff8800 > Feb 27 19:20:28 champagne kernel: [ 2664.993288] Buffer: state=3D125, blo= ck=3D23795642, b_size=3D4096, b_this_page=3Dffff8800371e7e70 > Feb 27 19:20:28 champagne kernel: [ 2664.993293] Other buffers in the pag= e: > Feb 27 19:20:28 champagne kernel: [ 2664.993355] ------------[ cut here ]= ------------ > Feb 27 19:20:28 champagne kernel: [ 2664.993361] Kernel BUG at ffffffff80= 2b3653 [verbose debug info unavailable] > Feb 27 19:20:28 champagne kernel: [ 2664.993366] invalid opcode: 0000 [#1= ] SMP > Feb 27 19:20:28 champagne kernel: [ 2664.993373] last sysfs file: /sys/de= vices/system/cpu/cpu0/cpufreq/scaling_cur_freq > Feb 27 19:20:28 champagne kernel: [ 2664.993378] CPU 1 > Feb 27 19:20:28 champagne kernel: [ 2664.993382] Modules linked in: xfs n= ls_iso8859_1 nls_cp437 vfat fat nls_base usb_storage libusual af_packet bin= fmt_misc rfcomm bridge stp llc bnep sco l2cap kvm_intel kvm ppdev ipv6 acpi= _cpufreq cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand= freq_table cpufreq_conservative pci_slot sbs sbshc iptable_filter ip_table= s x_tables dm_crypt sbp2 lp snd_hda_intel snd_hwdep snd_pcm_oss arc4 snd_pc= m snd_page_alloc ecb snd_mixer_oss snd_seq_dummy snd_seq_oss iwlagn iwlcore= usbhid snd_seq_midi rfkill btusb snd_rawmidi snd_seq_midi_event snd_seq hi= d parport_pc snd_timer mac80211 pcmcia bluetooth parport snd_seq_device lis= 3lv02d leds_hp_disk sdhci_pci sdhci snd video output ricoh_mmc pcspkr tpm_i= nfineon tpm tpm_bios cfg80211 mmc_core led_class yenta_socket rsrc_nonstati= c pcmcia_core psmouse container wmi battery ac button soundcore serio_raw i= TCO_wdt iTCO_vendor_support evdev dm_multipath ext3 jbd mbcache sr_mod cdro= m sg sd_mod crc_t10dif ohci1394 ata_piix ahci ieee1394 l > Feb 27 19:20:28 champagne kernel: bata scsi_mod ehci_hcd uhci_hcd usbcore= e1000e dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processo= r fan thermal_sys hwmon fuse > Feb 27 19:20:28 champagne kernel: [ 2664.993553] Pid: 8367, comm: xfsdata= d/1 Not tainted 2.6.28.7 #1 > Feb 27 19:20:28 champagne kernel: [ 2664.993558] RIP: 0010:[] [] end_buffer_async_write+0x119/0x18d > Feb 27 19:20:28 champagne kernel: [ 2664.993573] RSP: 0018:ffff880084555e= 40 EFLAGS: 00010246 > Feb 27 19:20:28 champagne kernel: [ 2664.993578] RAX: 0000000240000000 RB= X: ffff8800371e7e70 RCX: ffffffff80554d00 > Feb 27 19:20:28 champagne kernel: [ 2664.993584] RDX: ffff8800a7ae3000 RS= I: 0000000000000046 RDI: ffffffff80572f50 > Feb 27 19:20:28 champagne kernel: [ 2664.993589] RBP: ffff8800371e7e70 R0= 8: 0000000000000000 R09: 0000000000000000 > Feb 27 19:20:28 champagne kernel: [ 2664.993594] R10: 000000000000000a R1= 1: 0000000000018600 R12: ffff8801159fd288 > Feb 27 19:20:28 champagne kernel: [ 2664.993599] R13: ffffe20000885604 R1= 4: ffff88013b85ff00 R15: 0000000000000001 > Feb 27 19:20:28 champagne kernel: [ 2664.993605] FS: 0000000000000000(00= 00) GS:ffff88013b803a00(0000) knlGS:0000000000000000 > Feb 27 19:20:28 champagne kernel: [ 2664.993611] CS: 0010 DS: 0018 ES: 0= 018 CR0: 000000008005003b > Feb 27 19:20:28 champagne kernel: [ 2664.993616] CR2: 00007f9deefb8ca8 CR= 3: 0000000117829000 CR4: 00000000000026e0 > Feb 27 19:20:28 champagne kernel: [ 2664.993621] DR0: 0000000000000000 DR= 1: 0000000000000000 DR2: 0000000000000000 > Feb 27 19:20:28 champagne kernel: [ 2664.993626] DR3: 0000000000000000 DR= 6: 00000000ffff0ff0 DR7: 0000000000000400 > Feb 27 19:20:28 champagne kernel: [ 2664.993632] Process xfsdatad/1 (pid:= 8367, threadinfo ffff880084554000, task ffff88008c1222b0) > Feb 27 19:20:28 champagne kernel: [ 2664.993636] Stack: > Feb 27 19:20:28 champagne kernel: [ 2664.993640] 0000000000000282 000000= 0000000004 ffff88000248b6c0 ffff8801159fd288 > Feb 27 19:20:28 champagne kernel: [ 2664.993648] ffff88013b85fee0 000000= 0000000000 ffff88010dc356c0 ffff8801159fd288 > Feb 27 19:20:28 champagne kernel: [ 2664.993657] ffff88013b85fee0 ffffff= ffa055a9f9 ffffffffa055ab6b ffff8801159fd280 > Feb 27 19:20:28 champagne kernel: [ 2664.993667] Call Trace: > Feb 27 19:20:28 champagne kernel: [ 2664.993671] [] ? = xfs_destroy_ioend+0x23/0x71 [xfs] > Feb 27 19:20:28 champagne kernel: [ 2664.993723] [] ? = xfs_end_bio_delalloc+0x0/0x19 [xfs] > Feb 27 19:20:28 champagne kernel: [ 2664.993770] [] ? = xfs_end_bio_delalloc+0x0/0x19 [xfs] > Feb 27 19:20:28 champagne kernel: [ 2664.993815] [] ? = run_workqueue+0x79/0xfe > Feb 27 19:20:28 champagne kernel: [ 2664.993826] [] ? = worker_thread+0xd8/0xe7 > Feb 27 19:20:28 champagne kernel: [ 2664.993834] [] ? = autoremove_wake_function+0x0/0x2e > Feb 27 19:20:28 champagne kernel: [ 2664.993842] [] ? = worker_thread+0x0/0xe7 > Feb 27 19:20:28 champagne kernel: [ 2664.993849] [] ? = kthread+0x47/0x73 > Feb 27 19:20:28 champagne kernel: [ 2664.993856] [] ? = schedule_tail+0x27/0x5f > Feb 27 19:20:28 champagne kernel: [ 2664.993864] [] ? = child_rip+0xa/0x11 > Feb 27 19:20:28 champagne kernel: [ 2664.993872] [] ? = kthread+0x0/0x73 > Feb 27 19:20:28 champagne kernel: [ 2664.993879] [] ? = child_rip+0x0/0x11 > Feb 27 19:20:28 champagne kernel: [ 2664.993885] Code: 10 4c 8b 43 20 48 = 8b 13 48 89 de 48 c7 c7 f8 ef 46 80 31 c0 e8 b2 db 13 00 48 8b 5b 08 48 39 = eb 75 d7 49 8b 45 00 f6 c4 08 75 04 <0f> 0b eb fe 49 8b 5d 10 9c 41 5c fa e= b 07 f3 90 f603 10 75 f9 > Feb 27 19:20:28 champagne kernel: [ 2664.993950] RIP [= ] end_buffer_async_write+0x119/0x18d > Feb 27 19:20:28 champagne kernel: [ 2664.993959] RSP > Feb 27 19:20:28 champagne kernel: [ 2664.993985] ---[ end trace 2d34f9781= 1caf921 ]--- >=20 --=20 Jan Kara SUSE Labs, CR From alessandro.bono@gmail.com Mon Mar 2 09:05:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n22F5XdN217435 for ; Mon, 2 Mar 2009 09:05:39 -0600 X-ASG-Debug-ID: 1236006304-31cd02150000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from an-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60DBD164B63 for ; Mon, 2 Mar 2009 07:05:04 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by cuda.sgi.com with ESMTP id mLnMO21f8GmzJ2NX for ; Mon, 02 Mar 2009 07:05:04 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d11so1476132and.32 for ; Mon, 02 Mar 2009 07:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=V+t3Ijo03HF3ifQfuG1iJmbIVLRsHSBAUJke45D9tbI=; b=xQmtIXJ3MmtVi3GNpQUwQ/MblPS/NPgDJ7AFiB6b28XMILDj5QvPjGDeULL6Yti65B HLU9bK/Z17OGLb+ie2KnTrprlhZvQqCcO8PCO02kM0e0AiSfoK5jvCvMEcBy7catYlgy oQjSQZTUdYzrfP1Uq4LDoadUDj1DGrIkUVWO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Y03Tdqu4MQFT5yt3L+fMA1UrdCaZN6M6uDVRpWY0OScGOPQzlIkc4u0W7ORDImW19a yIUWibROo0zx/12EQcr6YnqnSD2qWZf+5uHHNUt1ooWTomao5cibiUATDyehaBvTCb9U bxyFAARKXYq+4ryJrWDXHdQ41QllGNLqNIAtA= Received: by 10.100.119.17 with SMTP id r17mr4816672anc.61.1236006303807; Mon, 02 Mar 2009 07:05:03 -0800 (PST) Received: from ?10.12.18.197? (host206-245-static.55-88-b.business.telecomitalia.it [88.55.245.206]) by mx.google.com with ESMTPS id d25sm4970573nfh.10.2009.03.02.07.05.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Mar 2009 07:05:02 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Jan Kara Cc: Dave Chinner , Christoph Hellwig , linux-xfs , linux-kernel In-Reply-To: <20090302133609.GD23880@duck.suse.cz> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <20090209075308.GA7360@infradead.org> <20090210104304.GP8830@disturbed> <1234432077.9204.15.camel@champagne.cantina> <20090226165838.GA9602@atrey.karlin.mff.cuni.cz> <1235763895.5743.3.camel@champagne> <20090302133609.GD23880@duck.suse.cz> Content-Type: text/plain Date: Mon, 02 Mar 2009 16:04:59 +0100 Message-Id: <1236006299.5744.7.camel@champagne> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: an-out-0708.google.com[209.85.132.241] X-Barracuda-Start-Time: 1236006305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 2009-03-02 at 14:36 +0100, Jan Kara wrote: > On Fri 27-02-09 20:44:55, Alessandro Bono wrote: > > On Thu, 2009-02-26 at 17:58 +0100, Jan Kara wrote: > > .... > > > > any suggestion? > > > Hmm, are you still able to reproduce the problem? As I'm looking in= to > > > registers in your dump, no register really seems to contain sensible = page > > > flags so it could be some corruption of page pointer. If you are stil= l > > > able to reproduce, could you please do so with the attached patch > > > applied? It will dump us much more information... Thanks. > > >=20 > > > Honza > > >=20 > >=20 > > this time with plain xfs, no lvm no dm_crypt > > just to add some info > > xfs fs created with this command > >=20 > > mkfs.xfs -f -l lazy-count=3D1,version=3D2,size=3D128m -i attr=3D2 -d ag= count=3D4 > > -L store /dev/sdb1 > OK, thanks for the data. I've looked at both your traces and I think th= e > most likely cause is a bit-flip in memory. Look: The page address (we got > from bh->b_page) is ffffe20000885604. IMHO it should be ffffe20000885600 > because if you look e.g. at mapping, it is 000ac69affff8800, which is a > bogus value but it would look like a valid pointer if we shift it by 32 > bits to the left. The same with private pointer. Index also looks absurdl= y > high but low 32-bits are actually 0 and previous 4 bytes in the page > structure (we have them shown in the upper 4 bytes of mapping pointer) > contain 0x000ac69a =3D> so given together page index would be 706202 - > perfectly sensible value. > And in the second report it is the same. Also buffer head looks perfect= ly > valid in both cases. > Such bit flips are usually caused by faulty memory or other HW (io > controler etc.) so I suggest trying to shuffle the hardware somehow - > change memory DIMMs as a starter, running memtest if you don't have a spa= re > DIMMs but it is not an exception that even though memtest runs just fine > for a long time, memory is really at fault. Ok, I'll change DIMMs, retest and report back Thanks a lot for your support >=20 > Honza >=20 > > Feb 27 19:20:28 champagne kernel: [ 2664.993272] Buffer ffff8800371e7e7= 0 of page ffffe20000885604 not private! Some data to debug: > > Feb 27 19:20:28 champagne kernel: [ 2664.993282] flags: 240000000, mapp= ing: 000ac69affff8800, index: 54276223274057728, private: 2489e50ffff8800 > > Feb 27 19:20:28 champagne kernel: [ 2664.993288] Buffer: state=3D125, b= lock=3D23795642, b_size=3D4096, b_this_page=3Dffff8800371e7e70 > > Feb 27 19:20:28 champagne kernel: [ 2664.993293] Other buffers in the p= age: > > Feb 27 19:20:28 champagne kernel: [ 2664.993355] ------------[ cut here= ]------------ > > Feb 27 19:20:28 champagne kernel: [ 2664.993361] Kernel BUG at ffffffff= 802b3653 [verbose debug info unavailable] > > Feb 27 19:20:28 champagne kernel: [ 2664.993366] invalid opcode: 0000 [= #1] SMP > > Feb 27 19:20:28 champagne kernel: [ 2664.993373] last sysfs file: /sys/= devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > > Feb 27 19:20:28 champagne kernel: [ 2664.993378] CPU 1 > > Feb 27 19:20:28 champagne kernel: [ 2664.993382] Modules linked in: xfs= nls_iso8859_1 nls_cp437 vfat fat nls_base usb_storage libusual af_packet b= infmt_misc rfcomm bridge stp llc bnep sco l2cap kvm_intel kvm ppdev ipv6 ac= pi_cpufreq cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondema= nd freq_table cpufreq_conservative pci_slot sbs sbshc iptable_filter ip_tab= les x_tables dm_crypt sbp2 lp snd_hda_intel snd_hwdep snd_pcm_oss arc4 snd_= pcm snd_page_alloc ecb snd_mixer_oss snd_seq_dummy snd_seq_oss iwlagn iwlco= re usbhid snd_seq_midi rfkill btusb snd_rawmidi snd_seq_midi_event snd_seq = hid parport_pc snd_timer mac80211 pcmcia bluetooth parport snd_seq_device l= is3lv02d leds_hp_disk sdhci_pci sdhci snd video output ricoh_mmc pcspkr tpm= _infineon tpm tpm_bios cfg80211 mmc_core led_class yenta_socket rsrc_nonsta= tic pcmcia_core psmouse container wmi battery ac button soundcore serio_raw= iTCO_wdt iTCO_vendor_support evdev dm_multipath ext3 jbd mbcache sr_mod cd= rom sg sd_mod crc_t10dif ohci1394 ata_piix ahci ieee1394 l > > Feb 27 19:20:28 champagne kernel: bata scsi_mod ehci_hcd uhci_hcd usbco= re e1000e dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal proces= sor fan thermal_sys hwmon fuse > > Feb 27 19:20:28 champagne kernel: [ 2664.993553] Pid: 8367, comm: xfsda= tad/1 Not tainted 2.6.28.7 #1 > > Feb 27 19:20:28 champagne kernel: [ 2664.993558] RIP: 0010:[] [] end_buffer_async_write+0x119/0x18d > > Feb 27 19:20:28 champagne kernel: [ 2664.993573] RSP: 0018:ffff88008455= 5e40 EFLAGS: 00010246 > > Feb 27 19:20:28 champagne kernel: [ 2664.993578] RAX: 0000000240000000 = RBX: ffff8800371e7e70 RCX: ffffffff80554d00 > > Feb 27 19:20:28 champagne kernel: [ 2664.993584] RDX: ffff8800a7ae3000 = RSI: 0000000000000046 RDI: ffffffff80572f50 > > Feb 27 19:20:28 champagne kernel: [ 2664.993589] RBP: ffff8800371e7e70 = R08: 0000000000000000 R09: 0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993594] R10: 000000000000000a = R11: 0000000000018600 R12: ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993599] R13: ffffe20000885604 = R14: ffff88013b85ff00 R15: 0000000000000001 > > Feb 27 19:20:28 champagne kernel: [ 2664.993605] FS: 0000000000000000(= 0000) GS:ffff88013b803a00(0000) knlGS:0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993611] CS: 0010 DS: 0018 ES:= 0018 CR0: 000000008005003b > > Feb 27 19:20:28 champagne kernel: [ 2664.993616] CR2: 00007f9deefb8ca8 = CR3: 0000000117829000 CR4: 00000000000026e0 > > Feb 27 19:20:28 champagne kernel: [ 2664.993621] DR0: 0000000000000000 = DR1: 0000000000000000 DR2: 0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993626] DR3: 0000000000000000 = DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > Feb 27 19:20:28 champagne kernel: [ 2664.993632] Process xfsdatad/1 (pi= d: 8367, threadinfo ffff880084554000, task ffff88008c1222b0) > > Feb 27 19:20:28 champagne kernel: [ 2664.993636] Stack: > > Feb 27 19:20:28 champagne kernel: [ 2664.993640] 0000000000000282 0000= 000000000004 ffff88000248b6c0 ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993648] ffff88013b85fee0 0000= 000000000000 ffff88010dc356c0 ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993657] ffff88013b85fee0 ffff= ffffa055a9f9 ffffffffa055ab6b ffff8801159fd280 > > Feb 27 19:20:28 champagne kernel: [ 2664.993667] Call Trace: > > Feb 27 19:20:28 champagne kernel: [ 2664.993671] [] = ? xfs_destroy_ioend+0x23/0x71 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993723] [] = ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993770] [] = ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993815] [] = ? run_workqueue+0x79/0xfe > > Feb 27 19:20:28 champagne kernel: [ 2664.993826] [] = ? worker_thread+0xd8/0xe7 > > Feb 27 19:20:28 champagne kernel: [ 2664.993834] [] = ? autoremove_wake_function+0x0/0x2e > > Feb 27 19:20:28 champagne kernel: [ 2664.993842] [] = ? worker_thread+0x0/0xe7 > > Feb 27 19:20:28 champagne kernel: [ 2664.993849] [] = ? kthread+0x47/0x73 > > Feb 27 19:20:28 champagne kernel: [ 2664.993856] [] = ? schedule_tail+0x27/0x5f > > Feb 27 19:20:28 champagne kernel: [ 2664.993864] [] = ? child_rip+0xa/0x11 > > Feb 27 19:20:28 champagne kernel: [ 2664.993872] [] = ? kthread+0x0/0x73 > > Feb 27 19:20:28 champagne kernel: [ 2664.993879] [] = ? child_rip+0x0/0x11 > > Feb 27 19:20:28 champagne kernel: [ 2664.993885] Code: 10 4c 8b 43 20 4= 8 8b 13 48 89 de 48 c7 c7 f8 ef 46 80 31 c0 e8 b2 db 13 00 48 8b 5b 08 48 3= 9 eb 75 d7 49 8b 45 00 f6 c4 08 75 04 <0f> 0b eb fe 49 8b 5d 10 9c 41 5c fa= eb 07 f3 90 f603 10 75 f9 > > Feb 27 19:20:28 champagne kernel: [ 2664.993950] RIP [] end_buffer_async_write+0x119/0x18d > > Feb 27 19:20:28 champagne kernel: [ 2664.993959] RSP > > Feb 27 19:20:28 champagne kernel: [ 2664.993985] ---[ end trace 2d34f97= 811caf921 ]--- > >=20 >=20 --=20 --- Cordiali Saluti Alessandro Bono From linux-kernel-owner+mshoulga=40yandex.ru-S1754855AbZCBPF3@vger.kernel.org Mon Mar 2 09:06:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n22F6JrI217461 for ; Mon, 2 Mar 2009 09:06:20 -0600 X-ASG-Debug-ID: 1236006349-25ee00c40000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from forwards3.yandex.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27D031C0DDCC for ; Mon, 2 Mar 2009 07:05:50 -0800 (PST) Received: from forwards3.yandex.ru (forwards3.yandex.ru [213.180.223.174]) by cuda.sgi.com with ESMTP id HEfEbdEbk0tM9Fne for ; Mon, 02 Mar 2009 07:05:50 -0800 (PST) X-ASG-Whitelist: Sender Received: from mxfront68.yandex.ru (mxfront68.yandex.ru [213.180.223.88]) by forwards3.yandex.ru (Yandex) with ESMTP id CC23319700B; Mon, 2 Mar 2009 18:05:46 +0300 (MSK) Received: from vger.kernel.org ([209.132.176.167]:17028 "EHLO vger.kernel.org" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1738286AbZCBPFf for (+ 4 others); Mon, 2 Mar 2009 18:05:35 +0300 X-Yandex-TimeMark: 1236006330 X-Yandex-Spam: 2 X-Yandex-Front: mxfront68 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754855AbZCBPF3 (ORCPT ); Mon, 2 Mar 2009 10:05:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752325AbZCBPFJ (ORCPT ); Mon, 2 Mar 2009 10:05:09 -0500 Received: from an-out-0708.google.com ([209.85.132.249]:43654 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752254AbZCBPFH convert rfc822-to-8bit (ORCPT ); Mon, 2 Mar 2009 10:05:07 -0500 Received: by an-out-0708.google.com with SMTP id c2so1669289anc.1 for ; Mon, 02 Mar 2009 07:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=V+t3Ijo03HF3ifQfuG1iJmbIVLRsHSBAUJke45D9tbI=; b=xQmtIXJ3MmtVi3GNpQUwQ/MblPS/NPgDJ7AFiB6b28XMILDj5QvPjGDeULL6Yti65B HLU9bK/Z17OGLb+ie2KnTrprlhZvQqCcO8PCO02kM0e0AiSfoK5jvCvMEcBy7catYlgy oQjSQZTUdYzrfP1Uq4LDoadUDj1DGrIkUVWO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Y03Tdqu4MQFT5yt3L+fMA1UrdCaZN6M6uDVRpWY0OScGOPQzlIkc4u0W7ORDImW19a yIUWibROo0zx/12EQcr6YnqnSD2qWZf+5uHHNUt1ooWTomao5cibiUATDyehaBvTCb9U bxyFAARKXYq+4ryJrWDXHdQ41QllGNLqNIAtA= Received: by 10.100.119.17 with SMTP id r17mr4816672anc.61.1236006303807; Mon, 02 Mar 2009 07:05:03 -0800 (PST) Received: from ?10.12.18.197? (host206-245-static.55-88-b.business.telecomitalia.it [88.55.245.206]) by mx.google.com with ESMTPS id d25sm4970573nfh.10.2009.03.02.07.05.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Mar 2009 07:05:02 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Jan Kara Cc: Dave Chinner , Christoph Hellwig , linux-xfs , linux-kernel In-Reply-To: <20090302133609.GD23880@duck.suse.cz> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <20090209075308.GA7360@infradead.org> <20090210104304.GP8830@disturbed> <1234432077.9204.15.camel@champagne.cantina> <20090226165838.GA9602@atrey.karlin.mff.cuni.cz> <1235763895.5743.3.camel@champagne> <20090302133609.GD23880@duck.suse.cz> Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Mar 2009 16:04:59 +0100 Message-Id: <1236006299.5744.7.camel@champagne> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Barracuda-Connect: forwards3.yandex.ru[213.180.223.174] X-Barracuda-Start-Time: 1236006352 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 2009-03-02 at 14:36 +0100, Jan Kara wrote: > On Fri 27-02-09 20:44:55, Alessandro Bono wrote: > > On Thu, 2009-02-26 at 17:58 +0100, Jan Kara wrote: > > .... > > > > any suggestion? > > > Hmm, are you still able to reproduce the problem? As I'm looking into > > > registers in your dump, no register really seems to contain sensible page > > > flags so it could be some corruption of page pointer. If you are still > > > able to reproduce, could you please do so with the attached patch > > > applied? It will dump us much more information... Thanks. > > > > > > Honza > > > > > > > this time with plain xfs, no lvm no dm_crypt > > just to add some info > > xfs fs created with this command > > > > mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > -L store /dev/sdb1 > OK, thanks for the data. I've looked at both your traces and I think the > most likely cause is a bit-flip in memory. Look: The page address (we got > from bh->b_page) is ffffe20000885604. IMHO it should be ffffe20000885600 > because if you look e.g. at mapping, it is 000ac69affff8800, which is a > bogus value but it would look like a valid pointer if we shift it by 32 > bits to the left. The same with private pointer. Index also looks absurdly > high but low 32-bits are actually 0 and previous 4 bytes in the page > structure (we have them shown in the upper 4 bytes of mapping pointer) > contain 0x000ac69a => so given together page index would be 706202 - > perfectly sensible value. > And in the second report it is the same. Also buffer head looks perfectly > valid in both cases. > Such bit flips are usually caused by faulty memory or other HW (io > controler etc.) so I suggest trying to shuffle the hardware somehow - > change memory DIMMs as a starter, running memtest if you don't have a spare > DIMMs but it is not an exception that even though memtest runs just fine > for a long time, memory is really at fault. Ok, I'll change DIMMs, retest and report back Thanks a lot for your support > > Honza > > > Feb 27 19:20:28 champagne kernel: [ 2664.993272] Buffer ffff8800371e7e70 of page ffffe20000885604 not private! Some data to debug: > > Feb 27 19:20:28 champagne kernel: [ 2664.993282] flags: 240000000, mapping: 000ac69affff8800, index: 54276223274057728, private: 2489e50ffff8800 > > Feb 27 19:20:28 champagne kernel: [ 2664.993288] Buffer: state=125, block=23795642, b_size=4096, b_this_page=ffff8800371e7e70 > > Feb 27 19:20:28 champagne kernel: [ 2664.993293] Other buffers in the page: > > Feb 27 19:20:28 champagne kernel: [ 2664.993355] ------------[ cut here ]------------ > > Feb 27 19:20:28 champagne kernel: [ 2664.993361] Kernel BUG at ffffffff802b3653 [verbose debug info unavailable] > > Feb 27 19:20:28 champagne kernel: [ 2664.993366] invalid opcode: 0000 [#1] SMP > > Feb 27 19:20:28 champagne kernel: [ 2664.993373] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > > Feb 27 19:20:28 champagne kernel: [ 2664.993378] CPU 1 > > Feb 27 19:20:28 champagne kernel: [ 2664.993382] Modules linked in: xfs nls_iso8859_1 nls_cp437 vfat fat nls_base usb_storage libusual af_packet binfmt_misc rfcomm bridge stp llc bnep sco l2cap kvm_intel kvm ppdev ipv6 acpi_cpufreq cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand freq_table cpufreq_conservative pci_slot sbs sbshc iptable_filter ip_tables x_tables dm_crypt sbp2 lp snd_hda_intel snd_hwdep snd_pcm_oss arc4 snd_pcm snd_page_alloc ecb snd_mixer_oss snd_seq_dummy snd_seq_oss iwlagn iwlcore usbhid snd_seq_midi rfkill btusb snd_rawmidi snd_seq_midi_event snd_seq hid parport_pc snd_timer mac80211 pcmcia bluetooth parport snd_seq_device lis3lv02d leds_hp_disk sdhci_pci sdhci snd video output ricoh_mmc pcspkr tpm_infineon tpm tpm_bios cfg80211 mmc_core led_class yenta_socket rsrc_nonstatic pcmcia_core psmouse container wmi battery ac button soundcore serio_raw iTCO_wdt iTCO_vendor_support evdev dm_multipath ext3 jbd mbcache sr_mod cdrom sg sd_mod c rc_t10dif ohci1394 ata_piix ahci ieee1394 l > > Feb 27 19:20:28 champagne kernel: bata scsi_mod ehci_hcd uhci_hcd usbcore e1000e dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processor fan thermal_sys hwmon fuse > > Feb 27 19:20:28 champagne kernel: [ 2664.993553] Pid: 8367, comm: xfsdatad/1 Not tainted 2.6.28.7 #1 > > Feb 27 19:20:28 champagne kernel: [ 2664.993558] RIP: 0010:[] [] end_buffer_async_write+0x119/0x18d > > Feb 27 19:20:28 champagne kernel: [ 2664.993573] RSP: 0018:ffff880084555e40 EFLAGS: 00010246 > > Feb 27 19:20:28 champagne kernel: [ 2664.993578] RAX: 0000000240000000 RBX: ffff8800371e7e70 RCX: ffffffff80554d00 > > Feb 27 19:20:28 champagne kernel: [ 2664.993584] RDX: ffff8800a7ae3000 RSI: 0000000000000046 RDI: ffffffff80572f50 > > Feb 27 19:20:28 champagne kernel: [ 2664.993589] RBP: ffff8800371e7e70 R08: 0000000000000000 R09: 0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993594] R10: 000000000000000a R11: 0000000000018600 R12: ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993599] R13: ffffe20000885604 R14: ffff88013b85ff00 R15: 0000000000000001 > > Feb 27 19:20:28 champagne kernel: [ 2664.993605] FS: 0000000000000000(0000) GS:ffff88013b803a00(0000) knlGS:0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993611] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > > Feb 27 19:20:28 champagne kernel: [ 2664.993616] CR2: 00007f9deefb8ca8 CR3: 0000000117829000 CR4: 00000000000026e0 > > Feb 27 19:20:28 champagne kernel: [ 2664.993621] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > Feb 27 19:20:28 champagne kernel: [ 2664.993626] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > Feb 27 19:20:28 champagne kernel: [ 2664.993632] Process xfsdatad/1 (pid: 8367, threadinfo ffff880084554000, task ffff88008c1222b0) > > Feb 27 19:20:28 champagne kernel: [ 2664.993636] Stack: > > Feb 27 19:20:28 champagne kernel: [ 2664.993640] 0000000000000282 0000000000000004 ffff88000248b6c0 ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993648] ffff88013b85fee0 0000000000000000 ffff88010dc356c0 ffff8801159fd288 > > Feb 27 19:20:28 champagne kernel: [ 2664.993657] ffff88013b85fee0 ffffffffa055a9f9 ffffffffa055ab6b ffff8801159fd280 > > Feb 27 19:20:28 champagne kernel: [ 2664.993667] Call Trace: > > Feb 27 19:20:28 champagne kernel: [ 2664.993671] [] ? xfs_destroy_ioend+0x23/0x71 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993723] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993770] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > Feb 27 19:20:28 champagne kernel: [ 2664.993815] [] ? run_workqueue+0x79/0xfe > > Feb 27 19:20:28 champagne kernel: [ 2664.993826] [] ? worker_thread+0xd8/0xe7 > > Feb 27 19:20:28 champagne kernel: [ 2664.993834] [] ? autoremove_wake_function+0x0/0x2e > > Feb 27 19:20:28 champagne kernel: [ 2664.993842] [] ? worker_thread+0x0/0xe7 > > Feb 27 19:20:28 champagne kernel: [ 2664.993849] [] ? kthread+0x47/0x73 > > Feb 27 19:20:28 champagne kernel: [ 2664.993856] [] ? schedule_tail+0x27/0x5f > > Feb 27 19:20:28 champagne kernel: [ 2664.993864] [] ? child_rip+0xa/0x11 > > Feb 27 19:20:28 champagne kernel: [ 2664.993872] [] ? kthread+0x0/0x73 > > Feb 27 19:20:28 champagne kernel: [ 2664.993879] [] ? child_rip+0x0/0x11 > > Feb 27 19:20:28 champagne kernel: [ 2664.993885] Code: 10 4c 8b 43 20 48 8b 13 48 89 de 48 c7 c7 f8 ef 46 80 31 c0 e8 b2 db 13 00 48 8b 5b 08 48 39 eb 75 d7 49 8b 45 00 f6 c4 08 75 04 <0f> 0b eb fe 49 8b 5d 10 9c 41 5c fa eb 07 f3 90 f603 10 75 f9 > > Feb 27 19:20:28 champagne kernel: [ 2664.993950] RIP [] end_buffer_async_write+0x119/0x18d > > Feb 27 19:20:28 champagne kernel: [ 2664.993959] RSP > > Feb 27 19:20:28 champagne kernel: [ 2664.993985] ---[ end trace 2d34f97811caf921 ]--- > > > -- --- Cordiali Saluti Alessandro Bono -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 09:37:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23FbnOu020093 for ; Tue, 3 Mar 2009 09:37:52 -0600 X-ASG-Debug-ID: 1236094642-111302f60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2DE0F1C12929 for ; Tue, 3 Mar 2009 07:37:22 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id vhjy4quQjBzRdRoB for ; Tue, 03 Mar 2009 07:37:22 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeWfq-0004vP-8Y; Tue, 03 Mar 2009 15:36:50 +0000 Date: Tue, 3 Mar 2009 10:36:50 -0500 From: Christoph Hellwig To: Aditya Alate Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_db guide Subject: Re: xfs_db guide Message-ID: <20090303153650.GA16816@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236094643 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Feb 05, 2009 at 06:05:25PM +0530, Aditya Alate wrote: > Hello there, > Is there any admin_guide kind of document for using xfs_db. I was searching > on web but couldn't find any brief description. man page for xfs_db is not > just enough. > > If somebody have user guide for xfs_db, pls do forward. I don't think there's one unfortuntely. A few examples can be found in the XFS training material: http://oss.sgi.com/projects/xfs/training/index.html but an actual xfs_db tutorial would be a something really good to have. From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 09:55:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23FtpGX020969 for ; Tue, 3 Mar 2009 09:55:52 -0600 X-ASG-Debug-ID: 1236095724-13b302ee0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F004F163457; Tue, 3 Mar 2009 07:55:24 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Yr5EBYgvTtPaTUEl; Tue, 03 Mar 2009 07:55:24 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeWxn-0007Ss-8Q; Tue, 03 Mar 2009 15:55:23 +0000 Date: Tue, 3 Mar 2009 10:55:23 -0500 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Eric Sandeen , Christoph Hellwig , Greg Banks , Mike Frysinger , xfs-oss , Nathan Scott X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Message-ID: <20090303155523.GC26376@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200902280107.06699.agruen@suse.de> <49A9BA50.7050101@sandeen.net> <200903011823.09613.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903011823.09613.agruen@suse.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236095724 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sun, Mar 01, 2009 at 06:23:09PM +0100, Andreas Gruenbacher wrote: > Yes, makes sense. I've copied Christoph's tree over and set up permissions; > you should have access now. > > Greg doesn't have a kernel.org account yet, so I can't give him access at the > moment. > > git://git.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git > ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/nfs4acl.git > > Would you like write access to the attr.git and acl.git trees as well? Greg or me? Don't think I want to do too much on it. I'll just bounce you whatever build system updates seem like fitting for acl/attr too. Still a few I need to send you. But Nathan Scott might want it as he wants to keep the debian packaging in the upstream git, and I suspect acl/attr aren't different from the xfs tools in that respect. From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 09:59:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23Fx8sI021146 for ; Tue, 3 Mar 2009 09:59:09 -0600 X-ASG-Debug-ID: 1236095921-13b302ff0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 233AE16A4DE; Tue, 3 Mar 2009 07:58:42 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LaXOjQFggopH3xAm; Tue, 03 Mar 2009 07:58:42 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeWw9-0006xQ-FY; Tue, 03 Mar 2009 15:53:41 +0000 Date: Tue, 3 Mar 2009 10:53:41 -0500 From: Christoph Hellwig To: Greg Banks Cc: Andreas Gruenbacher , Christoph Hellwig , Mike Frysinger , Eric Sandeen , xfs-oss X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Message-ID: <20090303155341.GB26376@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200902261817.02604.agruen@suse.de> <49A794D3.2000904@sgi.com> <200902271055.51564.agruen@suse.de> <49A9E555.7040607@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A9E555.7040607@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236095922 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sun, Mar 01, 2009 at 12:31:01PM +1100, Greg Banks wrote: > If the point here is to reduce the workload and potential errors > involved in making a release, you could add a release: target to the > Makefile to do the release procedure. That target only needs to work > for the maintainer, so it's relatively easy. You could do the stored > version bump, the tagging, the autotools futzing, and release tarball > building in there. The xfs tools (and acl/attr which use the same buildsystem) have a Makepkgs script that's supposed to do this with some help from the built system. I'm not sure we should add generating the tags and updating doc/CHANGES to it, but everything else is automated iff we actually use it. From sandeen@sandeen.net Tue Mar 3 10:00:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23G0fdY021348 for ; Tue, 3 Mar 2009 10:00:42 -0600 X-ASG-Debug-ID: 1236096013-13ce02cd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 401F6169FD5 for ; Tue, 3 Mar 2009 08:00:13 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id Hl5FGeu8NtAXwPU9 for ; Tue, 03 Mar 2009 08:00:13 -0800 (PST) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n23G05Fl025177; Tue, 3 Mar 2009 11:00:05 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n23G05Bn014920; Tue, 3 Mar 2009 11:00:06 -0500 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n23G02Wj024146; Tue, 3 Mar 2009 11:00:04 -0500 Message-ID: <49AD5401.30803@sandeen.net> Date: Tue, 03 Mar 2009 10:00:01 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christoph Hellwig CC: Alexander Beregalov , "linux-next@vger.kernel.org" , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: next-20090220: XFS: inconsistent lock state Subject: Re: next-20090220: XFS: inconsistent lock state References: <20090224200740.GA9266@infradead.org> In-Reply-To: <20090224200740.GA9266@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236096014 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19335 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > On Fri, Feb 20, 2009 at 08:52:59PM +0300, Alexander Beregalov wrote: >> Hi >> >> [ INFO: inconsistent lock state ] >> 2.6.29-rc5-next-20090220 #2 >> --------------------------------- >> inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. >> kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: >> (&(&ip->i_lock)->mr_lock){+++++?}, at: [] >> xfs_ilock+0xaa/0x120 >> {RECLAIM_FS-ON-W} state was registered at: > > That's a false positive. While the ilock can be taken in reclaim the > allocation here is done before the inode is added to the inode cache. > > The patch below should help avoiding the warning: Seems ok to me. I hate to see the BUG() added but I guess in this case something truly bizarre would have to happen for the ilock to fail on this inode. on irc you sugggested ASSERT(0); instead of BUG(); I might prefer that but either way: Reviewed-by: Eric Sandeen > > Index: xfs/fs/xfs/xfs_iget.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 20:56:00.716027739 +0100 > +++ xfs/fs/xfs/xfs_iget.c 2009-02-24 20:56:46.089031360 +0100 > @@ -246,9 +246,6 @@ xfs_iget_cache_miss( > goto out_destroy; > } > > - if (lock_flags) > - xfs_ilock(ip, lock_flags); > - > /* > * Preload the radix tree so we can insert safely under the > * write spinlock. Note that we cannot sleep inside the preload > @@ -259,6 +256,15 @@ xfs_iget_cache_miss( > goto out_unlock; > } > > + /* > + * Because the inode hasn't been added to the radix-tree yet it can't > + * be found by another thread, so we can do the non-sleeping lock here. > + */ > + if (lock_flags) { > + if (!xfs_ilock_nowait(ip, lock_flags)) > + BUG(); > + } > + > mask = ~(((XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog)) - 1); > first_index = agino & mask; > write_lock(&pag->pag_ici_lock); > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Tue Mar 3 10:14:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23GEd9C021902 for ; Tue, 3 Mar 2009 10:14:39 -0600 X-ASG-Debug-ID: 1236096851-13bc035c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5CB2A16A6B9 for ; Tue, 3 Mar 2009 08:14:11 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id HD9cEsHDsyq6Zkoh for ; Tue, 03 Mar 2009 08:14:11 -0800 (PST) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n23GE3JJ028132; Tue, 3 Mar 2009 11:14:03 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n23GE3GI018762; Tue, 3 Mar 2009 11:14:04 -0500 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n23GE1rI029788; Tue, 3 Mar 2009 11:14:03 -0500 Message-ID: <49AD5748.9050302@sandeen.net> Date: Tue, 03 Mar 2009 10:14:00 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: only issues a cache flush on unmount if barriers are enabled. Subject: Re: [PATCH] xfs: only issues a cache flush on unmount if barriers are enabled. References: <20090224133354.GA15820@infradead.org> In-Reply-To: <20090224133354.GA15820@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236096852 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19335 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > Currently we unconditionally issue a flush from xfs_free_buftarg, but > since 2.6.29-rc1 this gives a warning in the style of > > Filesystem "vdb": Disabling barriers, trial barrier write failed > > when the underlying device doesn't support these cache flushes. So make > the flush conditional on the barrier flag. > > > Signed-off-by: Christoph Hellwig Patch seems fine, Reviewed-by: Eric Sandeen but it seems that the changelog is not quite correct; the message shown above should only ever happen on mount, not unmount, I think. So I'd either put the right message in or just make a vague reference to it, because otherwise it's confusing. :) Thanks, -Eric > Index: xfs/fs/xfs/linux-2.6/xfs_buf.c > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_buf.c 2009-02-23 22:46:03.363048798 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_buf.c 2009-02-23 22:48:47.915052140 +0100 > @@ -34,6 +34,12 @@ > #include > #include > > +#include "xfs_sb.h" > +#include "xfs_inum.h" > +#include "xfs_ag.h" > +#include "xfs_dmapi.h" > +#include "xfs_mount.h" > + > static kmem_zone_t *xfs_buf_zone; > STATIC int xfsbufd(void *); > STATIC int xfsbufd_wakeup(int, gfp_t); > @@ -1442,10 +1448,12 @@ xfs_unregister_buftarg( > > void > xfs_free_buftarg( > - xfs_buftarg_t *btp) > + struct xfs_mount *mp, > + struct xfs_buftarg *btp) > { > xfs_flush_buftarg(btp, 1); > - xfs_blkdev_issue_flush(btp); > + if (mp->m_flags & XFS_MOUNT_BARRIER) > + xfs_blkdev_issue_flush(btp); > xfs_free_bufhash(btp); > iput(btp->bt_mapping->host); > > Index: xfs/fs/xfs/linux-2.6/xfs_buf.h > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_buf.h 2009-02-23 22:46:03.375049208 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_buf.h 2009-02-23 22:46:35.660960473 +0100 > @@ -416,7 +416,7 @@ static inline int XFS_bwrite(xfs_buf_t * > * Handling of buftargs. > */ > extern xfs_buftarg_t *xfs_alloc_buftarg(struct block_device *, int); > -extern void xfs_free_buftarg(xfs_buftarg_t *); > +extern void xfs_free_buftarg(struct xfs_mount *, struct xfs_buftarg *); > extern void xfs_wait_buftarg(xfs_buftarg_t *); > extern int xfs_setsize_buftarg(xfs_buftarg_t *, unsigned int, unsigned int); > extern int xfs_flush_buftarg(xfs_buftarg_t *, int); > Index: xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2009-02-23 22:46:46.637924949 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-02-23 22:47:19.787924537 +0100 > @@ -740,15 +740,15 @@ xfs_close_devices( > { > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > struct block_device *logdev = mp->m_logdev_targp->bt_bdev; > - xfs_free_buftarg(mp->m_logdev_targp); > + xfs_free_buftarg(mp, mp->m_logdev_targp); > xfs_blkdev_put(logdev); > } > if (mp->m_rtdev_targp) { > struct block_device *rtdev = mp->m_rtdev_targp->bt_bdev; > - xfs_free_buftarg(mp->m_rtdev_targp); > + xfs_free_buftarg(mp, mp->m_rtdev_targp); > xfs_blkdev_put(rtdev); > } > - xfs_free_buftarg(mp->m_ddev_targp); > + xfs_free_buftarg(mp, mp->m_ddev_targp); > } > > /* > @@ -817,9 +817,9 @@ xfs_open_devices( > > out_free_rtdev_targ: > if (mp->m_rtdev_targp) > - xfs_free_buftarg(mp->m_rtdev_targp); > + xfs_free_buftarg(mp, mp->m_rtdev_targp); > out_free_ddev_targ: > - xfs_free_buftarg(mp->m_ddev_targp); > + xfs_free_buftarg(mp, mp->m_ddev_targp); > out_close_rtdev: > if (rtdev) > xfs_blkdev_put(rtdev); > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From felixb@sgi.com Tue Mar 3 10:46:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23Gk0mM023405 for ; Tue, 3 Mar 2009 10:46:01 -0600 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2C6E730407B for ; Tue, 3 Mar 2009 08:45:30 -0800 (PST) Received: from eagdhcp-233-174.americas.sgi.com (eagdhcp-233-174.americas.sgi.com [128.162.233.174]) by estes.americas.sgi.com (Postfix) with ESMTP id E88787000103; Tue, 3 Mar 2009 10:45:29 -0600 (CST) Cc: Alexander Beregalov , "linux-next@vger.kernel.org" , LKML , xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090224200740.GA9266@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: next-20090220: XFS: inconsistent lock state Date: Tue, 3 Mar 2009 10:45:28 -0600 References: <20090224200740.GA9266@infradead.org> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Feb 24, 2009, at 2:07 PM, Christoph Hellwig wrote: > On Fri, Feb 20, 2009 at 08:52:59PM +0300, Alexander Beregalov wrote: >> Hi >> >> [ INFO: inconsistent lock state ] >> 2.6.29-rc5-next-20090220 #2 >> --------------------------------- >> inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. >> kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: >> (&(&ip->i_lock)->mr_lock){+++++?}, at: [] >> xfs_ilock+0xaa/0x120 >> {RECLAIM_FS-ON-W} state was registered at: > > That's a false positive. While the ilock can be taken in reclaim the > allocation here is done before the inode is added to the inode cache. > > The patch below should help avoiding the warning: > > > Index: xfs/fs/xfs/xfs_iget.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 20:56:00.716027739 +0100 > +++ xfs/fs/xfs/xfs_iget.c 2009-02-24 20:56:46.089031360 +0100 > @@ -246,9 +246,6 @@ xfs_iget_cache_miss( > goto out_destroy; > } > > - if (lock_flags) > - xfs_ilock(ip, lock_flags); > - > /* > * Preload the radix tree so we can insert safely under the > * write spinlock. Note that we cannot sleep inside the preload > @@ -259,6 +256,15 @@ xfs_iget_cache_miss( > goto out_unlock; Since we removed call to xfs_ilock() above, this should change to 'goto out_destroy;' Otherwise, seems goot to me. Reviewed-by: Felix Blyakher > > } > > + /* > + * Because the inode hasn't been added to the radix-tree yet it > can't > + * be found by another thread, so we can do the non-sleeping lock > here. > + */ > + if (lock_flags) { > + if (!xfs_ilock_nowait(ip, lock_flags)) > + BUG(); > > + } > + > mask = ~(((XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog)) - 1); > first_index = agino & mask; > write_lock(&pag->pag_ici_lock); > -- > To unsubscribe from this list: send the line "unsubscribe linux- > kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From sandeen@sandeen.net Tue Mar 3 10:47:18 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23GlH0J023570 for ; Tue, 3 Mar 2009 10:47:17 -0600 X-ASG-Debug-ID: 1236098809-7f26008b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C07E1C137B3 for ; Tue, 3 Mar 2009 08:46:49 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id pu3X3H7NIS0CTaaF for ; Tue, 03 Mar 2009 08:46:49 -0800 (PST) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n23GSeQq031546; Tue, 3 Mar 2009 11:28:40 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n23GSeW9024781; Tue, 3 Mar 2009 11:28:41 -0500 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n23GScaI000651; Tue, 3 Mar 2009 11:28:39 -0500 Message-ID: <49AD5AB5.9050604@sandeen.net> Date: Tue, 03 Mar 2009 10:28:37 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com, Andras Korn X-ASG-Orig-Subj: Re: xfs: prevent kernel crash due to corrupted inode log format Subject: Re: xfs: prevent kernel crash due to corrupted inode log format References: <20090215191344.GA16706@infradead.org> In-Reply-To: <20090215191344.GA16706@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236098810 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19335 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > Andras Korn reported an oops on log replay causes by a corrupted > xfs_inode_log_format_t passing a 0 size to kmem_zalloc. This patch handles > to small or too large numbers of log regions gracefully by rejecting the > log replay with a useful error message. > > Signed-off-by: Christoph Hellwig > Reported-by: Andras Korn Reviewed-by: Eric Sandeen > Index: xfs/fs/xfs/xfs_log_recover.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_log_recover.c 2009-02-12 19:00:29.056944584 +0100 > +++ xfs/fs/xfs/xfs_log_recover.c 2009-02-15 20:07:56.568971792 +0100 > @@ -1455,10 +1455,19 @@ xlog_recover_add_to_trans( > item = item->ri_prev; > > if (item->ri_total == 0) { /* first region to be added */ > - item->ri_total = in_f->ilf_size; > - ASSERT(item->ri_total <= XLOG_MAX_REGIONS_IN_ITEM); > - item->ri_buf = kmem_zalloc((item->ri_total * > - sizeof(xfs_log_iovec_t)), KM_SLEEP); > + if (in_f->ilf_size == 0 || > + in_f->ilf_size > XLOG_MAX_REGIONS_IN_ITEM) { > + xlog_warn( > + "XFS: bad number of regions (%d) in inode log format", > + in_f->ilf_size); > + ASSERT(0); > + return XFS_ERROR(EIO); > + } > + > + item->ri_total = in_f->ilf_size; > + item->ri_buf = > + kmem_zalloc(item->ri_total * sizeof(xfs_log_iovec_t), > + KM_SLEEP); > } > ASSERT(item->ri_total > item->ri_cnt); > /* Description region is ri_buf[0] */ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From felixb@sgi.com Tue Mar 3 10:57:38 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23GvcoT024006 for ; Tue, 3 Mar 2009 10:57:38 -0600 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id BBCED8F80AC for ; Tue, 3 Mar 2009 08:57:08 -0800 (PST) Received: from eagdhcp-233-174.americas.sgi.com (eagdhcp-233-174.americas.sgi.com [128.162.233.174]) by estes.americas.sgi.com (Postfix) with ESMTP id 8BFB47000103; Tue, 3 Mar 2009 10:57:08 -0600 (CST) Cc: Christoph Hellwig , Alexander Beregalov , "linux-next@vger.kernel.org" , LKML , xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Eric Sandeen In-Reply-To: <49AD5401.30803@sandeen.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: next-20090220: XFS: inconsistent lock state Date: Tue, 3 Mar 2009 10:57:07 -0600 References: <20090224200740.GA9266@infradead.org> <49AD5401.30803@sandeen.net> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 3, 2009, at 10:00 AM, Eric Sandeen wrote: > Christoph Hellwig wrote: >> On Fri, Feb 20, 2009 at 08:52:59PM +0300, Alexander Beregalov wrote: >>> Hi >>> >>> [ INFO: inconsistent lock state ] >>> 2.6.29-rc5-next-20090220 #2 >>> --------------------------------- >>> inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. >>> kswapd0/324 [HC0[0]:SC0[0]:HE1:SE1] takes: >>> (&(&ip->i_lock)->mr_lock){+++++?}, at: [] >>> xfs_ilock+0xaa/0x120 >>> {RECLAIM_FS-ON-W} state was registered at: >> >> That's a false positive. While the ilock can be taken in reclaim the >> allocation here is done before the inode is added to the inode cache. >> >> The patch below should help avoiding the warning: > > Seems ok to me. I hate to see the BUG() added but I guess in this > case > something truly bizarre would have to happen for the ilock to fail on > this inode. > > on irc you sugggested ASSERT(0); instead of BUG(); That would mean that instead of bombing out here, we do it in xfs debug kernels only, which is a good thing. However, do we just silently ignore it in non debug kernels, and later try to unlock without locking first? Maybe the following be better: if (lock_flags) { if (!xfs_ilock_nowait(ip, lock_flags)) { ASSERT(0); error = EAGAIN; goto out_destroy; } } Or just keep the BUG(); , as it shouldn't happen (we hope). Reviewed-by: Felix Blyakher > I might prefer that > but either way: > > Reviewed-by: Eric Sandeen > >> >> Index: xfs/fs/xfs/xfs_iget.c >> =================================================================== >> --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 20:56:00.716027739 +0100 >> +++ xfs/fs/xfs/xfs_iget.c 2009-02-24 20:56:46.089031360 +0100 >> @@ -246,9 +246,6 @@ xfs_iget_cache_miss( >> goto out_destroy; >> } >> >> - if (lock_flags) >> - xfs_ilock(ip, lock_flags); >> - >> /* >> * Preload the radix tree so we can insert safely under the >> * write spinlock. Note that we cannot sleep inside the preload >> @@ -259,6 +256,15 @@ xfs_iget_cache_miss( >> goto out_unlock; >> } >> >> + /* >> + * Because the inode hasn't been added to the radix-tree yet it >> can't >> + * be found by another thread, so we can do the non-sleeping lock >> here. >> + */ >> + if (lock_flags) { >> + if (!xfs_ilock_nowait(ip, lock_flags)) >> + BUG(); >> + } >> + >> mask = ~(((XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog)) - >> 1); >> first_index = agino & mask; >> write_lock(&pag->pag_ici_lock); >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux- > kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 11:03:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23H3FMk024446 for ; Tue, 3 Mar 2009 11:03:16 -0600 X-ASG-Debug-ID: 1236099768-6f5c00b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC4B016A532; Tue, 3 Mar 2009 09:02:48 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aApt0O8hxvFSWN6B; Tue, 03 Mar 2009 09:02:48 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeY12-0004hC-9A; Tue, 03 Mar 2009 17:02:48 +0000 Date: Tue, 3 Mar 2009 12:02:48 -0500 From: Christoph Hellwig To: Felix Blyakher Cc: Eric Sandeen , Christoph Hellwig , Alexander Beregalov , "linux-next@vger.kernel.org" , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: next-20090220: XFS: inconsistent lock state Subject: Re: next-20090220: XFS: inconsistent lock state Message-ID: <20090303170248.GA7036@infradead.org> References: <20090224200740.GA9266@infradead.org> <49AD5401.30803@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236099768 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Mar 03, 2009 at 10:57:07AM -0600, Felix Blyakher wrote: > if (lock_flags) { > if (!xfs_ilock_nowait(ip, lock_flags)) { > ASSERT(0); > error = EAGAIN; > goto out_destroy; > } > } > > Or just keep the BUG(); , as it shouldn't happen (we hope). Ok, let's keep the BUG for now and I'll throw in your error undwinding fix. Will resend the series for 2.6.29 patches after QAing them. From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 11:54:56 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_BACKHAIR_56 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23Hsu2v026573 for ; Tue, 3 Mar 2009 11:54:56 -0600 X-ASG-Debug-ID: 1236102868-7f4e02d90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 739BD1C13A9F for ; Tue, 3 Mar 2009 09:54:28 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id gyDTBMZGjVz4JIYO for ; Tue, 03 Mar 2009 09:54:28 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeYp1-0005Pb-Vs; Tue, 03 Mar 2009 17:54:27 +0000 Date: Tue, 3 Mar 2009 12:54:27 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com Cc: arekm@maven.pl X-ASG-Orig-Subj: [PATCH] xfs: validate quota log items during log recovery Subject: [PATCH] xfs: validate quota log items during log recovery Message-ID: <20090303175427.GA20582@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236102869 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Arkadiusz has been seeing really strange crashes in xfs_qm_dqcheck that I can only explain by a log item beeing too smal to actually fit the xfs_dqblk_t we're dereferencing all over xfs_qm_dqcheck. So add graceful checks for NULL or too small quota items to the log recovery code. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2009-03-02 04:15:11.410430892 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2009-03-02 04:16:29.649444226 +0100 @@ -1975,16 +1975,26 @@ xlog_recover_do_reg_buffer( error = 0; if (buf_f->blf_flags & (XFS_BLI_UDQUOT_BUF|XFS_BLI_PDQUOT_BUF|XFS_BLI_GDQUOT_BUF)) { + if (item->ri_buf[i].i_addr == NULL || + item->ri_buf[i].i_len < sizeof(xfs_dqblk_t)) { + cmn_err(CE_ALERT, + "XFS: dquot too small (%d) in xlog_recover_do_reg_buffer.", + item->ri_buf[i].i_len); + goto next; + } error = xfs_qm_dqcheck((xfs_disk_dquot_t *) item->ri_buf[i].i_addr, -1, 0, XFS_QMOPT_DOWARN, "dquot_buf_recover"); + if (error) + goto next; } - if (!error) - memcpy(xfs_buf_offset(bp, - (uint)bit << XFS_BLI_SHIFT), /* dest */ - item->ri_buf[i].i_addr, /* source */ - nbits<ri_buf[i].i_addr, /* source */ + nbits<ri_buf[1].i_addr; - ASSERT(recddq); + + if (item->ri_buf[1].i_addr == NULL || + item->ri_buf[1].i_len < sizeof(xfs_dqblk_t)) { + cmn_err(CE_ALERT, + "XFS: dquot too small (%d) in xlog_recover_do_dquot_trans.", + item->ri_buf[1].i_len); + return XFS_ERROR(EIO); + } + /* * This type of quotas was turned off, so ignore this record. */ From ESC1102476933811_1101197854682_10034@in.constantcontact.com Tue Mar 3 13:40:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,HTML_FONT_SIZE_LARGE, HTML_MESSAGE,J_CHICKENPOX_63 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23JeLBL030986 for ; Tue, 3 Mar 2009 13:40:22 -0600 X-ASG-Debug-ID: 1236109193-54f901590000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ccm29.constantcontact.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4800416B444 for ; Tue, 3 Mar 2009 11:39:54 -0800 (PST) Received: from ccm29.constantcontact.com (ccm29.constantcontact.com [208.75.123.225]) by cuda.sgi.com with ESMTP id PjE8ffYZcDqUJTax for ; Tue, 03 Mar 2009 11:39:54 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from p2-ws505.ad.prodcc.net (unknown [10.252.0.102]) by ccm29.constantcontact.com (Postfix) with ESMTP id 3F141280003E for ; Tue, 3 Mar 2009 13:45:51 -0500 (EST) Message-ID: <1102476933811.1101197854682.10034.5.301435E4@scheduler> Date: Tue, 3 Mar 2009 14:39:22 -0500 (EST) From: Emergency Film Group Reply-To: info@efilmgroup.com To: xfs@oss.sgi.com X-ASG-Orig-Subj: IED preparedness training Subject: IED preparedness training Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_47993168_1150370961.1236109162969" X-Mailer: Roving Constant Contact 0 (http://www.constantcontact.com) List-Unsubscribe: http://visitor.constantcontact.com/d.jsp?p=un&v=001LJMCW0I5jW0byL63YTets51TF4pTTIL41gSEExyZrfxLAMVPMPsBRY_jROozs0du X-Return-Path-Hint: ESC1102476933811_1101197854682_10034@in.roving.com X-Roving-ID: 1101197854682.10034 X-Lumos-SenderID: 1101197854682 X-Roving-CampaignId: 1102476933811 X-Roving-StreamId: 0 X-Barracuda-Connect: ccm29.constantcontact.com[208.75.123.225] X-Barracuda-Start-Time: 1236109195 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ------=_Part_47993168_1150370961.1236109162969 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Improvised Explosive Devices Training aids to strengthen IED preparedness ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Free shipping thru April 1, 2009 IED Training Package [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGx1CypdRhF2JbnHYmt_skltFKcV5oRB5kw69YKTK1yTYAAe9Fv4Czx_6A6kcItQFGX1hzAyNtj9h0r69X2SPqhSa98yxpZtbbWJNDm5ic9YGJn9XkvIdtWINuRaSASp44fLh6oblmgJnzXUSMVZIaSqZSiPvm7Vj4=] [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGx1CypdRhF2JbnHYmt_skltFKcV5oRB5kw69YKTK1yTYAAe9Fv4Czx_6A6kcItQFGX1hzAyNtj9h0r69X2SPqhSa98yxpZtbbWJNDm5ic9YGJn9XkvIdtWINuRaSASp44fLh6oblmgJnzXUSMVZIaSqZSiPvm7Vj4=] This package provides the training emergency personnel need to maximize the safety of their community during IED incidents, suicide bombings and other bomb situations. The package includes 4 best selling DVDs, each with an accompanying Leader's Guide or Instructor's CD-Rom that outlines a training seminar. Titles include: * IEDs & VBIEDs(DVD with Instructor CD-Rom) * Suicide Bomber(DVD plus Instructor Guide) * Bomb Threat (DVD plus Model Procedures Guide * Terrorism: Explosive & Incendiary Weapons (DVD plus Instructor Guide) Also included are two important texts: * Explosves Identification Guide (text) * Janes Unconventional Weapons Handbook (text) To order, click on the coupon below. Questions? Call 800.842.0999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 exciting and effective programs will strengthen IED attack deterrence and protection Are your emergency responders prepared to meet the challenges of an IED attack? Recent history has shown that improvised explosive devices and vehicle-borne improvised explosive devices are often the terrorists weapon of choice. It is likely that these attacks would be carried out in non-battlefield environments, possibly even your community. Recent funding priorities for the Department of Homeland Security Grant program required that funds must be allocated to meet IED preparedness goals. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IED Package covers [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGx1CypdRhF2JbnHYmt_skltFKcV5oRB5kw69YKTK1yTYAAe9Fv4Czx_6A6kcItQFGX1hzAyNtj9h0r69X2SPqhSa98yxpZtbbWJNDm5ic9YGJn9XkvIdtWINuRaSASp44fLh6oblmgJnzXUSMVZIaSqZSiPvm7Vj4=] The IED Training Packageprovides training for police officers, firefighters, hazmat teams, bomb squads, EMTs, emergency management, military personnel, security guards and others who may find themselves on the front lines of a domestic IED incident. Listed on Responder Knowledge Base [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnEqbfvLvbY9v0j2xSv8Hik7Gev3bqWBJJtEQ0r3c4VVyf2dwbNn6CYNPpYs-cTVI2bHxNUslzMMeFdELf2yGeYknqDs4aXoR9yf21jn9OcHnnVylr0xuNy8i6pavMcduoRNJyLUCTcGsl2HxqNUSVVnEMBXUIgsa3w=] Order here [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGx1CypdRhF2JbnHYmt_skltFKcV5oRB5kw69YKTK1yTYAAe9Fv4Czx_6A6kcItQFGX1hzAyNtj9h0r69X2SPqhSa98yxpZtbbWJNDm5ic9YGJn9XkvIdtWINuRaSASp44fLh6oblmgJnzXUSMVZIaSqZSiPvm7Vj4=], or click the coupon below SAVE $650 Individual List Price: $ 1,845 Package Price: $ 1,195 Plus FREE SHIPPING thru April 1, 2009 Technical committee members who served as advisors for these programs include the following authorities in IED preparedness and response: Jan Dunbar [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGkBGfInG5olR705UOOiW0zcWFoitXSo9_jnnYEJc4tetkTXQYdIg_fPu9YJE0pijCu5Z2oZKHLaafBMfc7YuHbkM-gq6wLIetysEy00LbXsREa7CRimyHCR_0gglBOM5acoFT4V-SOO0aChlFXNtKuLRqbKtLX5w7ZRg0kRQWxOw==], John Eversole [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGzpH6GU18TnNjWorYh01ut4WY-ssqVtivL_VQwx9vYaAq02JIQr1oVzWuwiQQIofOgLR08vnxQNriEfCtwgstCzYN-FOPDG9WvyU4gJeapGid19_xcEZfLqrWpRQbiHIOHk3_qRnXkkP23ZEr9ZYGUYsfhsu6y4OUSwtkHnoMT2lh7WlmYX3jb], Chris Hawley [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnEoLsemn5iRAHV3nOz0Xr4zXrinToW-MW6DLg1V8FFfPyu6__gPa70MbNlvQHkDslhXpWHa1gR7UvmblBcp6Faf9orjZXw0xcgo4fE8hubPqRtL2hsGKaW1ZP5KaNjpp1slqgm_qTKJ2w__AqNfxJHDmS_5s_NJE7rblyZllIHOVw==], Dieter Heinz [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnHP3CfReFGUMF9fePuDzZbN6hxJl7jv4TDTv_79uFYDMBqqhGxjoJ0j5_KhScURF5vYxQ5miYiAS6WtOrvhg6I9Lyu-_tP8GBf-GjwNzCYk7RSsB2Dz_OjuvnGcGgxN5Jb85ptqdxnRL4V21aVRNhUp--QeV26dPUdl1WppNsWgqg==], Mike Hildebrand [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnG8zSheUEz6qfQ_n15bo7FAgBZ2zydcCcKMcjoOGj37B7WvJkfdqWOhwXSND_RAtKPiKr9A8Tw5KJVYBJmPorav2G7fK6uNFNxKLGtyzLp4JfxvgzOQx2uKqBoPAFeGmy-DwuWe7S8qLNbKtDSwjZ17pGEXfiXhJdLFWkskMcqbFg==], Tom Rancich [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnE-kRZJMrjgkVwRxNUlGOguv2DwaASbUUqahC-Tza1ifzIOid9lSSGg1UQJ5m9JIREdnhpLRHBsBKIbZ0MRIP7MvcYj6TqIdM4pjlqcE4LTxoZGbjAOwb78bxFMq6I5AEKV2vv-0-jZZyl73x7h097o_BF92NjMq0nb0ki6ZxDO8w==], Chris Ronay [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnEXPnWbph2MKyzloX8sTw-3wsclOF3U1QaCswGbdl8Rrf0_qef8WHbWbNPAyDMrqaeJ6HfaM5uLD1zcWROYoLFMWpmDXb7xBLxwxptSwn3OkU165FwmRwjnPM-4-BCjrr9Rd5K0-l8mUHR34X4my00rFJL4vziZsbCztrq371ebJw==], August Vernon [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnHIS7FjZ0A0LaajflM1b9gvpkL9SAWlsNThmWR_sYzrsUVdoCdDOIzGREkcCddT1b5kiAvpE8T72RCl2PpBuI7ItV6PQZ3aht4tLGAGopYy57PTBzh3rnEEZqSrBumhB2dULTeBwkmynBTM6s2_yVGbDkzWfnWtO1ZUITlYiIw-GA==], Trent Walker [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnFd-EBDuVx0zq2Kbe5HVigsogCZzkDsO-WWxtkSwQFKpxx_xpTPDAkp1DD9LkTfz7kiKHkRVjcGwcvY13MgJDt2z4fDqbWWnii1sfUN83KT93X58ozm41oTzGmUu-rZpAg=], Sol Bradman [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGv4XdPERLbBnGBJS7-JOrpg8ro4qBOPRqASC5Z9rRaePyOLKmr1YNbNfEDZsEA6Pkvpy4zprPN7gGjXIB_UTjOmy2I8zymPlbNNoKjequjbTKzyFhYd3WwU9YyAsBufhg=], and Aaron Richman. [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnEzERfGDXfCvL64xM5Yt5HPLkHcDL4I15-FyzL30vIeBRFrvTW3VVddP6MWTtdhXD04yqkYb420XEVgRkU2jcOoVROQGL41ZXfQS2GECdhAlCaSJ_58VZKk9nX-kc7kP3s_06P4LSkA1m2l8pgqUsU796MvHs7zrbGAivb6Li6e2g==] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We set the standard for quality video-based training! Our programs have won more than 140 awards and are currently training over one million emergency responders across the US & Canada. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Save $650 Click here [http://rs6.net/tn.jsp?et=1102476933811&e=001IrP1PBZHRnGx1CypdRhF2JbnHYmt_skltFKcV5oRB5kw69YKTK1yTYAAe9Fv4Czx_6A6kcItQFGX1hzAyNtj9h0r69X2SPqhSa98yxpZtbbWJNDm5ic9YGJn9XkvIdtWINuRaSASp44fLh6oblmgJnzXUSMVZIaSqZSiPvm7Vj4=] to save $650 on the IED PACKAGE, 4 DVDs plus 2 texts, 3 Guides and 1 Instructor's CD-Rom with PowerPoints. Pay only $1,195, a savings of $650 off the individual catalog costs of these exciting and effective training aids, plus receive FREE SHIPPING through April 1. Or call us at 800.842.0999. VISA/MC/AmEx accepted. Free Shipping Expires: April 1, 2009 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email http://ui.constantcontact.com/sa/fwtf.jsp?m=1101197854682&ea=xfs@oss.sgi.com&a=1102476933811 This email was sent to xfs@oss.sgi.com by info@efilmgroup.com. Update Profile/Email Address http://visitor.constantcontact.com/d.jsp?v=001LJMCW0I5jW0byL63YTets51TF4pTTIL41gSEExyZrfxLAMVPMPsBRRyUJ9Xpvdlpy3hYL2bPHyE32wtc84dpeg%3D%3D&p=oo Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/d.jsp?v=001LJMCW0I5jW0byL63YTets51TF4pTTIL41gSEExyZrfxLAMVPMPsBRRyUJ9Xpvdlpy3hYL2bPHyE32wtc84dpeg%3D%3D&p=un Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Email Marketing by Constant Contact(R) www.constantcontact.com Emergency Film Group | PO Box 1928 | 140 Cooke St | Edgartown | MA | 02539 ------=_Part_47993168_1150370961.1236109162969 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=09
3D"Emergency
=09 =
Improvised Explosive Devices 
Training = aids to strengthen IED preparedness 
=09
Free shipping 
thru April 1, 2009
 
 3D"Hazmat
  

This package provides the training eme= rgency personnel need to maximize the safety of their community during IED = incidents, suicide bombings and other bomb situations.
 

The package includes 4 best selling DVDs, each with an ac= companying Leader's Guide or Instructor's CD-Rom that outlines a training s= eminar. Titles include:

  • IEDs & VBIEDs (DVD with Instructor CD-Rom)=20
  • Suicide Bomber (DVD plus Instructor Guide)=20
  • Bomb Threat (DVD plus Model Procedures Guide=20
  • Terrorism: Explosive & Incendiary Weapons (DVD
     = ;plus Instructor Guide)

Also included are two important texts:

  • Explosves Identification Guide (text)
  • Janes Unconventional
    Weapons Handbook     (te= xt)
 
 
To orde= r, click on the coupon below.=20
 
Questions?=20
Call 800.842.0999

 =09
=09=09
4 exciting and effective programs will strengthen IED attack deterrenc= e and protection
 
Are your emergency responders prepared to meet the challenges of an IE= D attack? Recent history has shown that improvised explosive devices and ve= hicle-borne improvised explosive devices are often the terrorists weapon of= choice. It is likely that these attacks would be carried out in non-battle= field environments, possibly even your community. Recent funding priorities= for the Department of Homeland Security Grant program required that funds = must be allocated to meet IED preparedness goals.  
<= /td>
=09=09 =09=09 =09=09=09 =09=09 =09=09
=09=09
&n= bsp;      3D"IED  
 The IED Training Package provid= es training for police officers, firefighters, hazmat teams, bomb squads, E= MTs, emergency management, military personnel, security guards and others w= ho may find themselves on the front lines of a domestic IED incident.=20
 
 
SAVE $650
Individual List Price: $ 1= ,845
Package Price: $ 1,195

 
Plus FREE SHIPPING= thru April 1, 2009

 

Technical committee members who served as advisors for&nb= sp;these programs include the following authorities in IED preparednes= s and response: Jan Dunbar, John Eversole, Chris Hawl= ey, Dieter Heinz, Mike Hildebrand, Tom Rancich, Chris Ronay, August Vernon, Trent Walker, Sol Bradman, and Aaron Richman.

 
=09=09
=09=09 =09=09 =20
 
We set the standard for quality= video-based training!
Our programs ha= ve won more than 140 awards and are currently training over one million eme= rgency responders across the US & Canada.
 
=09=09
=09
Save $650
 
 
Free Shipping Expires: April 1, 2009
3D"Safe
This email was sent to xfs@oss.sgi.com by info@e= filmgroup.com.
Emergency Film Grou= p | PO Box 1928 | 140 Cooke St | Edgartown | MA | 02539
------=_Part_47993168_1150370961.1236109162969-- From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 13:49:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23JnFsZ031608 for ; Tue, 3 Mar 2009 13:49:16 -0600 X-ASG-Debug-ID: 1236109728-758a02580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ACE8B1C14530 for ; Tue, 3 Mar 2009 11:48:48 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id onesJ8sHq6mjEIsl for ; Tue, 03 Mar 2009 11:48:48 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leabg-0003cM-Cn for xfs@oss.sgi.com; Tue, 03 Mar 2009 19:48:48 +0000 Message-Id: <20090303194834.264998000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Tue, 03 Mar 2009 14:48:34 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/3] 2.6.29 queue Subject: [PATCH 0/3] 2.6.29 queue X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236109728 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean A couple of small fixes for 2.6.29. From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 13:49:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23JnFjo031611 for ; Tue, 3 Mar 2009 13:49:16 -0600 X-ASG-Debug-ID: 1236109729-550a01a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60C3116B725 for ; Tue, 3 Mar 2009 11:48:49 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id YjYJHcNigzsbhMuy for ; Tue, 03 Mar 2009 11:48:49 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leabh-0003dT-0g for xfs@oss.sgi.com; Tue, 03 Mar 2009 19:48:49 +0000 Message-Id: <20090303194848.844247000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Tue, 03 Mar 2009 14:48:36 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/3] xfs: prevent kernel crash due to corrupted inode log format Subject: [PATCH 2/3] xfs: prevent kernel crash due to corrupted inode log format References: <20090303194834.264998000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-fix-log-replay-oops X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236109729 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Andras Korn reported an oops on log replay causes by a corrupted xfs_inode_log_format_t passing a 0 size to kmem_zalloc. This patch handles to small or too large numbers of log regions gracefully by rejecting the log replay with a useful error message. Signed-off-by: Christoph Hellwig Reported-by: Andras Korn Reviewed-by: Eric Sandeen Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2009-02-12 19:00:29.056944584 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2009-02-15 20:13:45.201071971 +0100 @@ -1455,10 +1455,19 @@ xlog_recover_add_to_trans( item = item->ri_prev; if (item->ri_total == 0) { /* first region to be added */ - item->ri_total = in_f->ilf_size; - ASSERT(item->ri_total <= XLOG_MAX_REGIONS_IN_ITEM); - item->ri_buf = kmem_zalloc((item->ri_total * - sizeof(xfs_log_iovec_t)), KM_SLEEP); + if (in_f->ilf_size == 0 || + in_f->ilf_size > XLOG_MAX_REGIONS_IN_ITEM) { + xlog_warn( + "XFS: bad number of regions (%d) in inode log format", + in_f->ilf_size); + ASSERT(0); + return XFS_ERROR(EIO); + } + + item->ri_total = in_f->ilf_size; + item->ri_buf = + kmem_zalloc(item->ri_total * sizeof(xfs_log_iovec_t), + KM_SLEEP); } ASSERT(item->ri_total > item->ri_cnt); /* Description region is ri_buf[0] */ From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 13:49:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23JnFNR031610 for ; Tue, 3 Mar 2009 13:49:16 -0600 X-ASG-Debug-ID: 1236109728-6ffe023a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0FC5A1C14534 for ; Tue, 3 Mar 2009 11:48:48 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 31qQh3NhwdF6iC3L for ; Tue, 03 Mar 2009 11:48:48 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leabg-0003cw-NH for xfs@oss.sgi.com; Tue, 03 Mar 2009 19:48:48 +0000 Message-Id: <20090303194848.533949000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Tue, 03 Mar 2009 14:48:35 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/3] xfs: prevent lockdep false positive in xfs_iget_cache_miss Subject: [PATCH 1/3] xfs: prevent lockdep false positive in xfs_iget_cache_miss References: <20090303194834.264998000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-iget-fix-lockdep-false-positive X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236109729 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The inode can't be locked by anyone else as we just created it a few lines above and it's not been added to any lookup data structure yet. So use a trylock that must succeed to get around the lockdep warnings. Signed-off-by: Christoph Hellwig Reported-by: Alexander Beregalov Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher Index: xfs/fs/xfs/xfs_iget.c =================================================================== --- xfs.orig/fs/xfs/xfs_iget.c 2009-03-03 18:02:56.262853671 +0100 +++ xfs/fs/xfs/xfs_iget.c 2009-03-03 18:08:44.681880431 +0100 @@ -246,9 +246,6 @@ xfs_iget_cache_miss( goto out_destroy; } - if (lock_flags) - xfs_ilock(ip, lock_flags); - /* * Preload the radix tree so we can insert safely under the * write spinlock. Note that we cannot sleep inside the preload @@ -256,7 +253,16 @@ xfs_iget_cache_miss( */ if (radix_tree_preload(GFP_KERNEL)) { error = EAGAIN; - goto out_unlock; + goto out_destroy; + } + + /* + * Because the inode hasn't been added to the radix-tree yet it can't + * be found by another thread, so we can do the non-sleeping lock here. + */ + if (lock_flags) { + if (!xfs_ilock_nowait(ip, lock_flags)) + BUG(); } mask = ~(((XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog)) - 1); @@ -284,7 +290,6 @@ xfs_iget_cache_miss( out_preload_end: write_unlock(&pag->pag_ici_lock); radix_tree_preload_end(); -out_unlock: if (lock_flags) xfs_iunlock(ip, lock_flags); out_destroy: From SRS0+b87ef1a9c52e8f9c6194+2018+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 3 13:49:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23Jnlsc031692 for ; Tue, 3 Mar 2009 13:49:47 -0600 X-ASG-Debug-ID: 1236109760-756d021a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 37FB51C1430E for ; Tue, 3 Mar 2009 11:49:20 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 0XuRUgjhEMabAiKG for ; Tue, 03 Mar 2009 11:49:20 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leabh-0003dz-AH for xfs@oss.sgi.com; Tue, 03 Mar 2009 19:48:49 +0000 Message-Id: <20090303194849.153376000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Tue, 03 Mar 2009 14:48:37 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/3] xfs: only issues a cache flush on unmount if barriers are enabled Subject: [PATCH 3/3] xfs: only issues a cache flush on unmount if barriers are enabled References: <20090303194834.264998000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-fix-barrier-warning X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236109760 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Currently we unconditionally issue a flush from xfs_free_buftarg, but since 2.6.29-rc1 this gives a warning in the style of end_request: I/O error, dev vdb, sector 0 Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Index: xfs/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_buf.c 2009-03-03 15:50:22.367860467 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_buf.c 2009-03-03 18:10:52.385007793 +0100 @@ -34,6 +34,12 @@ #include #include +#include "xfs_sb.h" +#include "xfs_inum.h" +#include "xfs_ag.h" +#include "xfs_dmapi.h" +#include "xfs_mount.h" + static kmem_zone_t *xfs_buf_zone; STATIC int xfsbufd(void *); STATIC int xfsbufd_wakeup(int, gfp_t); @@ -1435,10 +1441,12 @@ xfs_unregister_buftarg( void xfs_free_buftarg( - xfs_buftarg_t *btp) + struct xfs_mount *mp, + struct xfs_buftarg *btp) { xfs_flush_buftarg(btp, 1); - xfs_blkdev_issue_flush(btp); + if (mp->m_flags & XFS_MOUNT_BARRIER) + xfs_blkdev_issue_flush(btp); xfs_free_bufhash(btp); iput(btp->bt_mapping->host); Index: xfs/fs/xfs/linux-2.6/xfs_buf.h =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_buf.h 2009-03-03 15:50:22.376883054 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_buf.h 2009-03-03 18:10:52.386007991 +0100 @@ -413,7 +413,7 @@ static inline int XFS_bwrite(xfs_buf_t * * Handling of buftargs. */ extern xfs_buftarg_t *xfs_alloc_buftarg(struct block_device *, int); -extern void xfs_free_buftarg(xfs_buftarg_t *); +extern void xfs_free_buftarg(struct xfs_mount *, struct xfs_buftarg *); extern void xfs_wait_buftarg(xfs_buftarg_t *); extern int xfs_setsize_buftarg(xfs_buftarg_t *, unsigned int, unsigned int); extern int xfs_flush_buftarg(xfs_buftarg_t *, int); Index: xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2009-03-03 15:50:22.190853363 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-03-03 18:10:52.387004137 +0100 @@ -733,15 +733,15 @@ xfs_close_devices( { if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { struct block_device *logdev = mp->m_logdev_targp->bt_bdev; - xfs_free_buftarg(mp->m_logdev_targp); + xfs_free_buftarg(mp, mp->m_logdev_targp); xfs_blkdev_put(logdev); } if (mp->m_rtdev_targp) { struct block_device *rtdev = mp->m_rtdev_targp->bt_bdev; - xfs_free_buftarg(mp->m_rtdev_targp); + xfs_free_buftarg(mp, mp->m_rtdev_targp); xfs_blkdev_put(rtdev); } - xfs_free_buftarg(mp->m_ddev_targp); + xfs_free_buftarg(mp, mp->m_ddev_targp); } /* @@ -810,9 +810,9 @@ xfs_open_devices( out_free_rtdev_targ: if (mp->m_rtdev_targp) - xfs_free_buftarg(mp->m_rtdev_targp); + xfs_free_buftarg(mp, mp->m_rtdev_targp); out_free_ddev_targ: - xfs_free_buftarg(mp->m_ddev_targp); + xfs_free_buftarg(mp, mp->m_ddev_targp); out_close_rtdev: if (rtdev) xfs_blkdev_put(rtdev); From michael.monnerie@is.it-management.at Tue Mar 3 14:56:49 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n23Kumqd035266 for ; Tue, 3 Mar 2009 14:56:49 -0600 X-ASG-Debug-ID: 1236113778-70fb00b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A463B1C14848 for ; Tue, 3 Mar 2009 12:56:19 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id FjlEJywMiMAzFiph for ; Tue, 03 Mar 2009 12:56:19 -0800 (PST) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 0BF1643B4 for ; Tue, 3 Mar 2009 21:56:18 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id F1C52400176 for ; Tue, 3 Mar 2009 21:56:17 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and XEN Subject: Re: XFS and XEN Date: Tue, 3 Mar 2009 21:56:17 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.19-ZMI; KDE/4.1.3; x86_64; ; ) References: <200902170959.55077@zmi.at> <200902241604.29566@zmi.at> <20090224163823.GA19811@infradead.org> In-Reply-To: <20090224163823.GA19811@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903032156.17671@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236113780 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19352 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Dienstag 24 Februar 2009 Christoph Hellwig wrote: > The difference is just that you actually see the > corruption on XFS while it's pretty silent on extN. =A0If your Hardware > (or Hypervisor) is not reliable you _will_ lose data. =A0Either > silently or with a spectacular blowup if the filesystem actually has > consistency checking (which XFS has a lot). One more question: My hardware should be reliable: RAID controller,=20 battery backed cache, disk write cache=3Doff. So even in the event of a=20 power fail, nothing should happen. The controller should write open=20 blocks after reboot. But it doesn't. I've retested: power off. On bootup, the XEN domU=20 PostgreSQL reported errors again. This time of course I had a good=20 backup from a minute before. But still: Shouldn't it be impossible for=20 such an error to happen, as my hardware shouldn't eat any data? I'm=20 trying to find out where the DB gets destroyed. Is it that "just"=20 breaking within a transaction where XEN doesn't correctly fsync is=20 enough, despite all hardware else configured well? Damn, that's a complicated world. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From MultipleIncomeStream650m9@mail.com Tue Mar 3 18:01:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2401qI7041579 for ; Tue, 3 Mar 2009 18:01:53 -0600 X-ASG-Debug-ID: 1236124883-14b402260000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from metroid.cctechnology.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FC3016C31B for ; Tue, 3 Mar 2009 16:01:24 -0800 (PST) Received: from metroid.cctechnology.com (metroid.cctechnology.com [87.246.101.231]) by cuda.sgi.com with ESMTP id IBNwdkAyPuHh9vl8 for ; Tue, 03 Mar 2009 16:01:24 -0800 (PST) thread-index: AcmcW5UQ8kshJnG0So+ny6M2Y7k+vQ== Thread-Topic: Just get in Line and GET PAID From: To: X-ASG-Orig-Subj: Just get in Line and GET PAID Subject: Just get in Line and GET PAID Date: Tue, 3 Mar 2009 23:55:51 -0000 Message-ID: <0F0E415EAEF146EBA27170E5E1A5BFA8@harlequin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 X-Barracuda-Connect: metroid.cctechnology.com[87.246.101.231] X-Barracuda-Start-Time: 1236124885 X-Barracuda-Bayes: INNOCENT GLOBAL 0.7449 1.0000 1.7290 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.73 X-Barracuda-Spam-Status: No, SCORE=1.73 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19364 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear Onliner Marketer, Be On The Opportunity You are invited as free test drive If you're serious about making money on the internet. Apply Now http://biz4u.awardspace.biz/r/visit.php?e=xfs@oss.sgi.com&l=1 Find out how you can make a lucrative residual income from one of the most stable and Extreme Product and Profit Share System Online that is making people RICH on the net today. Apply Now http://biz4u.awardspace.biz/r/visit.php?e=xfs@oss.sgi.com&l=1 Worn down from worrying about your financial future ...when you can barely make ends meet today? Have a Blessed Day! Marilyn Beverly eNetPreneur Online ***** This is not 'SPAM'. You were submitted to our mailing list because you submit an AD to ONE of my FFA-Pages. Or you seeking for a serious home business to create a huge Income. PS: If you wish to unsubscribe click the link. You will be automatically deleted after a short while! Click Here http://xr.com/yourway2optout From michael.monnerie@is.it-management.at Tue Mar 3 20:43:27 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n242hP6E047366 for ; Tue, 3 Mar 2009 20:43:27 -0600 X-ASG-Debug-ID: 1236134575-364a02240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A97321680F0 for ; Tue, 3 Mar 2009 18:42:55 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id Dlqc7wRH8wQ7FFFq for ; Tue, 03 Mar 2009 18:42:55 -0800 (PST) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id AF73B43AD for ; Wed, 4 Mar 2009 03:42:53 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id EF6ED400161 for ; Wed, 4 Mar 2009 03:42:53 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and XEN Subject: Re: XFS and XEN Date: Wed, 4 Mar 2009 03:42:53 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.19-ZMI; KDE/4.1.3; x86_64; ; ) References: <200902170959.55077@zmi.at> <200902241604.29566@zmi.at> <20090224163823.GA19811@infradead.org> In-Reply-To: <20090224163823.GA19811@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903040342.53587@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236134576 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0201 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19373 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I just got this info at XEN: > LVM does not honor write-barriers. Then I searched and found a thread were Eric also talked: http://lkml.org/lkml/2008/5/16/390 http://hightechsorcery.com/2008/06/linux-write-barriers-write-caching- lvm-and-filesystems If I understand correctly, turning off disk cache write cache should be enough to be save, even when using LVM. Is it really XEN that messed the disk, or something else? Could the Areca controller driver do something wrong? I'd really love to get a stable and data-secure system, as you might understand. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From hifumi.hisashi@oss.ntt.co.jp Tue Mar 3 20:53:58 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n242ruWO048011 for ; Tue, 3 Mar 2009 20:53:58 -0600 X-ASG-Debug-ID: 1236135208-364a025c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from serv2.oss.ntt.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4DEC716CBC9; Tue, 3 Mar 2009 18:53:28 -0800 (PST) Received: from serv2.oss.ntt.co.jp (serv2.oss.ntt.co.jp [222.151.198.100]) by cuda.sgi.com with ESMTP id Zs3n6hOx4W395vwl; Tue, 03 Mar 2009 18:53:28 -0800 (PST) Received: from serv2.oss.ntt.co.jp (localhost [127.0.0.1]) by serv2.oss.ntt.co.jp (Postfix) with ESMTP id BC1E0248154; Wed, 4 Mar 2009 11:53:26 +0900 (JST) Received: from serv1.oss.ntt.co.jp (serv1.localdomain [172.19.0.2]) by serv2.oss.ntt.co.jp (Postfix) with ESMTP id AB45824814D; Wed, 4 Mar 2009 11:53:26 +0900 (JST) Received: from hifumi-PC.oss.ntt.co.jp (unknown [172.17.1.17]) by serv1.oss.ntt.co.jp (Postfix) with ESMTP id 88F6B104165; Wed, 4 Mar 2009 11:53:26 +0900 (JST) Message-Id: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> X-Sender: hhifumi@172.19.0.2 X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 04 Mar 2009 11:50:06 +0900 To: xfs-masters@oss.sgi.com, xfs@oss.sgi.com From: Hisashi Hifumi X-ASG-Orig-Subj: [PATCH] XFS: Pagecache usage optimization on XFS Subject: [PATCH] XFS: Pagecache usage optimization on XFS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: serv2.oss.ntt.co.jp[222.151.198.100] X-Barracuda-Start-Time: 1236135210 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19375 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi. I introduced "is_partially_uptodate" aops for XFS. A page can have multiple buffers and even if a page is not uptodate, some buffers can be uptodate on pagesize != blocksize environment. This aops checks that all buffers which correspond to a part of a file that we want to read are uptodate. If so, we do not have to issue actual read IO to HDD even if a page is not uptodate because the portion we want to read are uptodate. "block_is_partially_uptodate" function is already used by ext2/3/4. With the following patch random read/write mixed workloads or random read after random write workloads can be optimized and we can get performance improvement. I did a performance test using the sysbench. #sysbench --num-threads=4 --max-requests=100000 --test=fileio --file-num=1 --file-block-size=8K --file-total-size=1G --file-test-mode=rndrw --file-fsync-freq=0 --file-rw-ratio=0.5 run -2.6.29-rc6 Test execution summary: total time: 123.8645s total number of events: 100000 total time taken by event execution: 442.4994 per-request statistics: min: 0.0000s avg: 0.0044s max: 0.3387s approx. 95 percentile: 0.0118s -2.6.29-rc6-patched Test execution summary: total time: 108.0757s total number of events: 100000 total time taken by event execution: 417.7505 per-request statistics: min: 0.0000s avg: 0.0042s max: 0.3217s approx. 95 percentile: 0.0118s arch: ia64 pagesize: 16k blocksize: 4k Please merge following patch. Thanks. Signed-off-by: Hisashi Hifumi diff -Nrup linux-2.6.29-rc6.org/fs/xfs/linux-2.6/xfs_aops.c linux-2.6.29-rc6.xfs/fs/xfs/linux-2.6/xfs_aops.c --- linux-2.6.29-rc6.org/fs/xfs/linux-2.6/xfs_aops.c 2009-03-02 09:26:08.000000000 +0900 +++ linux-2.6.29-rc6.xfs/fs/xfs/linux-2.6/xfs_aops.c 2009-03-04 10:26:21.000000000 +0900 @@ -1623,4 +1623,5 @@ const struct address_space_operations xf .bmap = xfs_vm_bmap, .direct_IO = xfs_vm_direct_IO, .migratepage = buffer_migrate_page, + .is_partially_uptodate = block_is_partially_uptodate, }; From deportes@tribunero.com Wed Mar 4 03:28:46 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_50,HTML_MESSAGE, KB_DATE_CONTAINS_TAB autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n249SihZ065089 for ; Wed, 4 Mar 2009 03:28:45 -0600 X-ASG-Debug-ID: 1236158604-0cdc00ce0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from avas-mr16.fibertel.com.ar (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F204316D935 for ; Wed, 4 Mar 2009 01:23:24 -0800 (PST) Received: from avas-mr16.fibertel.com.ar (avas-mr16.fibertel.com.ar [24.232.0.248]) by cuda.sgi.com with ESMTP id 87hqJYkTGGARPHX4 for ; Wed, 04 Mar 2009 01:23:24 -0800 (PST) Received: from 112-25-188-190.cab.prima.net.ar ([190.188.25.112]:57057 "EHLO Notebook" smtp-auth: "tribunero" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr16.fibertel.com.ar with ESMTPA id S839402AbZCDJXM; Wed, 4 Mar 2009 07:23:12 -0200 Date: Wed, 4 Mar 2009 07:19:18 -0200 Mime-version: 1.0 X-ASG-Orig-Subj: Copa Libertadores / tenis / rugby Subject: Copa Libertadores / tenis / rugby From: Tribunero Deportes To: linux-xfs Message-Id: <34719.HTAJVCMP@tribunero.com> Reply-To: deportes@tribunero.com Content-Type: multipart/alternative; Boundary="--=BOUNDARY_34719_PEKY_KHIA_ICNU_KAAK" X-Fib-Al-Info: Al X-Fib-Al-MRId: 9b13373eafc3e0e0f69d00ff2a4a8f07 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: deportes@tribunero.com X-Barracuda-Connect: avas-mr16.fibertel.com.ar[24.232.0.248] X-Barracuda-Start-Time: 1236158605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5364 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19401 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Este mensaje esta en formato MIME. Debido a que su programa de correo no entiende este formato, todo o parte de este mensaje debe ser ilegible. ----=BOUNDARY_34719_PEKY_KHIA_ICNU_KAAK Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-transfer-encoding: quoted-printable Hola=2E Somos de una revista digital argentina llamada http://www=2Etribunero=2Ecom= Tenemos noticias, videos, informaci=F3n y comentarios de los acontecimiento= s deportivos m=E1s importantes del mundo=2E De f=FAtbol hablamos de torneos locales, Champions, eliminatorias y la Libe= rtadores=2E Luego tenemos tenis, rugby=2E=2E=2E Visitanos, es gratis, estamos en http://www=2Etribunero=2Ecom ----=BOUNDARY_34719_PEKY_KHIA_ICNU_KAAK Content-Type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable HTML Message
Hola=2E

Somos de una revista digital argentina llamada Tribunero=2Ecom
Tenemos notici= as, videos, informaci=F3n y comentarios de los acontecimientos deportivos m= =E1s importantes del mundo=2E

De f=FAtbol hablamos de torneos locale= s, Champions, eliminatorias y la Libertadores=2E

Luego tenemos tenis= , rugby=2E=2E=2E

Visitanos, es gratis, estamos en Tribunero=2Ecom
----=BOUNDARY_34719_PEKY_KHIA_ICNU_KAAK-- From felixb@oss.sgi.com Wed Mar 4 07:33:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24DXeTO077292 for ; Wed, 4 Mar 2009 07:33:40 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n24DXaHT077249; Wed, 4 Mar 2009 07:33:36 -0600 Date: Wed, 4 Mar 2009 07:33:36 -0600 Message-Id: <200903041333.n24DXaHT077249@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, mainline, updated. v2.6.28-rc3-13654-gfec6c6f X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 5955c7a2cfb6a35429adea5dc480002b15ca8cfc X-Git-Newrev: fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, mainline has been updated 27e88bf Revert "[XFS] remove old vmap cache" 7fdf582 Revert "[XFS] use scalable vmap API" from 5955c7a2cfb6a35429adea5dc480002b15ca8cfc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_buf.c | 79 ++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 76 insertions(+), 3 deletions(-) hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Wed Mar 4 07:33:44 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24DXhiD077360 for ; Wed, 4 Mar 2009 07:33:44 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n24DXf1I077299; Wed, 4 Mar 2009 07:33:41 -0600 Date: Wed, 4 Mar 2009 07:33:41 -0600 Message-Id: <200903041333.n24DXf1I077299@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-13684-gb796313 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 3a011a171906a3a51a43bb860fb7c66a64cab140 X-Git-Newrev: b79631330a653f568a2ac4eb4a32474c80e3fe77 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated b796313 xfs: only issues a cache flush on unmount if barriers are enabled ed93ec3 xfs: prevent lockdep false positive in xfs_iget_cache_miss e8fa6b4 xfs: prevent kernel crash due to corrupted inode log format 27e88bf Revert "[XFS] remove old vmap cache" 7fdf582 Revert "[XFS] use scalable vmap API" from 3a011a171906a3a51a43bb860fb7c66a64cab140 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit b79631330a653f568a2ac4eb4a32474c80e3fe77 Author: Christoph Hellwig Date: Tue Mar 3 14:48:37 2009 -0500 xfs: only issues a cache flush on unmount if barriers are enabled Currently we unconditionally issue a flush from xfs_free_buftarg, but since 2.6.29-rc1 this gives a warning in the style of end_request: I/O error, dev vdb, sector 0 Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Signed-off-by: Felix Blyakher commit ed93ec3907f063268ced18728d0653f6199d100c Author: Christoph Hellwig Date: Tue Mar 3 14:48:35 2009 -0500 xfs: prevent lockdep false positive in xfs_iget_cache_miss The inode can't be locked by anyone else as we just created it a few lines above and it's not been added to any lookup data structure yet. So use a trylock that must succeed to get around the lockdep warnings. Signed-off-by: Christoph Hellwig Reported-by: Alexander Beregalov Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher Signed-off-by: Felix Blyakher commit e8fa6b483feebd23ded5eb01afd7a6e82b6078c6 Author: Christoph Hellwig Date: Tue Mar 3 14:48:36 2009 -0500 xfs: prevent kernel crash due to corrupted inode log format Andras Korn reported an oops on log replay causes by a corrupted xfs_inode_log_format_t passing a 0 size to kmem_zalloc. This patch handles to small or too large numbers of log regions gracefully by rejecting the log replay with a useful error message. Signed-off-by: Christoph Hellwig Reported-by: Andras Korn Reviewed-by: Eric Sandeen Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_buf.c | 12 ++++++++++-- fs/xfs/linux-2.6/xfs_buf.h | 2 +- fs/xfs/linux-2.6/xfs_super.c | 10 +++++----- fs/xfs/xfs_iget.c | 15 ++++++++++----- fs/xfs/xfs_log_recover.c | 17 +++++++++++++---- 5 files changed, 39 insertions(+), 17 deletions(-) hooks/post-receive -- XFS development tree From SRS0+1e5fa176003345526f53+2019+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 4 11:23:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24HN8aI097818 for ; Wed, 4 Mar 2009 11:23:09 -0600 X-ASG-Debug-ID: 1236187360-105f00ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DAE021C18586 for ; Wed, 4 Mar 2009 09:22:41 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id TbA5mAg82QwVOQZu for ; Wed, 04 Mar 2009 09:22:41 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leuno-0002GU-8d; Wed, 04 Mar 2009 17:22:40 +0000 Date: Wed, 4 Mar 2009 12:22:40 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: XFS status update for February 2009 Subject: XFS status update for February 2009 Message-ID: <20090304172240.GA645@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236187361 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean In February various smaller fixes have been sent to Linus for 2.6.29, including a revert of the faster vmap APIs which don't seem to be quite ready yet on the VM side. At the same time various patches have been queued up for 2.6.30, with another big batch pending. There also has been a repost of the CRC patch series, including support for a new, larger inode core. SGI released various bits of work in progress from former employees that will be extremely helpful for the future development of XFS, thanks a lot to Mark Goodwin for making this happen. On the userspace side the long awaited 3.0.0 releases of xfsprogs and xfsdump finally happened early in the month, accompanies by a 2.2.9 release of the dmapi userspace. There have been some issues with packaging so a new minor release might follow soon. The xfs_irecover tool has been relicensed so that it can be merged into the GPLv2 codebase of xfsprogs, but the actual integration work hasn't happened yet. Important bits of XFS documentation that have been available on the XFS website in PDF form have been released in the document source form under the Creative Commons license so that they can be updates as a community effort, and checked into a public git tree. From SRS0+1e5fa176003345526f53+2019+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 4 11:27:58 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_65,J_CHICKENPOX_66,LOCAL_GNU_PATCH autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24HRvk5098003 for ; Wed, 4 Mar 2009 11:27:58 -0600 X-ASG-Debug-ID: 1236187650-03e3018b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AD2A416F9BD for ; Wed, 4 Mar 2009 09:27:30 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 1m1HFBis1nx2ekZK for ; Wed, 04 Mar 2009 09:27:30 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeusR-0008Ni-8z; Wed, 04 Mar 2009 17:27:27 +0000 Date: Wed, 4 Mar 2009 12:27:27 -0500 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Mike Frysinger , Christoph Hellwig , Eric Sandeen , xfs-oss X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Message-ID: <20090304172727.GA21463@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200902261323.09312.agruen@suse.de> <200902261017.30017.vapier@gentoo.org> <200902271835.30912.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902271835.30912.agruen@suse.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236187651 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Feb 27, 2009 at 06:35:30PM +0100, Andreas Gruenbacher wrote: > Okay, I've done that now in the configure Makefile target. This is an > improvement we definitely want, independent of whether or not we end up > shipping generated files. I've tried to port the patch you checked into xfsprogs (see below for the diff), but it fails to build for me. Any idea what might have gone wrong? diff --git a/Makefile b/Makefile index 133e496..4b61e41 100644 --- a/Makefile +++ b/Makefile @@ -12,8 +12,9 @@ endif CONFIGURE = configure include/builddefs include/platform_defs.h LSRCFILES = configure configure.in Makepkgs aclocal.m4 install-sh README VERSION -LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \ - Logs/* built .census install.* install-dev.* *.gz +LDIRT = config.log config.status config.cache config.guess config.sub \ + confdefs.h ltmain.sh libtool built .census \ + Logs/* conftest* install.* install-dev.* *.dep *.gz LIB_SUBDIRS = libxfs libxlog libxcmd libhandle libdisk TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \ @@ -21,7 +22,7 @@ TOOL_SUBDIRS = copy db estimate fsck fsr growfs io logprint mkfs quota \ SUBDIRS = include $(LIB_SUBDIRS) $(TOOL_SUBDIRS) -default: include/builddefs include/platform_defs.h +default: configure include/builddefs include/platform_defs.h ifeq ($(HAVE_BUILDDEFS), no) $(MAKE) -C . $@ else @@ -46,6 +47,8 @@ clean: # if configure hasn't run, nothing to clean endif configure include/builddefs: + libtoolize -c -f + aclocal -I m4 autoconf ./configure \ --prefix=/ \ @@ -68,9 +71,6 @@ include/platform_defs.h: include/builddefs $(MAKE) $(AM_MAKEFLAGS) include/builddefs; \ fi -aclocal.m4:: - aclocal --acdir=`pwd`/m4 --output=$@ - install: default $(addsuffix -install,$(SUBDIRS)) $(INSTALL) -m 755 -d $(PKG_DOC_DIR) $(INSTALL) -m 644 README $(PKG_DOC_DIR) diff --git a/configure.in b/configure.in index 4e4e50c..531d7d0 100644 --- a/configure.in +++ b/configure.in @@ -1,6 +1,9 @@ AC_INIT(include/libxfs.h) +AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_HEADER(include/platform_defs.h) +AC_PROG_LIBTOOL + AC_ARG_ENABLE(shared, [ --enable-shared=[yes/no] Enable use of shared libraries [default=yes]],, enable_shared=yes) From SRS0+1e5fa176003345526f53+2019+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 4 11:30:36 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66,LOCAL_GNU_PATCH autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24HUZBA098174 for ; Wed, 4 Mar 2009 11:30:36 -0600 X-ASG-Debug-ID: 1236187808-106200fe0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2D7FE1C18427 for ; Wed, 4 Mar 2009 09:30:08 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id VwH5T6CuWLDEwvCR for ; Wed, 04 Mar 2009 09:30:08 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Leuv2-0000Sd-M0 for xfs@oss.sgi.com; Wed, 04 Mar 2009 17:30:08 +0000 Date: Wed, 4 Mar 2009 12:30:08 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs: use generic Posix ACL code Subject: Re: xfs: use generic Posix ACL code Message-ID: <20090304173008.GA32471@infradead.org> References: <20090220205117.GA7943@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220205117.GA7943@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236187809 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Feb 20, 2009 at 03:51:17PM -0500, Christoph Hellwig wrote: > This patch rips out the XFS ACL handling code and uses the generic > fs/posix_acl.c code instead. The ondisk format is of course left > unchanged. > > This also introduces the same ACL caching all other Linux filesystems do > by adding pointers to the acl and default acl in struct xfs_inode. FYI: there was one hunk that slipped into another patch so that it was missing in this one. Correct one below: This patch rips out the XFS ACL handling code and uses the generic fs/posix_acl.c code instead. The ondisk format is of course left unchanged. This also introduces the same ACL caching all other Linux filesystems do by adding pointers to the acl and default acl in struct xfs_inode. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfs/fs/xfs/linux-2.6/xfs_acl.c 2009-02-25 14:58:48.495043588 +0100 @@ -0,0 +1,510 @@ +/* + * Copyright (C) 2008 Christoph Hellwig. + * Released under GPL v2. + */ +#include "xfs.h" +#include "xfs_acl.h" +#include "xfs_attr.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" +#include "xfs_vnodeops.h" +#include +#include + + +#define XFS_ACL_NOT_CACHED ((void *)-1) + +/* + * Locking scheme: + * - all ACL updates are protected by inode->i_mutex, which is taken before + * calling into this file. + * - access and updates to the ip->i_acl and ip->i_default_acl pointers are + * protected by inode->i_lock. + */ + +static struct posix_acl * +xfs_acl_from_disk(struct xfs_acl *aclp) +{ + struct posix_acl_entry *acl_e; + struct posix_acl *acl; + struct xfs_acl_entry *ace; + int count, i; + + count = be32_to_cpu(aclp->acl_cnt); + + acl = posix_acl_alloc(count, GFP_KERNEL); + if (!acl) + return ERR_PTR(-ENOMEM); + + for (i = 0; i < count; i++) { + acl_e = &acl->a_entries[i]; + ace = &aclp->acl_entry[i]; + + /* + * The tag is 32 bits on disk and 16 bits in core. + * + * Because every access to it goes through the core + * format first this is not a problem. + */ + acl_e->e_tag = be32_to_cpu(ace->ae_tag); + acl_e->e_perm = be16_to_cpu(ace->ae_perm); + + switch (acl_e->e_tag) { + case ACL_USER: + case ACL_GROUP: + acl_e->e_id = be32_to_cpu(ace->ae_id); + break; + case ACL_USER_OBJ: + case ACL_GROUP_OBJ: + case ACL_MASK: + case ACL_OTHER: + acl_e->e_id = ACL_UNDEFINED_ID; + break; + default: + goto fail; + } + } + return acl; + +fail: + posix_acl_release(acl); + return ERR_PTR(-EINVAL); +} + +static void +xfs_acl_to_disk(struct xfs_acl *aclp, const struct posix_acl *acl) +{ + const struct posix_acl_entry *acl_e; + struct xfs_acl_entry *ace; + int i; + + aclp->acl_cnt = cpu_to_be32(acl->a_count); + for (i = 0; i < acl->a_count; i++) { + ace = &aclp->acl_entry[i]; + acl_e = &acl->a_entries[i]; + + ace->ae_tag = cpu_to_be32(acl_e->e_tag); + ace->ae_id = cpu_to_be32(acl_e->e_id); + ace->ae_perm = cpu_to_be16(acl_e->e_perm); + } +} + +/* + * Update the cached ACL pointer in the inode. + * + * Because we don't hold any locks while reading/writing the attribute + * from/to disk another thread could have raced and updated the cached + * ACL value before us. In that case we release the previous cached value + * and update it with our new value. + */ +static void +xfs_update_cached_acl(struct inode *inode, struct posix_acl **p_acl, + struct posix_acl *acl) +{ + spin_lock(&inode->i_lock); + if (*p_acl && *p_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(*p_acl); + *p_acl = posix_acl_dup(acl); + spin_unlock(&inode->i_lock); +} + +struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl = NULL, **p_acl; + struct xfs_acl *xfs_acl; + int len = sizeof(struct xfs_acl); + char *ea_name; + int error; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return ERR_PTR(-EINVAL); + } + + spin_lock(&inode->i_lock); + if (*p_acl != XFS_ACL_NOT_CACHED) + acl = posix_acl_dup(*p_acl); + spin_unlock(&inode->i_lock); + + /* + * If we have a cached ACLs value just return it, not need to + * go out to the disk. + */ + if (acl) + return acl; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return ERR_PTR(-ENOMEM); + + error = -xfs_attr_get(ip, ea_name, (char *)xfs_acl, &len, ATTR_ROOT); + if (error) { + /* + * If the attribute doesn't exist make sure we have a negative + * cache entry, for any other error assume it is transient and + * leave the cache entry as XFS_ACL_NOT_CACHED. + */ + if (error == -ENOATTR) { + acl = NULL; + goto out_update_cache; + } + goto out; + } + + acl = xfs_acl_from_disk(xfs_acl); + if (IS_ERR(acl)) + goto out; + + out_update_cache: + xfs_update_cached_acl(inode, p_acl, acl); + out: + kfree(xfs_acl); + return acl; +} + +static int +xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl **p_acl; + char *ea_name; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + if (!S_ISDIR(inode->i_mode)) + return acl ? -EACCES : 0; + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return -EINVAL; + } + + if (acl) { + struct xfs_acl *xfs_acl; + int len; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return -ENOMEM; + + xfs_acl_to_disk(xfs_acl, acl); + len = sizeof(struct xfs_acl) - + (sizeof(struct xfs_acl_entry) * + (XFS_ACL_MAX_ENTRIES - acl->a_count)); + + error = -xfs_attr_set(ip, ea_name, (char *)xfs_acl, + len, ATTR_ROOT); + + kfree(xfs_acl); + } else { + /* + * A NULL ACL argument means we want to remove the ACL. + */ + error = -xfs_attr_remove(ip, ea_name, ATTR_ROOT); + + /* + * If the attribute didn't exist to start with that's fine. + */ + if (error == -ENOATTR) + error = 0; + } + + if (!error) + xfs_update_cached_acl(inode, p_acl, acl); + return error; +} + +int +xfs_check_acl(struct inode *inode, int mask) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl; + int error = -EAGAIN; + + xfs_itrace_entry(ip); + + /* + * If there is no attribute fork no ACL exists on this inode and + * we can skip the whole exercise. + */ + if (!XFS_IFORK_Q(ip)) + return -EAGAIN; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl) { + error = posix_acl_permission(inode, acl, mask); + posix_acl_release(acl); + } + + return error; +} + +static int +xfs_set_mode(struct inode *inode, mode_t mode) +{ + int error = 0; + + if (mode != inode->i_mode) { + struct iattr iattr; + + iattr.ia_valid = ATTR_MODE; + iattr.ia_mode = mode; + + error = -xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_NOACL); + } + + return error; +} + +static int +xfs_acl_exists(struct inode *inode, char *name) +{ + int len = sizeof(struct xfs_acl); + + return (xfs_attr_get(XFS_I(inode), name, NULL, &len, + ATTR_ROOT|ATTR_KERNOVAL) == 0); +} + +int +posix_acl_access_exists(struct inode *inode) +{ + return xfs_acl_exists(inode, SGI_ACL_FILE); +} + +int +posix_acl_default_exists(struct inode *inode) +{ + if (!S_ISDIR(inode->i_mode)) + return 0; + return xfs_acl_exists(inode, SGI_ACL_DEFAULT); +} + +/* + * No need for i_mutex because the inode is not yet exposed to the VFS. + */ +int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + struct posix_acl *clone; + mode_t mode; + int error = 0, inherit = 0; + + if (S_ISDIR(inode->i_mode)) { + error = xfs_set_acl(inode, ACL_TYPE_DEFAULT, default_acl); + if (error) + return error; + } + + clone = posix_acl_clone(default_acl, GFP_KERNEL); + if (!clone) + return -ENOMEM; + + mode = inode->i_mode; + error = posix_acl_create_masq(clone, &mode); + if (error < 0) + goto out_release_clone; + + /* + * If posix_acl_create_masq returns a positive value we need to + * inherit a permission that can't be represented using the Unix + * mode bits and we actually need to set an ACL. + */ + if (error > 0) + inherit = 1; + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release_clone; + + if (inherit) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + out_release_clone: + posix_acl_release(clone); + return error; +} + +int +xfs_acl_chmod(struct inode *inode) +{ + struct posix_acl *acl, *clone; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl) || !acl) + return PTR_ERR(acl); + + clone = posix_acl_clone(acl, GFP_KERNEL); + posix_acl_release(acl); + if (!clone) + return -ENOMEM; + + error = posix_acl_chmod_masq(clone, inode->i_mode); + if (!error) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + posix_acl_release(clone); + return error; +} + +void +xfs_inode_init_acls(struct xfs_inode *ip) +{ + /* + * No need for locking, inode is not live yet. + */ + ip->i_acl = XFS_ACL_NOT_CACHED; + ip->i_default_acl = XFS_ACL_NOT_CACHED; +} + +void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ + /* + * No need for locking here, the inode is not live anymore + * and just about to be freed. + */ + if (ip->i_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_acl); + if (ip->i_default_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_default_acl); +} + + +/* + * System xattr handlers. + * + * Currently Posix ACLs are the only system namespace extended attribute + * handlers supported by XFS, so we just implement the handlers here. + * If we ever support other system extended attributes this will need + * some refactoring. + */ + +static int +xfs_decode_acl(const char *name) +{ + if (strcmp(name, "posix_acl_access") == 0) + return ACL_TYPE_ACCESS; + else if (strcmp(name, "posix_acl_default") == 0) + return ACL_TYPE_DEFAULT; + return -EINVAL; +} + +static int +xfs_xattr_system_get(struct inode *inode, const char *name, + void *value, size_t size) +{ + struct posix_acl *acl; + int type, error; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + + acl = xfs_get_acl(inode, type); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl == NULL) + return -ENODATA; + + error = posix_acl_to_xattr(acl, value, size); + posix_acl_release(acl); + + return error; +} + +static int +xfs_xattr_system_set(struct inode *inode, const char *name, + const void *value, size_t size, int flags) +{ + struct posix_acl *acl = NULL; + int error = 0, type; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + if (flags & XATTR_CREATE) + return -EINVAL; + if (type == ACL_TYPE_DEFAULT && !S_ISDIR(inode->i_mode)) + return value ? -EACCES : 0; + if ((current_fsuid() != inode->i_uid) && !capable(CAP_FOWNER)) + return -EPERM; + + if (!value) + goto set_acl; + + acl = posix_acl_from_xattr(value, size); + if (!acl) { + /* + * acl_set_file(3) may request that we set default ACLs with + * zero length -- defend (gracefully) against that here. + */ + goto out; + } + if (IS_ERR(acl)) { + error = PTR_ERR(acl); + goto out; + } + + error = posix_acl_valid(acl); + if (error) + goto out_release; + + error = -EINVAL; + if (acl->a_count > XFS_ACL_MAX_ENTRIES) + goto out_release; + + if (type == ACL_TYPE_ACCESS) { + mode_t mode = inode->i_mode; + error = posix_acl_equiv_mode(acl, &mode); + + if (error <= 0) { + posix_acl_release(acl); + acl = NULL; + + if (error < 0) + return error; + } + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release; + } + + set_acl: + error = xfs_set_acl(inode, type, acl); + out_release: + posix_acl_release(acl); + out: + return error; +} + +struct xattr_handler xfs_xattr_system_handler = { + .prefix = XATTR_SYSTEM_PREFIX, + .get = xfs_xattr_system_get, + .set = xfs_xattr_system_set, +}; Index: xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2009-02-24 15:23:49.446532663 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_iops.c 2009-02-25 14:58:48.497044261 +0100 @@ -17,6 +17,7 @@ */ #include "xfs.h" #include "xfs_fs.h" +#include "xfs_acl.h" #include "xfs_bit.h" #include "xfs_log.h" #include "xfs_inum.h" @@ -51,6 +52,7 @@ #include #include #include +#include #include #include #include @@ -202,9 +204,8 @@ xfs_vn_mknod( { struct inode *inode; struct xfs_inode *ip = NULL; - xfs_acl_t *default_acl = NULL; + struct posix_acl *default_acl = NULL; struct xfs_name name; - int (*test_default_acl)(struct inode *) = _ACL_DEFAULT_EXISTS; int error; /* @@ -219,18 +220,14 @@ xfs_vn_mknod( rdev = 0; } - if (test_default_acl && test_default_acl(dir)) { - if (!_ACL_ALLOC(default_acl)) { - return -ENOMEM; - } - if (!_ACL_GET_DEFAULT(dir, default_acl)) { - _ACL_FREE(default_acl); - default_acl = NULL; - } - } + if (IS_POSIXACL(dir)) { + default_acl = xfs_get_acl(dir, ACL_TYPE_DEFAULT); + if (IS_ERR(default_acl)) + return -PTR_ERR(default_acl); - if (IS_POSIXACL(dir) && !default_acl) - mode &= ~current->fs->umask; + if (!default_acl) + mode &= ~current->fs->umask; + } xfs_dentry_to_name(&name, dentry); error = xfs_create(XFS_I(dir), &name, mode, rdev, &ip, NULL); @@ -244,10 +241,10 @@ xfs_vn_mknod( goto out_cleanup_inode; if (default_acl) { - error = _ACL_INHERIT(inode, mode, default_acl); + error = -xfs_inherit_acl(inode, default_acl); if (unlikely(error)) goto out_cleanup_inode; - _ACL_FREE(default_acl); + posix_acl_release(default_acl); } @@ -257,8 +254,7 @@ xfs_vn_mknod( out_cleanup_inode: xfs_cleanup_inode(dir, inode, dentry); out_free_acl: - if (default_acl) - _ACL_FREE(default_acl); + posix_acl_release(default_acl); return -error; } @@ -488,26 +484,6 @@ xfs_vn_put_link( kfree(s); } -#ifdef CONFIG_XFS_POSIX_ACL -STATIC int -xfs_check_acl( - struct inode *inode, - int mask) -{ - struct xfs_inode *ip = XFS_I(inode); - int error; - - xfs_itrace_entry(ip); - - if (XFS_IFORK_Q(ip)) { - error = xfs_acl_iaccess(ip, mask, NULL); - if (error != -1) - return -error; - } - - return -EAGAIN; -} - STATIC int xfs_vn_permission( struct inode *inode, @@ -515,9 +491,6 @@ xfs_vn_permission( { return generic_permission(inode, mask, xfs_check_acl); } -#else -#define xfs_vn_permission NULL -#endif STATIC int xfs_vn_getattr( Index: xfs/fs/xfs/Makefile =================================================================== --- xfs.orig/fs/xfs/Makefile 2009-02-24 15:32:35.859495267 +0100 +++ xfs/fs/xfs/Makefile 2009-02-25 14:58:48.497044261 +0100 @@ -40,7 +40,7 @@ xfs-$(CONFIG_PROC_FS) += quota/xfs_qm_s endif xfs-$(CONFIG_XFS_RT) += xfs_rtalloc.o -xfs-$(CONFIG_XFS_POSIX_ACL) += xfs_acl.o +xfs-$(CONFIG_XFS_POSIX_ACL) += $(XFS_LINUX)/xfs_acl.o xfs-$(CONFIG_PROC_FS) += $(XFS_LINUX)/xfs_stats.o xfs-$(CONFIG_SYSCTL) += $(XFS_LINUX)/xfs_sysctl.o xfs-$(CONFIG_COMPAT) += $(XFS_LINUX)/xfs_ioctl32.o Index: xfs/fs/xfs/xfs_inode.h =================================================================== --- xfs.orig/fs/xfs/xfs_inode.h 2009-02-24 15:23:49.544496182 +0100 +++ xfs/fs/xfs/xfs_inode.h 2009-02-25 14:58:48.499958180 +0100 @@ -18,6 +18,7 @@ #ifndef __XFS_INODE_H__ #define __XFS_INODE_H__ +struct posix_acl; struct xfs_dinode; struct xfs_inode; @@ -272,6 +273,11 @@ typedef struct xfs_inode { /* VFS inode */ struct inode i_vnode; /* embedded VFS inode */ +#ifdef CONFIG_XFS_POSIX_ACL + struct posix_acl *i_acl; + struct posix_acl *i_default_acl; +#endif + /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE struct ktrace *i_trace; /* general inode trace */ Index: xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2009-02-24 15:23:49.461498116 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_xattr.c 2009-02-25 14:58:48.502417500 +0100 @@ -29,67 +29,6 @@ #include -/* - * ACL handling. Should eventually be moved into xfs_acl.c - */ - -static int -xfs_decode_acl(const char *name) -{ - if (strcmp(name, "posix_acl_access") == 0) - return _ACL_TYPE_ACCESS; - else if (strcmp(name, "posix_acl_default") == 0) - return _ACL_TYPE_DEFAULT; - return -EINVAL; -} - -/* - * Get system extended attributes which at the moment only - * includes Posix ACLs. - */ -static int -xfs_xattr_system_get(struct inode *inode, const char *name, - void *buffer, size_t size) -{ - int acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - - return xfs_acl_vget(inode, buffer, size, acl); -} - -static int -xfs_xattr_system_set(struct inode *inode, const char *name, - const void *value, size_t size, int flags) -{ - int acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - if (flags & XATTR_CREATE) - return -EINVAL; - - if (!value) - return xfs_acl_vremove(inode, acl); - - return xfs_acl_vset(inode, (void *)value, size, acl); -} - -static struct xattr_handler xfs_xattr_system_handler = { - .prefix = XATTR_SYSTEM_PREFIX, - .get = xfs_xattr_system_get, - .set = xfs_xattr_system_set, -}; - - -/* - * Real xattr handling. The only difference between the namespaces is - * a flag passed to the low-level attr code. - */ - static int __xfs_xattr_get(struct inode *inode, const char *name, void *value, size_t size, int xflags) @@ -199,7 +138,9 @@ struct xattr_handler *xfs_xattr_handlers &xfs_xattr_user_handler, &xfs_xattr_trusted_handler, &xfs_xattr_security_handler, +#ifdef CONFIG_XFS_POSIX_ACL &xfs_xattr_system_handler, +#endif NULL }; @@ -310,7 +251,7 @@ xfs_vn_listxattr(struct dentry *dentry, /* * Then add the two synthetic ACL attributes. */ - if (xfs_acl_vhasacl_access(inode)) { + if (posix_acl_access_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, data, size, &context.count); @@ -318,7 +259,7 @@ xfs_vn_listxattr(struct dentry *dentry, return error; } - if (xfs_acl_vhasacl_default(inode)) { + if (posix_acl_default_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, data, size, &context.count); Index: xfs/fs/xfs/Kconfig =================================================================== --- xfs.orig/fs/xfs/Kconfig 2009-02-24 15:23:49.548494806 +0100 +++ xfs/fs/xfs/Kconfig 2009-02-25 14:58:48.502925526 +0100 @@ -39,6 +39,7 @@ config XFS_QUOTA config XFS_POSIX_ACL bool "XFS POSIX ACL support" depends on XFS_FS + select FS_POSIX_ACL help POSIX Access Control Lists (ACLs) support permissions for users and groups beyond the owner/group/world scheme. Index: xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2009-02-24 15:32:35.866394539 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-02-25 21:07:00.541670260 +0100 @@ -43,7 +43,6 @@ #include "xfs_itable.h" #include "xfs_fsops.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" @@ -1742,18 +1741,8 @@ xfs_init_zones(void) if (!xfs_ili_zone) goto out_destroy_inode_zone; -#ifdef CONFIG_XFS_POSIX_ACL - xfs_acl_zone = kmem_zone_init(sizeof(xfs_acl_t), "xfs_acl"); - if (!xfs_acl_zone) - goto out_destroy_ili_zone; -#endif - return 0; -#ifdef CONFIG_XFS_POSIX_ACL - out_destroy_ili_zone: -#endif - kmem_zone_destroy(xfs_ili_zone); out_destroy_inode_zone: kmem_zone_destroy(xfs_inode_zone); out_destroy_efi_zone: @@ -1787,9 +1776,6 @@ xfs_init_zones(void) STATIC void xfs_destroy_zones(void) { -#ifdef CONFIG_XFS_POSIX_ACL - kmem_zone_destroy(xfs_acl_zone); -#endif kmem_zone_destroy(xfs_ili_zone); kmem_zone_destroy(xfs_inode_zone); kmem_zone_destroy(xfs_efi_zone); Index: xfs/fs/xfs/xfs_attr.c =================================================================== --- xfs.orig/fs/xfs/xfs_attr.c 2009-02-24 15:32:35.857495152 +0100 +++ xfs/fs/xfs/xfs_attr.c 2009-02-25 14:58:48.507044347 +0100 @@ -45,7 +45,6 @@ #include "xfs_error.h" #include "xfs_quota.h" #include "xfs_trans_space.h" -#include "xfs_acl.h" #include "xfs_rw.h" #include "xfs_vnodeops.h" Index: xfs/fs/xfs/xfs_iomap.c =================================================================== --- xfs.orig/fs/xfs/xfs_iomap.c 2009-02-24 15:32:35.858495489 +0100 +++ xfs/fs/xfs/xfs_iomap.c 2009-02-25 14:58:48.508043915 +0100 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: xfs/fs/xfs/xfs_rw.c =================================================================== --- xfs.orig/fs/xfs/xfs_rw.c 2009-02-24 15:23:49.561494925 +0100 +++ xfs/fs/xfs/xfs_rw.c 2009-02-25 14:58:48.508952411 +0100 @@ -41,7 +41,6 @@ #include "xfs_ialloc.h" #include "xfs_attr.h" #include "xfs_bmap.h" -#include "xfs_acl.h" #include "xfs_error.h" #include "xfs_buf_item.h" #include "xfs_rw.h" Index: xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2009-02-24 15:32:35.865370666 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2009-02-25 14:58:48.510054506 +0100 @@ -40,7 +40,6 @@ #include "xfs_itable.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_bmap.h" #include "xfs_buf_item.h" Index: xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2009-02-24 15:23:49.510496742 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_lrw.c 2009-02-25 14:58:48.510944284 +0100 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_inode_item.h" #include "xfs_buf_item.h" Index: xfs/fs/xfs/quota/xfs_dquot.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_dquot.c 2009-02-24 15:32:35.867425537 +0100 +++ xfs/fs/xfs/quota/xfs_dquot.c 2009-02-25 20:19:38.983670126 +0100 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: xfs/fs/xfs/quota/xfs_dquot_item.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_dquot_item.c 2009-02-24 15:23:49.570494953 +0100 +++ xfs/fs/xfs/quota/xfs_dquot_item.c 2009-02-25 14:58:48.511920106 +0100 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" Index: xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm.c 2009-02-24 21:30:39.422052308 +0100 +++ xfs/fs/xfs/quota/xfs_qm.c 2009-02-25 20:19:38.988670274 +0100 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: xfs/fs/xfs/quota/xfs_qm_bhv.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2009-02-24 15:32:35.856495653 +0100 +++ xfs/fs/xfs/quota/xfs_qm_bhv.c 2009-02-25 14:58:48.513939567 +0100 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: xfs/fs/xfs/quota/xfs_qm_stats.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm_stats.c 2009-02-24 15:23:49.582495294 +0100 +++ xfs/fs/xfs/quota/xfs_qm_stats.c 2009-02-25 14:58:48.514948006 +0100 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-24 21:30:39.430057656 +0100 +++ xfs/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-25 14:58:48.517947689 +0100 @@ -45,7 +45,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" Index: xfs/fs/xfs/quota/xfs_trans_dquot.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2009-02-24 15:32:35.845494182 +0100 +++ xfs/fs/xfs/quota/xfs_trans_dquot.c 2009-02-25 14:58:48.518942020 +0100 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" Index: xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- xfs.orig/fs/xfs/xfs_vnodeops.c 2009-02-24 15:32:35.855495805 +0100 +++ xfs/fs/xfs/xfs_vnodeops.c 2009-02-25 20:19:38.999670627 +0100 @@ -42,6 +42,7 @@ #include "xfs_ialloc.h" #include "xfs_alloc.h" #include "xfs_bmap.h" +#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_rw.h" #include "xfs_error.h" @@ -466,8 +467,20 @@ xfs_setattr( xfs_qm_dqrele(udqp); xfs_qm_dqrele(gdqp); - if (code) { + if (code) return code; + + /* + * XXX(hch): Updating the ACL entries is not atomic vs the i_mode + * update. We could avoid this with linked transactions + * and an passing down the transaction pointer all the + * way to attr_set. No previous user of the generic + * Posix ACL code seems to care about this issue either. + */ + if ((mask & ATTR_MODE) && !(flags & XFS_ATTR_NOACL)) { + code = xfs_acl_chmod(inode); + if (code) + return code; } if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE) && Index: xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- xfs.orig/fs/xfs/xfs_vnodeops.h 2009-02-24 15:23:49.601494710 +0100 +++ xfs/fs/xfs/xfs_vnodeops.h 2009-02-25 14:58:48.520945068 +0100 @@ -18,6 +18,7 @@ int xfs_setattr(struct xfs_inode *ip, st #define XFS_ATTR_DMI 0x01 /* invocation from a DMI function */ #define XFS_ATTR_NONBLOCK 0x02 /* return EAGAIN if operation would block */ #define XFS_ATTR_NOLOCK 0x04 /* Don't grab any conflicting locks */ +#define XFS_ATTR_NOACL 0x08 /* Don't call xfs_acl_chmod */ int xfs_readlink(struct xfs_inode *ip, char *link); int xfs_fsync(struct xfs_inode *ip); Index: xfs/fs/xfs/xfs_acl.c =================================================================== --- xfs.orig/fs/xfs/xfs_acl.c 2009-02-24 15:23:49.605495639 +0100 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,874 +0,0 @@ -/* - * Copyright (c) 2001-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_inum.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_btree.h" -#include "xfs_acl.h" -#include "xfs_attr.h" -#include "xfs_vnodeops.h" - -#include -#include - -STATIC int xfs_acl_setmode(struct inode *, xfs_acl_t *, int *); -STATIC void xfs_acl_filter_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_endian(xfs_acl_t *); -STATIC int xfs_acl_access(uid_t, gid_t, xfs_acl_t *, mode_t, cred_t *); -STATIC int xfs_acl_invalid(xfs_acl_t *); -STATIC void xfs_acl_sync_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_attr(struct inode *, xfs_acl_t *, int, int, int *); -STATIC void xfs_acl_set_attr(struct inode *, xfs_acl_t *, int, int *); -STATIC int xfs_acl_allow_set(struct inode *, int); - -kmem_zone_t *xfs_acl_zone; - - -/* - * Test for existence of access ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_access( - struct inode *vp) -{ - int error; - - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_ACCESS, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Test for existence of default ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_default( - struct inode *vp) -{ - int error; - - if (!S_ISDIR(vp->i_mode)) - return 0; - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_DEFAULT, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Convert from extended attribute representation to in-memory for XFS. - */ -STATIC int -posix_acl_xattr_to_xfs( - posix_acl_xattr_header *src, - size_t size, - xfs_acl_t *dest) -{ - posix_acl_xattr_entry *src_entry; - xfs_acl_entry_t *dest_entry; - int n; - - if (!src || !dest) - return EINVAL; - - if (size < sizeof(posix_acl_xattr_header)) - return EINVAL; - - if (src->a_version != cpu_to_le32(POSIX_ACL_XATTR_VERSION)) - return EOPNOTSUPP; - - memset(dest, 0, sizeof(xfs_acl_t)); - dest->acl_cnt = posix_acl_xattr_count(size); - if (dest->acl_cnt < 0 || dest->acl_cnt > XFS_ACL_MAX_ENTRIES) - return EINVAL; - - /* - * acl_set_file(3) may request that we set default ACLs with - * zero length -- defend (gracefully) against that here. - */ - if (!dest->acl_cnt) - return 0; - - src_entry = (posix_acl_xattr_entry *)((char *)src + sizeof(*src)); - dest_entry = &dest->acl_entry[0]; - - for (n = 0; n < dest->acl_cnt; n++, src_entry++, dest_entry++) { - dest_entry->ae_perm = le16_to_cpu(src_entry->e_perm); - if (_ACL_PERM_INVALID(dest_entry->ae_perm)) - return EINVAL; - dest_entry->ae_tag = le16_to_cpu(src_entry->e_tag); - switch(dest_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->ae_id = le32_to_cpu(src_entry->e_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->ae_id = ACL_UNDEFINED_ID; - break; - default: - return EINVAL; - } - } - if (xfs_acl_invalid(dest)) - return EINVAL; - - return 0; -} - -/* - * Comparison function called from xfs_sort(). - * Primary key is ae_tag, secondary key is ae_id. - */ -STATIC int -xfs_acl_entry_compare( - const void *va, - const void *vb) -{ - xfs_acl_entry_t *a = (xfs_acl_entry_t *)va, - *b = (xfs_acl_entry_t *)vb; - - if (a->ae_tag == b->ae_tag) - return (a->ae_id - b->ae_id); - return (a->ae_tag - b->ae_tag); -} - -/* - * Convert from in-memory XFS to extended attribute representation. - */ -STATIC int -posix_acl_xfs_to_xattr( - xfs_acl_t *src, - posix_acl_xattr_header *dest, - size_t size) -{ - int n; - size_t new_size = posix_acl_xattr_size(src->acl_cnt); - posix_acl_xattr_entry *dest_entry; - xfs_acl_entry_t *src_entry; - - if (size < new_size) - return -ERANGE; - - /* Need to sort src XFS ACL by */ - xfs_sort(src->acl_entry, src->acl_cnt, sizeof(src->acl_entry[0]), - xfs_acl_entry_compare); - - dest->a_version = cpu_to_le32(POSIX_ACL_XATTR_VERSION); - dest_entry = &dest->a_entries[0]; - src_entry = &src->acl_entry[0]; - for (n = 0; n < src->acl_cnt; n++, dest_entry++, src_entry++) { - dest_entry->e_perm = cpu_to_le16(src_entry->ae_perm); - if (_ACL_PERM_INVALID(src_entry->ae_perm)) - return -EINVAL; - dest_entry->e_tag = cpu_to_le16(src_entry->ae_tag); - switch (src_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->e_id = cpu_to_le32(src_entry->ae_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->e_id = cpu_to_le32(ACL_UNDEFINED_ID); - break; - default: - return -EINVAL; - } - } - return new_size; -} - -int -xfs_acl_vget( - struct inode *vp, - void *acl, - size_t size, - int kind) -{ - int error; - xfs_acl_t *xfs_acl = NULL; - posix_acl_xattr_header *ext_acl = acl; - int flags = 0; - - if(size) { - if (!(_ACL_ALLOC(xfs_acl))) { - error = ENOMEM; - goto out; - } - memset(xfs_acl, 0, sizeof(xfs_acl_t)); - } else - flags = ATTR_KERNOVAL; - - xfs_acl_get_attr(vp, xfs_acl, kind, flags, &error); - if (error) - goto out; - - if (!size) { - error = -posix_acl_xattr_size(XFS_ACL_MAX_ENTRIES); - } else { - if (xfs_acl_invalid(xfs_acl)) { - error = EINVAL; - goto out; - } - if (kind == _ACL_TYPE_ACCESS) - xfs_acl_sync_mode(XFS_I(vp)->i_d.di_mode, xfs_acl); - error = -posix_acl_xfs_to_xattr(xfs_acl, ext_acl, size); - } -out: - if(xfs_acl) - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_vremove( - struct inode *vp, - int kind) -{ - int error; - - error = xfs_acl_allow_set(vp, kind); - if (!error) { - error = xfs_attr_remove(XFS_I(vp), - kind == _ACL_TYPE_DEFAULT? - SGI_ACL_DEFAULT: SGI_ACL_FILE, - ATTR_ROOT); - if (error == ENOATTR) - error = 0; /* 'scool */ - } - return -error; -} - -int -xfs_acl_vset( - struct inode *vp, - void *acl, - size_t size, - int kind) -{ - posix_acl_xattr_header *ext_acl = acl; - xfs_acl_t *xfs_acl; - int error; - int basicperms = 0; /* more than std unix perms? */ - - if (!acl) - return -EINVAL; - - if (!(_ACL_ALLOC(xfs_acl))) - return -ENOMEM; - - error = posix_acl_xattr_to_xfs(ext_acl, size, xfs_acl); - if (error) { - _ACL_FREE(xfs_acl); - return -error; - } - if (!xfs_acl->acl_cnt) { - _ACL_FREE(xfs_acl); - return 0; - } - - error = xfs_acl_allow_set(vp, kind); - - /* Incoming ACL exists, set file mode based on its value */ - if (!error && kind == _ACL_TYPE_ACCESS) - error = xfs_acl_setmode(vp, xfs_acl, &basicperms); - - if (error) - goto out; - - /* - * If we have more than std unix permissions, set up the actual attr. - * Otherwise, delete any existing attr. This prevents us from - * having actual attrs for permissions that can be stored in the - * standard permission bits. - */ - if (!basicperms) { - xfs_acl_set_attr(vp, xfs_acl, kind, &error); - } else { - error = -xfs_acl_vremove(vp, _ACL_TYPE_ACCESS); - } - -out: - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_iaccess( - xfs_inode_t *ip, - mode_t mode, - cred_t *cr) -{ - xfs_acl_t *acl; - int rval; - struct xfs_name acl_name = {SGI_ACL_FILE, SGI_ACL_FILE_SIZE}; - - if (!(_ACL_ALLOC(acl))) - return -1; - - /* If the file has no ACL return -1. */ - rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { - _ACL_FREE(acl); - return -1; - } - xfs_acl_get_endian(acl); - - /* If the file has an empty ACL return -1. */ - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) { - _ACL_FREE(acl); - return -1; - } - - /* Synchronize ACL with mode bits */ - xfs_acl_sync_mode(ip->i_d.di_mode, acl); - - rval = xfs_acl_access(ip->i_d.di_uid, ip->i_d.di_gid, acl, mode, cr); - _ACL_FREE(acl); - return rval; -} - -STATIC int -xfs_acl_allow_set( - struct inode *vp, - int kind) -{ - if (vp->i_flags & (S_IMMUTABLE|S_APPEND)) - return EPERM; - if (kind == _ACL_TYPE_DEFAULT && !S_ISDIR(vp->i_mode)) - return ENOTDIR; - if (vp->i_sb->s_flags & MS_RDONLY) - return EROFS; - if (XFS_I(vp)->i_d.di_uid != current_fsuid() && !capable(CAP_FOWNER)) - return EPERM; - return 0; -} - -/* - * Note: cr is only used here for the capability check if the ACL test fails. - * It is not used to find out the credentials uid or groups etc, as was - * done in IRIX. It is assumed that the uid and groups for the current - * thread are taken from "current" instead of the cr parameter. - */ -STATIC int -xfs_acl_access( - uid_t fuid, - gid_t fgid, - xfs_acl_t *fap, - mode_t md, - cred_t *cr) -{ - xfs_acl_entry_t matched; - int i, allows; - int maskallows = -1; /* true, but not 1, either */ - int seen_userobj = 0; - - matched.ae_tag = 0; /* Invalid type */ - matched.ae_perm = 0; - - for (i = 0; i < fap->acl_cnt; i++) { - /* - * Break out if we've got a user_obj entry or - * a user entry and the mask (and have processed USER_OBJ) - */ - if (matched.ae_tag == ACL_USER_OBJ) - break; - if (matched.ae_tag == ACL_USER) { - if (maskallows != -1 && seen_userobj) - break; - if (fap->acl_entry[i].ae_tag != ACL_MASK && - fap->acl_entry[i].ae_tag != ACL_USER_OBJ) - continue; - } - /* True if this entry allows the requested access */ - allows = ((fap->acl_entry[i].ae_perm & md) == md); - - switch (fap->acl_entry[i].ae_tag) { - case ACL_USER_OBJ: - seen_userobj = 1; - if (fuid != current_fsuid()) - continue; - matched.ae_tag = ACL_USER_OBJ; - matched.ae_perm = allows; - break; - case ACL_USER: - if (fap->acl_entry[i].ae_id != current_fsuid()) - continue; - matched.ae_tag = ACL_USER; - matched.ae_perm = allows; - break; - case ACL_GROUP_OBJ: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fgid)) - continue; - matched.ae_tag = ACL_GROUP_OBJ; - matched.ae_perm = allows; - break; - case ACL_GROUP: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fap->acl_entry[i].ae_id)) - continue; - matched.ae_tag = ACL_GROUP; - matched.ae_perm = allows; - break; - case ACL_MASK: - maskallows = allows; - break; - case ACL_OTHER: - if (matched.ae_tag != 0) - continue; - matched.ae_tag = ACL_OTHER; - matched.ae_perm = allows; - break; - } - } - /* - * First possibility is that no matched entry allows access. - * The capability to override DAC may exist, so check for it. - */ - switch (matched.ae_tag) { - case ACL_OTHER: - case ACL_USER_OBJ: - if (matched.ae_perm) - return 0; - break; - case ACL_USER: - case ACL_GROUP_OBJ: - case ACL_GROUP: - if (maskallows && matched.ae_perm) - return 0; - break; - case 0: - break; - } - - /* EACCES tells generic_permission to check for capability overrides */ - return EACCES; -} - -/* - * ACL validity checker. - * This acl validation routine checks each ACL entry read in makes sense. - */ -STATIC int -xfs_acl_invalid( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *entry, *e; - int user = 0, group = 0, other = 0, mask = 0; - int mask_required = 0; - int i, j; - - if (!aclp) - goto acl_invalid; - - if (aclp->acl_cnt > XFS_ACL_MAX_ENTRIES) - goto acl_invalid; - - for (i = 0; i < aclp->acl_cnt; i++) { - entry = &aclp->acl_entry[i]; - switch (entry->ae_tag) { - case ACL_USER_OBJ: - if (user++) - goto acl_invalid; - break; - case ACL_GROUP_OBJ: - if (group++) - goto acl_invalid; - break; - case ACL_OTHER: - if (other++) - goto acl_invalid; - break; - case ACL_USER: - case ACL_GROUP: - for (j = i + 1; j < aclp->acl_cnt; j++) { - e = &aclp->acl_entry[j]; - if (e->ae_id == entry->ae_id && - e->ae_tag == entry->ae_tag) - goto acl_invalid; - } - mask_required++; - break; - case ACL_MASK: - if (mask++) - goto acl_invalid; - break; - default: - goto acl_invalid; - } - } - if (!user || !group || !other || (mask_required && !mask)) - goto acl_invalid; - else - return 0; -acl_invalid: - return EINVAL; -} - -/* - * Do ACL endian conversion. - */ -STATIC void -xfs_acl_get_endian( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *ace, *end; - - INT_SET(aclp->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0]; ace < end; ace++) { - INT_SET(ace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(ace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(ace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } -} - -/* - * Get the ACL from the EA and do endian conversion. - */ -STATIC void -xfs_acl_get_attr( - struct inode *vp, - xfs_acl_t *aclp, - int kind, - int flags, - int *error) -{ - int len = sizeof(xfs_acl_t); - - ASSERT((flags & ATTR_KERNOVAL) ? (aclp == NULL) : 1); - flags |= ATTR_ROOT; - *error = xfs_attr_get(XFS_I(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE : SGI_ACL_DEFAULT, - (char *)aclp, &len, flags); - if (*error || (flags & ATTR_KERNOVAL)) - return; - xfs_acl_get_endian(aclp); -} - -/* - * Set the EA with the ACL and do endian conversion. - */ -STATIC void -xfs_acl_set_attr( - struct inode *vp, - xfs_acl_t *aclp, - int kind, - int *error) -{ - xfs_acl_entry_t *ace, *newace, *end; - xfs_acl_t *newacl; - int len; - - if (!(_ACL_ALLOC(newacl))) { - *error = ENOMEM; - return; - } - - len = sizeof(xfs_acl_t) - - (sizeof(xfs_acl_entry_t) * (XFS_ACL_MAX_ENTRIES - aclp->acl_cnt)); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0], newace = &newacl->acl_entry[0]; - ace < end; - ace++, newace++) { - INT_SET(newace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(newace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(newace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } - INT_SET(newacl->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - *error = xfs_attr_set(XFS_I(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE: SGI_ACL_DEFAULT, - (char *)newacl, len, ATTR_ROOT); - _ACL_FREE(newacl); -} - -int -xfs_acl_vtoacl( - struct inode *vp, - xfs_acl_t *access_acl, - xfs_acl_t *default_acl) -{ - int error = 0; - - if (access_acl) { - /* - * Get the Access ACL and the mode. If either cannot - * be obtained for some reason, invalidate the access ACL. - */ - xfs_acl_get_attr(vp, access_acl, _ACL_TYPE_ACCESS, 0, &error); - if (error) - access_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - else /* We have a good ACL and the file mode, synchronize. */ - xfs_acl_sync_mode(XFS_I(vp)->i_d.di_mode, access_acl); - } - - if (default_acl) { - xfs_acl_get_attr(vp, default_acl, _ACL_TYPE_DEFAULT, 0, &error); - if (error) - default_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - } - return error; -} - -/* - * This function retrieves the parent directory's acl, processes it - * and lets the child inherit the acl(s) that it should. - */ -int -xfs_acl_inherit( - struct inode *vp, - mode_t mode, - xfs_acl_t *pdaclp) -{ - xfs_acl_t *cacl; - int error = 0; - int basicperms = 0; - - /* - * If the parent does not have a default ACL, or it's an - * invalid ACL, we're done. - */ - if (!vp) - return 0; - if (!pdaclp || xfs_acl_invalid(pdaclp)) - return 0; - - /* - * Copy the default ACL of the containing directory to - * the access ACL of the new file and use the mode that - * was passed in to set up the correct initial values for - * the u::,g::[m::], and o:: entries. This is what makes - * umask() "work" with ACL's. - */ - - if (!(_ACL_ALLOC(cacl))) - return ENOMEM; - - memcpy(cacl, pdaclp, sizeof(xfs_acl_t)); - xfs_acl_filter_mode(mode, cacl); - error = xfs_acl_setmode(vp, cacl, &basicperms); - if (error) - goto out_error; - - /* - * Set the Default and Access ACL on the file. The mode is already - * set on the file, so we don't need to worry about that. - * - * If the new file is a directory, its default ACL is a copy of - * the containing directory's default ACL. - */ - if (S_ISDIR(vp->i_mode)) - xfs_acl_set_attr(vp, pdaclp, _ACL_TYPE_DEFAULT, &error); - if (!error && !basicperms) - xfs_acl_set_attr(vp, cacl, _ACL_TYPE_ACCESS, &error); -out_error: - _ACL_FREE(cacl); - return error; -} - -/* - * Set up the correct mode on the file based on the supplied ACL. This - * makes sure that the mode on the file reflects the state of the - * u::,g::[m::], and o:: entries in the ACL. Since the mode is where - * the ACL is going to get the permissions for these entries, we must - * synchronize the mode whenever we set the ACL on a file. - */ -STATIC int -xfs_acl_setmode( - struct inode *vp, - xfs_acl_t *acl, - int *basicperms) -{ - struct iattr iattr; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - int i, nomask = 1; - - *basicperms = 1; - - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) - return 0; - - /* - * Copy the u::, g::, o::, and m:: bits from the ACL into the - * mode. The m:: bits take precedence over the g:: bits. - */ - iattr.ia_valid = ATTR_MODE; - iattr.ia_mode = XFS_I(vp)->i_d.di_mode; - iattr.ia_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); - ap = acl->acl_entry; - for (i = 0; i < acl->acl_cnt; ++i) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - iattr.ia_mode |= ap->ae_perm << 6; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: /* more than just standard modes */ - nomask = 0; - iattr.ia_mode |= ap->ae_perm << 3; - *basicperms = 0; - break; - case ACL_OTHER: - iattr.ia_mode |= ap->ae_perm; - break; - default: /* more than just standard modes */ - *basicperms = 0; - break; - } - ap++; - } - - /* Set the group bits from ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - iattr.ia_mode |= gap->ae_perm << 3; - - return xfs_setattr(XFS_I(vp), &iattr, 0); -} - -/* - * The permissions for the special ACL entries (u::, g::[m::], o::) are - * actually stored in the file mode (if there is both a group and a mask, - * the group is stored in the ACL entry and the mask is stored on the file). - * This allows the mode to remain automatically in sync with the ACL without - * the need for a call-back to the ACL system at every point where the mode - * could change. This function takes the permissions from the specified mode - * and places it in the supplied ACL. - * - * This implementation draws its validity from the fact that, when the ACL - * was assigned, the mode was copied from the ACL. - * If the mode did not change, therefore, the mode remains exactly what was - * taken from the special ACL entries at assignment. - * If a subsequent chmod() was done, the POSIX spec says that the change in - * mode must cause an update to the ACL seen at user level and used for - * access checks. Before and after a mode change, therefore, the file mode - * most accurately reflects what the special ACL entries should permit/deny. - * - * CAVEAT: If someone sets the SGI_ACL_FILE attribute directly, - * the existing mode bits will override whatever is in the - * ACL. Similarly, if there is a pre-existing ACL that was - * never in sync with its mode (owing to a bug in 6.5 and - * before), it will now magically (or mystically) be - * synchronized. This could cause slight astonishment, but - * it is better than inconsistent permissions. - * - * The supplied ACL is a template that may contain any combination - * of special entries. These are treated as place holders when we fill - * out the ACL. This routine does not add or remove special entries, it - * simply unites each special entry with its associated set of permissions. - */ -STATIC void -xfs_acl_sync_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be set instead of the GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm = (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm = (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm = mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm = (mode >> 3) & 0x7; -} - -/* - * When inheriting an Access ACL from a directory Default ACL, - * the ACL bits are set to the intersection of the ACL default - * permission bits and the file permission bits in mode. If there - * are no permission bits on the file then we must not give them - * the ACL. This is what what makes umask() work with ACLs. - */ -STATIC void -xfs_acl_filter_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be merged with GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm &= (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm &= (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm &= mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm &= (mode >> 3) & 0x7; -} Index: xfs/fs/xfs/xfs_acl.h =================================================================== --- xfs.orig/fs/xfs/xfs_acl.h 2009-02-24 15:23:49.610494878 +0100 +++ xfs/fs/xfs/xfs_acl.h 2009-02-25 14:58:48.522044509 +0100 @@ -18,81 +18,48 @@ #ifndef __XFS_ACL_H__ #define __XFS_ACL_H__ -/* - * Access Control Lists - */ -typedef __uint16_t xfs_acl_perm_t; -typedef __int32_t xfs_acl_tag_t; -typedef __int32_t xfs_acl_id_t; +struct inode; +struct posix_acl; +struct xfs_inode; #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) -typedef struct xfs_acl_entry { - xfs_acl_tag_t ae_tag; - xfs_acl_id_t ae_id; - xfs_acl_perm_t ae_perm; -} xfs_acl_entry_t; - -typedef struct xfs_acl { - __int32_t acl_cnt; - xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; -} xfs_acl_t; +/* On-disk XFS access control list structure */ +struct xfs_acl { + __be32 acl_cnt; + struct xfs_acl_entry { + __be32 ae_tag; + __be32 ae_id; + __be16 ae_perm; + } acl_entry[XFS_ACL_MAX_ENTRIES]; +}; /* On-disk XFS extended attribute names */ -#define SGI_ACL_FILE "SGI_ACL_FILE" -#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" +#define SGI_ACL_FILE "SGI_ACL_FILE" +#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" #define SGI_ACL_FILE_SIZE (sizeof(SGI_ACL_FILE)-1) #define SGI_ACL_DEFAULT_SIZE (sizeof(SGI_ACL_DEFAULT)-1) -#define _ACL_TYPE_ACCESS 1 -#define _ACL_TYPE_DEFAULT 2 - #ifdef CONFIG_XFS_POSIX_ACL +extern int xfs_check_acl(struct inode *inode, int mask); +extern struct posix_acl *xfs_get_acl(struct inode *inode, int type); +extern int xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl); +extern int xfs_acl_chmod(struct inode *inode); +extern void xfs_inode_init_acls(struct xfs_inode *ip); +extern void xfs_inode_clear_acls(struct xfs_inode *ip); +extern int posix_acl_access_exists(struct inode *inode); +extern int posix_acl_default_exists(struct inode *inode); -struct vattr; -struct xfs_inode; - -extern struct kmem_zone *xfs_acl_zone; -#define xfs_acl_zone_init(zone, name) \ - (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) -#define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) - -extern int xfs_acl_inherit(struct inode *, mode_t mode, xfs_acl_t *); -extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); -extern int xfs_acl_vtoacl(struct inode *, xfs_acl_t *, xfs_acl_t *); -extern int xfs_acl_vhasacl_access(struct inode *); -extern int xfs_acl_vhasacl_default(struct inode *); -extern int xfs_acl_vset(struct inode *, void *, size_t, int); -extern int xfs_acl_vget(struct inode *, void *, size_t, int); -extern int xfs_acl_vremove(struct inode *, int); - -#define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) - -#define _ACL_INHERIT(c,m,d) (xfs_acl_inherit(c,m,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) -#define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access -#define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default - -#define _ACL_ALLOC(a) ((a) = kmem_zone_alloc(xfs_acl_zone, KM_SLEEP)) -#define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) - +extern struct xattr_handler xfs_xattr_system_handler; #else -#define xfs_acl_zone_init(zone,name) -#define xfs_acl_zone_destroy(zone) -#define xfs_acl_vset(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vget(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vremove(v,t) (-EOPNOTSUPP) -#define xfs_acl_vhasacl_access(v) (0) -#define xfs_acl_vhasacl_default(v) (0) -#define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ -#define _ACL_FREE(a) ((void)0) -#define _ACL_INHERIT(c,m,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) -#define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) -#define _ACL_DEFAULT_EXISTS (NULL) -#endif - +# define xfs_check_acl NULL +# define xfs_get_acl(inode, type) NULL +# define xfs_inherit_acl(inode, default_acl) 0 +# define xfs_acl_chmod(inode) 0 +# define xfs_inode_init_acls(ip) +# define xfs_inode_clear_acls(ip) +# define posix_acl_access_exists(inode) 0 +# define posix_acl_default_exists(inode) 0 +#endif /* CONFIG_XFS_POSIX_ACL */ #endif /* __XFS_ACL_H__ */ Index: xfs/fs/xfs/xfs_iget.c =================================================================== --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 20:56:46.089031360 +0100 +++ xfs/fs/xfs/xfs_iget.c 2009-02-25 21:07:07.323794484 +0100 @@ -18,6 +18,7 @@ #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" +#include "xfs_acl.h" #include "xfs_bit.h" #include "xfs_log.h" #include "xfs_inum.h" @@ -91,6 +92,7 @@ xfs_inode_alloc( memset(&ip->i_d, 0, sizeof(xfs_icdinode_t)); ip->i_size = 0; ip->i_new_size = 0; + xfs_inode_init_acls(ip); /* * Initialize inode's trace buffers. @@ -554,6 +556,7 @@ xfs_ireclaim( ASSERT(atomic_read(&ip->i_pincount) == 0); ASSERT(!spin_is_locked(&ip->i_flags_lock)); ASSERT(completion_done(&ip->i_flush)); + xfs_inode_clear_acls(ip); kmem_zone_free(xfs_inode_zone, ip); } Index: xfs/fs/xfs/xfs_inode.c =================================================================== --- xfs.orig/fs/xfs/xfs_inode.c 2009-02-24 15:23:49.618495059 +0100 +++ xfs/fs/xfs/xfs_inode.c 2009-02-25 20:19:38.965670279 +0100 @@ -49,7 +49,6 @@ #include "xfs_utils.h" #include "xfs_dir2_trace.h" #include "xfs_quota.h" -#include "xfs_acl.h" #include "xfs_filestream.h" #include "xfs_vnodeops.h" Index: xfs/fs/xfs/xfs_arch.h =================================================================== --- xfs.orig/fs/xfs/xfs_arch.h 2009-02-24 15:23:49.624495124 +0100 +++ xfs/fs/xfs/xfs_arch.h 2009-02-25 14:58:48.527043889 +0100 @@ -73,28 +73,6 @@ static inline void be64_add_cpu(__be64 * #endif /* __KERNEL__ */ -/* do we need conversion? */ -#define ARCH_NOCONVERT 1 -#ifdef XFS_NATIVE_HOST -# define ARCH_CONVERT ARCH_NOCONVERT -#else -# define ARCH_CONVERT 0 -#endif - -/* generic swapping macros */ - -#ifndef HAVE_SWABMACROS -#define INT_SWAP16(type,var) ((typeof(type))(__swab16((__u16)(var)))) -#define INT_SWAP32(type,var) ((typeof(type))(__swab32((__u32)(var)))) -#define INT_SWAP64(type,var) ((typeof(type))(__swab64((__u64)(var)))) -#endif - -#define INT_SWAP(type, var) \ - ((sizeof(type) == 8) ? INT_SWAP64(type,var) : \ - ((sizeof(type) == 4) ? INT_SWAP32(type,var) : \ - ((sizeof(type) == 2) ? INT_SWAP16(type,var) : \ - (var)))) - /* * get and set integers from potentially unaligned locations */ @@ -107,16 +85,6 @@ static inline void be64_add_cpu(__be64 * ((__u8*)(pointer))[1] = (((value) ) & 0xff); \ } -/* does not return a value */ -#define INT_SET(reference,arch,valueref) \ - (__builtin_constant_p(valueref) ? \ - (void)( (reference) = ( ((arch) != ARCH_NOCONVERT) ? (INT_SWAP((reference),(valueref))) : (valueref)) ) : \ - (void)( \ - ((reference) = (valueref)), \ - ( ((arch) != ARCH_NOCONVERT) ? (reference) = INT_SWAP((reference),(reference)) : 0 ) \ - ) \ - ) - /* * In directories inode numbers are stored as unaligned arrays of unsigned * 8bit integers on disk. From SRS0+1e5fa176003345526f53+2019+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 4 11:33:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24HXLhp098342 for ; Wed, 4 Mar 2009 11:33:22 -0600 X-ASG-Debug-ID: 1236187975-672c026e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7D43316F5AF for ; Wed, 4 Mar 2009 09:32:55 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id yKHJzt2hr49MBjf3 for ; Wed, 04 Mar 2009 09:32:55 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LeuxE-0000Yo-FD for xfs@oss.sgi.com; Wed, 04 Mar 2009 17:32:24 +0000 Date: Wed, 4 Mar 2009 12:32:24 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfsprogs: add projects(5) and projid(5) manpages Subject: Re: [PATCH] xfsprogs: add projects(5) and projid(5) manpages Message-ID: <20090304173224.GB32471@infradead.org> References: <20090224132737.GA8161@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224132737.GA8161@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236187975 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Feb 24, 2009 at 08:27:37AM -0500, Christoph Hellwig wrote: > Document the /etc/projects and /etc/projid files in their own manpages > instead of in xfs_quota(8). Doh, I forgot to quilt add projects.5, here's the complete patch: Index: xfsprogs-dev/man/man5/projid.5 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs-dev/man/man5/projid.5 2009-03-04 18:30:40.451978384 +0100 @@ -0,0 +1,29 @@ +.TH projid 5 +.SH NAME +projid \- the project name mapping file +.SH DESCRIPTION +The +.I /etc/projid +file provides a mapping between numeric project identifiers and a +simple human readable name (similar relationship to the one that +exists between usernames and uids). +Its format is simply: +.nf +.sp +.in +5 +# comments are hash-prefixed +# ... +cage:10 +logfiles:42 + +.in -5 +.fi +.PP + +This file is optional, if a project identifier cannot be mapped to +a name, it will be parsed and displayed as a numeric value. + +.SH SEE ALSO +.BR xfs_quota (8), +.BR xfsctl (3), +.BR projects (5). Index: xfsprogs-dev/man/man8/xfs_quota.8 =================================================================== --- xfsprogs-dev.orig/man/man8/xfs_quota.8 2009-03-03 16:45:43.355881326 +0100 +++ xfsprogs-dev/man/man8/xfs_quota.8 2009-03-04 18:30:40.452978791 +0100 @@ -628,46 +628,6 @@ for .I /etc/projects to exist. Note that if projects file exists then it is also used. -.SH FILE FORMATS -There are two files involved with the tree quota mechanism, namely -.I /etc/projects -and -.IR /etc/projid . -The latter is optional. -The -.I /etc/projects -file provides a mapping between numeric project identifiers and those -directories which are the roots of the quota tree. -Its format is simply: -.nf -.sp -.in +5 -# comments are hash-prefixed -# ... -10:/export/cage -42:/var/log -.in -5 -.fi -.PP -The -.I /etc/projid -file provides a mapping between numeric project identifiers and a -simple human readable name (similar relationship to the one that -exists between usernames and uids). -Its format is simply: -.nf -.sp -.in +5 -# comments are hash-prefixed -# ... -cage:10 -logfiles:42 -.in -5 -.fi -.PP -This file is optional, if a project identifier cannot be mapped to -a name, it will be displayed as a number only. -.PP .SH EXAMPLES Enabling quota enforcement on an XFS filesystem (restrict a user to a set amount of space). @@ -752,4 +712,6 @@ Mapping of numeric project identifiers t .SH SEE ALSO .BR df (1), .BR mount (1), -.BR sync (2). +.BR sync (2), +.BR projid (5), +.BR projects (5). Index: xfsprogs-dev/man/man5/projects.5 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs-dev/man/man5/projects.5 2009-03-04 18:31:01.456981579 +0100 @@ -0,0 +1,31 @@ +.TH projects 5 +.SH NAME +projects \- persistent project root defintion +.SH DESCRIPTION +The +.I /etc/projects +file provides a mapping between numeric project identifiers and those directories +which are the roots of the quota tree. Its format is simply: + +.nf +.sp +.in +5 +# comments are hash-prefixed +# ... +10:/export/cage +42:/var/log +.in -5 +.fi +.PP +The +.I /etc/projects +file is optional, instead +.BR xfs_quota (8) +can be used with the +.B \-p +argument to specify a project root directly for each operation. + +.SH SEE ALSO +.BR xfs_quota (8), +.BR xfsctl (3), +.BR projid (5). From malcolm.parsons@gmail.com Wed Mar 4 16:35:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24MZcGl108258 for ; Wed, 4 Mar 2009 16:35:39 -0600 X-ASG-Debug-ID: 1236206111-470a036b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp803.mail.ird.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id A18DD170C03 for ; Wed, 4 Mar 2009 14:35:12 -0800 (PST) Received: from smtp803.mail.ird.yahoo.com (smtp803.mail.ird.yahoo.com [217.146.188.63]) by cuda.sgi.com with SMTP id uXqnxV9K3nwhGUGi for ; Wed, 04 Mar 2009 14:35:12 -0800 (PST) Received: (qmail 39510 invoked from network); 4 Mar 2009 22:35:11 -0000 Received: from unknown (HELO trillian) (malcolm.parsons@217.44.130.225 with login) by smtp803.mail.ird.yahoo.com with SMTP; 4 Mar 2009 22:35:11 -0000 X-YMail-OSG: y7a2osEVM1ner_XRWIhNm4ea8jT.d12Ass8l6s34dUCRTOiTQ67XGzvAS7moDwSy101macAIctr7ZrEpOmFQnnBHwU6UUiRI.QtTsvd5kB5fJtpGAAai.6QDhGvR9NYuCVOeO3M1SJzf09SkHeqYZoes X-Yahoo-Newman-Property: ymail-3 Received: by trillian (Postfix, from userid 1000) id B9CB012C72F; Wed, 4 Mar 2009 22:35:09 +0000 (GMT) From: Malcolm Parsons To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] Fix various typos in XFS Subject: [PATCH] Fix various typos in XFS Date: Wed, 4 Mar 2009 22:35:08 +0000 Message-Id: <1236206109-13655-1-git-send-email-malcolm.parsons@gmail.com> X-Mailer: git-send-email 1.5.6.3 X-Barracuda-Connect: smtp803.mail.ird.yahoo.com[217.146.188.63] X-Barracuda-Start-Time: 1236206112 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19453 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From malcolm.parsons@gmail.com Wed Mar 4 16:35:41 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n24MZeEv108266 for ; Wed, 4 Mar 2009 16:35:41 -0600 X-ASG-Debug-ID: 1236206112-429103d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp802.mail.ird.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id CE5CD170C03 for ; Wed, 4 Mar 2009 14:35:12 -0800 (PST) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by cuda.sgi.com with SMTP id 6acgGB1fZHzNpb2B for ; Wed, 04 Mar 2009 14:35:12 -0800 (PST) Received: (qmail 8651 invoked from network); 4 Mar 2009 22:35:12 -0000 Received: from unknown (HELO trillian) (malcolm.parsons@217.44.130.225 with login) by smtp802.mail.ird.yahoo.com with SMTP; 4 Mar 2009 22:35:11 -0000 X-Yahoo-Newman-Property: ymail-3 Received: by trillian (Postfix, from userid 1000) id D894812B773; Wed, 4 Mar 2009 22:35:09 +0000 (GMT) From: Malcolm Parsons To: xfs@oss.sgi.com Cc: Malcolm Parsons X-ASG-Orig-Subj: [PATCH] Fix various typos in xfs. Subject: [PATCH] Fix various typos in xfs. Date: Wed, 4 Mar 2009 22:35:09 +0000 Message-Id: <1236206109-13655-2-git-send-email-malcolm.parsons@gmail.com> X-Mailer: git-send-email 1.5.6.3 In-Reply-To: <1236206109-13655-1-git-send-email-malcolm.parsons@gmail.com> References: <1236206109-13655-1-git-send-email-malcolm.parsons@gmail.com> X-Barracuda-Connect: smtp802.mail.ird.yahoo.com[217.146.188.62] X-Barracuda-Start-Time: 1236206113 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19453 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Signed-off-by: Malcolm Parsons --- fs/xfs/xfs_bmap.c | 6 +++--- fs/xfs/xfs_bmap.h | 2 +- fs/xfs/xfs_btree.c | 4 ++-- fs/xfs/xfs_btree.h | 2 +- fs/xfs/xfs_da_btree.h | 2 +- fs/xfs/xfs_dir2_data.h | 2 +- fs/xfs/xfs_dir2_node.c | 2 +- fs/xfs/xfs_fsops.c | 2 +- fs/xfs/xfs_ialloc.c | 2 +- fs/xfs/xfs_ialloc_btree.c | 2 +- fs/xfs/xfs_inode.h | 2 +- fs/xfs/xfs_iomap.h | 2 +- fs/xfs/xfs_itable.c | 2 +- fs/xfs/xfs_log.c | 10 +++++----- fs/xfs/xfs_mount.c | 8 ++++---- fs/xfs/xfs_mount.h | 4 ++-- fs/xfs/xfs_rtalloc.h | 4 ++-- fs/xfs/xfs_trans.h | 12 ++++++------ fs/xfs/xfs_trans_ail.c | 4 ++-- fs/xfs/xfs_trans_item.c | 2 +- fs/xfs/xfs_utils.c | 2 +- fs/xfs/xfs_vnodeops.c | 2 +- 22 files changed, 40 insertions(+), 40 deletions(-) diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c index c852cd6..138d1b5 100644 --- a/fs/xfs/xfs_bmap.c +++ b/fs/xfs/xfs_bmap.c @@ -2479,7 +2479,7 @@ xfs_bmap_adjacent( fb_agno = nullfb ? NULLAGNUMBER : XFS_FSB_TO_AGNO(mp, ap->firstblock); /* * If allocating at eof, and there's a previous real block, - * try to use it's last block as our starting point. + * try to use its last block as our starting point. */ if (ap->eof && ap->prevp->br_startoff != NULLFILEOFF && !isnullstartblock(ap->prevp->br_startblock) && @@ -4804,7 +4804,7 @@ xfs_bmapi( xfs_extlen_t minlen; /* min allocation size */ xfs_mount_t *mp; /* xfs mount structure */ int n; /* current extent index */ - int nallocs; /* number of extents alloc\'d */ + int nallocs; /* number of extents alloc'd */ xfs_extnum_t nextents; /* number of extents in file */ xfs_fileoff_t obno; /* old block number (offset) */ xfs_bmbt_irec_t prev; /* previous file extent record */ @@ -6494,7 +6494,7 @@ xfs_bmap_count_tree( block = XFS_BUF_TO_BLOCK(bp); if (--level) { - /* Not at node above leafs, count this level of nodes */ + /* Not at node above leaves, count this level of nodes */ nextbno = be64_to_cpu(block->bb_u.l.bb_rightsib); while (nextbno != NULLFSBLOCK) { if ((error = xfs_btree_read_bufl(mp, tp, nextbno, diff --git a/fs/xfs/xfs_bmap.h b/fs/xfs/xfs_bmap.h index be2979d..589d3da 100644 --- a/fs/xfs/xfs_bmap.h +++ b/fs/xfs/xfs_bmap.h @@ -125,7 +125,7 @@ typedef struct xfs_bmalloca { struct xfs_bmbt_irec *gotp; /* extent after, or delayed */ xfs_extlen_t alen; /* i/o length asked/allocated */ xfs_extlen_t total; /* total blocks needed for xaction */ - xfs_extlen_t minlen; /* mininum allocation size (blocks) */ + xfs_extlen_t minlen; /* minimum allocation size (blocks) */ xfs_extlen_t minleft; /* amount must be left after alloc */ char eof; /* set if allocating past last extent */ char wasdel; /* replacing a delayed allocation */ diff --git a/fs/xfs/xfs_btree.c b/fs/xfs/xfs_btree.c index e73c332..e9df995 100644 --- a/fs/xfs/xfs_btree.c +++ b/fs/xfs/xfs_btree.c @@ -1883,7 +1883,7 @@ xfs_btree_lshift( /* * We add one entry to the left side and remove one for the right side. - * Accout for it here, the changes will be updated on disk and logged + * Account for it here, the changes will be updated on disk and logged * later. */ lrecs++; @@ -3535,7 +3535,7 @@ xfs_btree_delrec( XFS_BTREE_STATS_INC(cur, join); /* - * Fix up the the number of records and right block pointer in the + * Fix up the number of records and right block pointer in the * surviving block, and log it. */ xfs_btree_set_numrecs(left, lrecs + rrecs); diff --git a/fs/xfs/xfs_btree.h b/fs/xfs/xfs_btree.h index 789fffd..4f852b7 100644 --- a/fs/xfs/xfs_btree.h +++ b/fs/xfs/xfs_btree.h @@ -41,7 +41,7 @@ extern kmem_zone_t *xfs_btree_cur_zone; /* * Generic btree header. * - * This is a comination of the actual format used on disk for short and long + * This is a combination of the actual format used on disk for short and long * format btrees. The first three fields are shared by both format, but * the pointers are different and should be used with care. * diff --git a/fs/xfs/xfs_da_btree.h b/fs/xfs/xfs_da_btree.h index 9d5a7e8..fd63f3c 100644 --- a/fs/xfs/xfs_da_btree.h +++ b/fs/xfs/xfs_da_btree.h @@ -185,7 +185,7 @@ typedef struct xfs_da_state { unsigned char inleaf; /* insert into 1->lf, 0->splf */ unsigned char extravalid; /* T/F: extrablk is in use */ unsigned char extraafter; /* T/F: extrablk is after new */ - xfs_da_state_blk_t extrablk; /* for double-splits on leafs */ + xfs_da_state_blk_t extrablk; /* for double-splits on leaves */ /* for dirv2 extrablk is data */ } xfs_da_state_t; diff --git a/fs/xfs/xfs_dir2_data.h b/fs/xfs/xfs_dir2_data.h index b816e02..efbc290 100644 --- a/fs/xfs/xfs_dir2_data.h +++ b/fs/xfs/xfs_dir2_data.h @@ -38,7 +38,7 @@ struct xfs_trans; /* * Directory address space divided into sections, - * spaces separated by 32gb. + * spaces separated by 32GB. */ #define XFS_DIR2_SPACE_SIZE (1ULL << (32 + XFS_DIR2_DATA_ALIGN_LOG)) #define XFS_DIR2_DATA_SPACE 0 diff --git a/fs/xfs/xfs_dir2_node.c b/fs/xfs/xfs_dir2_node.c index fa6c3a5..5a81ccd 100644 --- a/fs/xfs/xfs_dir2_node.c +++ b/fs/xfs/xfs_dir2_node.c @@ -1104,7 +1104,7 @@ xfs_dir2_leafn_remove( } xfs_dir2_leafn_check(dp, bp); /* - * Return indication of whether this leaf block is emtpy enough + * Return indication of whether this leaf block is empty enough * to justify trying to join it with a neighbor. */ *rval = diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 680d0e0..8379e3b 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -576,7 +576,7 @@ out: if (fdblks_delta) { /* * If we are putting blocks back here, m_resblks_avail is - * already at it's max so this will put it in the free pool. + * already at its max so this will put it in the free pool. * * If we need space, we'll either succeed in getting it * from the free block count or we'll get an enospc. If diff --git a/fs/xfs/xfs_ialloc.c b/fs/xfs/xfs_ialloc.c index 62d1cea..3120a3a 100644 --- a/fs/xfs/xfs_ialloc.c +++ b/fs/xfs/xfs_ialloc.c @@ -349,7 +349,7 @@ xfs_ialloc_ag_alloc( * Initialize all inodes in this buffer and then log them. * * XXX: It would be much better if we had just one transaction to - * log a whole cluster of inodes instead of all the indivdual + * log a whole cluster of inodes instead of all the individual * transactions causing a lot of log traffic. */ xfs_biozero(fbuf, 0, ninodes << args.mp->m_sb.sb_inodelog); diff --git a/fs/xfs/xfs_ialloc_btree.c b/fs/xfs/xfs_ialloc_btree.c index 99f2408..c282a9a 100644 --- a/fs/xfs/xfs_ialloc_btree.c +++ b/fs/xfs/xfs_ialloc_btree.c @@ -164,7 +164,7 @@ xfs_inobt_init_rec_from_cur( } /* - * intial value of ptr for lookup + * initial value of ptr for lookup */ STATIC void xfs_inobt_init_ptr_from_cur( diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h index 1f175fa..f879c1b 100644 --- a/fs/xfs/xfs_inode.h +++ b/fs/xfs/xfs_inode.h @@ -122,7 +122,7 @@ typedef struct xfs_ictimestamp { /* * NOTE: This structure must be kept identical to struct xfs_dinode - * in xfs_dinode.h except for the endianess annotations. + * in xfs_dinode.h except for the endianness annotations. */ typedef struct xfs_icdinode { __uint16_t di_magic; /* inode magic # = XFS_DINODE_MAGIC */ diff --git a/fs/xfs/xfs_iomap.h b/fs/xfs/xfs_iomap.h index ee1a0c1..a1cc132 100644 --- a/fs/xfs/xfs_iomap.h +++ b/fs/xfs/xfs_iomap.h @@ -63,7 +63,7 @@ typedef enum { */ typedef struct xfs_iomap { - xfs_daddr_t iomap_bn; /* first 512b blk of mapping */ + xfs_daddr_t iomap_bn; /* first 512B blk of mapping */ xfs_buftarg_t *iomap_target; xfs_off_t iomap_offset; /* offset of mapping, bytes */ xfs_off_t iomap_bsize; /* size of mapping, bytes */ diff --git a/fs/xfs/xfs_itable.c b/fs/xfs/xfs_itable.c index cf98a80..808799d 100644 --- a/fs/xfs/xfs_itable.c +++ b/fs/xfs/xfs_itable.c @@ -579,7 +579,7 @@ xfs_bulkstat( * first inode of the cluster. * * Careful with clustidx. There can be - * multple clusters per chunk, a single + * multiple clusters per chunk, a single * cluster per chunk or a cluster that has * inodes represented from several different * chunks (if blocksize is large). diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index c8f3008..2f1b518 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -1111,7 +1111,7 @@ xlog_bdstrat_cb(struct xfs_buf *bp) /* * Return size of each in-core log record buffer. * - * All machines get 8 x 32KB buffers by default, unless tuned otherwise. + * All machines get 8 x 32kB buffers by default, unless tuned otherwise. * * If the filesystem blocksize is too large, we may need to choose a * larger size since the directory code currently logs entire blocks. @@ -1141,8 +1141,8 @@ xlog_get_iclog_buffer_size(xfs_mount_t *mp, } if (xfs_sb_version_haslogv2(&mp->m_sb)) { - /* # headers = size / 32K - * one header holds cycles from 32K of data + /* # headers = size / 32k + * one header holds cycles from 32k of data */ xhdrs = mp->m_logbsize / XLOG_HEADER_CYCLE_SIZE; @@ -1158,7 +1158,7 @@ xlog_get_iclog_buffer_size(xfs_mount_t *mp, goto done; } - /* All machines use 32KB buffers by default. */ + /* All machines use 32kB buffers by default. */ log->l_iclog_size = XLOG_BIG_RECORD_BSIZE; log->l_iclog_size_log = XLOG_BIG_RECORD_BSHIFT; @@ -3192,7 +3192,7 @@ xlog_state_want_sync(xlog_t *log, xlog_in_core_t *iclog) */ /* - * Free a used ticket when it's refcount falls to zero. + * Free a used ticket when its refcount falls to zero. */ void xfs_log_ticket_put( diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 664961e..b31a520 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -645,7 +645,7 @@ xfs_initialize_perag_data(xfs_mount_t *mp, xfs_agnumber_t agcount) for (index = 0; index < agcount; index++) { /* * read the agf, then the agi. This gets us - * all the inforamtion we need and populates the + * all the information we need and populates the * per-ag structures for us. */ error = xfs_alloc_pagf_init(mp, NULL, index, 0); @@ -1226,7 +1226,7 @@ xfs_unmountfs( /* * We can potentially deadlock here if we have an inode cluster - * that has been freed has it's buffer still pinned in memory because + * that has been freed has its buffer still pinned in memory because * the transaction is still sitting in a iclog. The stale inodes * on that buffer will have their flush locks held until the * transaction hits the disk and the callbacks run. the inode @@ -1258,7 +1258,7 @@ xfs_unmountfs( * Unreserve any blocks we have so that when we unmount we don't account * the reserved free space as used. This is really only necessary for * lazy superblock counting because it trusts the incore superblock - * counters to be aboslutely correct on clean unmount. + * counters to be absolutely correct on clean unmount. * * We don't bother correcting this elsewhere for lazy superblock * counting because on mount of an unclean filesystem we reconstruct the @@ -1860,7 +1860,7 @@ xfs_mount_log_sb( * we disable the per-cpu counter and go through the slow path. * * The slow path is the current xfs_mod_incore_sb() function. This means that - * when we disable a per-cpu counter, we need to drain it's resources back to + * when we disable a per-cpu counter, we need to drain its resources back to * the global superblock. We do this after disabling the counter to prevent * more threads from queueing up on the counter. * diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 1438dd4..0ceecb2 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -385,8 +385,8 @@ typedef struct xfs_mount { * Synchronous read and write sizes. This should be * better for NFSv2 wsync filesystems. */ -#define XFS_WSYNC_READIO_LOG 15 /* 32K */ -#define XFS_WSYNC_WRITEIO_LOG 14 /* 16K */ +#define XFS_WSYNC_READIO_LOG 15 /* 32k */ +#define XFS_WSYNC_WRITEIO_LOG 14 /* 16k */ /* * Allow large block sizes to be reported to userspace programs if the diff --git a/fs/xfs/xfs_rtalloc.h b/fs/xfs/xfs_rtalloc.h index 3bac681..b2d67ad 100644 --- a/fs/xfs/xfs_rtalloc.h +++ b/fs/xfs/xfs_rtalloc.h @@ -23,8 +23,8 @@ struct xfs_trans; /* Min and max rt extent sizes, specified in bytes */ #define XFS_MAX_RTEXTSIZE (1024 * 1024 * 1024) /* 1GB */ -#define XFS_DFL_RTEXTSIZE (64 * 1024) /* 64KB */ -#define XFS_MIN_RTEXTSIZE (4 * 1024) /* 4KB */ +#define XFS_DFL_RTEXTSIZE (64 * 1024) /* 64kB */ +#define XFS_MIN_RTEXTSIZE (4 * 1024) /* 4kB */ /* * Constants for bit manipulations. diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 166f728..775249a 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -292,7 +292,7 @@ xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) * In a write transaction we can allocate a maximum of 2 * extents. This gives: * the inode getting the new extents: inode size - * the inode\'s bmap btree: max depth * block size + * the inode's bmap btree: max depth * block size * the agfs of the ags from which the extents are allocated: 2 * sector * the superblock free block counter: sector size * the allocation btrees: 2 exts * 2 trees * (2 * max depth - 1) * block size @@ -321,7 +321,7 @@ xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) /* * In truncating a file we free up to two extents at once. We can modify: * the inode being truncated: inode size - * the inode\'s bmap btree: (max depth + 1) * block size + * the inode's bmap btree: (max depth + 1) * block size * And the bmap_finish transaction can free the blocks and bmap blocks: * the agf for each of the ags: 4 * sector size * the agfl for each of the ags: 4 * sector size @@ -431,8 +431,8 @@ xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) * the new inode: inode size * the inode btree entry: 1 block * the directory btree: (max depth + v2) * dir block size - * the directory inode\'s bmap btree: (max depth + v2) * block size - * the blocks for the symlink: 1 KB + * the directory inode's bmap btree: (max depth + v2) * block size + * the blocks for the symlink: 1 kB * Or in the first xact we allocate some inodes giving: * the agi and agf of the ag getting the new inodes: 2 * sectorsize * the inode blocks allocated: XFS_IALLOC_BLOCKS * blocksize @@ -463,7 +463,7 @@ xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) * the inode btree entry: block size * the superblock for the nlink flag: sector size * the directory btree: (max depth + v2) * dir block size - * the directory inode\'s bmap btree: (max depth + v2) * block size + * the directory inode's bmap btree: (max depth + v2) * block size * Or in the first xact we allocate some inodes giving: * the agi and agf of the ag getting the new inodes: 2 * sectorsize * the superblock for the nlink flag: sector size @@ -637,7 +637,7 @@ xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) /* * Removing the attribute fork of a file * the inode being truncated: inode size - * the inode\'s bmap btree: max depth * block size + * the inode's bmap btree: max depth * block size * And the bmap_finish transaction can free the blocks and bmap blocks: * the agf for each of the ags: 4 * sector size * the agfl for each of the ags: 4 * sector size diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index 2d47f10..f31271c 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -79,7 +79,7 @@ xfs_trans_ail_tail( * the push is run asynchronously in a separate thread, so we return the tail * of the log right now instead of the tail after the push. This means we will * either continue right away, or we will sleep waiting on the async thread to - * do it's work. + * do its work. * * We do this unlocked - we only need to know whether there is anything in the * AIL at the time we are called. We don't need to access the contents of @@ -160,7 +160,7 @@ xfs_trans_ail_cursor_next( /* * Now that the traversal is complete, we need to remove the cursor * from the list of traversing cursors. Avoid removing the embedded - * push cursor, but use the fact it is alway present to make the + * push cursor, but use the fact it is always present to make the * list deletion simple. */ void diff --git a/fs/xfs/xfs_trans_item.c b/fs/xfs/xfs_trans_item.c index e110bf5..eb3fc57 100644 --- a/fs/xfs/xfs_trans_item.c +++ b/fs/xfs/xfs_trans_item.c @@ -22,7 +22,7 @@ #include "xfs_inum.h" #include "xfs_trans.h" #include "xfs_trans_priv.h" -/* XXX: from here down needed until struct xfs_trans has it's own ailp */ +/* XXX: from here down needed until struct xfs_trans has its own ailp */ #include "xfs_bit.h" #include "xfs_buf_item.h" #include "xfs_sb.h" diff --git a/fs/xfs/xfs_utils.c b/fs/xfs/xfs_utils.c index fcc2285..79b9e5e 100644 --- a/fs/xfs/xfs_utils.c +++ b/fs/xfs/xfs_utils.c @@ -374,7 +374,7 @@ xfs_truncate_file( /* * Follow the normal truncate locking protocol. Since we - * hold the inode in the transaction, we know that it's number + * hold the inode in the transaction, we know that its number * of references will stay constant. */ xfs_ilock(ip, XFS_ILOCK_EXCL); diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c index 59de049..fa935ff 100644 --- a/fs/xfs/xfs_vnodeops.c +++ b/fs/xfs/xfs_vnodeops.c @@ -2862,7 +2862,7 @@ xfs_free_file_space( /* * Need to zero the stuff we're not freeing, on disk. - * If its a realtime file & can't use unwritten extents then we + * If it's a realtime file & can't use unwritten extents then we * actually need to zero the extent edges. Otherwise xfs_bunmapi * will take care of it for us. */ -- 1.5.6.3 From audio@pb-conferences.com Wed Mar 4 21:11:28 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n253BRgc118105 for ; Wed, 4 Mar 2009 21:11:28 -0600 X-ASG-Debug-ID: 1236222478-7903026d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from evempbp04.workforpbp.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8FE871717FC for ; Wed, 4 Mar 2009 19:07:58 -0800 (PST) Received: from evempbp04.workforpbp.com (evempbp04.workforpbp.com [208.89.23.69]) by cuda.sgi.com with ESMTP id 4Mqplo75DzwjZtse for ; Wed, 04 Mar 2009 19:07:58 -0800 (PST) Received: from PBP-04 (208.89.23.69) by evempbp04.workforpbp.com id hlt13g0ktask for ; Wed, 4 Mar 2009 21:08:06 -0500 (envelope-from ) Date: Wed, 04 Mar 2009 21:08:06 -0500 X-Mailer: PDSoft Smtp Control v4.0.390 X-Sender: audio@pb-conferences.com To: xfs@oss.sgi.com From: "audio@pb-conferences.com" X-ASG-Orig-Subj: Last Chance - Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference Subject: Last Chance - Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Barracuda-Connect: evempbp04.workforpbp.com[208.89.23.69] X-Barracuda-Start-Time: 1236222481 Message-Id: <20090305030758.8FE871717FC@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear David Chinner, Last chance. Just a reminder that there are only 5 days left to join us for this practical, 60-minute audio conference: "Handling Difficult Conversations: Keys to Stopping Bad Behavior" Wednesday, March 11, 2009 - 1:00-2:00 p.m. ET http://www.pb-conferences.com/8K/0/2/p29X9Fc/p1V4TXABi/p0e Managers do it all the time – avoid difficult conversations, hoping the problem will go away. If left unaddressed, these problems fester – causing bigger problems for you and your team. Join us for a 60-minute audio conference where you and your team will discover how to: ** Deliver criticism without creating confrontation and conflict ** Eliminate the fear of confronting employees ** Handle employees with bad attitudes ** Prevent a worker's negative emotions from spreading to others Back by popular demand, Larry Johnson is one of our highest rated presenters. He is recognized as a leading expert in reducing turnover, increasing productivity and boosting morale. ** Since 1986, Larry Johnson has been president of a successful international management development firm ** His clients include Harley-Davidson, the National Apartment Association, the Royal College of Nursing, Southwest Airlines, American Express, McDonald's Corporation, Federal Express, the U.S. Bureau of Land Management, and the American Health Care Association. ** Larry has written more than 50 articles on the topics of leadership, people management, customer service, and changing corporate culture. He is the co-author of Absolute Honesty: Building A Corporate Culture That Values Straight Talk and Rewards Integrity EARN HRCI Credit: This program has been approved for 1 recertification credit hour toward PHR and SPHR recertification through the Human Resource Certification Institute (HRCI). For more information about certification or recertification, please visit the HRCI homepage at www.hrci.org Hosted by Progressive Business Publications, the leader in fast-read actionable advice on workplace issues, the audio conference gives you the opportunity to add immediate, impact to your marketing efforts in a manner that is: FAST - No wasted time here. Get right to the heart of the matter in a 1-hour block designed to easily fit into your busy schedule. CONVENIENT - No airlines. No travel. No time out of the office. Listen from the comfort and convenience of your desk. EASY - A telephone is all the equipment you need. Just dial in, punch in your access code, and you're in. That's it. Follow along with the audio conference handouts provided in advance. ACTIONABLE - Our audio conferences provide money-saving tactics you can start using right when you hang up the phone. IDEAL FOR MULTIPLE LISTENERS - Use a speakerphone and as many people as you want can listen in - at no extra cost to you. Many professionals use these sessions as a cost-efficient, time-efficient means of training supervisors, managers, and staff and reinforcing key issues in a fresh new manner that they will remember and act on. AFFORDABLE - Priced at $199, it is a fraction of the cost of travel and attendance fees for other high-priced conferences or seminars. ** "Handling Difficult Conversations: Keys to Stopping Bad Behavior " ** ** Live, 60-Minute Audio Conference ** ** Wednesday, March 11, 2009 - 1:00-2:00 p.m. ET ** Register now for this exciting event by clicking the following link or calling 800-964-6033. http://www.pb-conferences.com/8K/0/2/p29X9Fc/p1V4TXABi/p0e We hope you'll join us. Sincerely, Progressive Business Audio Conferences 384 Technology Drive Malvern, PA 19355 P.S. As usual we offer a full refund if not satisfied from now until 7 days after the event. If you do not wish to receive further notices about this conference, or future conferences, please click here: http://www.pb-conferences.com/8K/3T/2/p29X9Fc/p1V4TXABi/p0e Please do not reply directly to this e-mail, as we are unable to process it. We sent this using a "send only" address. If registering by phone, please refer to your priority code: 51349 ContactID#: -1850744551 From michael.monnerie@is.it-management.at Thu Mar 5 00:45:43 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n256jg88127701 for ; Thu, 5 Mar 2009 00:45:43 -0600 X-ASG-Debug-ID: 1236235512-624503970000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A80AE17212C for ; Wed, 4 Mar 2009 22:45:12 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id 26QjUiMymsSCRIJR for ; Wed, 04 Mar 2009 22:45:12 -0800 (PST) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id C2E7743E5 for ; Thu, 5 Mar 2009 07:44:39 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id CED8D40017A for ; Thu, 5 Mar 2009 07:44:39 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and XEN Subject: Re: XFS and XEN Date: Thu, 5 Mar 2009 07:44:39 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.19-ZMI; KDE/4.1.3; x86_64; ; ) References: <200902170959.55077@zmi.at> <20090224163823.GA19811@infradead.org> <200902250740.43223@zmi.at> In-Reply-To: <200902250740.43223@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903050744.39283@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236235514 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0134 1.0000 -1.9338 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.83 X-Barracuda-Spam-Status: No, SCORE=-1.83 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19482 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mittwoch 25 Februar 2009 Michael Monnerie wrote: > Q: Which settings are best with virtualization like VMware, XEN, > qemu? > > The biggest problem is that those products seem to also virtualize > disk writes in a way that even barriers don't work anymore, which > means even a fsync is not reliable. Tests confirm that unplugging the > power from such a system even with RAID controller with battery > backed cache and hard disk cache turned off (which is save on a > normal host) you can destroy a database within the virtual machine > (client, domU whatever you call it). > > In qemu you can specify cache=off on the line specifying the virtual > disk. For others I have no information what to do. In as question 26 now http://xfs.org/index.php/XFS_FAQ mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From hannes@hanneseder.net Thu Mar 5 08:22:14 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n25EMD2v149667 for ; Thu, 5 Mar 2009 08:22:13 -0600 X-ASG-Debug-ID: 1236262905-1fb503430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f176.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69BDA1737EC for ; Thu, 5 Mar 2009 06:21:46 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by cuda.sgi.com with ESMTP id JOgzmdYULUCNyKWE for ; Thu, 05 Mar 2009 06:21:46 -0800 (PST) Received: by fxm24 with SMTP id 24so3291169fxm.20 for ; Thu, 05 Mar 2009 06:21:45 -0800 (PST) Received: by 10.103.178.17 with SMTP id f17mr573305mup.45.1236262905041; Thu, 05 Mar 2009 06:21:45 -0800 (PST) Received: from vmbox.hanneseder.net (fwbda1010.mmc.at [212.108.34.194]) by mx.google.com with ESMTPS id s11sm34695mue.17.2009.03.05.06.21.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Mar 2009 06:21:44 -0800 (PST) Received: by vmbox.hanneseder.net (sSMTP sendmail emulation); Thu, 05 Mar 2009 15:21:41 +0100 From: Hannes Eder Date: Thu, 05 Mar 2009 15:20:25 +0100 Message-ID: <20090305141912.22775.64010.stgit@f10box.hanneseder.net> User-Agent: StGit/0.14.3.348.gcb02.dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: [PATCH 3/3 v2] xfs: include header files for prototypes Subject: [PATCH 3/3 v2] xfs: include header files for prototypes To: Christoph Hellwig Cc: Felix Blyakher , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20090305133917.GC14854@lst.de> References: <20090304183136.525.13769.stgit@f10box.hanneseder.net> <20090304183418.525.22262.stgit@f10box.hanneseder.net> <20090305133917.GC14854@lst.de> X-Barracuda-Connect: mail-fx0-f176.google.com[209.85.220.176] X-Barracuda-Start-Time: 1236262907 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19505 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Fix this sparse warnings: fs/xfs/linux-2.6/xfs_ioctl.c:72:1: warning: symbol 'xfs_find_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:249:1: warning: symbol 'xfs_open_by_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:361:1: warning: symbol 'xfs_readlink_by_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:496:1: warning: symbol 'xfs_attrmulti_attr_get' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:525:1: warning: symbol 'xfs_attrmulti_attr_set' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:555:1: warning: symbol 'xfs_attrmulti_attr_remove' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:657:1: warning: symbol 'xfs_ioc_space' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:1340:1: warning: symbol 'xfs_file_ioctl' was not declared. Should it be static? fs/xfs/support/debug.c:65:1: warning: symbol 'xfs_fs_vcmn_err' was not declared. Should it be static? fs/xfs/support/debug.c:112:1: warning: symbol 'xfs_hex_dump' was not declared. Should it be static? Signed-off-by: Hannes Eder Acked-by: Christoph Hellwig --- On Thu, Mar 5, 2009 at 2:39 PM, Christoph Hellwig wrote: > looks good, except for a tiny nit-pick: I still treat this as a Acked-by: ... Ok? >> +++ b/fs/xfs/support/debug.c >> @@ -19,6 +19,7 @@ >> #include "debug.h" >> >> /* xfs_mount.h drags a lot of crap in, sorry.. */ >> +#include "xfs_error.h" >> #include "xfs_sb.h" >> #include "xfs_inum.h" >> #include "xfs_ag.h" > > as xfs_mount.h doesn't require xfs_error.h it should be included > above that comment. hm. but that way it is still included before xfs_mount.h. fs/xfs/linux-2.6/xfs_ioctl.c | 1 + fs/xfs/support/debug.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_ioctl.c b/fs/xfs/linux-2.6/xfs_ioctl.c index 6f04493..d0b4994 100644 --- a/fs/xfs/linux-2.6/xfs_ioctl.c +++ b/fs/xfs/linux-2.6/xfs_ioctl.c @@ -34,6 +34,7 @@ #include "xfs_dir2_sf.h" #include "xfs_dinode.h" #include "xfs_inode.h" +#include "xfs_ioctl.h" #include "xfs_btree.h" #include "xfs_ialloc.h" #include "xfs_rtalloc.h" diff --git a/fs/xfs/support/debug.c b/fs/xfs/support/debug.c index ae54829..930bb34 100644 --- a/fs/xfs/support/debug.c +++ b/fs/xfs/support/debug.c @@ -17,6 +17,7 @@ */ #include #include "debug.h" +#include "xfs_error.h" /* xfs_mount.h drags a lot of crap in, sorry.. */ #include "xfs_sb.h" From SRS0=0f+r=7E=gmx.net=klaus.strebel@srs.kundenserver.de Thu Mar 5 11:06:05 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n25H639e157813 for ; Thu, 5 Mar 2009 11:06:05 -0600 X-ASG-Debug-ID: 1236272737-64c6024a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from moutng.kundenserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CEB451749BD for ; Thu, 5 Mar 2009 09:05:37 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by cuda.sgi.com with ESMTP id EJLspVCwAGAHkmbQ for ; Thu, 05 Mar 2009 09:05:37 -0800 (PST) Received: from [172.25.16.129] (mailout.bct-technology.com [85.115.16.62]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MKv1o-1LfH0p2639-000E8C; Thu, 05 Mar 2009 18:05:36 +0100 Message-ID: <49B0065F.7000602@gmx.net> Date: Thu, 05 Mar 2009 18:05:35 +0100 From: Klaus Strebel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: XFS X-ASG-Orig-Subj: Re: Last Chance - Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference Subject: Re: Last Chance - Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference References: <20090305030758.8FE871717FC@cuda.sgi.com> In-Reply-To: <20090305030758.8FE871717FC@cuda.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1/j5awcAGIK/5Lu23CaLnszhW3M/vHmuStt6zk 8rh6KnqScaQuXO37Ew2VQE1iQ634q94mnQlqqmcVBcrrFjZ5Mi 0Vc/FC7SGBiK8DyP2nJSw== X-Barracuda-Connect: moutng.kundenserver.de[212.227.126.171] X-Barracuda-Start-Time: 1236272737 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4964 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19515 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean audio@pb-conferences.com schrieb: > Last chance. Just a reminder that there are only 5 days left to > join us for this practical, 60-minute audio conference: > > "Handling Difficult Conversations: Keys to Stopping Bad Behavior" > Wednesday, March 11, 2009 - 1:00-2:00 p.m. ET Hm, these guys seem the have some experiance with bad behaviour, if not not, they wouldn't spam mailing lists ;-). Cheers Klaus -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From SRS0+a217f167280a378e0582+2020+infradead.org+hch@bombadil.srs.infradead.org Thu Mar 5 15:29:51 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n25LTom8167813 for ; Thu, 5 Mar 2009 15:29:50 -0600 X-ASG-Debug-ID: 1236288563-30b103dd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 79801175DBE; Thu, 5 Mar 2009 13:29:23 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id XqGkKJtoDuBXznes; Thu, 05 Mar 2009 13:29:23 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LfL84-0001LF-NA; Thu, 05 Mar 2009 21:29:20 +0000 Date: Thu, 5 Mar 2009 16:29:20 -0500 From: Christoph Hellwig To: Hannes Eder Cc: Christoph Hellwig , Felix Blyakher , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/3 v2] xfs: include header files for prototypes Subject: Re: [PATCH 3/3 v2] xfs: include header files for prototypes Message-ID: <20090305212920.GA1883@infradead.org> References: <20090304183136.525.13769.stgit@f10box.hanneseder.net> <20090304183418.525.22262.stgit@f10box.hanneseder.net> <20090305133917.GC14854@lst.de> <20090305141912.22775.64010.stgit@f10box.hanneseder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090305141912.22775.64010.stgit@f10box.hanneseder.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236288564 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Mar 05, 2009 at 03:20:25PM +0100, Hannes Eder wrote: > I still treat this as a Acked-by: ... Ok? Should be a review, as far as you can review these sort of patches.. > hm. but that way it is still included before xfs_mount.h. Sure, but the point is entirely the comment which describes the block of includes below. From SRS0+a217f167280a378e0582+2020+infradead.org+hch@bombadil.srs.infradead.org Thu Mar 5 15:36:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n25LaIP4168223 for ; Thu, 5 Mar 2009 15:36:19 -0600 X-ASG-Debug-ID: 1236288953-5cf502660000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4FE11175E5A for ; Thu, 5 Mar 2009 13:35:53 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aCp1E0hAB85iJlWk for ; Thu, 05 Mar 2009 13:35:53 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LfLDu-0001Ua-0q; Thu, 05 Mar 2009 21:35:22 +0000 Date: Thu, 5 Mar 2009 16:35:22 -0500 From: Christoph Hellwig To: Malcolm Parsons Cc: xfs@oss.sgi.com, hch@infradead.org X-ASG-Orig-Subj: Re: [PATCH] Fix various typos in xfs Subject: Re: [PATCH] Fix various typos in xfs Message-ID: <20090305213521.GA24911@infradead.org> References: <20090303214629.GA15885@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090303214629.GA15885@localhost> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1236288953 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Mar 03, 2009 at 09:46:29PM +0000, Malcolm Parsons wrote: > Fix various typos in xfs. > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=815 > > Signed-off-by: Malcolm Parsons Thanks a lot, the patch looks good to me. Reviewed-by: Christoph Hellwig From a.beregalov@gmail.com Fri Mar 6 03:38:33 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n269cVK2202947 for ; Fri, 6 Mar 2009 03:38:32 -0600 X-ASG-Debug-ID: 1236332284-712b03d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f168.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3976B1C20792 for ; Fri, 6 Mar 2009 01:38:04 -0800 (PST) Received: from mail-bw0-f168.google.com (mail-bw0-f168.google.com [209.85.218.168]) by cuda.sgi.com with ESMTP id TYLdrHUnuksvhyEf for ; Fri, 06 Mar 2009 01:38:04 -0800 (PST) Received: by bwz12 with SMTP id 12so277381bwz.20 for ; Fri, 06 Mar 2009 01:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mkzkbxzBUWKu8a9UPGfhDzpLJ4iSqWcdUmEqNx2AjU0=; b=mvS8do25A4HCEEnwTI7eXErfiQZ5mRHPC5B7xLPoVQL7hzUQbducn6ye+a/lWG2ooU Y7a0AX1WcfDDTUGUqpUmaJnVYb90l7hZ07YyRe0GCqK+ojpMRS3l84dkimeZmNC3dGns F+jdV4aGkWOFpnmk6DAOd0eSce+zi39GDgJ7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HBBO01YCOkKwh2ZO9MGOTwYNOhSlOJQdEeKsUOg2XbXwYD22zvt+dktgDAkNolkUkO BDPraDsPl1EB2wISuQo/CkIx4kJKVoxvr3l1MmIgtnyDty1DYVdxVIGvT3/DdoORKO6V eVTgzLxgIhRDfmK/xelEUKRKh3KH+SBZCTVQM= MIME-Version: 1.0 Received: by 10.223.111.134 with SMTP id s6mr1823590fap.37.1236331854709; Fri, 06 Mar 2009 01:30:54 -0800 (PST) In-Reply-To: <20090303170248.GA7036@infradead.org> References: <20090224200740.GA9266@infradead.org> <49AD5401.30803@sandeen.net> <20090303170248.GA7036@infradead.org> Date: Fri, 6 Mar 2009 12:30:53 +0300 Message-ID: X-ASG-Orig-Subj: Re: next-20090220: XFS: inconsistent lock state Subject: Re: next-20090220: XFS: inconsistent lock state From: Alexander Beregalov To: Christoph Hellwig Cc: Felix Blyakher , Eric Sandeen , "linux-next@vger.kernel.org" , LKML , xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-bw0-f168.google.com[209.85.218.168] X-Barracuda-Start-Time: 1236332286 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19580 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Is it the same issue? [ INFO: inconsistent lock state ] 2.6.29-rc7-next-20090305 #8 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. kswapd0/318 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&ip->i_lock)->mr_lock){+++++?}, at: [] xfs_ilock+0xaa/0x120 {RECLAIM_FS-ON-W} state was registered at: [] mark_held_locks+0x69/0x90 [] lockdep_trace_alloc+0x41/0xb0 [] kmem_cache_alloc+0x2d/0x100 [] kmem_zone_alloc+0x97/0xe0 [] kmem_zone_zalloc+0x19/0x50 [] xfs_da_state_alloc+0x15/0x20 [] xfs_dir2_node_lookup+0x17/0x110 [] xfs_dir_lookup+0x1c8/0x1e0 [] xfs_lookup+0x4f/0xe0 [] xfs_vn_lookup+0x49/0x90 [] do_lookup+0x1b6/0x250 [] __link_path_walk+0x295/0xec0 [] path_walk+0x6e/0xe0 [] do_path_lookup+0xa6/0x1d0 [] path_lookup_open+0x65/0xd0 [] do_filp_open+0xaa/0x8f0 [] do_sys_open+0x78/0x110 [] sys_open+0x1b/0x20 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff irq event stamp: 531011 hardirqs last enabled at (531011): [] __rcu_read_unlock+0xa4/0xc0 hardirqs last disabled at (531010): [] __rcu_read_unlock+0x59/0xc0 softirqs last enabled at (524334): [] __do_softirq+0x139/0x150 softirqs last disabled at (524329): [] call_softirq+0x1c/0x30 other info that might help us debug this: 2 locks held by kswapd0/318: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x32/0x1c0 #1: (iprune_mutex){+.+.-.}, at: [] shrink_icache_memory+0x84/0x2a0 stack backtrace: Pid: 318, comm: kswapd0 Not tainted 2.6.29-rc7-next-20090305 #8 Call Trace: [] print_usage_bug+0x17d/0x190 [] mark_lock+0x31d/0x450 [] ? check_usage_forwards+0x0/0xc0 [] __lock_acquire+0x40d/0x12a0 [] lock_acquire+0x91/0xc0 [] ? xfs_ilock+0xaa/0x120 [] down_read_nested+0x50/0x90 [] ? xfs_ilock+0xaa/0x120 [] xfs_ilock+0xaa/0x120 [] xfs_free_eofblocks+0x84/0x280 [] ? __lock_acquire+0x2cc/0x12a0 [] xfs_inactive+0xee/0x540 [] xfs_fs_clear_inode+0x67/0x70 [] clear_inode+0x9a/0x120 [] dispose_list+0x30/0x110 [] shrink_icache_memory+0x248/0x2a0 [] shrink_slab+0x15c/0x1c0 [] kswapd+0x56a/0x6b0 [] ? finish_task_switch+0x46/0x110 [] ? isolate_pages_global+0x0/0x270 [] ? autoremove_wake_function+0x0/0x40 [] ? kswapd+0x0/0x6b0 [] kthread+0x56/0x90 [] child_rip+0xa/0x20 [] ? finish_task_switch+0x89/0x110 [] ? _spin_unlock_irq+0x36/0x60 [] ? restore_args+0x0/0x30 [] ? kthread+0x0/0x90 [] ? child_rip+0x0/0x20 From raziebe@gmail.com Fri Mar 6 11:48:18 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n26HmHsc225208 for ; Fri, 6 Mar 2009 11:48:18 -0600 X-ASG-Debug-ID: 1236361670-5313023c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f168.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4ECFC179E33 for ; Fri, 6 Mar 2009 09:47:50 -0800 (PST) Received: from mail-bw0-f168.google.com (mail-bw0-f168.google.com [209.85.218.168]) by cuda.sgi.com with ESMTP id Ovf2GfhKsJGWeAjh for ; Fri, 06 Mar 2009 09:47:50 -0800 (PST) Received: by bwz12 with SMTP id 12so458758bwz.20 for ; Fri, 06 Mar 2009 09:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=arw0TTWzAzM0f3ii7cqjY03xn/aKTQM1SF0r5jH2Nvw=; b=xtnIJBp8AhpJUcALo0XGWa8p0R8WCUA3TqokiZK6jHL8FYS8cmQ4zyWVmohSJ1nSOF HJuAtMD9yb7yeFKR2eLL0tR1hVWDhztTCZt6ZQHjsou5PvmUdBm3M0ojTBgN1xmVuH2A pN3m6l8M+B4M/5ZZfaXyLxzaPEiMsiiRBPCmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MHqI0vXbkXFWI0UcfT882cal4iYqEOca0ZxUBhTPKbjQBMZPFt+FAH9BDo9Q+KLkgJ OGd5SPwQ/xF2t7peDUZncw4cm6zYvaa2up4pnfufIFt4QWhxPdubSRsAelXbcJdupJS6 NFjtM8QEFvPcJVLkxaqFUxTgRmWAXLATo5kw8= MIME-Version: 1.0 Received: by 10.103.226.20 with SMTP id d20mr1188771mur.8.1236361669869; Fri, 06 Mar 2009 09:47:49 -0800 (PST) Date: Fri, 6 Mar 2009 19:47:49 +0200 Message-ID: <5d96567b0903060947x5678a4b4tdfbc76a786dfe257@mail.gmail.com> X-ASG-Orig-Subj: xfs_irecover Subject: xfs_irecover From: Raz To: hch@infradead.org Cc: xfs-oss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-bw0-f168.google.com[209.85.218.168] X-Barracuda-Start-Time: 1236361672 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2867 1.0000 -0.4056 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.41 X-Barracuda-Spam-Status: No, SCORE=-0.41 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19611 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hello i am trying to use xfs_ircover. when i typed: xfs_irecover -N 100 -D /dev/md5 -o /d2/temp/ it just hangs. how about some verbosity ? i am using 2.6.18-8.el5 kernel thank you raz From ESC1102493219801_1101176123914_4378@in.constantcontact.com Fri Mar 6 15:13:34 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,HTML_MESSAGE, J_CHICKENPOX_42 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n26LDXaL233599 for ; Fri, 6 Mar 2009 15:13:34 -0600 X-ASG-Debug-ID: 1236373987-30f201b80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ccm25.constantcontact.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 52D0417AE94 for ; Fri, 6 Mar 2009 13:13:07 -0800 (PST) Received: from ccm25.constantcontact.com (ccm25.constantcontact.com [208.75.123.133]) by cuda.sgi.com with ESMTP id fDRsHjRdN8Kxp5If for ; Fri, 06 Mar 2009 13:13:07 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from p2-ws505.ad.prodcc.net (unknown [10.252.0.102]) by ccm25.constantcontact.com (Postfix) with ESMTP id 6CE4310300CC for ; Fri, 6 Mar 2009 15:16:18 -0500 (EST) Message-ID: <1102493219801.1101176123914.4378.5.16161019@scheduler> Date: Fri, 6 Mar 2009 16:12:36 -0500 (EST) From: OTC ADVISORS Reply-To: info@otc-advisors.com To: xfs@oss.sgi.com X-ASG-Orig-Subj: Another Great Pick!!! Subject: Another Great Pick!!! Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14452490_13369548.1236373956322" X-Mailer: Roving Constant Contact 0 (http://www.constantcontact.com) List-Unsubscribe: http://visitor.constantcontact.com/d.jsp?p=un&v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wgnUFD5HxYbvQ== X-Return-Path-Hint: ESC1102493219801_1101176123914_4378@in.roving.com X-Roving-ID: 1101176123914.4378 X-Lumos-SenderID: 1101176123914 X-Roving-CampaignId: 1102493219801 X-Roving-StreamId: 0 X-Barracuda-Connect: ccm25.constantcontact.com[208.75.123.133] X-Barracuda-Start-Time: 1236373988 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ------=_Part_14452490_13369548.1236373956322 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit You're receiving this email because of your relationship with OTC ADVISORS LLC. Please confirm http://visitor.constantcontact.com/c.jsp?t=1102493219801.4378.33528.2&m=1101176123914&wl=F your continued interest in receiving email from us. You may unsubscribe http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wi_3spowgLCHnMnbTMHx_YE7_5UkGJ5-c8%3D&p=un if you no longer wish to receive our emails. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OTC ADVISORS LLC Newsletter February Newsletter 3/6/2009 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here at OTC ADVISORS, we are dedicated to bringing you stocks that are poised to explode! Some of our recent picks have been: AMOR.OB - AM Oil Resources & Technology, Inc. [http://rs6.net/tn.jsp?et=1102493219801&e=001GOPzxRjMeXFqSxPilnyTTr5WTQSRZuXDd_4VW41w8LUC3cshprSPYJqQ6xZiyGFPs3eoYUmd8quHOZQ70AfuI686hr9hTWwYRiYMcURC3YNZ7ing6OgMk3RT3pxlBsrgONcvoxc2J-4=] Am Oil's mission is to be the premiere provider of environmentally friendly thermal extraction technologies for the oil field in both domestic and international markets. BEEI.OB - Bald Eagle Energy, Inc. [http://rs6.net/tn.jsp?et=1102493219801&e=001GOPzxRjMeXHHqSjcSPxuUpx8uKKAIVCKduUX7mwief--bADXdyX8oP0i-cMdaMtC0xWXwRyapaQjmg70KqIQA9CxmmRhZiT2xFOhynRlOgyS50TMW5bHKGbI3uMG4GMJ] Bald Eagle Energy Inc. was formed in response to America's oil crisis with the purpose of working toward American energy independence. Right now we're switching gears and bringing you a company that is forging an Emergency Response Revolution, Improving safety through Pre-deployable Technology and Pre-deployed resources as the way to save lives, avert injuries, reduce liability and to "Bridge the Survival Gap". Recently, this company has received a ton of attention. We want you to start your research now. Start Here [http://rs6.net/tn.jsp?et=1102493219801&e=001GOPzxRjMeXE9RBW_OOihQIlWhGEQYx7kcbL8C9372e8ZNSBFEDTl0Ig3Qhqn_JJBslufqU_gGEhjemnbR_IqLmvXjwxvzJkWEurKtNFjDm2YtcIPwL38sLMQO4fmMKF9] STAY FOCUSED, BE PREPARED AND AS ALWAYS, DO YOUR HOMEWORK! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ About OTC-ADVISORS.COM OTC-ADVISORS.COM is a website that profiles stocks of interest. We are not licensed brokers or financial consultants. The information here is believed to be reliable, but not guaranteed to be accurate by OTC-ADVISORS. Please be advised that the information contained may or may not be complete and is solely for informational purposes only. This is not to be construed as an offer to sell, hold or the solicitation of an offer to buy. Investors are encouraged to seek opinions by their registered brokers or financial advisors after extensive due diligence is performed. For additional information, please contact info@otc-advisors.com [mailto:info@otc-advisors.com]. Disclaimer [http://rs6.net/tn.jsp?et=1102493219801&e=001GOPzxRjMeXFrHmDlVaUGgLlpCZOWPp3rZPBEDdIZp4xEsLrS6U5_1oJaaB_V9fXUk1SE3XdNni_Ad2Q8gzXoVwuax4PG6malp-or5o1tyoJKfqKzZmO8pCamBuWb8XJdaumhigz89nA=]. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email http://ui.constantcontact.com/sa/fwtf.jsp?m=1101176123914&ea=xfs@oss.sgi.com&a=1102493219801 This email was sent to xfs@oss.sgi.com by info@otc-advisors.com. Update Profile/Email Address http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wi_3spowgLCHnMnbTMHx_YE7_5UkGJ5-c8%3D&p=oo Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wi_3spowgLCHnMnbTMHx_YE7_5UkGJ5-c8%3D&p=un Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Email Marketing by Constant Contact(R) http://www.constantcontact.com/home.jsp?pn=atlantasky&cc=news01 OTC ADVISORS, LLC | 1 Grove St. | Suite 217 | Pittsford | NY | 14534 ------=_Part_14452490_13369548.1236373956322 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
You're receiving this email because of your relationship with OTC ADVISORS LLC. Please confirm your continued interest in receiving email from us.
 
You may unsubscribe if you no longer wish to receive our emails.
otc.logo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OTC ADVISORS LLC Newsletter
February Newsletter
3/6/2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
 
 
Here at OTC ADVISORS, we are dedicated to bringing you stocks that are poised to explode! 
 
 
Some of our recent picks have been: 
 
 
Am Oil's mission is to be the premiere provider of environmentally friendly thermal extraction technologies for the oil field in both domestic and international markets.

 
Bald Eagle Energy Inc. was formed in response to America's oil crisis with the purpose of working toward American energy independence. 
 

Right now we're switching gears and bringing you a company that is forging an Emergency Response Revolution, Improving safety through Pre-deployable Technology and Pre-deployed resources as the way to save lives, avert injuries, reduce liability and to "Bridge the Survival Gap".

 
Recently, this company has received a ton of attention.  We want you to start your research now.
 
 
 

 
 
 
 
STAY FOCUSED, BE PREPARED AND AS ALWAYS, DO YOUR HOMEWORK!

Trading Floor
 
About OTC-ADVISORS.COM
 
OTC-ADVISORS.COM is a website that profiles stocks of interest. We are not licensed brokers or financial consultants. The information here is believed to be reliable, but not guaranteed to be accurate by OTC-ADVISORS.
 
Please be advised that the information contained may or may not be complete and is solely for informational purposes only. This is not to be construed as an offer to sell, hold or the solicitation of an offer to buy. Investors are encouraged to seek opinions by their registered brokers or financial advisors after extensive due diligence is performed.
 
For additional information, please contact info@otc-advisors.com.  Disclaimer. 
Safe Unsubscribe
This email was sent to xfs@oss.sgi.com by info@otc-advisors.com.
OTC ADVISORS, LLC | 1 Grove St. | Suite 217 | Pittsford | NY | 14534
------=_Part_14452490_13369548.1236373956322-- From felixb@oss.sgi.com Fri Mar 6 17:22:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n26NMDTm240152 for ; Fri, 6 Mar 2009 17:22:13 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n26NM5WA240128; Fri, 6 Mar 2009 17:22:05 -0600 Date: Fri, 6 Mar 2009 17:22:05 -0600 Message-Id: <200903062322.n26NM5WA240128@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, mainline, updated. v2.6.28-rc3-13657-g559595a X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc X-Git-Newrev: 559595a985e106d2fa9f0c79b7f5805453fed593 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, mainline has been updated from fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Fri Mar 6 17:22:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n26NMHiE240200 for ; Fri, 6 Mar 2009 17:22:17 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n26NMEPd240158; Fri, 6 Mar 2009 17:22:14 -0600 Date: Fri, 6 Mar 2009 17:22:14 -0600 Message-Id: <200903062322.n26NMEPd240158@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-13718-g7bf446f X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: b79631330a653f568a2ac4eb4a32474c80e3fe77 X-Git-Newrev: 7bf446f8b581cef434f5ff05e8a791563bc09b7f This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated 7bf446f xfs: include header files for prototypes 3180e66 xfs: make symbols static 2441849 xfs: move declaration to header file from b79631330a653f568a2ac4eb4a32474c80e3fe77 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 7bf446f8b581cef434f5ff05e8a791563bc09b7f Author: Hannes Eder Date: Thu Mar 5 15:20:25 2009 +0100 xfs: include header files for prototypes Fix this sparse warnings: fs/xfs/linux-2.6/xfs_ioctl.c:72:1: warning: symbol 'xfs_find_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:249:1: warning: symbol 'xfs_open_by_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:361:1: warning: symbol 'xfs_readlink_by_handle' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:496:1: warning: symbol 'xfs_attrmulti_attr_get' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:525:1: warning: symbol 'xfs_attrmulti_attr_set' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:555:1: warning: symbol 'xfs_attrmulti_attr_remove' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:657:1: warning: symbol 'xfs_ioc_space' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_ioctl.c:1340:1: warning: symbol 'xfs_file_ioctl' was not declared. Should it be static? fs/xfs/support/debug.c:65:1: warning: symbol 'xfs_fs_vcmn_err' was not declared. Should it be static? fs/xfs/support/debug.c:112:1: warning: symbol 'xfs_hex_dump' was not declared. Should it be static? Signed-off-by: Hannes Eder Reviewed-by: Christoph Hellwig Signed-off-by: Felix Blyakher commit 3180e66d77e3c34cb466188105eace05dfeb5681 Author: Hannes Eder Date: Wed Mar 4 19:34:10 2009 +0100 xfs: make symbols static Instead of the keyword 'static' the macro 'STATIC' is used, so the symbols are still global with CONFIG_XFS_DEBUG. Fix this sparse warnings: fs/xfs/linux-2.6/xfs_super.c:638:1: warning: symbol 'xfs_blkdev_get' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_super.c:655:1: warning: symbol 'xfs_blkdev_put' was not declared. Should it be static? fs/xfs/linux-2.6/xfs_super.c:876:1: warning: symbol 'xfsaild' was not declared. Should it be static? fs/xfs/xfs_bmap.c:6208:1: warning: symbol 'xfs_check_block' was not declared. Should it be static? fs/xfs/xfs_dir2_leaf.c:553:1: warning: symbol 'xfs_dir2_leaf_check' was not declared. Should it be static? Signed-off-by: Hannes Eder Reviewed-by: Christoph Hellwig Signed-off-by: Felix Blyakher commit 24418492aa245e9812c425593883b9db52fd8d29 Author: Hannes Eder Date: Wed Mar 4 19:33:48 2009 +0100 xfs: move declaration to header file Fix this sparse warning: fs/xfs/xfs_da_btree.c:1550:26: warning: symbol 'xfs_default_nameops' was not declared. Should it be static? Signed-off-by: Hannes Eder Reviewed-by: Christoph Hellwig Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_ioctl.c | 1 + fs/xfs/linux-2.6/xfs_super.c | 6 +++--- fs/xfs/support/debug.c | 1 + fs/xfs/xfs_bmap.c | 2 +- fs/xfs/xfs_da_btree.h | 1 + fs/xfs/xfs_dir2.c | 2 -- fs/xfs/xfs_dir2_leaf.c | 2 +- 7 files changed, 8 insertions(+), 7 deletions(-) hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Fri Mar 6 17:36:03 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n26Na3Yg241031 for ; Fri, 6 Mar 2009 17:36:03 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n26Na1fq240994; Fri, 6 Mar 2009 17:36:01 -0600 Date: Fri, 6 Mar 2009 17:36:01 -0600 Message-Id: <200903062336.n26Na1fq240994@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-12449-gc141b29 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: 27e88bf6af7d42adf790f7b2ed7d65475f191cf2 X-Git-Newrev: c141b2928fe20396a9ecdec85526e4b66ae96c90 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, for-linus has been updated c141b29 xfs: only issues a cache flush on unmount if barriers are enabled 7d46be4 xfs: prevent lockdep false positive in xfs_iget_cache_miss ff392c4 xfs: prevent kernel crash due to corrupted inode log format from 27e88bf6af7d42adf790f7b2ed7d65475f191cf2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c141b2928fe20396a9ecdec85526e4b66ae96c90 Author: Christoph Hellwig Date: Tue Mar 3 14:48:37 2009 -0500 xfs: only issues a cache flush on unmount if barriers are enabled Currently we unconditionally issue a flush from xfs_free_buftarg, but since 2.6.29-rc1 this gives a warning in the style of end_request: I/O error, dev vdb, sector 0 Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Signed-off-by: Felix Blyakher commit 7d46be4a25fdfb503c20bad60a618adebfe2ac5c Author: Christoph Hellwig Date: Tue Mar 3 14:48:35 2009 -0500 xfs: prevent lockdep false positive in xfs_iget_cache_miss The inode can't be locked by anyone else as we just created it a few lines above and it's not been added to any lookup data structure yet. So use a trylock that must succeed to get around the lockdep warnings. Signed-off-by: Christoph Hellwig Reported-by: Alexander Beregalov Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher Signed-off-by: Felix Blyakher commit ff392c497b43ddedbab5627b53928a654cc5486e Author: Christoph Hellwig Date: Tue Mar 3 14:48:36 2009 -0500 xfs: prevent kernel crash due to corrupted inode log format Andras Korn reported an oops on log replay causes by a corrupted xfs_inode_log_format_t passing a 0 size to kmem_zalloc. This patch handles to small or too large numbers of log regions gracefully by rejecting the log replay with a useful error message. Signed-off-by: Christoph Hellwig Reported-by: Andras Korn Reviewed-by: Eric Sandeen Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_buf.c | 12 ++++++++++-- fs/xfs/linux-2.6/xfs_buf.h | 2 +- fs/xfs/linux-2.6/xfs_super.c | 10 +++++----- fs/xfs/xfs_iget.c | 15 ++++++++++----- fs/xfs/xfs_log_recover.c | 17 +++++++++++++---- 5 files changed, 39 insertions(+), 17 deletions(-) hooks/post-receive -- XFS development tree From agruen@suse.de Sun Mar 8 08:11:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28DBD7C081411 for ; Sun, 8 Mar 2009 08:11:17 -0500 X-ASG-Debug-ID: 1236517848-446a01ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71D231C26DC1 for ; Sun, 8 Mar 2009 06:10:49 -0700 (PDT) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id JZC0pP7Bv2Fy91k8 for ; Sun, 08 Mar 2009 06:10:49 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 0ACC7456F7; Sun, 8 Mar 2009 14:10:48 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: Christoph Hellwig X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Date: Sun, 8 Mar 2009 14:09:28 +0100 User-Agent: KMail/1.9.9 Cc: Mike Frysinger , Eric Sandeen , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <200902271835.30912.agruen@suse.de> <20090304172727.GA21463@infradead.org> In-Reply-To: <20090304172727.GA21463@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903081409.28808.agruen@suse.de> X-Barracuda-Connect: ns1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1236517849 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wednesday, 4 March 2009 18:27:27 Christoph Hellwig wrote: > I've tried to port the patch you checked into xfsprogs (see below for > the diff), but it fails to build for me. Any idea what might have > gone wrong? git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git is missing the following commit from ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/acl.git: commit 8de7788c29d2656f8d52d98327a80e4dfd1e3898 Author: Barry Naujok Date: Tue Jan 23 14:51:14 2007 +0000 Fix cross-compile issues with libtool and compiler. This is equivalent to commit de7b3f6 from Barry Naujok in the acl package, and part of the Gentoo package, as pointed out by Mike Frysinger . Signed-off-by: Andreas Gruenbacher While looking into this, I noticed that the attr and acl packages were calling AC_PROG_LIBTOOL both in configure.in and m4/package_utilies.m4. I have removed the redundant call from m4/package_utilies.m4 now. Andreas From aisha.hani@up-uk.com Sun Mar 8 11:07:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28G7LeD088297 for ; Sun, 8 Mar 2009 11:07:21 -0500 X-ASG-Debug-ID: 1236528409-38b8035f0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2499C1C2730F; Sun, 8 Mar 2009 09:06:50 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id fZfloaJrj3rhv4rM; Sun, 08 Mar 2009 09:06:50 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 00:06:09 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 00:06:09 +0800 Message-ID: <20090309000609.gfcj5ofad4w0sc8s@webmail.up-uk.com> Date: Mon, 09 Mar 2009 00:06:09 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236528416 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 11:38:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28Gcwcx090114 for ; Sun, 8 Mar 2009 11:38:58 -0500 X-ASG-Debug-ID: 1236530309-55ae039d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E68481C2722F; Sun, 8 Mar 2009 09:38:30 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id GGoAtrgPYeSMz46B; Sun, 08 Mar 2009 09:38:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 00:31:03 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 00:31:02 +0800 Message-ID: <20090309003102.37evlwj2g4gk4o04@webmail.up-uk.com> Date: Mon, 09 Mar 2009 00:31:02 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236530313 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19776 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 11:39:29 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28GdTNh090152 for ; Sun, 8 Mar 2009 11:39:29 -0500 X-ASG-Debug-ID: 1236530341-1411029a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 892E81C27244 for ; Sun, 8 Mar 2009 09:39:01 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id iSRkXPzSYC0flR61 for ; Sun, 08 Mar 2009 09:39:01 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 00:34:50 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 00:34:50 +0800 Message-ID: <20090309003450.6chl8tpa0wscgwss@webmail.up-uk.com> Date: Mon, 09 Mar 2009 00:34:50 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236530344 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19776 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 12:05:57 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28H5utK091054 for ; Sun, 8 Mar 2009 12:05:56 -0500 X-ASG-Debug-ID: 1236531923-17f700440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC86C1C272B3; Sun, 8 Mar 2009 10:05:24 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id bGDHhHkG0o3mYu7D; Sun, 08 Mar 2009 10:05:24 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 00:55:12 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 00:55:11 +0800 Message-ID: <20090309005511.62zqyj9btw0s88ow@webmail.up-uk.com> Date: Mon, 09 Mar 2009 00:55:11 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236531931 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 12:15:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28HF9Wf091396 for ; Sun, 8 Mar 2009 12:15:09 -0500 X-ASG-Debug-ID: 1236532473-17f7006a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 98A881C27600 for ; Sun, 8 Mar 2009 10:14:41 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id tWuu8sYPETtFW5CR for ; Sun, 08 Mar 2009 10:14:41 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 00:59:13 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 00:59:11 +0800 Message-ID: <20090309005911.48wv9pym35a88sws@webmail.up-uk.com> Date: Mon, 09 Mar 2009 00:59:11 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236532484 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 13:16:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28IGrYG094519 for ; Sun, 8 Mar 2009 13:16:54 -0500 X-ASG-Debug-ID: 1236536186-3c2900d80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 524A01C2793D for ; Sun, 8 Mar 2009 11:16:27 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id ka8EpqfHEChlEEgQ for ; Sun, 08 Mar 2009 11:16:27 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 01:27:42 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 01:27:40 +0800 Message-ID: <20090309012740.qv9locwkpw4oosow@webmail.up-uk.com> Date: Mon, 09 Mar 2009 01:27:40 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236536189 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Sun Mar 8 13:23:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n28IN1jL094653 for ; Sun, 8 Mar 2009 13:23:01 -0500 X-ASG-Debug-ID: 1236536554-181301be0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C4D531C27850 for ; Sun, 8 Mar 2009 11:22:34 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id 7BCgwVhlx77lAjYI for ; Sun, 08 Mar 2009 11:22:34 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 01:41:12 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 01:41:10 +0800 Message-ID: <20090309014110.3tsxugkjxck88wkk@webmail.up-uk.com> Date: Mon, 09 Mar 2009 01:41:10 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236536556 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From ESC1102495174691_1101176123914_4378@in.constantcontact.com Sun Mar 8 21:50:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n292ow8L111416 for ; Sun, 8 Mar 2009 21:50:59 -0500 X-ASG-Debug-ID: 1236567033-57bb003c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ccm32.constantcontact.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BDCF17EE84 for ; Sun, 8 Mar 2009 19:50:33 -0700 (PDT) Received: from ccm32.constantcontact.com (ccm32.constantcontact.com [208.75.123.228]) by cuda.sgi.com with ESMTP id Teykj4UElTONf3GR for ; Sun, 08 Mar 2009 19:50:33 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from p2-ws505.ad.prodcc.net (unknown [10.252.0.102]) by ccm32.constantcontact.com (Postfix) with ESMTP id 3B697320031 for ; Sun, 8 Mar 2009 21:57:12 -0400 (EDT) Message-ID: <1102495174691.1101176123914.4378.5.20225019@scheduler> Date: Sun, 8 Mar 2009 22:50:33 -0400 (EDT) From: OTC ADVISORS Reply-To: info@otc-advisors.com To: xfs@oss.sgi.com X-ASG-Orig-Subj: Sunday Night Homework Subject: Sunday Night Homework Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18212198_1218988200.1236567033383" X-Mailer: Roving Constant Contact 0 (http://www.constantcontact.com) List-Unsubscribe: http://visitor.constantcontact.com/d.jsp?p=un&v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wiGgzmUZTb14A== X-Return-Path-Hint: ESC1102495174691_1101176123914_4378@in.roving.com X-Roving-ID: 1101176123914.4378 X-Lumos-SenderID: 1101176123914 X-Roving-CampaignId: 1102495174691 X-Roving-StreamId: 0 X-Barracuda-Connect: ccm32.constantcontact.com[208.75.123.228] X-Barracuda-Start-Time: 1236567034 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ------=_Part_18212198_1218988200.1236567033383 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit You're receiving this email because of your relationship with OTC ADVISORS LLC. Please confirm http://visitor.constantcontact.com/c.jsp?t=1102495174691.4378.33528.2&m=1101176123914&wl=F your continued interest in receiving email from us. You may unsubscribe http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wgSTwe1h4PznPXcmaPr6rfepilxMFcjIBU%3D&p=un if you no longer wish to receive our emails. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OTC ADVISORS LLC Newsletter March Newsletter 3/8/2009 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Greetings! WE DON'T WANT YOU TO MISS THE CHANCE TO READ EXCITING INFORMATION ON GTX CORP. First check out this video - CLICK HERE [http://rs6.net/tn.jsp?et=1102495174691&e=001ih7qjnUL0Xa-Fn-dgUKWtVsGlXOVryTizj1xGpViqgNlZl-i8VAXF8lhQ5KXYb6EB2_sS1dXY60LrrAb8n4KGeVxiM5u6diq04a5SUAXNgNtL2nuSScboicYrHSGJgEO2IlPQ8DHcmubJhDYq5F_r4WZMqilQgrLC0Tq1kX416VIeQji-aafwA==] Just imagine how GPS can be used to help find missing people, kids and the elderly! READERS, THIS IS HUGE! WE SEE A FEW REALLY BIG STOCKS EVERY YEAR AND WE FEEL STRONGLY ABOUT THIS BEING ONE OF THEM! Recent News: Mar 3, 2009 -- GTX Corp, a leader in customizable 2-Way Global Positioning Systems (GPS) / Position Location Systems (PLS) applications, accelerates its "go-to-market" strategy through its product expansion and the addition of Dr. Gilbert Amelio of Alteon Capital Partners as a Strategic Advisor. Wireless subscriber adoption is building year after year and is estimated to exceed four billion mobile handsets globally in 2011 according to Wireless Intelligence, the GSMA's market intelligence unit. An increasing number will have GPS and positioning capability. GTX Corp is implementing an accelerated plan to address this burgeoning opportunity by leveraging its intellectual property portfolio and product line with leading edge Location Based Solutions. Continuing its strategy of building its team of premier strategic advisors, GTX Corp is bringing on Dr. Gilbert Amelio and George Lauro, Managing Partners of Alteon Capital Partners. Alteon provides financing, corporate development, transformation/repositioning and value recovery services for companies commercializing leading-edge technologies. Read More Here. [http://rs6.net/tn.jsp?et=1102495174691&e=001ih7qjnUL0XalQ8dnrjBPVfh_cT2XKy5reksBv9W3P3aX4wyU303-rjyIvq_EjHZj5HvNiqGVCQ6Qxu7C3YfWtfU4iZaQpu-ga1XJYkiWXibY7RyDYou2kCY7j_b_SZjFkZji7osTnsr6OiXtvHSntQ==] About GTX Corp GTX Corp develops miniaturized Global Positioning Service (GPS) satellite tracking and location-transmitting technology devices for integration into branded licensee consumer products. The company's Personal Location Services (PLS) platform consists of a matchbook-sized, location-reporting module that utilizes GTX Corp's "always-on" Assisted-GPS tracking capabilities. At the convergence of technology, media and telecommunications - the TMT sector of the telecom industry - GTX Corp continues its efforts to advance GPS technology as it defines the PLS space. The gpVector(TM) system uses cellular transmission provided by our wireless carrier partner, AT&T, to deliver real-time geographic coordinates, rendered on Google Maps, to subscribers via secure internet connections. GTX Corp has more than six years in research and development, strategic partnerships, and an ongoing program of intellectual property protection. GTX Corp melds technology and form factor seamlessly to deliver the right solution to specific markets. The company is headquartered in Los Angeles, California, with an R&D facility in Palo Alto, California. www.gtxcorp.com [http://rs6.net/tn.jsp?et=1102495174691&e=001ih7qjnUL0Xb4s-cWl-BH0rjUZislz8uG5QX-zgMsUS3ujuus6l2nHUt647HBq7cqd7deBn2uRwK_M0FOAa7XPWdbfYu2Bi1DKVGH_llwmKXk5VOylAgz9w==] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ About OTC-ADVISORS.COM OTC-ADVISORS.COM is a website that profiles stocks of interest. We are not licensed brokers or financial consultants. The information here is believed to be reliable, but not guaranteed to be accurate by OTC-ADVISORS. Please be advised that the information contained may or may not be complete and is solely for informational purposes only. This is not to be construed as an offer to sell, hold or the solicitation of an offer to buy. Investors are encouraged to seek opinions by their registered brokers or financial advisors after extensive due diligence is performed. For additional information, please contact info@otc-advisors.com [mailto:info@otc-advisors.com]. Disclaimer [http://rs6.net/tn.jsp?et=1102495174691&e=001ih7qjnUL0Xb-gRp8yLeaKXZ6tL3x4_t4QMTx7uwGQ3m2_SOtLwaYFpzSGHmQY6lQ03eO9ErKYdqIVl9J8SHlAH26ScGu3vmj3bGhtRVyRz_KK3kTktDIPw_7tCkK4Eaorp8hktUMgEw=]. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email http://ui.constantcontact.com/sa/fwtf.jsp?m=1101176123914&ea=xfs@oss.sgi.com&a=1102495174691 This email was sent to xfs@oss.sgi.com by info@otc-advisors.com. Update Profile/Email Address http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wgSTwe1h4PznPXcmaPr6rfepilxMFcjIBU%3D&p=oo Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/d.jsp?v=001kdIqtH8ZGZaB9alrhpvhxeVpWZWDaCMBmp9JiiJ71wgSTwe1h4PznPXcmaPr6rfepilxMFcjIBU%3D&p=un Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Email Marketing by Constant Contact(R) http://www.constantcontact.com/home.jsp?pn=atlantasky&cc=news01 OTC ADVISORS LLC | 250 Exchange Blvd. | Suite 105 | Rochester | NY | 14608 ------=_Part_18212198_1218988200.1236567033383 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
You're receiving this email because of your relationship with OTC ADVISORS LLC. Please confirm your continued interest in receiving email from us.
 
You may unsubscribe if you no longer wish to receive our emails.
otc.logo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OTC ADVISORS LLC Newsletter
March Newsletter
3/8/2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Greetings!
 
 
 
WE DON'T WANT YOU TO MISS THE CHANCE TO READ EXCITING INFORMATION ON GTX CORP.
 
 
First check out this video - CLICK HERE
 
 
Just imagine how GPS can be used to help find missing people, kids and the elderly!
 
 
READERS, THIS IS HUGE! WE SEE A FEW REALLY BIG STOCKS EVERY YEAR AND WE FEEL STRONGLY ABOUT THIS BEING ONE OF THEM!
 
 
 
Recent News:
 
Mar 3, 2009 -- GTX Corp, a leader in customizable 2-Way Global Positioning Systems (GPS) / Position Location Systems (PLS) applications, accelerates its "go-to-market" strategy through its product expansion and the addition of Dr. Gilbert Amelio of Alteon Capital Partners as a Strategic Advisor. 
 
Wireless subscriber adoption is building year after year and is estimated to exceed four billion mobile handsets globally in 2011 according to Wireless Intelligence, the GSMA's market intelligence unit.
 
An increasing number will have GPS and positioning capability. GTX Corp is implementing an accelerated plan to address this burgeoning opportunity by leveraging its intellectual property portfolio and product line with leading edge Location Based Solutions.
 
Continuing its strategy of building its team of premier strategic advisors, GTX Corp is bringing on Dr. Gilbert Amelio and George Lauro, Managing Partners of Alteon Capital Partners.
 
Alteon provides financing, corporate development, transformation/repositioning and value recovery services for companies commercializing leading-edge technologies. 

 
 
 
About GTX Corp
GTX Corp develops miniaturized Global Positioning Service (GPS) satellite tracking and location-transmitting technology devices for integration into branded licensee consumer products.
 
The company's Personal Location Services (PLS) platform consists of a matchbook-sized, location-reporting module that utilizes GTX Corp's "always-on" Assisted-GPS tracking capabilities.
 
At the convergence of technology, media and telecommunications - the TMT sector of the telecom industry - GTX Corp continues its efforts to advance GPS technology as it defines the PLS space.
 
The gpVector(TM) system uses cellular transmission provided by our wireless carrier partner, AT&T, to deliver real-time geographic coordinates, rendered on Google Maps, to subscribers via secure internet connections.
 
GTX Corp has more than six years in research and development, strategic partnerships, and an ongoing program of intellectual property protection.
 
GTX Corp melds technology and form factor seamlessly to deliver the right solution to specific markets.
 
The company is headquartered in Los Angeles, California, with an R&D facility in Palo Alto, California. www.gtxcorp.com  
 
About OTC-ADVISORS.COM
 
OTC-ADVISORS.COM is a website that profiles stocks of interest. We are not licensed brokers or financial consultants. The information here is believed to be reliable, but not guaranteed to be accurate by OTC-ADVISORS.
 
Please be advised that the information contained may or may not be complete and is solely for informational purposes only. This is not to be construed as an offer to sell, hold or the solicitation of an offer to buy. Investors are encouraged to seek opinions by their registered brokers or financial advisors after extensive due diligence is performed.
 
For additional information, please contact info@otc-advisors.com.  Disclaimer. 
Safe Unsubscribe
This email was sent to xfs@oss.sgi.com by info@otc-advisors.com.
OTC ADVISORS LLC | 250 Exchange Blvd. | Suite 105 | Rochester | NY | 14608
------=_Part_18212198_1218988200.1236567033383-- From nate@houseofnate.net Sun Mar 8 22:23:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n293NMYN112563 for ; Sun, 8 Mar 2009 22:23:23 -0500 X-ASG-Debug-ID: 1236568975-15a4035c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from millhouse.houseofnate.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 319301C2826F for ; Sun, 8 Mar 2009 20:22:55 -0700 (PDT) Received: from millhouse.houseofnate.net (dsl092-086-237.bos1.dsl.speakeasy.net [66.92.86.237]) by cuda.sgi.com with ESMTP id NJm4vvvWi8z3RYcO for ; Sun, 08 Mar 2009 20:22:55 -0700 (PDT) Received: from [66.92.86.237] (dsl092-086-237.bos1.dsl.speakeasy.net [::ffff:66.92.86.237]) (AUTH: LOGIN nturner, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by millhouse.houseofnate.net with esmtp; Sun, 08 Mar 2009 23:22:55 -0400 id 0000000000270713.0000000049B48B8F.00007550 Message-ID: <49B48B8E.3030602@houseofnate.net> Date: Sun, 08 Mar 2009 23:22:54 -0400 From: "Nathaniel W. Turner" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs_repair: open filesystem device exclusively Subject: [PATCH] xfs_repair: open filesystem device exclusively X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: dsl092-086-237.bos1.dsl.speakeasy.net[66.92.86.237] X-Barracuda-Start-Time: 1236568978 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19811 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi folks, I'm sure there is a better way to fix this, but without this patch, two xfs_repair processes will happily operate on the same filesystem device at the same time. It is also possible to mount a filesystem that is in the process of being repaired. This seems like it's probably not ideal, so this patch just modifies xfs_repair to open the filesystem device with O_EXCL unless it was invoked in "no modify" or "dangerous" mode. The net effect is that a 2nd xfs_repair will now safely fail with "xfs_repair: cannot open /dev/foo: Device or resource busy", and a mount command will fail with (the slightly cryptic) "mount: /dev/foo already mounted or /mountpoint busy". Note that this has no effect if the filesystem is stored in a regular file instead of on a block device. (Error messages could probably be improved to be more user-friendly in this new failure case, and it probably wouldn't hurt to add a BLKROGET ioctl to check for read-only block devices with read-write permissions, but this should at least make things a bit safer.) Signed-off-by: Nathaniel W. Turner --- repair/init.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/repair/init.c b/repair/init.c index 8e508c4..3d88b8b 100644 --- a/repair/init.c +++ b/repair/init.c @@ -142,6 +142,8 @@ xfs_init(libxfs_init_t *args) args->isreadonly = (LIBXFS_ISREADONLY | LIBXFS_ISINACTIVE); else if (dangerously) args->isreadonly = (LIBXFS_ISINACTIVE | LIBXFS_DANGEROUSLY); + else + args->isreadonly = LIBXFS_EXCLUSIVELY; if (!libxfs_init(args)) do_error(_("couldn't initialize XFS library\n")); -- 1.5.6.3 -- Nathaniel W. Turner http://houseofnate.net/ From nate@houseofnate.net Sun Mar 8 22:50:29 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n293oSw3113422 for ; Sun, 8 Mar 2009 22:50:29 -0500 X-ASG-Debug-ID: 1236570603-6fc4016b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from millhouse.houseofnate.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 086321968266 for ; Sun, 8 Mar 2009 20:50:03 -0700 (PDT) Received: from millhouse.houseofnate.net (dsl092-086-237.bos1.dsl.speakeasy.net [66.92.86.237]) by cuda.sgi.com with ESMTP id kDvpQSWeOHVkjIZa for ; Sun, 08 Mar 2009 20:50:03 -0700 (PDT) Received: from [66.92.86.237] (dsl092-086-237.bos1.dsl.speakeasy.net [::ffff:66.92.86.237]) (AUTH: LOGIN nturner, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by millhouse.houseofnate.net with esmtp; Sun, 08 Mar 2009 23:50:03 -0400 id 0000000000270715.0000000049B491EB.000001E9 Message-ID: <49B491EA.4090003@houseofnate.net> Date: Sun, 08 Mar 2009 23:50:02 -0400 From: "Nathaniel W. Turner" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs_repair: open filesystem device exclusively Subject: Re: [PATCH] xfs_repair: open filesystem device exclusively References: <49B48B8E.3030602@houseofnate.net> In-Reply-To: <49B48B8E.3030602@houseofnate.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: dsl092-086-237.bos1.dsl.speakeasy.net[66.92.86.237] X-Barracuda-Start-Time: 1236570604 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19813 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I forgot to mention that this is against xfsprogs 3.0.0. Also, the indentation was a bit messed up on that last post, so here's the patch again (all 2 lines of it): ---- I'm sure there is a better way to fix this, but without this patch, two xfs_repair processes will happily operate on the same filesystem device at the same time. It is also possible to mount a filesystem that is in the process of being repaired. This seems like it's probably not ideal, so this patch just modifies xfs_repair to open the filesystem device with O_EXCL unless it was invoked in "no modify" or "dangerous" mode. The net effect is that a 2nd xfs_repair will now safely fail with "xfs_repair: cannot open /dev/foo: Device or resource busy", and a mount command will fail with (the slightly cryptic) "mount: /dev/foo already mounted or /mountpoint busy". Note that this has no effect if the filesystem is stored in a regular file instead of on a block device. (Error messages could probably be improved to be more user-friendly in this new failure case, and it probably wouldn't hurt to add a BLKROGET ioctl to check for read-only block devices with read-write permissions, but this does the job for me.) Signed-off-by: Nathaniel W. Turner --- repair/init.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/repair/init.c b/repair/init.c index 8e508c4..7e5052c 100644 --- a/repair/init.c +++ b/repair/init.c @@ -142,6 +142,8 @@ xfs_init(libxfs_init_t *args) args->isreadonly = (LIBXFS_ISREADONLY | LIBXFS_ISINACTIVE); else if (dangerously) args->isreadonly = (LIBXFS_ISINACTIVE | LIBXFS_DANGEROUSLY); + else + args->isreadonly = LIBXFS_EXCLUSIVELY; if (!libxfs_init(args)) do_error(_("couldn't initialize XFS library\n")); -- Nathaniel W. Turner http://houseofnate.net/ From aisha.hani@up-uk.com Mon Mar 9 13:37:15 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29IbEg7154160 for ; Mon, 9 Mar 2009 13:37:15 -0500 X-ASG-Debug-ID: 1236623808-0c8c00e00000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ABB481C2B4C8; Mon, 9 Mar 2009 11:36:48 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id ICc9IwOazAmsIUxg; Mon, 09 Mar 2009 11:36:48 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 02:06:48 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 02:06:48 +0800 Message-ID: <20090309020648.ju84bu6u38k4sgkg@webmail.up-uk.com> Date: Mon, 09 Mar 2009 02:06:48 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236623810 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19870 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Mon Mar 9 13:52:24 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29IqNw8155596 for ; Mon, 9 Mar 2009 13:52:23 -0500 X-ASG-Debug-ID: 1236624713-0c8401040000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3785B1C2B47A; Mon, 9 Mar 2009 11:51:54 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id kC6za7v1IxAwAqQj; Mon, 09 Mar 2009 11:51:54 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 02:21:53 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 02:21:52 +0800 Message-ID: <20090309022152.2cathr4t2ckg0wsc@webmail.up-uk.com> Date: Mon, 09 Mar 2009 02:21:52 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236624718 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19872 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Mon Mar 9 14:09:10 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29J99VF156486 for ; Mon, 9 Mar 2009 14:09:10 -0500 X-ASG-Debug-ID: 1236625720-694f02420000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEE5F1C2B81C for ; Mon, 9 Mar 2009 12:08:41 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id pvZChznuR0BlzXZI for ; Mon, 09 Mar 2009 12:08:41 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 02:38:40 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 02:38:40 +0800 Message-ID: <20090309023840.q4pno5zu6sswc0w4@webmail.up-uk.com> Date: Mon, 09 Mar 2009 02:38:40 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236625725 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19872 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Mon Mar 9 14:30:15 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29JUEvg157676 for ; Mon, 9 Mar 2009 14:30:15 -0500 X-ASG-Debug-ID: 1236626988-0c9501930000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DFDF31C2B237 for ; Mon, 9 Mar 2009 12:29:48 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id VHnfbNZVaSllNL2H for ; Mon, 09 Mar 2009 12:29:48 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 02:59:48 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 02:59:47 +0800 Message-ID: <20090309025947.funb25id4w0ggkw0@webmail.up-uk.com> Date: Mon, 09 Mar 2009 02:59:47 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236626990 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Mon Mar 9 15:05:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29K5ZJP159417 for ; Mon, 9 Mar 2009 15:05:35 -0500 X-ASG-Debug-ID: 1236629108-0ccc002a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0F5F21C2B7F7 for ; Mon, 9 Mar 2009 13:05:09 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id XdykwnE8t8ILywa6 for ; Mon, 09 Mar 2009 13:05:09 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 03:35:09 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 03:35:08 +0800 Message-ID: <20090309033508.x8b8us12gogk40og@webmail.up-uk.com> Date: Mon, 09 Mar 2009 03:35:08 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236629111 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19876 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From aisha.hani@up-uk.com Mon Mar 9 15:19:18 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n29KJHqv159702 for ; Mon, 9 Mar 2009 15:19:18 -0500 X-ASG-Debug-ID: 1236629931-0c86026c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from windows6.internet-webhosting.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A3A0E1C2BC3A for ; Mon, 9 Mar 2009 13:18:52 -0700 (PDT) Received: from windows6.internet-webhosting.com (Win6.internet-webhosting.com [202.75.36.46]) by cuda.sgi.com with ESMTP id wqkre7a6ZC0bIa5y for ; Mon, 09 Mar 2009 13:18:52 -0700 (PDT) Received: from localhost ([127.0.0.1]) by windows6.internet-webhosting.com with MailEnable ESMTP; Mon, 09 Mar 2009 03:48:51 +0800 Received: from 60.52.97.78 ([60.52.97.78]) by webmail.up-uk.com (Horde MIME library) with HTTP; Mon, 09 Mar 2009 03:48:50 +0800 Message-ID: <20090309034850.w8ype7s2oksc804g@webmail.up-uk.com> Date: Mon, 09 Mar 2009 03:48:50 +0800 From: aisha.hani@up-uk.com To: undisclosed-recipients:; X-ASG-Orig-Subj: please reply Subject: please reply MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Barracuda-Connect: Win6.internet-webhosting.com[202.75.36.46] X-Barracuda-Start-Time: 1236629933 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6587 1.0000 1.0772 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.08 X-Barracuda-Spam-Status: No, SCORE=1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19876 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean HI I know you will be surprise to read from someone relatively unknown to =20 you. My name is Miss. Aisha Hani Abdullah. Before now, I must say that =20 I am very uncomfortable sending this message to you without knowing =20 truly if you misconstrue the importance and secrecy of this deal and =20 decide to go public which will affect my carrier and the future of =20 this deal. I feel safe sending you this business proposal, having gone through =20 your contact on the Internet, even though this medium (Internet) has =20 been greatly abused, I choose to reach you through this medium =20 because it still remain the surest and above all, the most secured =20 medium of communication. My company wants a product called (SAPHIRE BLUE STONE). It's used for =20 jewelries, necklace, wrist watch, marble ties etc. The only original =20 supplier of these MINERAL is in Malaysia. As such; my company needs =20 not less than one hundred to two hundred kg. Since you are in =20 Malaysia, I would you to handle this business. Please contact me via email, should you accept this offer: =20 (aisha_hani@up-uk.com) Regards Aisha Hani ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From agruen@suse.de Tue Mar 10 11:42:27 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2AGg66D218744 for ; Tue, 10 Mar 2009 11:42:27 -0500 X-ASG-Debug-ID: 1236703281-571301310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 45B5D1865A1 for ; Tue, 10 Mar 2009 09:41:21 -0700 (PDT) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id ELSmoFTX9vsyVQYP for ; Tue, 10 Mar 2009 09:41:21 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 28D90457DD; Tue, 10 Mar 2009 17:41:20 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: Christoph Hellwig X-ASG-Orig-Subj: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0 Date: Tue, 10 Mar 2009 17:41:06 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-4-pae; KDE/4.1.3; i686; ; ) Cc: Mike Frysinger , Eric Sandeen , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <20090304172727.GA21463@infradead.org> <200903081409.28808.agruen@suse.de> In-Reply-To: <200903081409.28808.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903101741.07043.agruen@suse.de> X-Barracuda-Connect: mx1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1236703303 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sunday 08 March 2009 14:09:28 Andreas Gruenbacher wrote: > On Wednesday, 4 March 2009 18:27:27 Christoph Hellwig wrote: > > I've tried to port the patch you checked into xfsprogs (see below for > > the diff), but it fails to build for me. Any idea what might have > > gone wrong? > > git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git is missing the > following commit from > ssh://master.kernel.org/pub/scm/linux/kernel/git/agruen/acl.git: > > commit 8de7788c29d2656f8d52d98327a80e4dfd1e3898 > Author: Barry Naujok > Date: Tue Jan 23 14:51:14 2007 +0000 > > Fix cross-compile issues with libtool and compiler. > > This is equivalent to commit de7b3f6 from Barry Naujok > in the acl package, and part of the Gentoo package, as > pointed out by Mike Frysinger . > > Signed-off-by: Andreas Gruenbacher > > While looking into this, I noticed that the attr and acl packages were > calling AC_PROG_LIBTOOL both in configure.in and m4/package_utilies.m4. I > have removed the redundant call from m4/package_utilies.m4 now. As it turns out, I was running into more trouble with libtoolize from libtool 2.2.6. See this commit in attr.git: commit 604290f79a199eb0c73a0cd05a473e1801a00673 Author: Andreas Gruenbacher Date: Tue Mar 10 17:00:35 2009 +0100 More libtoolize fixes Recent versions of libtool behave slightly differently, which causes some breakage in how libtoolize was used here. Make sure that libtoolize adds the auxiliary files (config.guess and config.sub). Move install-sh into include/ so that libtoolize does not destroy it. Split up the ``make clean'' and ``make distclean'' targets: the former removes all files generated during a build. The latter removes all files generated by libtoolize, autoconf, and configure as well. Signed-off-by: Andreas Gruenbacher With these changes, the build/*.src.tar.gz tarball should now build properly without depending on the version of libtool on the system with: ./configure make make install (The acl.git repository has the equivalent changes.) Andreas From thomas.gutzler@gmail.com Tue Mar 10 21:51:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_23 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2B2okh6244729 for ; Tue, 10 Mar 2009 21:51:07 -0500 X-ASG-Debug-ID: 1236739821-7ad002580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ti-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AC0371C31DF2 for ; Tue, 10 Mar 2009 19:50:21 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by cuda.sgi.com with ESMTP id OTLh5gbxmSKifX3D for ; Tue, 10 Mar 2009 19:50:21 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1980547tib.18 for ; Tue, 10 Mar 2009 19:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eUCJRKIyCMtyy/SBbOPV+xAws9h2XYJgN6SIrYW0+HM=; b=nUBeabfBwDVNLGy8TIDKIKHO4mQmLVHCk+JMWvZQDYWE9xTTLG8iRTejo/pK7BqU1W 5jDOX6UTn554Pns644+i+jwvBaNwcoUY4WFDOFZ6stD6TWafi3943jEqY6LHBKy8TVjq 6v3JTIE/fhlqcynXDLRzti6lrC7bx/uki8PQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D4p8IvM+l3vLo1wmwxpexSm3y+9SHB3anIvjI8kLC5MAOeu+xZQhu/dGIYq1CbTzMv mINoqI8g12YIaFUsGmHmq4LG3vM+ztBU9SpprxT396o7AkDNdlknUIW7M79xUAg7xmOz s9wLn41dCpihjm/tMuCJ1UAlTzFumPpuqvE8I= MIME-Version: 1.0 Received: by 10.110.16.15 with SMTP id 15mr10647060tip.26.1236739471652; Tue, 10 Mar 2009 19:44:31 -0700 (PDT) In-Reply-To: <495D88EE.2040406@sandeen.net> References: <169670ec0901011846q1d370e6cu31514519afc8295d@mail.gmail.com> <495D88EE.2040406@sandeen.net> Date: Wed, 11 Mar 2009 11:44:31 +0900 Message-ID: <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> X-ASG-Orig-Subj: Re: Corruption of in-memory data detected Subject: Re: Corruption of in-memory data detected From: Thomas Gutzler To: Eric Sandeen Cc: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: ti-out-0910.google.com[209.85.142.188] X-Barracuda-Start-Time: 1236739822 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.19996 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, a while ago I was having problems with the xfs module on ubuntu feisty. I have then upgraded to 8.10 intrepid and am still getting the occasional bug. Good thing is that now the system keeps running after the bug occurs with load slowly increasing as random processes are affected by this turn into zombies. On Fri, Jan 2, 2009 at 12:24, Eric Sandeen wrote: > Thomas Gutzler wrote: >> Hi, >> >> I've been running an 8x500G hardware SATA RAID5 on an adaptec 31605 >> controller for a while. The operating system is ubuntu feisty with the >> 2.6.22-16-server kernel. Recently, I added a disk. After the array >> rebuild was completed, I kept getting errors from the xfs module such >> as this one: >> Dec 30 22:55:39 io kernel: [21844.939832] Filesystem "sda": >> xfs_iflush: Bad inode 1610669723 magic number 0xec9d, ptr 0xe523eb00 >> Dec 30 22:55:39 io kernel: [21844.939879] xfs_force_shutdown(sda,0x8) >> called from line 3277 of file >> /build/buildd/linux-source-2.6.22-2.6.22/fs/xfs/xfs_inode.c. =C2=A0Retur= n >> address =3D 0xf8af263c >> Dec 30 22:55:39 io kernel: [21844.939885] Filesystem "sda": Corruption >> of in-memory data detected. =C2=A0Shutting down filesystem: sda >> >> My first thought was to run memcheck on the machine, which completed >> several passes without error; the raid controller doesn't report any >> SMART failures either. > > Both good ideas, but note that "Corruption of in-memory data detected" > doesn't necessarily mean bad memory (though it might, so memcheck was > prudent). =C2=A00xec9d is not the correct magic nr. for an on-disk inode,= so > that's why things went south. =C2=A0Were there no storage related errors > prior to this? > >> After an xfs_repair, which fixed a few things, > > Knowing which things were fixed might lend some clues ... > >> I mounted the file >> system but the error kept reappearing after a few hours unless I >> mounted read-only. Since xfs_ncheck -i always exited with 'Out of >> memory' > > xfs_check takes a ton of memory; xfs_repair much less so > >> I decided to reduce the max amount of inodes to 1% (156237488) >> by running xfs_growfs -m 1 - the total amount of inodes used is still >> less than 1%. Unfortunately, both xfs_check and xfs_ncheck still say >> 'out of memory' with 2GB installed. > > the max inodes really have no bearing on check or repair memory usage; > it's just an upper limit on how many inodes *could* be created. > >> After the modification, the file system survived for a day until the >> following happened: >> Jan =C2=A02 09:33:29 io kernel: [232751.699812] BUG: unable to handle >> kernel paging request at virtual address 0003fffb >> Jan =C2=A02 09:33:29 io kernel: [232751.699848] =C2=A0printing eip: >> Jan =C2=A02 09:33:29 io kernel: [232751.699863] c017d872 >> Jan =C2=A02 09:33:29 io kernel: [232751.699865] *pdpt =3D 000000003711e0= 01 >> Jan =C2=A02 09:33:29 io kernel: [232751.699881] *pde =3D 000000000000000= 0 >> Jan =C2=A02 09:33:29 io kernel: [232751.699898] Oops: 0002 [#1] >> Jan =C2=A02 09:33:29 io kernel: [232751.699913] SMP >> Jan =C2=A02 09:33:29 io kernel: [232751.699931] Modules linked in: nfs n= fsd >> exportfs lockd sunrpc xt_tcpudp nf_conntrack_ipv4 xt_state >> nf_conntrack nfnetlink iptable_filter ip_tables x_tables ipv6 ext2 >> mbcache coretemp w83627ehf i2c_isa i2c_core acpi_cpufreq >> cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand >> freq_table cpufreq_conservative psmouse serio_raw pcspkr shpchp >> pci_hotplug evdev intel_agp agpgart xfs sr_mod cdrom pata_jmicron >> ata_piix sg sd_mod ata_generic ohci1394 ieee1394 ahci libata e1000 >> aacraid scsi_mod uhci_hcd ehci_hcd usbcore thermal processor fan fuse >> apparmor commoncap >> Jan =C2=A02 09:33:29 io kernel: [232751.700180] CPU: =C2=A0 =C2=A01 >> Jan =C2=A02 09:33:29 io kernel: [232751.700181] EIP: >> 0060:[__slab_free+50/672] =C2=A0 =C2=A0Not tainted VLI >> Jan =C2=A02 09:33:29 io kernel: [232751.700182] EFLAGS: 00010046 >> (2.6.22-16-server #1) >> Jan =C2=A02 09:33:29 io kernel: [232751.700234] EIP is at __slab_free+0x= 32/0x2a0 > > Memory corruption perhaps? > >> Jan =C2=A02 09:33:29 io kernel: [232751.700252] eax: 0000ffff =C2=A0 ebx= : >> ffffffff =C2=A0 ecx: ffffffff =C2=A0 edx: 000014aa >> Jan =C2=A02 09:33:29 io kernel: [232751.700273] esi: c17fffe0 =C2=A0 edi= : >> e6b8e0c0 =C2=A0 ebp: f8ac2c8c =C2=A0 esp: c21dfe44 >> Jan =C2=A02 09:33:29 io kernel: [232751.700293] ds: 007b =C2=A0 es: 007b= =C2=A0 fs: >> 00d8 =C2=A0gs: 0000 =C2=A0ss: 0068 >> Jan =C2=A02 09:33:29 io kernel: [232751.700313] Process kswapd0 (pid: 19= 8, >> ti=3Dc21de000 task=3Dc21f39f0 task.ti=3Dc21de000) >> Jan =C2=A02 09:33:29 io kernel: [232751.700334] Stack: 00000000 00000065 >> 00000000 fffffffe ffffffff c17fffe0 00000287 e6b8e0c0 >> Jan =C2=A02 09:33:29 io kernel: [232751.700378] =C2=A0 =C2=A0 =C2=A0 =C2= =A000000001 c017e3fe >> f8ac2c8c cecb7d20 00000001 df2e2600 f8ac2c8c df2e2600 >> Jan =C2=A02 09:33:29 io kernel: [232751.700422] =C2=A0 =C2=A0 =C2=A0 =C2= =A0f8d7559c e8247900 >> f8ac5224 df2e2600 f8d7559c e8247900 f8ae1606 00000001 >> Jan =C2=A02 09:33:29 io kernel: [232751.700466] Call Trace: >> Jan =C2=A02 09:33:29 io kernel: [232751.700499] =C2=A0[kfree+126/192] kf= ree+0x7e/0xc0 >> Jan =C2=A02 09:33:29 io kernel: [232751.700519] =C2=A0[] >> xfs_idestroy_fork+0x2c/0xf0 [xfs] >> Jan =C2=A02 09:33:29 io kernel: [232751.700561] =C2=A0[] >> xfs_idestroy_fork+0x2c/0xf0 [xfs] >> Jan =C2=A02 09:33:29 io kernel: [232751.700601] =C2=A0[] >> xfs_idestroy+0x44/0xb0 [xfs] >> Jan =C2=A02 09:33:29 io kernel: [232751.700640] =C2=A0[] >> xfs_finish_reclaim+0x36/0x160 [xfs] >> Jan =C2=A02 09:33:29 io kernel: [232751.700681] =C2=A0[] >> xfs_fs_clear_inode+0x97/0xc0 [xfs] >> Jan =C2=A02 09:33:29 io kernel: [232751.700721] =C2=A0[clear_inode+143/3= 20] >> clear_inode+0x8f/0x140 >> Jan =C2=A02 09:33:29 io kernel: [232751.700743] =C2=A0[dispose_list+26/2= 24] >> dispose_list+0x1a/0xe0 >> Jan =C2=A02 09:33:29 io kernel: [232751.700765] >> [shrink_icache_memory+379/592] shrink_icache_memory+0x17b/0x250 >> Jan =C2=A02 09:33:29 io kernel: [232751.700789] =C2=A0[shrink_slab+279/3= 68] >> shrink_slab+0x117/0x170 >> Jan =C2=A02 09:33:29 io kernel: [232751.700815] =C2=A0[kswapd+859/1136] = kswapd+0x35b/0x470 >> Jan =C2=A02 09:33:29 io kernel: [232751.700842] >> [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 >> Jan =C2=A02 09:33:29 io kernel: [232751.700867] =C2=A0[kswapd+0/1136] ks= wapd+0x0/0x470 >> Jan =C2=A02 09:33:29 io kernel: [232751.700886] =C2=A0[kthread+66/112] k= thread+0x42/0x70 >> Jan =C2=A02 09:33:29 io kernel: [232751.700904] =C2=A0[kthread+0/112] kt= hread+0x0/0x70 >> Jan =C2=A02 09:33:29 io kernel: [232751.700923] >> [kernel_thread_helper+7/28] kernel_thread_helper+0x7/0x1c >> Jan =C2=A02 09:33:29 io kernel: [232751.700946] =C2=A0=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Jan =C2=A02 09:33:29 io kernel: [232751.700962] Code: 53 89 cb 83 ec 14 = 8b >> 6c 24 28 f0 0f ba 2e 00 19 c0 85 c0 74 0a 8b 06 a8 01 74 ef f3 90 eb >> f6 f6 06 02 75 48 0f b7 46 0a 8b 56 14 <89> 14 83 0f b7 46 08 89 5e 14 >> 83 e8 01 f6 06 40 66 89 46 08 75 >> Jan =C2=A02 09:33:29 io kernel: [232751.701128] EIP: [__slab_free+50/672= ] >> __slab_free+0x32/0x2a0 SS:ESP 0068:c21dfe44 >> >> Any thoughts what this could be or what could be done to fix it? > > seems like maybe something went wrong w/ the raid rebuild, if that's > when things started going south. =C2=A0Do you get any storage error relat= ed > messages at all? I couldn't find any errors other than the dump in dmesg (see below). I also called adaptec and they said they never had memory failure in they raid cards. > Ubuntu knows best what's in this oldish distro kernel, I guess; I don't > know offhand what might be going wrong. =C2=A0If they have a debug kernel > variant, you could run that to see if you get earlier indications of > problems. > > If you can reproduce on a more recent upstream kernel, that would be > interesting. Here's the dmesg output: [1369713.678092] BUG: unable to handle kernel paging request at ffff87f947d= a5088 [1369713.682882] IP: [] xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] [1369713.687802] PGD 0 [1369713.688055] Oops: 0000 [1] SMP [1369713.688055] CPU 1 [1369713.688055] Modules linked in: nls_cp437 cifs nfsd auth_rpcgss exportfs wmi video output sbs sbshc pci _slot container battery ac xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack nfs lockd nfs_acl sunrpc ipv6 iptable_filter ip_tables x_tables ext3 jbd mbcache cpufreq_userspace cpufreq_stats cpufreq_powersave cpufre q_ondemand cpufreq_conservative acpi_cpufreq freq_table sbp2 parport_pc lp parport loop evdev pcspkr iTCO_w dt iTCO_vendor_support button shpchp pci_hotplug intel_agp xfs pata_jmicron sd_mod crc_t10dif sg pata_acpi ata_piix ohci1394 ieee1394 aacraid ata_generic ahci libata scsi_mod e1000e dock uhci_hcd ehci_hcd usbcore t hermal processor fan fuse vesafb fbcon tileblit font bitblit softcursor [1369713.688055] Pid: 5278, comm: smbd Not tainted 2.6.27-11-server #1 [1369713.688055] RIP: 0010:[] [] xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] [1369713.688055] RSP: 0018:ffff88007120ba28 EFLAGS: 00010286 [1369713.688055] RAX: 00000005a072ded8 RBX: 00000000da072ded RCX: 0000000000000000 [1369713.688055] RDX: 00000000b40e5bda RSI: ffff88007a474c48 RDI: ffffffffda072ded [1369713.688055] RBP: ffff88007120ba98 R08: ffff87fa77a0e120 R09: 00000000ffffffff [1369713.688055] R10: 00000000db5b0eb4 R11: ffff88001813bff8 R12: ffff88007120bae8 [1369713.688055] R13: 000000000000002a R14: 0000000000000000 R15: ffff88007120bb74 [1369713.688055] FS: 00007f79bf44e700(0000) GS:ffff88007f802880(0000) knlGS:0000000000000000 [1369713.688055] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [1369713.688055] CR2: ffff87f947da5088 CR3: 0000000053e88000 CR4: 00000000000006e0 [1369713.688055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1369713.688055] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [1369713.688055] Process smbd (pid: 5278, threadinfo ffff88007120a000, task ffff88000350ace0) [1369713.688055] Stack: ffff88007120bd68 ffffffff802fa04c ffff88007120bab4 ffff88007120baa8 [1369713.688055] ffff88001813b000 ffff88007acb3000 0000000000000000 ffffffffa01d0289 [1369713.688055] ffff88007a474c48 ffff880035a2c8c0 ffff88007120bae8 ffff88007120bae8 [1369713.688055] Call Trace: [1369713.688055] [] ? do_select+0x5bc/0x610 [1369713.688055] [] ? xfs_bmbt_get_blockcount+0x9/0x20 [= xfs] [1369713.688055] [] xfs_dir2_block_lookup+0x20/0xc0 [xfs= ] [1369713.688055] [] xfs_dir_lookup+0x195/0x1c0 [xfs] [1369713.688055] [] xfs_lookup+0x7b/0xe0 [xfs] [1369713.688055] [] ? __d_lookup+0x16/0x150 [1369713.688055] [] xfs_vn_lookup+0x51/0x90 [xfs] [1369713.688055] [] real_lookup+0xee/0x170 [1369713.688055] [] do_lookup+0xb0/0x110 [1369713.688055] [] __link_path_walk+0x60d/0xc20 [1369713.688055] [] ? mntput_no_expire+0x36/0x160 [1369713.688055] [] path_walk+0x6e/0xe0 [1369713.688055] [] do_path_lookup+0xe3/0x200 [1369713.688055] [] ? getname+0x4a/0xb0 [1369713.688055] [] user_path_at+0x7b/0xb0 [1369713.688055] [] ? cp_new_stat+0xe8/0x100 [1369713.688055] [] vfs_stat_fd+0x2d/0x60 [1369713.688055] [] sys_newstat+0x2c/0x50 [1369713.688055] [] system_call_fastpath+0x16/0x1b [1369713.688055] [1369713.688055] [1369713.688055] Code: f8 31 c9 45 8b 13 4d 89 d8 44 89 d2 0f ca 89 d0 83 ea 01 48 c1 e0 03 49 29 c0 eb 07 8d 4b 01 39 ca 7c 1c 8d 1c 11 d1 fb 48 63 fb <41> 8b 04 f8 0f c8 41 39 c5 74 26 77 e4 8d 53 ff 39 ca 7d e4 48 [1369713.688055] RIP [] xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] [1369713.688055] RSP [1369713.688055] CR2: ffff87f947da5088 [1369714.057232] ---[ end trace 0735c8702d5e7899 ]--- What can I do to help getting this fixed? Tom From sandeen@sandeen.net Tue Mar 10 23:31:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2B4Uu58248825 for ; Tue, 10 Mar 2009 23:31:17 -0500 X-ASG-Debug-ID: 1236745811-3f1001ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1F4B01C320C3 for ; Tue, 10 Mar 2009 21:30:11 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id pFmBQb4rpv5AelPx for ; Tue, 10 Mar 2009 21:30:11 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2B4U93e030538; Wed, 11 Mar 2009 00:30:09 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2B4U9qm003563; Wed, 11 Mar 2009 00:30:09 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2B4U7P1026046; Wed, 11 Mar 2009 00:30:08 -0400 Message-ID: <49B73E50.5080906@sandeen.net> Date: Tue, 10 Mar 2009 23:30:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Thomas Gutzler CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data detected Subject: Re: Corruption of in-memory data detected References: <169670ec0901011846q1d370e6cu31514519afc8295d@mail.gmail.com> <495D88EE.2040406@sandeen.net> <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> In-Reply-To: <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236745833 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20002 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Thomas Gutzler wrote: > Hi, > > a while ago I was having problems with the xfs module on ubuntu > feisty. I have then upgraded to 8.10 intrepid and am still getting the > occasional bug. although from the looks of it, a different one. I'm curious, if you log these bug with Ubuntu, do they look into it? It'd be nice to at least have initial triage to know for example where in the function it blew up. > Good thing is that now the system keeps running after > the bug occurs with load slowly increasing as random processes are > affected by this turn into zombies. ... >>> Jan 2 09:33:29 io kernel: [232751.701128] EIP: [__slab_free+50/672] >>> __slab_free+0x32/0x2a0 SS:ESP 0068:c21dfe44 ... last error was slab corruption perhaps >>> Any thoughts what this could be or what could be done to fix it? >> seems like maybe something went wrong w/ the raid rebuild, if that's >> when things started going south. Do you get any storage error related >> messages at all? > > I couldn't find any errors other than the dump in dmesg (see below). > I also called adaptec and they said they never had memory failure in > they raid cards. > >> Ubuntu knows best what's in this oldish distro kernel, I guess; I don't >> know offhand what might be going wrong. If they have a debug kernel >> variant, you could run that to see if you get earlier indications of >> problems. >> >> If you can reproduce on a more recent upstream kernel, that would be >> interesting. > > Here's the dmesg output: > [1369713.678092] BUG: unable to handle kernel paging request at ffff87f947da5088 > [1369713.682882] IP: [] > xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] Ok, so this looks like a different problem; at least a different oops. > [1369713.687802] PGD 0 > [1369713.688055] Oops: 0000 [1] SMP > [1369713.688055] CPU 1 > [1369713.688055] Modules linked in: nls_cp437 cifs nfsd auth_rpcgss > exportfs wmi video output sbs sbshc pci > _slot container battery ac xt_tcpudp nf_conntrack_ipv4 xt_state > nf_conntrack nfs lockd nfs_acl sunrpc ipv6 > iptable_filter ip_tables x_tables ext3 jbd mbcache cpufreq_userspace > cpufreq_stats cpufreq_powersave cpufre > q_ondemand cpufreq_conservative acpi_cpufreq freq_table sbp2 > parport_pc lp parport loop evdev pcspkr iTCO_w > dt iTCO_vendor_support button shpchp pci_hotplug intel_agp xfs > pata_jmicron sd_mod crc_t10dif sg pata_acpi > ata_piix ohci1394 ieee1394 aacraid ata_generic ahci libata scsi_mod > e1000e dock uhci_hcd ehci_hcd usbcore t > hermal processor fan fuse vesafb fbcon tileblit font bitblit softcursor > [1369713.688055] Pid: 5278, comm: smbd Not tainted 2.6.27-11-server #1 > [1369713.688055] RIP: 0010:[] [] > xfs_dir2_block_lookup_int+0xcf/0x210 > [xfs] > [1369713.688055] RSP: 0018:ffff88007120ba28 EFLAGS: 00010286 > [1369713.688055] RAX: 00000005a072ded8 RBX: 00000000da072ded RCX: > 0000000000000000 > [1369713.688055] RDX: 00000000b40e5bda RSI: ffff88007a474c48 RDI: > ffffffffda072ded > [1369713.688055] RBP: ffff88007120ba98 R08: ffff87fa77a0e120 R09: > 00000000ffffffff > [1369713.688055] R10: 00000000db5b0eb4 R11: ffff88001813bff8 R12: > ffff88007120bae8 > [1369713.688055] R13: 000000000000002a R14: 0000000000000000 R15: > ffff88007120bb74 > [1369713.688055] FS: 00007f79bf44e700(0000) GS:ffff88007f802880(0000) > knlGS:0000000000000000 > [1369713.688055] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [1369713.688055] CR2: ffff87f947da5088 CR3: 0000000053e88000 CR4: > 00000000000006e0 > [1369713.688055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > [1369713.688055] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > 0000000000000400 > [1369713.688055] Process smbd (pid: 5278, threadinfo ffff88007120a000, > task ffff88000350ace0) > [1369713.688055] Stack: ffff88007120bd68 ffffffff802fa04c > ffff88007120bab4 ffff88007120baa8 > [1369713.688055] ffff88001813b000 ffff88007acb3000 0000000000000000 > ffffffffa01d0289 > [1369713.688055] ffff88007a474c48 ffff880035a2c8c0 ffff88007120bae8 > ffff88007120bae8 > [1369713.688055] Call Trace: > [1369713.688055] [] ? do_select+0x5bc/0x610 > [1369713.688055] [] ? xfs_bmbt_get_blockcount+0x9/0x20 [xfs] > [1369713.688055] [] xfs_dir2_block_lookup+0x20/0xc0 [xfs] > [1369713.688055] [] xfs_dir_lookup+0x195/0x1c0 [xfs] > [1369713.688055] [] xfs_lookup+0x7b/0xe0 [xfs] > [1369713.688055] [] ? __d_lookup+0x16/0x150 > [1369713.688055] [] xfs_vn_lookup+0x51/0x90 [xfs] > [1369713.688055] [] real_lookup+0xee/0x170 > [1369713.688055] [] do_lookup+0xb0/0x110 > [1369713.688055] [] __link_path_walk+0x60d/0xc20 > [1369713.688055] [] ? mntput_no_expire+0x36/0x160 > [1369713.688055] [] path_walk+0x6e/0xe0 > [1369713.688055] [] do_path_lookup+0xe3/0x200 > [1369713.688055] [] ? getname+0x4a/0xb0 > [1369713.688055] [] user_path_at+0x7b/0xb0 > [1369713.688055] [] ? cp_new_stat+0xe8/0x100 > [1369713.688055] [] vfs_stat_fd+0x2d/0x60 > [1369713.688055] [] sys_newstat+0x2c/0x50 > [1369713.688055] [] system_call_fastpath+0x16/0x1b > [1369713.688055] > [1369713.688055] > [1369713.688055] Code: f8 31 c9 45 8b 13 4d 89 d8 44 89 d2 0f ca 89 d0 > 83 ea 01 48 c1 e0 03 49 29 c0 eb 07 8d 4b 01 39 ca 7c 1c 8d 1c 11 d1 > fb 48 63 fb <41> 8b 04 f8 0f c8 41 39 c5 74 26 77 e4 8d 53 ff 39 ca 7d > e4 48 > [1369713.688055] RIP [] > xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] > [1369713.688055] RSP > [1369713.688055] CR2: ffff87f947da5088 > [1369714.057232] ---[ end trace 0735c8702d5e7899 ]--- > > What can I do to help getting this fixed? > > Tom can you make an xfs_metadump of the filesystem in question, and then try an xfs_repair? Capture/save the repair output. If repair finds errors, then perhaps the bug is triggered by bad error checking on a corrupted image, and we might reproduce it w/ the metadump image. It'd be nice if ubuntu had debug kernel variants (Fedora does this, I dunno about ubuntu) - if you are hitting any kind of memory corruption then a kernel with debug checks enabled might catch it sooner. -Eric From thomas.gutzler@gmail.com Wed Mar 11 05:43:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2BAh67F003685 for ; Wed, 11 Mar 2009 05:43:22 -0500 X-ASG-Debug-ID: 1236768139-745002f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from panacea.ucs.uwa.edu.au (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 61FCC1895EB for ; Wed, 11 Mar 2009 03:42:19 -0700 (PDT) Received: from panacea.ucs.uwa.edu.au (panacea.ucs.uwa.edu.au [130.95.128.132]) by cuda.sgi.com with ESMTP id 5CzYTz4G5QVJcesG for ; Wed, 11 Mar 2009 03:42:19 -0700 (PDT) Received: from kas30pipe.localhost (localhost.localdomain [127.0.0.1]) by panacea.uwa.edu.au (Postfix) with ESMTP id 5F6DE88127 for ; Wed, 11 Mar 2009 19:42:17 +0900 (WST) Received: from panacea (localhost.localdomain [127.0.0.1]) by panacea.prekas (Postfix) with SMTP id D2AE388111 for ; Wed, 11 Mar 2009 19:42:16 +0900 (WST) X-UWA-Client-IP: 130.95.208.1 (UWA) Received: from swanee.ee.uwa.edu.au (mailgate.ee.uwa.edu.au [130.95.208.1]) by panacea.extinput (Postfix) with ESMTP id 8F0ED88127 for ; Wed, 11 Mar 2009 19:42:16 +0900 (WST) Received: from badger.ee.uwa.edu.au ([130.95.208.10] helo=mail.ee.uwa.edu.au) by swanee.ee.uwa.edu.au with esmtp (Exim 4.69) (envelope-from ) id 1LhLt7-0003DJ-Ma; Wed, 11 Mar 2009 19:42:13 +0900 Received: from krikkit.ee.uwa.edu.au ([130.95.136.109]) by mail.ee.uwa.edu.au with esmtp (Exim 4.69) (envelope-from ) id 1LhLt7-0001Ub-9m; Wed, 11 Mar 2009 19:42:13 +0900 Message-ID: <49B79586.5060801@gmail.com> Date: Wed, 11 Mar 2009 19:42:14 +0900 From: Thomas Gutzler User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Sandeen Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data detected Subject: Re: Corruption of in-memory data detected References: <169670ec0901011846q1d370e6cu31514519afc8295d@mail.gmail.com> <495D88EE.2040406@sandeen.net> <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> <49B73E50.5080906@sandeen.net> In-Reply-To: <49B73E50.5080906@sandeen.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------000302040506060400060204" X-SpamTest-Envelope-From: thomas.gutzler@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 7661 [Mar 11 2009] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-Barracuda-Connect: panacea.ucs.uwa.edu.au[130.95.128.132] X-Barracuda-Start-Time: 1236768162 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20025 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. --------------000302040506060400060204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Thomas Gutzler wrote: >> Hi, >> >> a while ago I was having problems with the xfs module on ubuntu >> feisty. I have then upgraded to 8.10 intrepid and am still getting the >> occasional bug. > > although from the looks of it, a different one. I'm curious, if you log > these bug with Ubuntu, do they look into it? It'd be nice to at least > have initial triage to know for example where in the function it blew up. I can see myself heading this way. >> Here's the dmesg output: >> [1369713.678092] BUG: unable to handle kernel paging request at ffff87f947da5088 >> [1369713.682882] IP: [] >> xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] > > Ok, so this looks like a different problem; at least a different oops. > >> [1369713.687802] PGD 0 >> [1369713.688055] Oops: 0000 [1] SMP >> [1369713.688055] CPU 1 >> [1369713.688055] Modules linked in: nls_cp437 cifs nfsd auth_rpcgss >> exportfs wmi video output sbs sbshc pci >> _slot container battery ac xt_tcpudp nf_conntrack_ipv4 xt_state >> nf_conntrack nfs lockd nfs_acl sunrpc ipv6 >> iptable_filter ip_tables x_tables ext3 jbd mbcache cpufreq_userspace >> cpufreq_stats cpufreq_powersave cpufre >> q_ondemand cpufreq_conservative acpi_cpufreq freq_table sbp2 >> parport_pc lp parport loop evdev pcspkr iTCO_w >> dt iTCO_vendor_support button shpchp pci_hotplug intel_agp xfs >> pata_jmicron sd_mod crc_t10dif sg pata_acpi >> ata_piix ohci1394 ieee1394 aacraid ata_generic ahci libata scsi_mod >> e1000e dock uhci_hcd ehci_hcd usbcore t >> hermal processor fan fuse vesafb fbcon tileblit font bitblit softcursor >> [1369713.688055] Pid: 5278, comm: smbd Not tainted 2.6.27-11-server #1 >> [1369713.688055] RIP: 0010:[] [] >> xfs_dir2_block_lookup_int+0xcf/0x210 >> [xfs] >> [1369713.688055] RSP: 0018:ffff88007120ba28 EFLAGS: 00010286 >> [1369713.688055] RAX: 00000005a072ded8 RBX: 00000000da072ded RCX: >> 0000000000000000 >> [1369713.688055] RDX: 00000000b40e5bda RSI: ffff88007a474c48 RDI: >> ffffffffda072ded >> [1369713.688055] RBP: ffff88007120ba98 R08: ffff87fa77a0e120 R09: >> 00000000ffffffff >> [1369713.688055] R10: 00000000db5b0eb4 R11: ffff88001813bff8 R12: >> ffff88007120bae8 >> [1369713.688055] R13: 000000000000002a R14: 0000000000000000 R15: >> ffff88007120bb74 >> [1369713.688055] FS: 00007f79bf44e700(0000) GS:ffff88007f802880(0000) >> knlGS:0000000000000000 >> [1369713.688055] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> [1369713.688055] CR2: ffff87f947da5088 CR3: 0000000053e88000 CR4: >> 00000000000006e0 >> [1369713.688055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> 0000000000000000 >> [1369713.688055] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: >> 0000000000000400 >> [1369713.688055] Process smbd (pid: 5278, threadinfo ffff88007120a000, >> task ffff88000350ace0) >> [1369713.688055] Stack: ffff88007120bd68 ffffffff802fa04c >> ffff88007120bab4 ffff88007120baa8 >> [1369713.688055] ffff88001813b000 ffff88007acb3000 0000000000000000 >> ffffffffa01d0289 >> [1369713.688055] ffff88007a474c48 ffff880035a2c8c0 ffff88007120bae8 >> ffff88007120bae8 >> [1369713.688055] Call Trace: >> [1369713.688055] [] ? do_select+0x5bc/0x610 >> [1369713.688055] [] ? xfs_bmbt_get_blockcount+0x9/0x20 [xfs] >> [1369713.688055] [] xfs_dir2_block_lookup+0x20/0xc0 [xfs] >> [1369713.688055] [] xfs_dir_lookup+0x195/0x1c0 [xfs] >> [1369713.688055] [] xfs_lookup+0x7b/0xe0 [xfs] >> [1369713.688055] [] ? __d_lookup+0x16/0x150 >> [1369713.688055] [] xfs_vn_lookup+0x51/0x90 [xfs] >> [1369713.688055] [] real_lookup+0xee/0x170 >> [1369713.688055] [] do_lookup+0xb0/0x110 >> [1369713.688055] [] __link_path_walk+0x60d/0xc20 >> [1369713.688055] [] ? mntput_no_expire+0x36/0x160 >> [1369713.688055] [] path_walk+0x6e/0xe0 >> [1369713.688055] [] do_path_lookup+0xe3/0x200 >> [1369713.688055] [] ? getname+0x4a/0xb0 >> [1369713.688055] [] user_path_at+0x7b/0xb0 >> [1369713.688055] [] ? cp_new_stat+0xe8/0x100 >> [1369713.688055] [] vfs_stat_fd+0x2d/0x60 >> [1369713.688055] [] sys_newstat+0x2c/0x50 >> [1369713.688055] [] system_call_fastpath+0x16/0x1b >> [1369713.688055] >> [1369713.688055] >> [1369713.688055] Code: f8 31 c9 45 8b 13 4d 89 d8 44 89 d2 0f ca 89 d0 >> 83 ea 01 48 c1 e0 03 49 29 c0 eb 07 8d 4b 01 39 ca 7c 1c 8d 1c 11 d1 >> fb 48 63 fb <41> 8b 04 f8 0f c8 41 39 c5 74 26 77 e4 8d 53 ff 39 ca 7d >> e4 48 >> [1369713.688055] RIP [] >> xfs_dir2_block_lookup_int+0xcf/0x210 [xfs] >> [1369713.688055] RSP >> [1369713.688055] CR2: ffff87f947da5088 >> [1369714.057232] ---[ end trace 0735c8702d5e7899 ]--- >> >> What can I do to help getting this fixed? >> > can you make an xfs_metadump of the filesystem in question, and then try > an xfs_repair? Capture/save the repair output. If repair finds errors, > then perhaps the bug is triggered by bad error checking on a corrupted > image, and we might reproduce it w/ the metadump image. I tried... root@io:~# xfs_metadump /dev/sda xfs_metadump_sda *** glibc detected *** xfs_db: double free or corruption (out): 0x00000000017b8000 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f4f10298a58] /lib/libc.so.6(cfree+0x76)[0x7f4f1029b0a6] xfs_db[0x416f53] xfs_db[0x4189b9] xfs_db[0x41b4db] xfs_db[0x4186f5] xfs_db[0x41b07e] xfs_db[0x4186f5] xfs_db[0x41aa4b] xfs_db[0x415d03] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4f1023d466] xfs_db[0x4029d9] ======= Memory map: ======== 00400000-00477000 r-xp 00000000 08:17 100768239 /usr/sbin/xfs_db 00676000-00678000 rw-p 00076000 08:17 100768239 /usr/sbin/xfs_db 00678000-00683000 rw-p 00678000 00:00 0 0176a000-017cc000 rw-p 0176a000 00:00 0 [heap] 7f4f08000000-7f4f08021000 rw-p 7f4f08000000 00:00 0 7f4f08021000-7f4f0c000000 ---p 7f4f08021000 00:00 0 7f4f0fbc8000-7f4f0fbde000 r-xp 00000000 08:15 50382939 /lib/libgcc_s.so.1 7f4f0fbde000-7f4f0fdde000 ---p 00016000 08:15 50382939 /lib/libgcc_s.so.1 7f4f0fdde000-7f4f0fddf000 r--p 00016000 08:15 50382939 /lib/libgcc_s.so.1 7f4f0fddf000-7f4f0fde0000 rw-p 00017000 08:15 50382939 /lib/libgcc_s.so.1 7f4f0fde0000-7f4f0fde2000 r-xp 00000000 08:15 50712055 /lib/libdl-2.8.90.so 7f4f0fde2000-7f4f0ffe2000 ---p 00002000 08:15 50712055 /lib/libdl-2.8.90.so 7f4f0ffe2000-7f4f0ffe3000 r--p 00002000 08:15 50712055 /lib/libdl-2.8.90.so 7f4f0ffe3000-7f4f0ffe4000 rw-p 00003000 08:15 50712055 /lib/libdl-2.8.90.so 7f4f0ffe4000-7f4f1001b000 r-xp 00000000 08:15 50331947 /lib/libncurses.so.5.6 7f4f1001b000-7f4f1021a000 ---p 00037000 08:15 50331947 /lib/libncurses.so.5.6 7f4f1021a000-7f4f1021f000 rw-p 00036000 08:15 50331947 /lib/libncurses.so.5.6 7f4f1021f000-7f4f10388000 r-xp 00000000 08:15 50712052 /lib/libc-2.8.90.so 7f4f10388000-7f4f10587000 ---p 00169000 08:15 50712052 /lib/libc-2.8.90.so 7f4f10587000-7f4f1058b000 r--p 00168000 08:15 50712052 /lib/libc-2.8.90.so 7f4f1058b000-7f4f1058c000 rw-p 0016c000 08:15 50712052 /lib/libc-2.8.90.so 7f4f1058c000-7f4f10591000 rw-p 7f4f1058c000 00:00 0 7f4f10591000-7f4f105c8000 r-xp 00000000 08:15 50363305 /lib/libreadline.so.5.2 7f4f105c8000-7f4f107c8000 ---p 00037000 08:15 50363305 /lib/libreadline.so.5.2 7f4f107c8000-7f4f107d0000 rw-p 00037000 08:15 50363305 /lib/libreadline.so.5.2 7f4f107d0000-7f4f107d1000 rw-p 7f4f107d0000 00:00 0 7f4f107d1000-7f4f107e8000 r-xp 00000000 08:15 50630786 /lib/libpthread-2.8.90.so 7f4f107e8000-7f4f109e7000 ---p 00017000 08:15 50630786 /lib/libpthread-2.8.90.so 7f4f109e7000-7f4f109e8000 r--p 00016000 08:15 50630786 /lib/libpthread-2.8.90.so 7f4f109e8000-7f4f109e9000 rw-p 00017000 08:15 50630786 /lib/libpthread-2.8.90.so 7f4f109e9000-7f4f109ed000 rw-p 7f4f109e9000 00:00 0 7f4f109ed000-7f4f109f5000 r-xp 00000000 08:15 50630788 /lib/librt-2.8.90.so 7f4f109f5000-7f4f10bf4000 ---p 00008000 08:15 50630788 /lib/librt-2.8.90.so 7f4f10bf4000-7f4f10bf5000 r--p 00007000 08:15 50630788 /lib/librt-2.8.90.so 7f4f10bf5000-7f4f10bf6000 rw-p 00008000 08:15 50630788 /lib/librt-2.8.90.so 7f4f10bf6000-7f4f10bf9000 r-xp 00000000 08:15 50331815 /lib/libuuid.so.1.2 7f4f10bf9000-7f4f10df9000 ---p 00003000 08:15 50331815 /lib/libuuid.so.1.2 7f4f10df9000-7f4f10dfa000 r--p 00003000 08:15 50331815 /lib/libuuid.so.1.2 7f4f10dfa000-7f4f10dfb000 rw-p 00004000 08:15 50331815 /lib/libuuid.so.1.2 7f4f10dfb000-7f4f10e1a000 r-xp 00000000 08:15 50712049 /lib/ld-2.8.90.so 7f4f10fcc000-7f4f11011000 rw-p 7f4f10fcc000 00:00 0 7f4f11015000-7f4f11019000 rw-p 7f4f11015000 00:00 0 7f4f11019000-7f4f1101a000 r--p 0001e000 08:15 50712049 /lib/ld-2.8.90.so 7f4f1101a000-7f4f1101b000 rw-p 0001f000 08:15 50712049 /lib/ld-2.8.90.so 7fff19006000-7fff1901b000 rw-p 7ffffffea000 00:00 0 [stack] 7fff191ff000-7fff19200000 r-xp 7fff191ff000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted and tried again: root@io:~# xfs_metadump -w /dev/sda xfs_metadump_sda root@io:~# ll xfs_metadump_sda -rw-r--r-- 1 root root 588407296 2009-03-11 19:09 xfs_metadump_sda (where do I upload this to?) xfs_repair fixed "bad names" of 4 inodes (see attached log file) another xfs_metadump /dev/sda xfs_metadump_sda_2 (without -w): -rw-r--r-- 1 root root 588261888 2009-03-11 19:23 xfs_metadump_sda_2 > It'd be nice if ubuntu had debug kernel variants (Fedora does this, I > dunno about ubuntu) - if you are hitting any kind of memory corruption > then a kernel with debug checks enabled might catch it sooner. I haven't seen any - probably have to build my own debug kernel. Oh joy. Is the metadump of any use? Tom --------------000302040506060400060204 Content-Type: text/plain; name="xfs_repair.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="xfs_repair.log" U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIDExIE1hciAyMDA5IDE5OjEyOjMxIFdTVApyb290QGlv On4jIHhmc19yZXBhaXIgLXYgL2Rldi9zZGEgDQpQaGFzZSAxIC0gZmluZCBhbmQgdmVyaWZ5 IHN1cGVyYmxvY2suLi4NCiAgICAgICAgLSBibG9jayBjYWNoZSBzaXplIHNldCB0byAxMjYz NDQgZW50cmllcw0KUGhhc2UgMiAtIHVzaW5nIGludGVybmFsIGxvZw0KICAgICAgICAtIHpl cm8gbG9nLi4uDQp6ZXJvX2xvZzogaGVhZCBibG9jayA5NTQ0NyB0YWlsIGJsb2NrIDk1NDQ3 DQogICAgICAgIC0gc2NhbiBmaWxlc3lzdGVtIGZyZWVzcGFjZSBhbmQgaW5vZGUgbWFwcy4u Lg0KICAgICAgICAtIGZvdW5kIHJvb3QgaW5vZGUgY2h1bmsNClBoYXNlIDMgLSBmb3IgZWFj aCBBRy4uLg0KICAgICAgICAtIHNjYW4gYW5kIGNsZWFyIGFnaSB1bmxpbmtlZCBsaXN0cy4u Lg0KICAgICAgICAtIHByb2Nlc3Mga25vd24gaW5vZGVzIGFuZCBwZXJmb3JtIGlub2RlIGRp c2NvdmVyeS4uLg0KICAgICAgICAtIGFnbm8gPSAwDQogICAgICAgIC0gYWdubyA9IDENCmF0 dHJpYnV0ZSBlbnRyeSAwIGluIGF0dHIgYmxvY2sgMCwgaW5vZGUgNTM2OTI4ODk2IGhhcyBi YWQgbmFtZSAobmFtZWxlbiA9IDApDQpwcm9ibGVtIHdpdGggYXR0cmlidXRlIGNvbnRlbnRz IGluIGlub2RlIDUzNjkyODg5Ng0KY2xlYXJpbmcgaW5vZGUgNTM2OTI4ODk2IGF0dHJpYnV0 ZXMNCmNvcnJlY3RpbmcgbmJsb2NrcyBmb3IgaW5vZGUgNTM2OTI4ODk2LCB3YXMgMSAtIGNv dW50ZWQgMA0KYXR0cmlidXRlIGVudHJ5IDAgaW4gYXR0ciBibG9jayAwLCBpbm9kZSA1Mzgw OTU5MjAgaGFzIGJhZCBuYW1lIChuYW1lbGVuID0gMCkNCnByb2JsZW0gd2l0aCBhdHRyaWJ1 dGUgY29udGVudHMgaW4gaW5vZGUgNTM4MDk1OTIwDQpjbGVhcmluZyBpbm9kZSA1MzgwOTU5 MjAgYXR0cmlidXRlcw0KY29ycmVjdGluZyBuYmxvY2tzIGZvciBpbm9kZSA1MzgwOTU5MjAs IHdhcyAxIC0gY291bnRlZCAwDQogICAgICAgIC0gYWdubyA9IDINCmF0dHJpYnV0ZSBlbnRy eSAwIGluIGF0dHIgYmxvY2sgMCwgaW5vZGUgMTA3NTAzNTcwOSBoYXMgYmFkIG5hbWUgKG5h bWVsZW4gPSAwKQ0KcHJvYmxlbSB3aXRoIGF0dHJpYnV0ZSBjb250ZW50cyBpbiBpbm9kZSAx MDc1MDM1NzA5DQpjbGVhcmluZyBpbm9kZSAxMDc1MDM1NzA5IGF0dHJpYnV0ZXMNCmNvcnJl Y3RpbmcgbmJsb2NrcyBmb3IgaW5vZGUgMTA3NTAzNTcwOSwgd2FzIDEgLSBjb3VudGVkIDAN CiAgICAgICAgLSBhZ25vID0gMw0KICAgICAgICAtIGFnbm8gPSA0DQogICAgICAgIC0gYWdu byA9IDUNCmF0dHJpYnV0ZSBlbnRyeSAwIGluIGF0dHIgYmxvY2sgMCwgaW5vZGUgMjY4NDM3 MTcxNSBoYXMgYmFkIG5hbWUgKG5hbWVsZW4gPSAwKQ0KcHJvYmxlbSB3aXRoIGF0dHJpYnV0 ZSBjb250ZW50cyBpbiBpbm9kZSAyNjg0MzcxNzE1DQpjbGVhcmluZyBpbm9kZSAyNjg0Mzcx NzE1IGF0dHJpYnV0ZXMNCmNvcnJlY3RpbmcgbmJsb2NrcyBmb3IgaW5vZGUgMjY4NDM3MTcx NSwgd2FzIDEgLSBjb3VudGVkIDANCiAgICAgICAgLSBhZ25vID0gNg0KICAgICAgICAtIGFn bm8gPSA3DQogICAgICAgIC0gYWdubyA9IDgNCiAgICAgICAgLSBhZ25vID0gOQ0KICAgICAg ICAtIGFnbm8gPSAxMA0KICAgICAgICAtIGFnbm8gPSAxMQ0KICAgICAgICAtIGFnbm8gPSAx Mg0KICAgICAgICAtIGFnbm8gPSAxMw0KICAgICAgICAtIGFnbm8gPSAxNA0KICAgICAgICAt IGFnbm8gPSAxNQ0KICAgICAgICAtIGFnbm8gPSAxNg0KICAgICAgICAtIGFnbm8gPSAxNw0K ICAgICAgICAtIGFnbm8gPSAxOA0KICAgICAgICAtIGFnbm8gPSAxOQ0KICAgICAgICAtIGFn bm8gPSAyMA0KICAgICAgICAtIGFnbm8gPSAyMQ0KICAgICAgICAtIGFnbm8gPSAyMg0KICAg ICAgICAtIGFnbm8gPSAyMw0KICAgICAgICAtIGFnbm8gPSAyNA0KICAgICAgICAtIGFnbm8g PSAyNQ0KICAgICAgICAtIGFnbm8gPSAyNg0KICAgICAgICAtIGFnbm8gPSAyNw0KICAgICAg ICAtIGFnbm8gPSAyOA0KICAgICAgICAtIGFnbm8gPSAyOQ0KICAgICAgICAtIGFnbm8gPSAz MA0KICAgICAgICAtIGFnbm8gPSAzMQ0KICAgICAgICAtIGFnbm8gPSAzMg0KICAgICAgICAt IGFnbm8gPSAzMw0KICAgICAgICAtIGFnbm8gPSAzNA0KICAgICAgICAtIGFnbm8gPSAzNQ0K ICAgICAgICAtIGFnbm8gPSAzNg0KICAgICAgICAtIHByb2Nlc3MgbmV3bHkgZGlzY292ZXJl ZCBpbm9kZXMuLi4NClBoYXNlIDQgLSBjaGVjayBmb3IgZHVwbGljYXRlIGJsb2Nrcy4uLg0K ICAgICAgICAtIHNldHRpbmcgdXAgZHVwbGljYXRlIGV4dGVudCBsaXN0Li4uDQogICAgICAg IC0gY2hlY2sgZm9yIGlub2RlcyBjbGFpbWluZyBkdXBsaWNhdGUgYmxvY2tzLi4uDQogICAg ICAgIC0gYWdubyA9IDANCiAgICAgICAgLSBhZ25vID0gMQ0KYmFkIGF0dHJpYnV0ZSBmb3Jt YXQgMSBpbiBpbm9kZSA1MzY5Mjg4OTYsIHJlc2V0dGluZyB2YWx1ZQ0KYmFkIGF0dHJpYnV0 ZSBmb3JtYXQgMSBpbiBpbm9kZSA1MzgwOTU5MjAsIHJlc2V0dGluZyB2YWx1ZQ0KICAgICAg ICAtIGFnbm8gPSAyDQogICAgICAgIC0gYWdubyA9IDMNCmJhZCBhdHRyaWJ1dGUgZm9ybWF0 IDEgaW4gaW5vZGUgMTA3NTAzNTcwOSwgcmVzZXR0aW5nIHZhbHVlDQogICAgICAgIC0gYWdu byA9IDQNCiAgICAgICAgLSBhZ25vID0gNQ0KYmFkIGF0dHJpYnV0ZSBmb3JtYXQgMSBpbiBp bm9kZSAyNjg0MzcxNzE1LCByZXNldHRpbmcgdmFsdWUNCiAgICAgICAgLSBhZ25vID0gNg0K ICAgICAgICAtIGFnbm8gPSA3DQogICAgICAgIC0gYWdubyA9IDgNCiAgICAgICAgLSBhZ25v ID0gOQ0KICAgICAgICAtIGFnbm8gPSAxMA0KICAgICAgICAtIGFnbm8gPSAxMQ0KICAgICAg ICAtIGFnbm8gPSAxMg0KICAgICAgICAtIGFnbm8gPSAxMw0KICAgICAgICAtIGFnbm8gPSAx NA0KICAgICAgICAtIGFnbm8gPSAxNQ0KICAgICAgICAtIGFnbm8gPSAxNg0KICAgICAgICAt IGFnbm8gPSAxNw0KICAgICAgICAtIGFnbm8gPSAxOA0KICAgICAgICAtIGFnbm8gPSAxOQ0K ICAgICAgICAtIGFnbm8gPSAyMA0KICAgICAgICAtIGFnbm8gPSAyMQ0KICAgICAgICAtIGFn bm8gPSAyMg0KICAgICAgICAtIGFnbm8gPSAyMw0KICAgICAgICAtIGFnbm8gPSAyNA0KICAg ICAgICAtIGFnbm8gPSAyNQ0KICAgICAgICAtIGFnbm8gPSAyNg0KICAgICAgICAtIGFnbm8g PSAyNw0KICAgICAgICAtIGFnbm8gPSAyOA0KICAgICAgICAtIGFnbm8gPSAyOQ0KICAgICAg ICAtIGFnbm8gPSAzMA0KICAgICAgICAtIGFnbm8gPSAzMQ0KICAgICAgICAtIGFnbm8gPSAz Mg0KICAgICAgICAtIGFnbm8gPSAzMw0KICAgICAgICAtIGFnbm8gPSAzNA0KICAgICAgICAt IGFnbm8gPSAzNQ0KICAgICAgICAtIGFnbm8gPSAzNg0KUGhhc2UgNSAtIHJlYnVpbGQgQUcg aGVhZGVycyBhbmQgdHJlZXMuLi4NCiAgICAgICAgLSBhZ25vID0gMA0KICAgICAgICAtIGFn bm8gPSAxDQogICAgICAgIC0gYWdubyA9IDINCiAgICAgICAgLSBhZ25vID0gMw0KICAgICAg ICAtIGFnbm8gPSA0DQogICAgICAgIC0gYWdubyA9IDUNCiAgICAgICAgLSBhZ25vID0gNg0K ICAgICAgICAtIGFnbm8gPSA3DQogICAgICAgIC0gYWdubyA9IDgNCiAgICAgICAgLSBhZ25v ID0gOQ0KICAgICAgICAtIGFnbm8gPSAxMA0KICAgICAgICAtIGFnbm8gPSAxMQ0KICAgICAg ICAtIGFnbm8gPSAxMg0KICAgICAgICAtIGFnbm8gPSAxMw0KICAgICAgICAtIGFnbm8gPSAx NA0KICAgICAgICAtIGFnbm8gPSAxNQ0KICAgICAgICAtIGFnbm8gPSAxNg0KICAgICAgICAt IGFnbm8gPSAxNw0KICAgICAgICAtIGFnbm8gPSAxOA0KICAgICAgICAtIGFnbm8gPSAxOQ0K ICAgICAgICAtIGFnbm8gPSAyMA0KICAgICAgICAtIGFnbm8gPSAyMQ0KICAgICAgICAtIGFn bm8gPSAyMg0KICAgICAgICAtIGFnbm8gPSAyMw0KICAgICAgICAtIGFnbm8gPSAyNA0KICAg ICAgICAtIGFnbm8gPSAyNQ0KICAgICAgICAtIGFnbm8gPSAyNg0KICAgICAgICAtIGFnbm8g PSAyNw0KICAgICAgICAtIGFnbm8gPSAyOA0KICAgICAgICAtIGFnbm8gPSAyOQ0KICAgICAg ICAtIGFnbm8gPSAzMA0KICAgICAgICAtIGFnbm8gPSAzMQ0KICAgICAgICAtIGFnbm8gPSAz Mg0KICAgICAgICAtIGFnbm8gPSAzMw0KICAgICAgICAtIGFnbm8gPSAzNA0KICAgICAgICAt IGFnbm8gPSAzNQ0KICAgICAgICAtIGFnbm8gPSAzNg0KICAgICAgICAtIHJlc2V0IHN1cGVy YmxvY2suLi4NClBoYXNlIDYgLSBjaGVjayBpbm9kZSBjb25uZWN0aXZpdHkuLi4NCiAgICAg ICAgLSByZXNldHRpbmcgY29udGVudHMgb2YgcmVhbHRpbWUgYml0bWFwIGFuZCBzdW1tYXJ5 IGlub2Rlcw0KICAgICAgICAtIHRyYXZlcnNpbmcgZmlsZXN5c3RlbSAuLi4NCiAgICAgICAg LSBhZ25vID0gMA0KICAgICAgICAtIGFnbm8gPSAxDQogICAgICAgIC0gYWdubyA9IDINCiAg ICAgICAgLSBhZ25vID0gMw0KICAgICAgICAtIGFnbm8gPSA0DQogICAgICAgIC0gYWdubyA9 IDUNCiAgICAgICAgLSBhZ25vID0gNg0KICAgICAgICAtIGFnbm8gPSA3DQogICAgICAgIC0g YWdubyA9IDgNCiAgICAgICAgLSBhZ25vID0gOQ0KICAgICAgICAtIGFnbm8gPSAxMA0KICAg ICAgICAtIGFnbm8gPSAxMQ0KICAgICAgICAtIGFnbm8gPSAxMg0KICAgICAgICAtIGFnbm8g PSAxMw0KICAgICAgICAtIGFnbm8gPSAxNA0KICAgICAgICAtIGFnbm8gPSAxNQ0KICAgICAg ICAtIGFnbm8gPSAxNg0KICAgICAgICAtIGFnbm8gPSAxNw0KICAgICAgICAtIGFnbm8gPSAx OA0KICAgICAgICAtIGFnbm8gPSAxOQ0KICAgICAgICAtIGFnbm8gPSAyMA0KICAgICAgICAt IGFnbm8gPSAyMQ0KICAgICAgICAtIGFnbm8gPSAyMg0KICAgICAgICAtIGFnbm8gPSAyMw0K ICAgICAgICAtIGFnbm8gPSAyNA0KICAgICAgICAtIGFnbm8gPSAyNQ0KICAgICAgICAtIGFn bm8gPSAyNg0KICAgICAgICAtIGFnbm8gPSAyNw0KICAgICAgICAtIGFnbm8gPSAyOA0KICAg ICAgICAtIGFnbm8gPSAyOQ0KICAgICAgICAtIGFnbm8gPSAzMA0KICAgICAgICAtIGFnbm8g PSAzMQ0KICAgICAgICAtIGFnbm8gPSAzMg0KICAgICAgICAtIGFnbm8gPSAzMw0KICAgICAg ICAtIGFnbm8gPSAzNA0KICAgICAgICAtIGFnbm8gPSAzNQ0KICAgICAgICAtIGFnbm8gPSAz Ng0KICAgICAgICAtIHRyYXZlcnNhbCBmaW5pc2hlZCAuLi4NCiAgICAgICAgLSBtb3Zpbmcg ZGlzY29ubmVjdGVkIGlub2RlcyB0byBsb3N0K2ZvdW5kIC4uLg0KUGhhc2UgNyAtIHZlcmlm eSBhbmQgY29ycmVjdCBsaW5rIGNvdW50cy4uLg0KcmVzZXR0aW5nIGlub2RlIDE1NTg0IG5s aW5rcyBmcm9tIDIgdG8gNw0KDQogICAgICAgIFhGU19SRVBBSVIgU3VtbWFyeSAgICBXZWQg TWFyIDExIDE5OjE0OjUxIDIwMDkNCg0KUGhhc2UJCVN0YXJ0CQlFbmQJCUR1cmF0aW9uDQpQ aGFzZSAxOgkwMy8xMSAxOToxNDoxMwkwMy8xMSAxOToxNDoxMwkNClBoYXNlIDI6CTAzLzEx IDE5OjE0OjEzCTAzLzExIDE5OjE0OjE3CTQgc2Vjb25kcw0KUGhhc2UgMzoJMDMvMTEgMTk6 MTQ6MTcJMDMvMTEgMTk6MTQ6NDYJMjkgc2Vjb25kcw0KUGhhc2UgNDoJMDMvMTEgMTk6MTQ6 NDYJMDMvMTEgMTk6MTQ6NDgJMiBzZWNvbmRzDQpQaGFzZSA1OgkwMy8xMSAxOToxNDo0OAkw My8xMSAxOToxNDo0OAkNClBoYXNlIDY6CTAzLzExIDE5OjE0OjQ4CTAzLzExIDE5OjE0OjUw CTIgc2Vjb25kcw0KUGhhc2UgNzoJMDMvMTEgMTk6MTQ6NTAJMDMvMTEgMTk6MTQ6NTAJDQoN ClRvdGFsIHJ1biB0aW1lOiAzNyBzZWNvbmRzDQpkb25lDQpyb290QGlvOn4jIGV4aXQNCgpT Y3JpcHQgZG9uZSBvbiBXZWQgMTEgTWFyIDIwMDkgMTk6MTU6MzMgV1NUCg== --------------000302040506060400060204-- From alessandro.bono@gmail.com Wed Mar 11 12:05:15 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2BH4sWV019270 for ; Wed, 11 Mar 2009 12:05:15 -0500 X-ASG-Debug-ID: 1236791049-6a1d00040000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f170.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC2B818B64B for ; Wed, 11 Mar 2009 10:04:10 -0700 (PDT) Received: from mail-ew0-f170.google.com (mail-ew0-f170.google.com [209.85.219.170]) by cuda.sgi.com with ESMTP id XXSB8MHaOOyKRiEQ for ; Wed, 11 Mar 2009 10:04:10 -0700 (PDT) Received: by ewy18 with SMTP id 18so84233ewy.20 for ; Wed, 11 Mar 2009 10:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Axffz7T/fCJI4879QEKJjPY+Wgbtdu+MxyaVMIdgbco=; b=Zwa4cCG37Orc/+Vk/PFJ3h2CZBl5X1rkqT97n/WXDX/EGnzLWMJjxZf9bCuQpRI2+x 1xBIxLXt4Y+mLqLHDKYZsrnJADM9cE3OQF7l0zD8NL5lF7ora5E79WwI59veR+7IKrXT 4Z7T2f8v6gs9P6PAUJnfg0f1l7BSW9hvVN3u8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=T/M5zgWMsbO7wcZNTRCk2+aJlUOSJr2u06KlOJZkI3jtl+ZWKcleJ1QzwZdgbxVyEF oFUL1gT0YRYMDYmfJLeHNkadR1ZANYh3vCWIbgZLJV1iztow9gAdhCBBKhgxPUZYyVQR AOMj+bn1XR+V1NqpK7ik14iElU1HuN3c6642k= Received: by 10.216.46.79 with SMTP id q57mr3519201web.212.1236791049344; Wed, 11 Mar 2009 10:04:09 -0700 (PDT) Received: from ?10.153.1.83? (host122-152-static.34-85-b.business.telecomitalia.it [85.34.152.122]) by mx.google.com with ESMTPS id f8sm86796nfh.2.2009.03.11.10.04.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 10:04:08 -0700 (PDT) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Jan Kara Cc: Dave Chinner , Christoph Hellwig , linux-xfs , linux-kernel In-Reply-To: <20090302133609.GD23880@duck.suse.cz> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <20090209075308.GA7360@infradead.org> <20090210104304.GP8830@disturbed> <1234432077.9204.15.camel@champagne.cantina> <20090226165838.GA9602@atrey.karlin.mff.cuni.cz> <1235763895.5743.3.camel@champagne> <20090302133609.GD23880@duck.suse.cz> Content-Type: text/plain Date: Wed, 11 Mar 2009 18:04:06 +0100 Message-Id: <1236791046.5814.12.camel@champagne> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-ew0-f170.google.com[209.85.219.170] X-Barracuda-Start-Time: 1236791071 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0816 1.0000 -1.5038 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.50 X-Barracuda-Spam-Status: No, SCORE=-1.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20042 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 2009-03-02 at 14:36 +0100, Jan Kara wrote: ..... > Such bit flips are usually caused by faulty memory or other HW (io > controler etc.) so I suggest trying to shuffle the hardware somehow - > change memory DIMMs as a starter, running memtest if you don't have a spare > DIMMs but it is not an exception that even though memtest runs just fine > for a long time, memory is really at fault. Hi I changed DIMMs on my laptop and after that I can't reproduce bug So at the end it's an hardware problem Many thanks to you, Dave and Christoph for your time and patience -- Cordiali Saluti Alessandro Bono From felixb@oss.sgi.com Wed Mar 11 16:02:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2BL2Kxp029281 for ; Wed, 11 Mar 2009 16:02:20 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2BL2FeD029259; Wed, 11 Mar 2009 16:02:15 -0500 Date: Wed, 11 Mar 2009 16:02:15 -0500 Message-Id: <200903112102.n2BL2FeD029259@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, mainline, updated. v2.6.28-rc3-13820-g16b71fd X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 559595a985e106d2fa9f0c79b7f5805453fed593 X-Git-Newrev: 16b71fdf97599f1b1b7f38418ee9922d9f117396 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, mainline has been updated from 559595a985e106d2fa9f0c79b7f5805453fed593 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Wed Mar 11 16:02:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2BL2NkF029316 for ; Wed, 11 Mar 2009 16:02:23 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2BL2KbZ029286; Wed, 11 Mar 2009 16:02:20 -0500 Date: Wed, 11 Mar 2009 16:02:20 -0500 Message-Id: <200903112102.n2BL2KbZ029286@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-13882-gf3697bc X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 7bf446f8b581cef434f5ff05e8a791563bc09b7f X-Git-Newrev: f3697bc314e912599f422cc5c6e53c7382c0aeb2 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated from 7bf446f8b581cef434f5ff05e8a791563bc09b7f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: hooks/post-receive -- XFS development tree From felixb@sgi.com Wed Mar 11 16:14:38 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2BLEI4t029915 for ; Wed, 11 Mar 2009 16:14:38 -0500 Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by relay2.corp.sgi.com (Postfix) with ESMTP id AE275304062 for ; Wed, 11 Mar 2009 14:13:55 -0700 (PDT) Received: by attica.americas.sgi.com (Postfix, from userid 29043) id 236A514167101; Wed, 11 Mar 2009 16:04:55 -0500 (CDT) Date: Wed, 11 Mar 2009 16:04:55 -0500 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.29-rc8 User-Agent: Heirloom mailx 12.2 01/07/07 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20090311210455.236A514167101@attica.americas.sgi.com> From: felixb@sgi.com (Felix Blyakher) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The following changes since commit 559595a985e106d2fa9f0c79b7f5805453fed593: Linus Torvalds (1): Merge branch 'merge' of git://git.kernel.org/.../benh/powerpc are available in the git repository at: git://oss.sgi.com/xfs/xfs for-linus Christoph Hellwig (3): xfs: prevent kernel crash due to corrupted inode log format xfs: prevent lockdep false positive in xfs_iget_cache_miss xfs: only issues a cache flush on unmount if barriers are enabled fs/xfs/linux-2.6/xfs_buf.c | 12 ++++++++++-- fs/xfs/linux-2.6/xfs_buf.h | 2 +- fs/xfs/linux-2.6/xfs_super.c | 10 +++++----- fs/xfs/xfs_iget.c | 15 ++++++++++----- fs/xfs/xfs_log_recover.c | 17 +++++++++++++---- 5 files changed, 39 insertions(+), 17 deletions(-) From sandeen@sandeen.net Wed Mar 11 21:24:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2C2NeX7045825 for ; Wed, 11 Mar 2009 21:24:00 -0500 X-ASG-Debug-ID: 1236824595-65cf02de0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 91A441C36B15 for ; Wed, 11 Mar 2009 19:23:15 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id fral8FcKH6vs44FF for ; Wed, 11 Mar 2009 19:23:15 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2C2ND1R014983; Wed, 11 Mar 2009 22:23:13 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2C2ND6L031454; Wed, 11 Mar 2009 22:23:13 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2C2NCZv022640; Wed, 11 Mar 2009 22:23:12 -0400 Message-ID: <49B8720E.3070400@sandeen.net> Date: Wed, 11 Mar 2009 21:23:10 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Thomas Gutzler CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data detected Subject: Re: Corruption of in-memory data detected References: <169670ec0901011846q1d370e6cu31514519afc8295d@mail.gmail.com> <495D88EE.2040406@sandeen.net> <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> <49B73E50.5080906@sandeen.net> <49B79586.5060801@gmail.com> In-Reply-To: <49B79586.5060801@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236824595 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20080 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Thomas Gutzler wrote: > Eric Sandeen wrote: >> Thomas Gutzler wrote: ... >>> What can I do to help getting this fixed? >>> >> can you make an xfs_metadump of the filesystem in question, and then try >> an xfs_repair? Capture/save the repair output. If repair finds errors, >> then perhaps the bug is triggered by bad error checking on a corrupted >> image, and we might reproduce it w/ the metadump image. > > I tried... > > root@io:~# xfs_metadump /dev/sda xfs_metadump_sda > *** glibc detected *** xfs_db: double free or corruption (out): > 0x00000000017b8000 *** ... > Aborted :( what version of xfsprogs? > and tried again: > root@io:~# xfs_metadump -w /dev/sda xfs_metadump_sda > root@io:~# ll xfs_metadump_sda > -rw-r--r-- 1 root root 588407296 2009-03-11 19:09 xfs_metadump_sda > (where do I upload this to?) You can bzip2 it and probably shrink it pretty well (it's sparse). See how big that is, and we can find a place for it. > xfs_repair fixed "bad names" of 4 inodes (see attached log file) > > another xfs_metadump /dev/sda xfs_metadump_sda_2 (without -w): > -rw-r--r-- 1 root root 588261888 2009-03-11 19:23 xfs_metadump_sda_2 > >> It'd be nice if ubuntu had debug kernel variants (Fedora does this, I >> dunno about ubuntu) - if you are hitting any kind of memory corruption >> then a kernel with debug checks enabled might catch it sooner. > > I haven't seen any - probably have to build my own debug kernel. Oh joy. > > Is the metadump of any use? it might be, let's see how well it shrinks. -Eric > Tom > > > ------------------------------------------------------------------------ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From audio@pbconferences.com Wed Mar 11 23:34:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2C4Y8Jd049824 for ; Wed, 11 Mar 2009 23:34:29 -0500 X-ASG-Debug-ID: 1236832403-1c6a00130000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from evempbp04.workforpbp.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4DD581C36FCD for ; Wed, 11 Mar 2009 21:33:23 -0700 (PDT) Received: from evempbp04.workforpbp.com (evempbp04.workforpbp.com [208.89.23.69]) by cuda.sgi.com with ESMTP id 9kLaLsZCHITGCgYL for ; Wed, 11 Mar 2009 21:33:23 -0700 (PDT) Received: from PBP-04 (208.89.23.69) by evempbp04.workforpbp.com id hn28920ktaso for ; Wed, 11 Mar 2009 23:30:48 -0400 (envelope-from ) Date: Wed, 11 Mar 2009 23:30:48 -0400 X-Mailer: PDSoft Smtp Control v4.0.390 X-Sender: audio@pbconferences.com To: xfs@oss.sgi.com From: "audio@pbconferences.com" X-ASG-Orig-Subj: Coaching Skills for Managers: Increase Productivity; Boost Morale: 4/9 Audio Conference Subject: Coaching Skills for Managers: Increase Productivity; Boost Morale: 4/9 Audio Conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Barracuda-Connect: evempbp04.workforpbp.com[208.89.23.69] X-Barracuda-Start-Time: 1236832425 Message-Id: <20090312043323.4DD581C36FCD@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.4994 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA041a X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20088 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.00 BSF_SC5_SA041a Custom Rule SA041a X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear David Chinner, For those concerned about, boosting productivity and morale through high-impact coaching skills you are invited to join us for our leading 60-minute audio conference: "Coaching Skills for Managers: Increase Productivity; Boost Morale" Thursday, April 9, 2009 - 1:00-2:00 p.m. ET http://www.pbconferences.com/AH/0/2/p2B13Mc/p232D3Q3i/p0e Great coaches create environments with higher morale, tremendous loyalty and increased productivity. There are simple, but powerful ways for today’s managers to improve their coaching skills. Join us for a 60-minute audio conference where your team will discover how to: ** Change behavior - by rewarding the behaviors you want continued ** Give feedback that increases performance and accountability ** Drive stronger results and excellence through others ** Effectively handle attitude problems and rule-breakers Carol Hacker, is recognized as a leading authority on reducing turnover, increasing productivity and boosting morale. Her background includes: ** Founder and President of Hacker and Associates - a prestigious management consulting and seminar company ** Over 25 years delivering high-impact leadership solutions to such prestigious companies as IBM, Turner Broadcasting System, American Airlines, GE, Atlanta Braves and CNN ** One of the most in-demand and top-rated speakers in the country - speaking to thousands people a year. EARN HRCI Credit: This program has been approved for 1 recertification credit hour toward PHR and SPHR recertification through the Human Resource Certification Institute (HRCI). For more information about certification or recertification, please visit the HRCI homepage at www.hrci.org Hosted by Progressive Business Publications, the leader in fast-read actionable advice on workplace issues, the audio conference gives you the opportunity to add immediate, impact to your marketing efforts in a manner that is: FAST - No wasted time here. Get right to the heart of the matter in a 1-hour block designed to easily fit into your busy schedule. CONVENIENT - No airlines. No travel. No time out of the office. Listen from the comfort and convenience of your desk. EASY - A telephone is all the equipment you need. Just dial in, punch in your access code, and you're in. That's it. Follow along with the audio conference handouts provided in advance. ACTIONABLE - Our audio conferences provide money-saving tactics you can start using right when you hang up the phone. IDEAL FOR MULTIPLE LISTENERS - Use a speakerphone and as many people as you want can listen in - at no extra cost to you. Many professionals use these sessions as a cost-efficient, time-efficient means of training supervisors, managers, and staff and reinforcing key issues in a fresh new manner that they will remember and act on. AFFORDABLE - Priced at $199, it is a fraction of the cost of travel and attendance fees for other high-priced conferences or seminars. ** "Coaching Skills for Managers: Increase Productivity; Boost Morale " ** ** Live, 60-Minute Audio Conference ** ** Thursday, April 9, 2009 - 1:00-2:00 p.m. ET ** Register now for this exciting event by clicking the following link or calling 800-964-6033. http://www.pbconferences.com/AH/0/2/p2B13Mc/p232D3Q3i/p0e We hope you'll join us. Sincerely, Progressive Business Audio Conferences 384 Technology Drive Malvern, PA 19355 P.S. As usual we offer a full refund if not satisfied from now until 7 days after the event. If you do not wish to receive further notices about this conference, or future conferences, please click here: http://www.pbconferences.com/AH/36/2/p2B13Mc/p232D3Q3i/p0e Please do not reply directly to this e-mail, as we are unable to process it. We sent this using a "send only" address. If registering by phone, please refer to your priority code: 85267 ContactID#: -1847910816 From thomas.gutzler@gmail.com Thu Mar 12 00:07:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2C57QRZ053814 for ; Thu, 12 Mar 2009 00:07:47 -0500 X-ASG-Debug-ID: 1236834423-7daf01aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DCCA518DD8C for ; Wed, 11 Mar 2009 22:07:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by cuda.sgi.com with ESMTP id aV5dLBTngcqh8X2c for ; Wed, 11 Mar 2009 22:07:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g9so3167125rvb.4 for ; Wed, 11 Mar 2009 22:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=WUKqkiv3IyMbTccuLjvWa681Ai9Liop3VxwthjWI2jk=; b=BsO6u1hbxCeo9grx4CB8vsEjstdeHojK7HziVJ4cRiH0OqoMYsBFRcdTdIi2fUWfGO fWyU1xSEvwuX44n7mmRwrGKOEUjzrnkgga7g73TdX+RpnsTmy21qdkMeCvmOcWWGLkTO 72bpQBmKLbMjeAFNtVw92qQsmPGzYvUpo4uW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=cYgFd2rv66EV9whSeTxOVH0EvHV8785x2IQ35Oyq/dxov/zxTq5UcA/xrdCXQ/oNe2 mMWsz8Q5vslqfjurN+SdV0a718P0Wxb8Sf8fyp8y0nh3qbKdoIDSbnQfqB3coKBuIEga RJTj92fdrQ6bBbWbZjhkXVJDPXJpYQN+ZFrlY= Received: by 10.140.132.3 with SMTP id f3mr4808156rvd.21.1236834422985; Wed, 11 Mar 2009 22:07:02 -0700 (PDT) Received: from ?130.95.70.106? (tgutzler.dialup.ee.uwa.edu.au [130.95.70.106]) by mx.google.com with ESMTPS id k2sm854412rvb.4.2009.03.11.22.06.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 22:07:01 -0700 (PDT) Message-ID: <49B8986F.60009@gmail.com> Date: Thu, 12 Mar 2009 14:06:55 +0900 From: Thomas Gutzler User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data detected Subject: Re: Corruption of in-memory data detected References: <169670ec0901011846q1d370e6cu31514519afc8295d@mail.gmail.com> <495D88EE.2040406@sandeen.net> <169670ec0903101944i2ea05432q7bf9776a347a11a5@mail.gmail.com> <49B73E50.5080906@sandeen.net> <49B79586.5060801@gmail.com> <49B8720E.3070400@sandeen.net> In-Reply-To: <49B8720E.3070400@sandeen.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rv-out-0506.google.com[209.85.198.228] X-Barracuda-Start-Time: 1236834423 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20090 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Eric Sandeen wrote: > Thomas Gutzler wrote: >> >> root@io:~# xfs_metadump /dev/sda xfs_metadump_sda >> *** glibc detected *** xfs_db: double free or corruption (out): >> 0x00000000017b8000 *** > > ... > >> Aborted > > :( what version of xfsprogs? xfsprogs 2.9.8-1 most recent version that comes with ubuntu intrepid. >> and tried again: >> root@io:~# xfs_metadump -w /dev/sda xfs_metadump_sda >> root@io:~# ll xfs_metadump_sda >> -rw-r--r-- 1 root root 588407296 2009-03-11 19:09 xfs_metadump_sda >> (where do I upload this to?) > > You can bzip2 it and probably shrink it pretty well (it's sparse). See > how big that is, and we can find a place for it. 87M xfs_metadump_sda_2.bz2 109M xfs_metadump_sda.bz2 The filesystem has 3.1TB of data on it. I can put that on our webserver for download or put it somewhere - let me know what's best. Tom From michael.monnerie@is.it-management.at Thu Mar 12 06:40:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CBeXfP073287 for ; Thu, 12 Mar 2009 06:40:54 -0500 X-ASG-Debug-ID: 1236858008-79c400470000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF65518EDA9 for ; Thu, 12 Mar 2009 04:40:08 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id Vp99AVhQjVQjvfZM for ; Thu, 12 Mar 2009 04:40:08 -0700 (PDT) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id F371F450A for ; Thu, 12 Mar 2009 12:39:35 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id D08AC40017F for ; Thu, 12 Mar 2009 12:39:35 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: LWN article: ext4 and data loss Subject: LWN article: ext4 and data loss Date: Thu, 12 Mar 2009 12:39:31 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.28.7-ZMI; KDE/4.1.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15666740.9atQLHLN2z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903121239.35442@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236858008 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20116 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart15666740.9atQLHLN2z Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ Very good, maybe similar patches for XFS would help? IANA Coder, but could be a hint. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 --nextPart15666740.9atQLHLN2z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkm49HcACgkQzhSR9xwSCbTHBgCgm08p5MWYZBihjUYVdlpAquWO vDQAn1h1DLf72e3q0FuBH3nGSBqTzlJr =gj/P -----END PGP SIGNATURE----- --nextPart15666740.9atQLHLN2z-- From michael.monnerie@is.it-management.at Thu Mar 12 07:00:25 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CC04t9074243 for ; Thu, 12 Mar 2009 07:00:25 -0500 X-ASG-Debug-ID: 1236859163-51f8001a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3A91C1C38185 for ; Thu, 12 Mar 2009 04:59:24 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id KsPUn4HtbYPhye6M for ; Thu, 12 Mar 2009 04:59:24 -0700 (PDT) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id ED783450D for ; Thu, 12 Mar 2009 12:58:51 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id DD36740017F for ; Thu, 12 Mar 2009 12:58:51 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: LWN article: 4K disk sectors Subject: LWN article: 4K disk sectors Date: Thu, 12 Mar 2009 12:58:51 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.28.7-ZMI; KDE/4.1.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903121258.51497@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236859181 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean http://lwn.net/SubscriberLink/322777/16380cde8af0a37e/ 4K disk sectors coming 2011, might be interesting for devs to prepare supporting it. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From sandeen@sandeen.net Thu Mar 12 08:11:55 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CDBYUQ077379 for ; Thu, 12 Mar 2009 08:11:55 -0500 X-ASG-Debug-ID: 1236863470-39b401ea0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 726A01C38922 for ; Thu, 12 Mar 2009 06:11:11 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id aEio5PJuYHmlBVUO for ; Thu, 12 Mar 2009 06:11:11 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CD9JON023909; Thu, 12 Mar 2009 09:09:19 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CD9JSD002926; Thu, 12 Mar 2009 09:09:19 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CD9HXu029032; Thu, 12 Mar 2009 09:09:18 -0400 Message-ID: <49B9097C.1070003@sandeen.net> Date: Thu, 12 Mar 2009 08:09:16 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Monnerie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: ext4 and data loss Subject: Re: LWN article: ext4 and data loss References: <200903121239.35442@zmi.at> In-Reply-To: <200903121239.35442@zmi.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236863471 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0172 1.0000 -1.9091 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.91 X-Barracuda-Spam-Status: No, SCORE=-1.91 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20122 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Michael Monnerie wrote: > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ > > Very good, maybe similar patches for XFS would help? > IANA Coder, but could be a hint. > > mfg zmi > ext4 is taking its hints from XFS in this regard, not the other way around. XFS dealt with this long ago. -Eric From sandeen@sandeen.net Thu Mar 12 08:12:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35, J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CDBmDM077403 for ; Thu, 12 Mar 2009 08:12:09 -0500 X-ASG-Debug-ID: 1236863464-4d1203db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 156FE18F2EF for ; Thu, 12 Mar 2009 06:11:04 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id X9MHCdyi7pfw6dEc for ; Thu, 12 Mar 2009 06:11:04 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CDAco2024377; Thu, 12 Mar 2009 09:10:38 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CDAcbu003667; Thu, 12 Mar 2009 09:10:38 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CDAbYg029490; Thu, 12 Mar 2009 09:10:38 -0400 Message-ID: <49B909CC.7080402@sandeen.net> Date: Thu, 12 Mar 2009 08:10:36 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Monnerie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors References: <200903121258.51497@zmi.at> In-Reply-To: <200903121258.51497@zmi.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236863486 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20122 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Michael Monnerie wrote: > http://lwn.net/SubscriberLink/322777/16380cde8af0a37e/ > > 4K disk sectors coming 2011, might be interesting for devs to prepare > supporting it. Take a look at the mkfs.xfs man page: -s sector_size This option specifies the fundamental sector size of the filesystem. The sector_size is specified either as a value in bytes with size=value or as a base two loga- rithm value with log=value. The default sector_size is 512 bytes. The minimum value for sector size is 512; the maximum is 32768 (32 KiB). The sector_size must be a power of 2 size and cannot be made larger than the filesystem block size. -Eric From michael.monnerie@is.it-management.at Thu Mar 12 08:53:33 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_35,J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CDrCn4079679 for ; Thu, 12 Mar 2009 08:53:32 -0500 X-ASG-Debug-ID: 1236865969-577300f00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 91B6318F39F for ; Thu, 12 Mar 2009 06:52:49 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id SLpaypVx46mAR806 for ; Thu, 12 Mar 2009 06:52:49 -0700 (PDT) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id EE777450C for ; Thu, 12 Mar 2009 14:52:16 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id E137340017F for ; Thu, 12 Mar 2009 14:52:16 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors Date: Thu, 12 Mar 2009 14:52:16 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.28.7-ZMI; KDE/4.1.3; x86_64; ; ) References: <200903121258.51497@zmi.at> <49B909CC.7080402@sandeen.net> In-Reply-To: <49B909CC.7080402@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903121452.16419@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1236865969 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Donnerstag 12 M=E4rz 2009 Eric Sandeen wrote: > Take a look at the mkfs.xfs man page: > > =A0 =A0 =A0 =A0-s sector_size > =A0 =A0 =A0 =A0 =A0 =A0 =A0 This option specifies the fundamental =A0sect= or =A0size =A0of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 the filesystem. =A0The sector_size is specifi= ed either as > =A0 =A0 =A0 =A0 =A0 =A0 =A0 a value in bytes with size=3Dvalue or as a ba= se two loga- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 rithm value with log=3Dvalue. =A0The default = sector_size is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 512 bytes. The minimum value for sector =A0si= ze =A0is =A0512; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 the =A0maximum is 32768 (32 KiB). The sector_= size must be > =A0 =A0 =A0 =A0 =A0 =A0 =A0 a power of 2 size and cannot be made =A0large= r =A0than =A0the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 filesystem block size. Ugh, I felt so good this morning, until you responded ... ;-) I thought that it's a limitation of the Linux kernel in more parts than=20 just the filesystem (like block cache), that sector sizes must be 512B.=20 If I had a 4K drive, would that be usable with XFS already? mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From Martin@lichtvoll.de Thu Mar 12 09:15:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CEEw9h080510 for ; Thu, 12 Mar 2009 09:15:19 -0500 X-ASG-Debug-ID: 1236867253-51e902db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E3FE81C39119 for ; Thu, 12 Mar 2009 07:14:13 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id sCmRaSVpMvk8Bn9Q for ; Thu, 12 Mar 2009 07:14:13 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.83.171.186.52.ip-pool.NEFkom.net [83.171.186.52]) by mail.lichtvoll.de (Postfix) with ESMTPSA id DD7C95ADB7 for ; Thu, 12 Mar 2009 15:13:38 +0100 (CET) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: ext4 and data loss Subject: Re: LWN article: ext4 and data loss Date: Thu, 12 Mar 2009 15:14:11 +0100 User-Agent: KMail/1.9.9 References: <200903121239.35442@zmi.at> <49B9097C.1070003@sandeen.net> (sfid-20090312_151043_496061_D19DDB11) In-Reply-To: <49B9097C.1070003@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903121514.12732.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1236867274 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Am Donnerstag 12 M=E4rz 2009 schrieb Eric Sandeen: > Michael Monnerie wrote: > > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ > > > > Very good, maybe similar patches for XFS would help? > > IANA Coder, but could be a hint. > > > > mfg zmi > > ext4 is taking its hints from XFS in this regard, not the other way > around. XFS dealt with this long ago. Hmmm, I remember having had similar issues with XFS not to long ago, where= =20 at least some KDE configuration were lost or truncated. It seems=20 applications will have to get rid of behavioral assumptions regation=20 filesystem and use safe writing via fsync and whatever else for=20 configuration and other important files. I am thinking about a bug report for KDE at least. =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From Martin@lichtvoll.de Thu Mar 12 09:17:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35, J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CEHcbV080772 for ; Thu, 12 Mar 2009 09:17:58 -0500 X-ASG-Debug-ID: 1236867434-51ea02d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E8E11C3915A for ; Thu, 12 Mar 2009 07:17:15 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id HXyeHnC5HfW0EOwk for ; Thu, 12 Mar 2009 07:17:15 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.83.171.186.52.ip-pool.NEFkom.net [83.171.186.52]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 121B15ADB7 for ; Thu, 12 Mar 2009 15:17:14 +0100 (CET) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors Date: Thu, 12 Mar 2009 15:17:47 +0100 User-Agent: KMail/1.9.9 References: <200903121258.51497@zmi.at> <49B909CC.7080402@sandeen.net> <200903121452.16419@zmi.at> (sfid-20090312_151032_516649_56909F94) In-Reply-To: <200903121452.16419@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903121517.48426.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1236867435 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Am Donnerstag 12 M=E4rz 2009 schrieb Michael Monnerie: > On Donnerstag 12 M=E4rz 2009 Eric Sandeen wrote: > > Take a look at the mkfs.xfs man page: > > > > =A0 =A0 =A0 =A0-s sector_size > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 This option specifies the fundamental =A0se= ctor =A0size =A0of > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 the filesystem. =A0The sector_size is speci= fied either as > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 a value in bytes with size=3Dvalue or as a = base two loga- > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 rithm value with log=3Dvalue. =A0The defaul= t sector_size is > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 512 bytes. The minimum value for sector =A0= size =A0is =A0512; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 the =A0maximum is 32768 (32 KiB). The secto= r_size must be > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 a power of 2 size and cannot be made =A0lar= ger =A0than =A0the > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 filesystem block size. > > Ugh, I felt so good this morning, until you responded ... ;-) > > I thought that it's a limitation of the Linux kernel in more parts than > just the filesystem (like block cache), that sector sizes must be 512B. > If I had a 4K drive, would that be usable with XFS already? I have an USB stick with 2KB hardware sector size. It worked nicely when=20 using fdisk instead of cfdisk which only supports 512 byte sectors. Dunno=20 remember exactly which filesystems I tried back then. And first I wondered why it had a partition in the first quarter of it and= =20 then empty space. I thought it might have been a fake 1 GB stick, but=20 still just deleted the partition and made it size the whole disk in=20 cfdisk - well at least I thought I did. The Linux kernel complained about=20 writing beyond end of device while mkfsing, I think it was an ext3. =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From martin.petersen@oracle.com Thu Mar 12 09:26:05 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CEPi2Z081189 for ; Thu, 12 Mar 2009 09:26:04 -0500 X-ASG-Debug-ID: 1236867921-51f903460000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rgminet12.oracle.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7EB441C38F6D for ; Thu, 12 Mar 2009 07:25:21 -0700 (PDT) Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by cuda.sgi.com with ESMTP id q2eYeXAlhoPXjeD1 for ; Thu, 12 Mar 2009 07:25:21 -0700 (PDT) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n2CENXe0024310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Mar 2009 14:23:34 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n2CENdYr013700; Thu, 12 Mar 2009 14:23:40 GMT Received: from groovelator.mkp.net (/209.217.122.111) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Mar 2009 14:23:32 +0000 To: Michael Monnerie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors From: "Martin K. Petersen" Organization: Oracle References: <200903121258.51497@zmi.at> <49B909CC.7080402@sandeen.net> <200903121452.16419@zmi.at> Date: Thu, 12 Mar 2009 10:23:30 -0400 In-Reply-To: <200903121452.16419@zmi.at> (Michael Monnerie's message of "Thu\, 12 Mar 2009 14\:52\:16 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.49B91AE9.0108:SCFSTAT928724,ss=1,fgs=0 X-Barracuda-Connect: rcsinet12.oracle.com[148.87.113.124] X-Barracuda-Start-Time: 1236867921 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20128 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >>>>> "Michael" == Michael Monnerie writes: Michael> I thought that it's a limitation of the Linux kernel in more Michael> parts than just the filesystem (like block cache), that sector Michael> sizes must be 512B. Nope. We've supported bigger sector sizes for years because of CD-ROMs, mainframe DASD, etc. Michael> If I had a 4K drive, would that be usable with XFS already? # cat /sys/block/sdc/queue/hw_sector_size 4096 # xfs_info /mnt meta-data=/dev/sdc1 isize=256 agcount=16, agsize=5113686 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=81818976, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 -- Martin K. Petersen Oracle Linux Engineering From sandeen@sandeen.net Thu Mar 12 10:01:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35, J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CF0kNI084224 for ; Thu, 12 Mar 2009 10:01:07 -0500 X-ASG-Debug-ID: 1236870023-1411004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A153D1C38CBF for ; Thu, 12 Mar 2009 08:00:23 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id sa6W3c2CElYr12FK for ; Thu, 12 Mar 2009 08:00:23 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CEwYQN014010; Thu, 12 Mar 2009 10:58:34 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CEwX8G011331; Thu, 12 Mar 2009 10:58:33 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CEwVmd026180; Thu, 12 Mar 2009 10:58:33 -0400 Message-ID: <49B92311.7030708@sandeen.net> Date: Thu, 12 Mar 2009 09:58:25 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Michael Monnerie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors References: <200903121258.51497@zmi.at> <49B909CC.7080402@sandeen.net> <200903121452.16419@zmi.at> In-Reply-To: <200903121452.16419@zmi.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236870023 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20130 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Michael Monnerie wrote: > On Donnerstag 12 März 2009 Eric Sandeen wrote: >> Take a look at the mkfs.xfs man page: >> >> -s sector_size >> This option specifies the fundamental sector size of >> the filesystem. The sector_size is specified either as >> a value in bytes with size=value or as a base two loga- >> rithm value with log=value. The default sector_size is >> 512 bytes. The minimum value for sector size is 512; >> the maximum is 32768 (32 KiB). The sector_size must be >> a power of 2 size and cannot be made larger than the >> filesystem block size. > > Ugh, I felt so good this morning, until you responded ... ;-) > > I thought that it's a limitation of the Linux kernel in more parts than > just the filesystem (like block cache), that sector sizes must be 512B. > If I had a 4K drive, would that be usable with XFS already? Other layers need work, yes, but by and large xfs should be ready when the rest of the kernel & linux infastructure catches up. -Eric From felixb@sgi.com Thu Mar 12 10:14:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CFEJmh084668 for ; Thu, 12 Mar 2009 10:14:40 -0500 Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5147F304067 for ; Thu, 12 Mar 2009 08:13:57 -0700 (PDT) Received: by attica.americas.sgi.com (Postfix, from userid 29043) id 6516A1419BF88; Thu, 12 Mar 2009 09:54:15 -0500 (CDT) From: Felix Blyakher To: xfs@oss.sgi.com Cc: Felix Blyakher Subject: [PATCH] Fix xfs debug build breakage Date: Thu, 12 Mar 2009 09:54:15 -0500 Message-Id: <1236869655-14757-1-git-send-email-felixb@sgi.com> X-Mailer: git-send-email 1.5.4.rc3 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Fix xfs debug build breakage by pushing xfs_error.h after xfs_mount.h, which it depends on. Signed-off-by: Felix Blyakher --- fs/xfs/support/debug.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/xfs/support/debug.c b/fs/xfs/support/debug.c index 930bb34..3f3610a 100644 --- a/fs/xfs/support/debug.c +++ b/fs/xfs/support/debug.c @@ -17,7 +17,6 @@ */ #include #include "debug.h" -#include "xfs_error.h" /* xfs_mount.h drags a lot of crap in, sorry.. */ #include "xfs_sb.h" @@ -25,6 +24,7 @@ #include "xfs_ag.h" #include "xfs_dmapi.h" #include "xfs_mount.h" +#include "xfs_error.h" static char message[1024]; /* keep it off the stack */ static DEFINE_SPINLOCK(xfs_err_lock); -- 1.5.4.rc3 From sandeen@sandeen.net Thu Mar 12 10:17:26 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35, J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CFH5ve084951 for ; Thu, 12 Mar 2009 10:17:25 -0500 X-ASG-Debug-ID: 1236871002-27f1001c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9F4491C396B0 for ; Thu, 12 Mar 2009 08:16:42 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id 2emaVGH7OqxUrXE5 for ; Thu, 12 Mar 2009 08:16:42 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CF3jG4014994; Thu, 12 Mar 2009 11:03:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CF3iDh013187; Thu, 12 Mar 2009 11:03:45 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CF3hme027192; Thu, 12 Mar 2009 11:03:44 -0400 Message-ID: <49B92449.90805@sandeen.net> Date: Thu, 12 Mar 2009 10:03:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Steigerwald CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors References: <200903121258.51497@zmi.at> <49B909CC.7080402@sandeen.net> <200903121452.16419@zmi.at> (sfid-20090312_151032_516649_56909F94) <200903121517.48426.Martin@lichtvoll.de> In-Reply-To: <200903121517.48426.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236871002 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20130 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Martin Steigerwald wrote: > Am Donnerstag 12 März 2009 schrieb Michael Monnerie: >> On Donnerstag 12 März 2009 Eric Sandeen wrote: >>> Take a look at the mkfs.xfs man page: >>> >>> -s sector_size >>> This option specifies the fundamental sector size of >>> the filesystem. The sector_size is specified either as >>> a value in bytes with size=value or as a base two loga- >>> rithm value with log=value. The default sector_size is >>> 512 bytes. The minimum value for sector size is 512; >>> the maximum is 32768 (32 KiB). The sector_size must be >>> a power of 2 size and cannot be made larger than the >>> filesystem block size. >> Ugh, I felt so good this morning, until you responded ... ;-) >> >> I thought that it's a limitation of the Linux kernel in more parts than >> just the filesystem (like block cache), that sector sizes must be 512B. >> If I had a 4K drive, would that be usable with XFS already? > > I have an USB stick with 2KB hardware sector size. It worked nicely when > using fdisk instead of cfdisk which only supports 512 byte sectors. Dunno > remember exactly which filesystems I tried back then. really? what kind of usb stick? I've never seen such a thing. -Eric From sandeen@sandeen.net Thu Mar 12 10:17:26 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CFH67s084954 for ; Thu, 12 Mar 2009 10:17:26 -0500 X-ASG-Debug-ID: 1236871002-27f1001c0002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E0A91C396B4 for ; Thu, 12 Mar 2009 08:16:42 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id 2SI8b29UMUDbPlCu for ; Thu, 12 Mar 2009 08:16:42 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CF36jD014931; Thu, 12 Mar 2009 11:03:07 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CF36xU013010; Thu, 12 Mar 2009 11:03:07 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CF35hk027114; Thu, 12 Mar 2009 11:03:06 -0400 Message-ID: <49B92423.4020708@sandeen.net> Date: Thu, 12 Mar 2009 10:02:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Steigerwald CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: ext4 and data loss Subject: Re: LWN article: ext4 and data loss References: <200903121239.35442@zmi.at> <49B9097C.1070003@sandeen.net> (sfid-20090312_151043_496061_D19DDB11) <200903121514.12732.Martin@lichtvoll.de> In-Reply-To: <200903121514.12732.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-Barracuda-Connect: mx2.redhat.com[66.187.237.31] X-Barracuda-Start-Time: 1236871003 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20130 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Martin Steigerwald wrote: > Am Donnerstag 12 März 2009 schrieb Eric Sandeen: >> Michael Monnerie wrote: >>> http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ >>> >>> Very good, maybe similar patches for XFS would help? >>> IANA Coder, but could be a hint. >>> >>> mfg zmi >> ext4 is taking its hints from XFS in this regard, not the other way >> around. XFS dealt with this long ago. > > Hmmm, I remember having had similar issues with XFS not to long ago, where depends on what you mean by not too long ago, I think. Yes, kde had this issue on xfs too, and xfs gave up on teaching apps to fsync, and implemented the same sorts of things ext4 has done (or will do) to mitigate this quite some time ago. > at least some KDE configuration were lost or truncated. It seems > applications will have to get rid of behavioral assumptions regation > filesystem and use safe writing via fsync and whatever else for > configuration and other important files. It's simple. Want your data safe on disk? fsync. There's not a lot more to it than that. (and if fsync hurts perf too much, re-think how you are storing your data) Filesystems can hack around some heuristics to try to make unsafe apps safer, but in the end, it's the app's job to make sure a buffered write hits permanent storage when it matters. -Eric > I am thinking about a bug report for KDE at least. > From sandeen@sandeen.net Thu Mar 12 11:37:36 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CGbGqV088240 for ; Thu, 12 Mar 2009 11:37:36 -0500 X-ASG-Debug-ID: 1236875789-78d1005a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 855D51906BD; Thu, 12 Mar 2009 09:36:29 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id tdCUo7NxM5n4R5xu; Thu, 12 Mar 2009 09:36:29 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2CGaRGC002760; Thu, 12 Mar 2009 12:36:27 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2CGaRrN014457; Thu, 12 Mar 2009 12:36:27 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2CGaQjo021135; Thu, 12 Mar 2009