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 12:36:27 -0400 Message-ID: <49B93A04.4070405@sandeen.net> Date: Thu, 12 Mar 2009 11:36:20 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Greg Banks CC: Martin Steigerwald , 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> <49B92423.4020708@sandeen.net> <49B9396D.7060809@sgi.com> In-Reply-To: <49B9396D.7060809@sgi.com> 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: 1236875810 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.20136 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 Greg Banks wrote: > Eric Sandeen wrote: >> 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. >> > > Stewart Smith has a highly entertaining presentation on this very topic. > > http://www.linux.org.au/conf/2007/talk/278.html > and http://www.flamingspork.com/talks/2007/06/eat_my_data.odp In hindsight, http://linuxmafia.com/faq/Filesystems/reiserfs.html is entertaining, too ;) -Eric From gnb@sgi.com Thu Mar 12 11:59:03 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 relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CGwggM089763 for ; Thu, 12 Mar 2009 11:59:02 -0500 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay3.corp.sgi.com (Postfix) with SMTP id E43CFAC018 for ; Thu, 12 Mar 2009 09:58:18 -0700 (PDT) Received: from [134.15.251.2] (melb-sw-corp-251-2.corp.sgi.com [134.15.251.2]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA11024; Fri, 13 Mar 2009 03:40:58 +1100 Message-ID: <49B93C15.5040507@sgi.com> Date: Fri, 13 Mar 2009 03:45:09 +1100 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Martin Steigerwald , xfs@oss.sgi.com 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> <49B92423.4020708@sandeen.net> <49B9396D.7060809@sgi.com> <49B93A04.4070405@sandeen.net> In-Reply-To: <49B93A04.4070405@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: > > In hindsight, http://linuxmafia.com/faq/Filesystems/reiserfs.html is > entertaining, too ;) > > There was a fascinating internal thread about that one when somebody noticed it a few years back :-) -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. From gnb@sgi.com Thu Mar 12 11:59:04 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 relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2CGwhJa089764 for ; Thu, 12 Mar 2009 11:59:03 -0500 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay3.corp.sgi.com (Postfix) with SMTP id 504DBAC015 for ; Thu, 12 Mar 2009 09:58:20 -0700 (PDT) Received: from [134.15.251.2] (melb-sw-corp-251-2.corp.sgi.com [134.15.251.2]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA10707; Fri, 13 Mar 2009 03:29:39 +1100 Message-ID: <49B9396D.7060809@sgi.com> Date: Fri, 13 Mar 2009 03:33:49 +1100 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Martin Steigerwald , xfs@oss.sgi.com 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> <49B92423.4020708@sandeen.net> In-Reply-To: <49B92423.4020708@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: > > 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. > Stewart Smith has a highly entertaining presentation on this very topic. http://www.linux.org.au/conf/2007/talk/278.html -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. From kevin@kevinjamieson.com Thu Mar 12 13:51: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=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 n2CIp0Gt093974 for ; Thu, 12 Mar 2009 13:51:20 -0500 X-ASG-Debug-ID: 1236883816-27f103b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from idcmail-mo1so.shaw.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4E5921C3AA1E for ; Thu, 12 Mar 2009 11:50:16 -0700 (PDT) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by cuda.sgi.com with ESMTP id cgx0inihISv86DzK for ; Thu, 12 Mar 2009 11:50:16 -0700 (PDT) Received: from pd3ml1so-ssvc.prod.shaw.ca ([10.0.141.140]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 12 Mar 2009 12:50:15 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=pcezlQ9ACQAg5CQeQP8A:9 a=BxNtJr7PxevjKRHHgfXD6MZ7uysA:4 a=sgOHI7_M_msA:10 a=P3uGiYoS1yEA:10 a=M8wPuokCQ-QA:10 Received: from s0106002078c6464f.vn.shawcable.net (HELO mail.kevinjamieson.com) ([24.87.84.75]) by pd3ml1so-dmz.prod.shaw.ca with ESMTP; 12 Mar 2009 12:50:15 -0600 Received: by mail.kevinjamieson.com (Postfix, from userid 1102) id 717B820255; Thu, 12 Mar 2009 11:50:15 -0700 (PDT) Received: from squirrel.kevinjamieson.com (localhost [127.0.0.1]) by mail.kevinjamieson.com (Postfix) with ESMTP id 5FA6020146 for ; Thu, 12 Mar 2009 11:50:14 -0700 (PDT) Received: from 24.80.224.145 (SquirrelMail authenticated user kevin) by squirrel.kevinjamieson.com with HTTP; Thu, 12 Mar 2009 11:50:14 -0700 (PDT) Message-ID: <64323.24.80.224.145.1236883814.squirrel@squirrel.kevinjamieson.com> Date: Thu, 12 Mar 2009 11:50:14 -0700 (PDT) X-ASG-Orig-Subj: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 Subject: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 From: "Kevin Jamieson" To: xfs@oss.sgi.com Reply-To: kevin@kevinjamieson.com User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: idcmail-mo1so.shaw.ca[24.71.223.10] X-Barracuda-Start-Time: 1236883837 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0025 1.0000 -2.0049 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=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20144 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 Hello, We have triggered the below oops in XFS several times on the SLES 10 SP2 kernel (2.6.16.60-0.21-smp). We've also seen it on earlier SLES 10 kernels (2.6.16.21-0.8-smp). The oops seems to occur with an application that backs up largish (~ 1GB) files to the XFS file system over NFS, although it is not easily reproducible (it happens about once a week on our test system). We have run xfs_repair a few times afterwards, and it did not detect any problems with the file system. We will be reporting this to Novell support, of course, but I thought I'd post it here too in case anyone had any ideas or has seen this before. Thanks, Kevin Mar 11 13:10:26 gn1 kernel: Unable to handle kernel paging request at virtual address 0301c39c Mar 11 13:10:26 gn1 kernel: printing eip: Mar 11 13:10:26 gn1 kernel: f95899ab Mar 11 13:10:26 gn1 kernel: *pde = 00000000 Mar 11 13:10:26 gn1 kernel: Oops: 0000 [#1] Mar 11 13:10:26 gn1 kernel: SMP Mar 11 13:10:26 gn1 kernel: last sysfs file: /devices/pci0000:00/0000:00:06.0/0000:17:00.0/host1/target1:0:3/1:0:3:0/type Mar 11 13:10:26 gn1 kernel: Modules linked in: nfsd exportfs lockd nfs_acl sunrpc af_packet xfs_quota sg qla2xxx_conf qla2xxx intermodule bnx2 xt_pkttype ipt_LOG xt_limit bonding ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_ma ngle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables ipv6 loop xfs_dmapi xfs dmapi dm_mod usbhid hw_random shpchp pci_hotplug uhci_hcd ehci_hcd ide_cd cdrom usbcore e10 00 ext3 jbd ata_piix ahci libata edd fan thermal processor firmware_class scsi_transport_fc cciss piix sd_mod scsi_mod ide_disk ide_core Mar 11 13:10:26 gn1 kernel: CPU: 0 Mar 11 13:10:26 gn1 kernel: EIP: 0060:[] Tainted: G U VLI Mar 11 13:10:26 gn1 kernel: EFLAGS: 00010202 (2.6.16.60-0.21-smp #1) Mar 11 13:10:26 gn1 kernel: EIP is at xfs_bmbt_get_startoff+0x2/0x15 [xfs] Mar 11 13:10:26 gn1 kernel: eax: 0301c398 ebx: ec9fc6d0 ecx: 0301c398 edx: 00001c39 Mar 11 13:10:26 gn1 kernel: esi: ec9fc680 edi: 0301c398 ebp: d9c1fe40 esp: d9c1fe24 Mar 11 13:10:26 gn1 kernel: ds: 007b es: 007b ss: 0068 Mar 11 13:10:26 gn1 kernel: Process nfsd (pid: 2178, threadinfo=d9c1e000 task=dfc80910) Mar 11 13:10:26 gn1 kernel: Stack: <0>f957eb34 ec9fc680 ec9fc680 f651b000 00000000 f95a2f4e 00000000 dfc80910 Mar 11 13:10:26 gn1 kernel: 00100100 ec9fc680 ec9fc680 2f14a000 f95a3045 00000001 d0bcd800 ec9fc680 Mar 11 13:10:26 gn1 kernel: 00000000 0002f14a 00000000 f95bae44 2f14a000 00000000 00000fff 00000000 Mar 11 13:10:26 gn1 kernel: Call Trace: Mar 11 13:10:26 gn1 kernel: [] xfs_bmap_last_offset+0xc0/0xdc [xfs] Mar 11 13:10:26 gn1 kernel: [] xfs_file_last_byte+0x1e/0xbc [xfs] Mar 11 13:10:26 gn1 kernel: [] xfs_itruncate_start+0x59/0xa8 [xfs] Mar 11 13:10:26 gn1 kernel: [] xfs_free_eofblocks+0x17a/0x276 [xfs] Mar 11 13:10:26 gn1 kernel: [] xfs_release+0x115/0x175 [xfs] Mar 11 13:10:26 gn1 kernel: [] xfs_file_release+0x13/0x1a [xfs] Mar 11 13:10:26 gn1 kernel: [] __fput+0x9d/0x170 Mar 11 13:10:26 gn1 kernel: [] nfsd_write+0xb6/0xbf [nfsd] Mar 11 13:10:26 gn1 kernel: [] nfsd3_proc_write+0xd0/0xe7 [nfsd] Mar 11 13:10:26 gn1 kernel: [] svcauth_unix_accept+0xe1/0x18e [sunrpc] Mar 11 13:10:26 gn1 kernel: [] nfsd_dispatch+0xbb/0x16c [nfsd] Mar 11 13:10:26 gn1 kernel: [] svc_process+0x388/0x616 [sunrpc] Mar 11 13:10:26 gn1 kernel: [] nfsd+0x197/0x2ff [nfsd] Mar 11 13:10:26 gn1 kernel: [] nfsd+0x0/0x2ff [nfsd] Mar 11 13:10:26 gn1 kernel: [] kernel_thread_helper+0x5/0xb Mar 11 13:10:26 gn1 kernel: Code: 53 89 c1 8b 00 31 d2 8b 59 0c 8b 49 08 25 ff 01 00 00 89 c2 b8 00 00 00 00 0f ac d9 15 c1 e2 0b 09 c8 c1 eb 15 09 da 5b c3 89 c1 <8b> 51 04 8b 00 81 e2 ff ff ff 7f 0f ac d0 09 c1 ea 09 c3 57 56 From sandeen@sandeen.net Thu Mar 12 14:24:04 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 n2CJNhgI095090 for ; Thu, 12 Mar 2009 14:24:04 -0500 X-ASG-Debug-ID: 1236885800-20e500340000-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 9C4221C3AC19 for ; Thu, 12 Mar 2009 12:23:20 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id VFjZxMak21kyawvb for ; Thu, 12 Mar 2009 12:23:20 -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 n2CJNJhG005368; Thu, 12 Mar 2009 15:23: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 n2CJNIIb002188; Thu, 12 Mar 2009 15:23:19 -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 n2CJNH1T030934; Thu, 12 Mar 2009 15:23:18 -0400 Message-ID: <49B9611F.5040009@sandeen.net> Date: Thu, 12 Mar 2009 14:23:11 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: kevin@kevinjamieson.com CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 Subject: Re: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 References: <64323.24.80.224.145.1236883814.squirrel@squirrel.kevinjamieson.com> In-Reply-To: <64323.24.80.224.145.1236883814.squirrel@squirrel.kevinjamieson.com> 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: 1236885800 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: -0.52 X-Barracuda-Spam-Status: No, SCORE=-0.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_SC1_TG172a X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20144 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 1.00 BSF_SC1_TG172a Custom Rule TG172a X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Kevin Jamieson wrote: > Hello, > > We have triggered the below oops in XFS several times on the SLES 10 SP2 > kernel (2.6.16.60-0.21-smp). We've also seen it on earlier SLES 10 kernels > (2.6.16.21-0.8-smp). > > The oops seems to occur with an application that backs up largish (~ 1GB) > files to the XFS file system over NFS, although it is not easily > reproducible (it happens about once a week on our test system). We have > run xfs_repair a few times afterwards, and it did not detect any problems > with the file system. > > We will be reporting this to Novell support, of course, but I thought I'd > post it here too in case anyone had any ideas or has seen this before. For SLES that usually is the best route... However, http://oss.sgi.com/archives/xfs/2009-02/msg00220.html looks applicable... don't think it ever got merged though. perhaps you could test it? -Eric > Thanks, > Kevin > > Mar 11 13:10:26 gn1 kernel: Unable to handle kernel paging request at > virtual address 0301c39c > Mar 11 13:10:26 gn1 kernel: printing eip: > Mar 11 13:10:26 gn1 kernel: f95899ab > Mar 11 13:10:26 gn1 kernel: *pde = 00000000 > Mar 11 13:10:26 gn1 kernel: Oops: 0000 [#1] > Mar 11 13:10:26 gn1 kernel: SMP > Mar 11 13:10:26 gn1 kernel: last sysfs file: > /devices/pci0000:00/0000:00:06.0/0000:17:00.0/host1/target1:0:3/1:0:3:0/type > Mar 11 13:10:26 gn1 kernel: Modules linked in: nfsd exportfs lockd nfs_acl > sunrpc af_packet xfs_quota sg qla2xxx_conf qla2xxx intermodule bnx2 > xt_pkttype ipt_LOG xt_limit bonding ip6t_REJECT xt_tcpudp ipt_REJECT > xt_state iptable_ma > ngle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack > nfnetlink ip_tables ip6table_filter ip6_tables x_tables ipv6 loop > xfs_dmapi xfs dmapi dm_mod usbhid hw_random shpchp pci_hotplug uhci_hcd > ehci_hcd ide_cd cdrom usbcore e10 > 00 ext3 jbd ata_piix ahci libata edd fan thermal processor firmware_class > scsi_transport_fc cciss piix sd_mod scsi_mod ide_disk ide_core > Mar 11 13:10:26 gn1 kernel: CPU: 0 > Mar 11 13:10:26 gn1 kernel: EIP: 0060:[] Tainted: G U VLI > Mar 11 13:10:26 gn1 kernel: EFLAGS: 00010202 (2.6.16.60-0.21-smp #1) > Mar 11 13:10:26 gn1 kernel: EIP is at xfs_bmbt_get_startoff+0x2/0x15 [xfs] > Mar 11 13:10:26 gn1 kernel: eax: 0301c398 ebx: ec9fc6d0 ecx: 0301c398 > edx: 00001c39 > Mar 11 13:10:26 gn1 kernel: esi: ec9fc680 edi: 0301c398 ebp: d9c1fe40 > esp: d9c1fe24 > Mar 11 13:10:26 gn1 kernel: ds: 007b es: 007b ss: 0068 > Mar 11 13:10:26 gn1 kernel: Process nfsd (pid: 2178, threadinfo=d9c1e000 > task=dfc80910) > Mar 11 13:10:26 gn1 kernel: Stack: <0>f957eb34 ec9fc680 ec9fc680 f651b000 > 00000000 f95a2f4e 00000000 dfc80910 > Mar 11 13:10:26 gn1 kernel: 00100100 ec9fc680 ec9fc680 2f14a000 > f95a3045 00000001 d0bcd800 ec9fc680 > Mar 11 13:10:26 gn1 kernel: 00000000 0002f14a 00000000 f95bae44 > 2f14a000 00000000 00000fff 00000000 > Mar 11 13:10:26 gn1 kernel: Call Trace: > Mar 11 13:10:26 gn1 kernel: [] xfs_bmap_last_offset+0xc0/0xdc > [xfs] > Mar 11 13:10:26 gn1 kernel: [] xfs_file_last_byte+0x1e/0xbc [xfs] > Mar 11 13:10:26 gn1 kernel: [] xfs_itruncate_start+0x59/0xa8 [xfs] > Mar 11 13:10:26 gn1 kernel: [] xfs_free_eofblocks+0x17a/0x276 > [xfs] > Mar 11 13:10:26 gn1 kernel: [] xfs_release+0x115/0x175 [xfs] > Mar 11 13:10:26 gn1 kernel: [] xfs_file_release+0x13/0x1a [xfs] > Mar 11 13:10:26 gn1 kernel: [] __fput+0x9d/0x170 > Mar 11 13:10:26 gn1 kernel: [] nfsd_write+0xb6/0xbf [nfsd] > Mar 11 13:10:26 gn1 kernel: [] nfsd3_proc_write+0xd0/0xe7 [nfsd] > Mar 11 13:10:26 gn1 kernel: [] svcauth_unix_accept+0xe1/0x18e > [sunrpc] > Mar 11 13:10:26 gn1 kernel: [] nfsd_dispatch+0xbb/0x16c [nfsd] > Mar 11 13:10:26 gn1 kernel: [] svc_process+0x388/0x616 [sunrpc] > Mar 11 13:10:26 gn1 kernel: [] nfsd+0x197/0x2ff [nfsd] > Mar 11 13:10:26 gn1 kernel: [] nfsd+0x0/0x2ff [nfsd] > Mar 11 13:10:26 gn1 kernel: [] kernel_thread_helper+0x5/0xb > Mar 11 13:10:26 gn1 kernel: Code: 53 89 c1 8b 00 31 d2 8b 59 0c 8b 49 08 > 25 ff 01 00 00 89 c2 b8 00 00 00 00 0f ac d9 15 c1 e2 0b 09 c8 c1 eb 15 09 > da 5b c3 89 c1 <8b> 51 04 8b 00 81 e2 ff ff ff 7f 0f ac d0 09 c1 ea 09 c3 > 57 56 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From bswince@yahoo.com Thu Mar 12 14:57:29 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=BAYES_05,HTML_MESSAGE 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 n2CJv8FA096575 for ; Thu, 12 Mar 2009 14:57:29 -0500 X-ASG-Debug-ID: 1236887805-210f00ac0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web31805.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 1E9941C3AE20 for ; Thu, 12 Mar 2009 12:56:45 -0700 (PDT) Received: from web31805.mail.mud.yahoo.com (web31805.mail.mud.yahoo.com [68.142.207.68]) by cuda.sgi.com with SMTP id 06rakXCKWh5ppyut for ; Thu, 12 Mar 2009 12:56:45 -0700 (PDT) Received: (qmail 90275 invoked by uid 60001); 12 Mar 2009 19:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236887805; bh=r/d+9xKBtwuOwEGAcUTnHNyM9Ljdllct3QAtdYP8X1w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=eJOsrDny9Hik/QivzaPCaJrQOsYZCDNMH6D5Obx4AniwTvtQfmlwqgFyfuIufGKfsRFWTQeR42ATuTUFERtm8+4a2ZLo1dmrgoveep7UCbYv24HlzetPo9L11MDrfGE+ulnuD5V3ASy4NCT/u37IEXSH7kAAZwVBLJPM3hI9sKY= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=V31LJURCfAMJS6/a3M9g8TzUxBFya9IL3OZ8RBe6w9YrfZEDT6BomGWeCROkd7O+ga5GMVqWIiQWW1cIMPZcXATDfPUyyodAKvArIMugZmdDcg92w1Vdem8weQGtpQ1E192n4GcbOWhWxI3o4XfAmLrJ9/bWU/6BdWZWfXpXpWc=; Message-ID: <296855.89556.qm@web31805.mail.mud.yahoo.com> X-YMail-OSG: QVuB35wVM1n_2wuJCByK6iDV4QxKdRzo4Eyq0usX4EqnsfKO6jI7Fqj4GmkMRjcf2eHWcbMtTZ1FgKVQl4KYN8QKWMKvUoAZSqgNaiqV3rqB4TC2FFhouPtRvezlU9zWf.DWSQXUzFCMr8F2o8N4IRCD5G.aWTIUwesGDURU725m7j_JrSIWH5mtG_kdrg-- Received: from [198.24.6.135] by web31805.mail.mud.yahoo.com via HTTP; Thu, 12 Mar 2009 12:56:45 PDT X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.9 Date: Thu, 12 Mar 2009 12:56:45 -0700 (PDT) From: brian wince X-ASG-Orig-Subj: issues with project quota over nfs Subject: issues with project quota over nfs To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2113199796-1236887805=:89556" X-Barracuda-Connect: web31805.mail.mud.yahoo.com[68.142.207.68] X-Barracuda-Start-Time: 1236887806 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0016 1.0000 -2.0105 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 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.20144 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 --0-2113199796-1236887805=:89556 Content-Type: text/plain; charset=us-ascii All, We have a Quad-core server running gentoo 2.6.27-r7 that is used as an nfs server for a xfs partition. We are using project quota's on directories within this partition and exporting this. When a client tries to untar in the dir with project quotas set and reaches the quota limit the load on the NFS server goes up dramatically and stays like this for a few minutes after the tar has gone through trying to write all of it files and failing due to quota limit exceeded. Is this a known issue and if so is there anything that can be done to resolve this. We do not see this issue if on the locally mounted partition. This only happens over NFS. Please let me know if you need more information or if this should be addressed on a different list. TIA, Brian --0-2113199796-1236887805=:89556 Content-Type: text/html; charset=us-ascii
All,
We have a Quad-core server running gentoo 2.6.27-r7 that is used as an nfs server for a xfs partition.
We are using project quota's on directories within this partition and exporting this.
When a client tries to untar in the dir with project quotas set and reaches the quota limit the load on the NFS server goes up dramatically and stays like this for a few minutes after the tar has gone through trying to write all of it files and failing due to quota limit exceeded.
 
Is this a known issue and if so is there anything that can be done to resolve this.
 
We do not see this issue if on the locally mounted partition. This only happens over NFS.
 
Please let me know if you need more information or if this should be addressed on a different list.
 
TIA,
 
Brian

--0-2113199796-1236887805=:89556-- From kevin@kevinjamieson.com Thu Mar 12 18:14: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 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 n2CNE6oB105067 for ; Thu, 12 Mar 2009 18:14:27 -0500 X-ASG-Debug-ID: 1236899623-210403b70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from idcmail-mo2no.shaw.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D9DC71C3B6D8 for ; Thu, 12 Mar 2009 16:13:43 -0700 (PDT) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by cuda.sgi.com with ESMTP id 4AjJPXr3TLpF7svw for ; Thu, 12 Mar 2009 16:13:43 -0700 (PDT) Received: from pd6ml2no-ssvc.prod.shaw.ca ([10.0.153.163]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 12 Mar 2009 17:13:43 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=eJfxgxciAAAA:8 a=BAxYGtd1ilxgaZwYLNsA:9 a=ccDTAlOxzR2TLjKUq25uzZa8el0A:4 a=T6zWE12s9mEA:10 a=p0z0BktFnWsA:10 a=M8wPuokCQ-QA:10 Received: from s0106002078c6464f.vn.shawcable.net (HELO mail.kevinjamieson.com) ([24.87.84.75]) by pd6ml2no-dmz.prod.shaw.ca with ESMTP; 12 Mar 2009 17:13:42 -0600 Received: by mail.kevinjamieson.com (Postfix, from userid 1102) id C199120255; Thu, 12 Mar 2009 16:13:42 -0700 (PDT) Received: from squirrel.kevinjamieson.com (localhost [127.0.0.1]) by mail.kevinjamieson.com (Postfix) with ESMTP id 71EAB20058; Thu, 12 Mar 2009 16:13:40 -0700 (PDT) Received: from 24.80.224.145 (SquirrelMail authenticated user kevin) by squirrel.kevinjamieson.com with HTTP; Thu, 12 Mar 2009 16:13:40 -0700 (PDT) Message-ID: <58707.24.80.224.145.1236899620.squirrel@squirrel.kevinjamieson.com> In-Reply-To: <49B9611F.5040009@sandeen.net> References: <64323.24.80.224.145.1236883814.squirrel@squirrel.kevinjamieson.com> <49B9611F.5040009@sandeen.net> Date: Thu, 12 Mar 2009 16:13:40 -0700 (PDT) X-ASG-Orig-Subj: Re: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 Subject: Re: Oops at xfs_bmbt_get_startoff in SLES 10 2.6.16 From: "Kevin Jamieson" To: "Eric Sandeen" Cc: xfs@oss.sgi.com Reply-To: kevin@kevinjamieson.com User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: idcmail-mo2no.shaw.ca[64.59.134.9] X-Barracuda-Start-Time: 1236899623 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0952 1.0000 -1.4217 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 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.20155 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 Thu, March 12, 2009 12:23 pm, Eric Sandeen wrote: > For SLES that usually is the best route... > > However, http://oss.sgi.com/archives/xfs/2009-02/msg00220.html looks > applicable... don't think it ever got merged though. > > perhaps you could test it? Thanks, Eric. I will test Lachlan's patch on our system. Kevin From gnb@sgi.com Thu Mar 12 21:29:02 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 relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2D2SfWR112840 for ; Thu, 12 Mar 2009 21:29:01 -0500 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay3.corp.sgi.com (Postfix) with SMTP id 6F523AC01D for ; Thu, 12 Mar 2009 19:28:18 -0700 (PDT) Received: from [134.15.251.2] (melb-sw-corp-251-2.corp.sgi.com [134.15.251.2]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23151; Fri, 13 Mar 2009 13:15:32 +1100 Message-ID: <49B9C2BD.8070802@sgi.com> Date: Fri, 13 Mar 2009 13:19:41 +1100 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: brian wince CC: xfs@oss.sgi.com Subject: Re: issues with project quota over nfs References: <296855.89556.qm@web31805.mail.mud.yahoo.com> In-Reply-To: <296855.89556.qm@web31805.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean brian wince wrote: > All, > We have a Quad-core server running gentoo 2.6.27-r7 that is used as an > nfs server for a xfs partition. > We are using project quota's on directories within this partition and > exporting this. > When a client tries to untar in the dir with project quotas set and > reaches the quota limit the load on the NFS server goes up > dramatically and stays like this for a few minutes after the tar has > gone through trying to write all of it files and failing due to quota > limit exceeded. > > Is this a known issue and if so is there anything that can be done to > resolve this. You probably want to update the client kernels to have this commit: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=commit&h=7b159fc18d417980f57aef64cab3417ee6af70f8 > > We do not see this issue if on the locally mounted partition. This > only happens over NFS. > > Please let me know if you need more information or if this should be > addressed on a different list. You should ask NFS questions on the NFS list, linux-nfs@vger.kernel.org. -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. From SEMA-CR-1-3ZQ89U@ptcmarketing.com Fri Mar 13 04:54:18 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_QP_LONG_LINE 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 n2D9rvW8132949 for ; Fri, 13 Mar 2009 04:54:17 -0500 X-ASG-Debug-ID: 1236937993-336902eb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8C761C3D145 for ; Fri, 13 Mar 2009 02:53:13 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id berxP4g7Rsplc7an for ; Fri, 13 Mar 2009 02:53:13 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,356,1233550800"; d="scan'208,217";a="291618281" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 13 Mar 2009 05:38:47 -0400 To: MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: New Pro/ENGINEER Training Exercise Demo! Subject: New Pro/ENGINEER Training Exercise Demo! Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1236936064830_1269139682 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1236938014 Date: Fri, 13 Mar 2009 02:53:13 -0700 (PDT) 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 --BF_1236936064830_1269139682 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable BONUS OFFER! Request your free 3-part video sample training before March 31, 2009, and yo= u=E2=80=99ll automatically be entered into a drawing for a $50 American Expr= ess=C2=AE personal gift card (http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3OT7J4= &o=3D= 1-3YYTLJ= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D85794) Actual Pro/ENGINEER Auto Round training video offers an insider=E2=80=99s vi= ew of PTC University courses. Here=E2=80=99s your chance to see firsthand=E2=80=94and without cost=E2=80= =94how the instructors at PTC University can help you and your co-workers ma= ximize your Pro/ENGINEER design skills and productivity. Click here to receive a FREE three-part sample learning exercise featuring t= he Pro/ENGINEER Auto Round training module. Discover how this powerful Auto = Round tool can enhance your design capabilities faster and more efficiently=E2=80=A6 then apply your new= found knowledge to live projects you=E2=80=99re currently working on.(http:/= /www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3OT7J4= &o=3D= 1-3YYTLJ= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D85794) With the free example learning exercise, you=E2=80=99ll receive: - An audio and slide presentation that introduces and outlines the Pro/ENG= INEER Auto Rounds module - A video demonstration and narration of the application in use - Step-by-step audio instructions on how to utilize the Auto Rounds module= to enhance your design process. Of course, this is just one example of the thousands of topics that PTC Univ= ersity covers in its courses. You can attend classes at one of our training = centers, learn on-line or request onsite training right at your place of bus= iness. Look at everything that=E2=80=99s included! This offer is valid in the US and Canada only. Responders who complete the f= orm and download the sample class demo will automatically be entered into th= e drawing for one American Express gift card valued at 50.00 US Dollars. Off= er expires March 31, 2009. Limit one entry per person. A winner will be chos= en 21 business days after the the promotion expiration date.=C2=A9 2009 Para= metric Technology Corporation (PTC). All rights reserved.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-3YYTLJ= &campd=3D= 1-3OT7J4= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-3YYTLJ= &campd=3D= 1-3OT7J4= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= edit profile http://www.ptc.com/read?&w=3D= 2354034= &t=3D/common/account/index.htm ----------------------------------------------------------------------------= --- This email was sent to: = xfs@oss.sgi.com= PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to= unsubscribe@ptc.com. --BF_1236936064830_1269139682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable ProE Lead Gen Direct Marketing Event Email 2  NA Q209</titl= e> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8" /> <style type=3D"text/css"> <!-- body { background-color: #e3f0f6; } div.ptcemailbody {position: relative; display: block; width: 662px; backgrou= nd-color: #ffffff; font-family: Verdana, Arial, sans-serif; font-size: 0.8em; color: #000000; = margin-left: auto; margin-right: auto;} div.ptcemailbody a {text-decoration: underline;} div.ptcemailbody a:link {color: #0C689D;} div.ptcemailbody a:visited {color: #4946BE;} div.ptcemailbody a:active {color: #8FABBE;} div.ptcemailbody a:hover {color: #000000;} div.ptcemailbody img {border: 0px;} div.ptcemailbody .emailtext {padding: 5px;} div.ptcemailbody h1 {font-size: 1.8em; font-weight: extra-light; font-style:= italic; font-family: arial,helvetica,san-serif; color: #666666;} div.ptcemailbody h2 {font-size: 1.2em; font-weight: extra-light; font-style:= normal; font-family: arial,helvetica,san-serif; color: #002B54;} div.ptcemailbody h3 {font-size: 1em; font-weight: extra-light; font-style: n= ormal; font-family: arial,helvetica,san-serif; color: #002B54;}=09 div.ptcemailbody .emailfooter { font-family: verdana,arial,helvetica,san-ser= if; color: #000000; text-decoration:none; font-size: 0.9em; padding: 8px 5px 8px 5px; background-color: #e3f0f6;} div.ptcemailbody .emailHeader { background-color:#000000; text-align: right;= width: 100%;} --> </style> </head> <body align=3D"center"><div align=3D"center"> <div class=3D"ptcemailbody" align=3D"left"> <div class=3D"emailHeader"><img height=3D"52" alt=3D"PTC.com" src=3D"http://= www.ptc.com/WCMS/images/28758en_image1.gif" width=3D"248" border=3D"0" /></d= iv> <div><a href=3D"http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3OT7J4= &o=3D= 1-3YYTLJ= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D85794"><img height=3D"= 160" alt=3D"FREE Pro/ENGINEER Auto Round™ demo class!" src=3D"http://w= ww.ptc.com/WCMS/images/89390/89390en_banner.gif" width=3D"662" border=3D"0" = /></a></div> <div class=3D"emailtext"><strong><br /> </strong>=20 <p><strong>BONUS OFFER!</strong></p> <p><strong>Request your <a href=3D"http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3OT7J4= &o=3D= 1-3YYTLJ= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D85794">free 3-part vid= eo sample training</a> before March 31, 2009, and you’ll automatically= be entered into a drawing for a $50 American Express<sup>®</sup> perso= nal gift card!<br /> </strong><br /> Actual Pro/ENGINEER Auto Round training video offers an insider’s view= of PTC University courses.</p> <p>Here’s your chance to see firsthand—and without cost—ho= w the instructors at PTC University can help you and your co-workers maximiz= e your Pro/ENGINEER design skills and productivity.<br /> <br /> <a href=3D"http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3OT7J4= &o=3D= 1-3YYTLJ= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D85794">Click here</a> = to receive a FREE three-part sample learning exercise featuring the Pro/ENGI= NEER Auto Round training module. Discover how this powerful Auto Round tool = can enhance your design capabilities faster and more efficiently… then= apply your newfound knowledge to live projects you’re currently worki= ng on.</p> <p>With the free example learning exercise, you’ll receive:</p> <ul> <li> <div>An audio and slide presentation that introduces and outlines the Pro/EN= GINEER Auto Rounds module<br /> <br /> </div> </li> <li> <div>A video demonstration and narration of the application in use<br /> <br /> </div> </li> <li> <div>Step-by-step audio instructions on how to utilize the Auto Rounds modul= e to enhance your design process.</div> </li> </ul> <p>Of course, this is just one example of the thousands of topics that PTC U= niversity covers in its courses. You can attend classes at one of our traini= ng centers, learn on-line or request onsite training right at your place of = business.</p> <p><strong>Look at everything that’s included!</strong></p> <p></p> <p></p> <font size=3D"1"><span lang=3D"EN-US"><span lang=3D"EN-US">This offer is val= id in the US and Canada only.  Responders who complete the form and dow= nload the sample class demo will automatically be entered into the drawing f= or one American Express gift card valued at 50.00 US Dollars.  Offer ex= pires March 31, 2009.  Limit one entry per person.  A winner will = be chosen 21 business days after the the promotion expiration date.</span></= span>© 2009 Parametric Technology Corporation (PTC). All rights reserve= d. </font>=20 <div><img height=3D"72" alt=3D"PTCU Logo" src=3D"http://www.ptc.com/WCMS/ima= ges/89390/89390en_signature.jpg" width=3D"400" border=3D"0" /></div> <img height=3D"1" alt=3D"" src=3D"http://www.ptc.com/images/common/dot_clear= .gif?o=3D= 1-3YYTLJ= &c=3D= 1-3OT7J4= &u=3D= 1-5LWLN-2077= " width=3D"1" border=3D"0" /></div> <div class=3D"emailfooter"><a href=3D"http://www.ptc.com/company/contacts/in= dex.htm">contact PTC</a> | <a href=3D"http://www.ptc.com/company/policies/in= dex.htm">privacy policy</a> | <a href=3D"http://www.ptc.com/appserver/mkt/ma= il/preferences.jsp?&offd=3D= 1-3YYTLJ= &campd=3D= 1-3OT7J4= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= ">unsubscribe</a> | <a href=3D"http://www.ptc.com/appserver/mkt/mail/prefere= nces.jsp?&offd=3D= 1-3YYTLJ= &campd=3D= 1-3OT7J4= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= ">change preferences</a> | <a href=3D"http://www.ptc.com/read?&w=3D= 2354034= &t=3D/common/account/index.htm">edit profile</a><br /> <div>This email was sent to: = xfs@oss.sgi.com=     PTC, 140 Kendrick Street, Needham, MA 02494 USA</div> <div>If you wish to unsubscribe from all PTC Emails, please send a blank ema= il to <a href=3D"mailto:unsubscribe@ptc.com">unsubscribe@ptc.com</a>.</div> </div> </div> </div> </body> </html> --BF_1236936064830_1269139682-- From webinars@knowledgewave.com Fri Mar 13 22:30: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.7 required=5.0 tests=AWL,BAYES_20 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 n2E3TvaP175534 for <xfs@oss.sgi.com>; Fri, 13 Mar 2009 22:30:18 -0500 X-ASG-Debug-ID: 1237001375-76db03080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kwtmain.knowledgewave.local (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A89241C40ECA for <xfs@oss.sgi.com>; Fri, 13 Mar 2009 20:29:35 -0700 (PDT) Received: from kwtmain.knowledgewave.local (rr-64-25-211-193.teljet.com [64.25.211.193]) by cuda.sgi.com with ESMTP id Ounvze93Unpyn1os for <xfs@oss.sgi.com>; Fri, 13 Mar 2009 20:29:35 -0700 (PDT) Received: from SHAREPOINT ([10.0.0.12]) by kwtmain.knowledgewave.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 23:29:34 -0400 Sensitivity: Normal Importance: Normal MIME-Version: 1.0 From: "Knowledgewave Webinars" <webinars@knowledgewave.com> To: xfs@oss.sgi.com Date: 13 Mar 2009 23:29:35 -0400 X-ASG-Orig-Subj: Webinar: Learn how to create eye-catching charts in Excel. Subject: Webinar: Learn how to create eye-catching charts in Excel. Message-ID: <KWTMAINjix3A1R1q0iL00030ecd@kwtmain.knowledgewave.local> X-OriginalArrivalTime: 14 Mar 2009 03:29:34.0943 (UTC) FILETIME=[18A546F0:01C9A455] X-Barracuda-Connect: rr-64-25-211-193.teljet.com[64.25.211.193] X-Barracuda-Start-Time: 1237001375 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 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.20269 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 From webinars@knowledgewave.com Sat Mar 14 01:01:55 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=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 n2E61Y3l183270 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 01:01:54 -0500 X-ASG-Debug-ID: 1237010451-0a09023c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kwtmain.knowledgewave.local (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3DA431C412C9 for <xfs@oss.sgi.com>; Fri, 13 Mar 2009 23:00:51 -0700 (PDT) Received: from kwtmain.knowledgewave.local (rr-64-25-211-193.teljet.com [64.25.211.193]) by cuda.sgi.com with ESMTP id bPDeRPuq2DCKomCv for <xfs@oss.sgi.com>; Fri, 13 Mar 2009 23:00:51 -0700 (PDT) Received: from SHAREPOINT ([10.0.0.12]) by kwtmain.knowledgewave.local with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Mar 2009 02:00:19 -0400 Sensitivity: Normal Importance: Normal MIME-Version: 1.0 From: "Knowledgewave Webinars" <webinars@knowledgewave.com> To: xfs@oss.sgi.com Date: 14 Mar 2009 02:00:19 -0400 X-ASG-Orig-Subj: Webinar: Learn how to create eye-catching charts in Excel. Subject: Webinar: Learn how to create eye-catching charts in Excel. Message-ID: <KWTMAINzUnebRmw3plH00041540@kwtmain.knowledgewave.local> X-OriginalArrivalTime: 14 Mar 2009 06:00:19.0432 (UTC) FILETIME=[2794C680:01C9A46A] X-Barracuda-Connect: rr-64-25-211-193.teljet.com[64.25.211.193] X-Barracuda-Start-Time: 1237010472 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 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.20279 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 From webinars@knowledgewave.com Sat Mar 14 04:34:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY 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 n2E9Xx2n191488 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 04:34:20 -0500 X-ASG-Debug-ID: 1237023216-135c019c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kwtmain.knowledgewave.local (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DCFB6197D8B for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 02:33:36 -0700 (PDT) Received: from kwtmain.knowledgewave.local (rr-64-25-211-193.teljet.com [64.25.211.193]) by cuda.sgi.com with ESMTP id UaEXt3BIbDYaHS9t for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 02:33:36 -0700 (PDT) Received: from SHAREPOINT ([10.0.0.12]) by kwtmain.knowledgewave.local with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Mar 2009 05:33:35 -0400 Sensitivity: Normal Importance: Normal MIME-Version: 1.0 From: "Knowledgewave Webinars" <webinars@knowledgewave.com> To: xfs@oss.sgi.com Date: 14 Mar 2009 05:33:35 -0400 X-ASG-Orig-Subj: Webinar: Learn how to create eye-catching charts in Excel. Subject: Webinar: Learn how to create eye-catching charts in Excel. Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Message-ID: <KWTMAIN3HQ07lp3a1ji00051bf1@kwtmain.knowledgewave.local> X-OriginalArrivalTime: 14 Mar 2009 09:33:35.0937 (UTC) FILETIME=[F2E47B10:01C9A487] X-Barracuda-Connect: rr-64-25-211-193.teljet.com[64.25.211.193] X-Barracuda-Start-Time: 1237023216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5005 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.90 X-Barracuda-Spam-Status: No, SCORE=1.90 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, HTML_MIME_NO_HTML_TAG, MIME_HTML_ONLY, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20293 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 1.05 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 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 DQo8aGVhZD4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQouc3R5bGUxIHsNCglmb250LXNp emU6IHgtc21hbGw7DQoJZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7DQp9DQouc3R5bGUzIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCi5zdHlsZTQg ew0KCWZvbnQtc2l6ZTogeC1zbWFsbDsNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQoNCjx0aXRs ZT5XZWJpbmFyOiBObyBGZWUgRXZlbnQ6IE91dGxvb2sgMjAwNyBOZXcgRmVhdHVyZXM8L3Rp dGxlPg0KDQo8c3BhbiBjbGFzcz0ic3R5bGUzIj48c3BhbiBjbGFzcz0ic3R5bGU0Ij5EYXZp ZA0KDQo8L3NwYW4+DQo8c3Ryb25nPjxlbT48c3BhbiBjbGFzcz0ic3R5bGU0Ij48YnI+DQo8 YnI+DQpXaGF0IHdpbGwgeW91IGxlYXJuPzwvc3Bhbj48L2VtPjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJzdHlsZTQiPjxicj4NCkFsbW9zdCBldmVyeW9uZSBoYXMgc2VlbiBvciB3b3JrZWQg d2l0aCBhIGNoYXJ0IGF0IG9uZSB0aW1lIG9yIGFub3RoZXItLWNoYXJ0cyBpbGx1c3RyYXRl IGRhdGEsIHJlbGF0aW9uc2hpcHMsIG9yIHRyZW5kcywgZ3JhcGhpY2FsbHkuIExpa2UgdGhl IHNheWluZyDigJxhIHBpY3R1cmUgaXMgd29ydGggYSB0aG91c2FuZCB3b3Jkc+KAnSBjaGFy dHMgYXJlIG9mdGVuIGEgYmV0dGVyIHRvb2wgZm9yIHByZXNlbnRpbmcgaW5mb3JtYXRpb24g dGhhbiBoYXJkLXRvLXJlYWQgbnVtYmVycy4gVGhpcyBXZWJpbmFyIGNvdmVycyBqdXN0IGFi b3V0IGV2ZXJ5dGhpbmcgdGhlcmUgaXMgdG8ga25vdyBhYm91dCBjaGFydHMuIFRoZSBkYXp6 bGluZyBjaGFydHMgeW91IHdpbGwgYmUgYWJsZSB0byBjcmVhdGUgYWZ0ZXIgeW91IGZpbmlz aCB0aGlzIGNvdXJzZSB3aWxsIGltcHJlc3MgYm90aCB5b3UgYW5kIHlvdXIgY29sbGVhZ3Vl cy48YnI+DQo8YnI+DQpLbm93bGVkZ2VXYXZlIGlzIGhvc3RpbmcgYSBuZXcgd2ViaW5hciB0 aXRsZWQgDQo8c3Ryb25nPlRlbGwgWW91ciBTdG9yeSBWaXN1YWxseSB3aXRoIEV5ZS1DYXRj aGluZyBDaGFydHMgaW4gTWljcm9zb2Z0IEV4Y2VsICgyMDAzKTwvc3Ryb25nPi4gDQpXZSBh cmUgcGxlYXNlZCB0byBwcm92aWRlIHRoaXMgZXZlbnQgDQpvbiA8c3Ryb25nPk1hcmNoIDE4 LCAyMDA5PC9zdHJvbmc+LiAgS25vd2xlZGdlV2F2ZSBvZmZlcnMgb3ZlciA4MCsgd2ViaW5h ciB0aXRsZXMgaW4gYm90aCBvcGVuIGVucm9sbG1lbnQgYW5kIGNsb3NlZCBjb3Jwb3JhdGUg Zm9ybWF0LiBUaGlzIGV2ZW50IGlzIG9wZW4gdG8gdGhlIGdlbmVyYWwgcHVibGljIA0KZm9y IGEgZmVlIG9mICQ3OS4wMC4gRW5yb2xsIHRvZGF5IGFuZCBsZWFybiBmcm9tIHRoZSBleHBl cnRzITxicj4NCjxicj4NCjwvc3Bhbj4NCjxzdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+ UHJvZHVjdChzKTogTWljcm9zb2Z0IEV4Y2VsIDIwMDMuICBBdWRpZW5jZShzKTogQnVzaW5l c3MgUHJvZmVzc2lvbmFsLiBEdXJhdGlvbjogNjAgTWludXRlcyBTdGFydCBEYXRlOiAgDQpN YXJjaCAxOCwgMjAwOSA5OjAwIEFNIEVTVC48L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9 InN0eWxlNCI+PGJyPg0KPC9zcGFuPg0KPGEgaHJlZj0iaHR0cDovL3d3dy4xc2hvcHBpbmdj YXJ0LmNvbS9TZWN1cmVDYXJ0L1NlY3VyZUNhcnQuYXNweD9taWQ9NkU4MjYwMTgtMjhFOS00 MjBGLUJCMTEtMTNDOTNFNjYxQTc5JnBpZD0zODY2ZmQ4NTU0NWZjNzAwMmI4OTA3MmFjNmVi YzAyZSZibj0xIj48c3BhbiBjbGFzcz0ic3R5bGU0Ij5SZWdpc3RlciBUb2RheTwvc3Bhbj48 L2E+PHNwYW4gY2xhc3M9InN0eWxlNCI+OiBDbGljayB0aGUgbGluay4NCjxicj4NCjxicj4N CldlYmluYXJzIGFyZQ0KPC9zcGFuPiA8c3Ryb25nPjxzcGFuIGNsYXNzPSJzdHlsZTQiPmZh c3Q8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+LCANCjwvc3Bhbj4gPHN0 cm9uZz48c3BhbiBjbGFzcz0ic3R5bGU0Ij5jb252ZW5pZW50PC9zcGFuPjwvc3Ryb25nPjxz cGFuIGNsYXNzPSJzdHlsZTQiPiBhbmQgDQo8L3NwYW4+IDxzdHJvbmc+DQo8c3BhbiBjbGFz cz0ic3R5bGU0Ij5hZmZvcmRhYmxlPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJzdHls ZTQiPi4gVGhlcmUgaXMgbm8gd2FzdGVkIHRpbWUuIEdldCByaWdodCB0byB0aGUgb2JqZWN0 aXZlIG9mIHRoZSANCjEtaG91ciBzZXNzaW9uLiBXZWJpbmFycyBhcmUgZGVzaWduZWQgdG8g Zml0IGVhc2lseSBpbnRvIHlvdXIgYnVzeSBzY2hlZHVsZS4gWW91IA0KaGF2ZSBubyB0cmF2 ZWwgYW5kIG5vIHRpbWUgb3V0IG9mIHRoZSBvZmZpY2UhIE91ciB3ZWJpbmFycyBhcmUgZnJl ZSBvciBwcmljZWQgYXQgDQpsZXNzIHRoYW4gJDkwISBUaGF0JiMzOTtzIGEgZnJhY3Rpb24g b2YgdGhlIGNvc3Qgb2YgdHJhdmVsIGFuZCBhdHRlbmRhbmNlIGZlZXMgZm9yIA0Kb3RoZXIg aGlnaC1wcmljZWQgY2xhc3NlcywgY29uZmVyZW5jZXMsIHNlbWluYXJzIG9yIG90aGVyIG9u bGluZSB3ZWJpbmFycy4mbmJzcDsNCjxicj4NCjxicj4NCjwvc3Bhbj4NCjxhIGhyZWY9Imh0 dHA6Ly93d3cuMXNob3BwaW5nY2FydC5jb20vU2VjdXJlQ2FydC9TZWN1cmVDYXJ0LmFzcHg/ bWlkPTZFODI2MDE4LTI4RTktNDIwRi1CQjExLTEzQzkzRTY2MUE3OSZwaWQ9Mzg2NmZkODU1 NDVmYzcwMDJiODkwNzJhYzZlYmMwMmUmYm49MSI+PHNwYW4gY2xhc3M9InN0eWxlNCI+UmVn aXN0ZXIgVG9kYXk8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJzdHlsZTQiPjogQ2xpY2sgdGhl IGxpbmsuDQo8YnI+DQo8YnI+DQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIHdlYmlu YXIgYW5kIG91ciBvdGhlciB3ZWJpbmFyIGV2ZW50cywgcGxlYXNlIGdvIHRvIG91ciB3ZWJz aXRlOg0KPC9zcGFuPiANCjxhIGhyZWY9Imh0dHA6Ly93d3cua25vd2xlZGdld2F2ZS5jb20v d2ViaW5hcnMucGhwIj48c3BhbiBjbGFzcz0ic3R5bGU0Ij5odHRwOi8vd3d3Lmtub3dsZWRn ZXdhdmUuY29tL3dlYmluYXJzLnBocDwvc3Bhbj48L2E+PC9zcGFuPg0KPHNwYW4gY2xhc3M9 InN0eWxlMyI+PHNwYW4gY2xhc3M9InN0eWxlNCI+PGJyPg0KPGJyPg0KVGhhbmtzLCBhbmQg aGF2ZSBhIGdyZWF0IGRheS4NCg0KPGJyPg0KPGJyPg0KPC9zcGFuPg0KPHN0cm9uZz48c3Bh biBjbGFzcz0ic3R5bGU0Ij5Lbm93bGVkZ2VXYXZlIFdlYmluYXIgU3RhZmYgPC9zcGFuPg0K DQogDQoNCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KPC9zdHJvbmc+PGJyPg0KPGJyPg0KPGltZyBhbHQ9Iktub3dsZWRnZVdhdmUgV2ViaW5h cnMiIHNyYz0iaHR0cDovL3d3dy5rbm93bGVkZ2V3YXZlLmNvbS9pbWFnZXMvbG9nby1jb2xv ci13ZWIuanBnIiB3aWR0aD0iMjYwIiBoZWlnaHQ9IjUxIj48YnI+DQo8YnI+DQo8aW1nIGFs dD0iTWljcm9zb2Z0IEdvbGQgUGFydG5lciIgc3JjPSJodHRwOi8vd3d3Lmtub3dsZWRnZXdh dmUuY29tL2ltYWdlcy9taWNyb3NvZnRHb2xkQ2VydGlmaWVkLmdpZiIgd2lkdGg9IjI2MyIg aGVpZ2h0PSI1MiI+PGJyPg0KPGJyPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOndlYmluYXJz QGtub3dsZWRnZXdhdmUuY29tIj53ZWJpbmFyc0Brbm93bGVkZ2V3YXZlLmNvbTwvYT48L3Nw YW4+DQo8c3BhbiBjbGFzcz0ic3R5bGUzIj48YnI+DQpLbm93bGVkZ2V3YXZlIGlzIFZlcm1v bnQncyBvbmx5IENlcnRpZmllZCBNaWNyb3NvZnQgR29sZCBQYXJ0bmVyIGZvciBMZWFybmlu ZyBTb2x1dGlvbnMuDQogPGJyPg0KwqkgMjAwOCBLbm93bGVkZ2VXYXZlLiANCjxicj4NCjMw IENvbW11bml0eSBEcml2ZSwgU3RlIDUsIFNvdXRoIEJ1cmxpbmd0b24sIFZUIDA1NDAzIA0K PGJyPg0KQ2FsbDogMS04MDAtODMxLTg0NDkNCiANCjxicj4NCjxicj4NCjwvc3Bhbj48c3Bh biBjbGFzcz0ic3R5bGUxIj5UaGUgZW1haWwgd2FzIHNlbnQgdG8geGZzQG9zcy5zZ2kuY29t LiBJZiB5b3UgcHJlZmVyIG5vdCB0byByZWNlaXZlIHRoZXNlIGVtYWlscywgcGxlYXNlIHJl cGx5IHRvIHRoaXMgbWVzc2FnZSB3aXRoIFJFTU9WRSBpbiB0aGUgc3ViamVjdCBsaW5lIGFu ZCB3ZSB3aWxsIHJlbW92ZSB5b3VyIGVtYWlsIGFkZHJlc3MgZnJvbSBmdXR1cmUgS25vd2xl ZGdlV2F2ZSBkaXN0cmlidXRpb25zLg0KPC9zcGFuPg== From SRS0+29ffd3d6107b141fde38+2029+infradead.org+hch@bombadil.srs.infradead.org Sat Mar 14 10:25: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.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 n2EFPcNO206438 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 10:25:59 -0500 X-ASG-Debug-ID: 1237044316-2818007d0000-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 D14811C41E51; Sat, 14 Mar 2009 08:25:16 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Q4p8BHRbGtcblYWJ; Sat, 14 Mar 2009 08:25:16 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LiVjg-0007Pt-67; Sat, 14 Mar 2009 15:25:16 +0000 Date: Sat, 14 Mar 2009 11:25:16 -0400 From: Christoph Hellwig <hch@infradead.org> To: Felix Blyakher <felixb@sgi.com> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Fix xfs debug build breakage Subject: Re: [PATCH] Fix xfs debug build breakage Message-ID: <20090314152516.GA18811@infradead.org> References: <1236869655-14757-1-git-send-email-felixb@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236869655-14757-1-git-send-email-felixb@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1237044316 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 12, 2009 at 09:54:15AM -0500, Felix Blyakher wrote: > Fix xfs debug build breakage by pushing xfs_error.h after > xfs_mount.h, which it depends on. Looks good. From SRS0+29ffd3d6107b141fde38+2029+infradead.org+hch@bombadil.srs.infradead.org Sat Mar 14 10:27: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2EFRZdl206556 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 10:27:55 -0500 X-ASG-Debug-ID: 1237044412-0e2100b80000-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 94082198798 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 08:26:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id BkQobqbuEdPWFrLB for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 08:26:52 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LiVkj-0007Uj-95; Sat, 14 Mar 2009 15:26:21 +0000 Date: Sat, 14 Mar 2009 11:26:21 -0400 From: Christoph Hellwig <hch@infradead.org> To: Michael Monnerie <michael.monnerie@is.it-management.at> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors Message-ID: <20090314152621.GB18811@infradead.org> References: <200903121258.51497@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903121258.51497@zmi.at> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1237044433 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 12, 2009 at 12:58:51PM +0100, Michael Monnerie wrote: > http://lwn.net/SubscriberLink/322777/16380cde8af0a37e/ > > 4K disk sectors coming 2011, might be interesting for devs to prepare > supporting it. Fortunately there's not just the PC world. 4k is the standard sector size of most common mainframe DASD so the Linux filesystems including xfs deal with it very well. The real issue are bootloader and anything involving the DOS partitioning scheme. From Martin@lichtvoll.de Sat Mar 14 14:10:53 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,J_CHICKENPOX_35, J_CHICKENPOX_43,J_CHICKENPOX_45,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 n2EJAW9a222618 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 14:10:52 -0500 X-ASG-Debug-ID: 1237057808-2ec401830000-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 B311B1987FA for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:10:09 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id Muqan0eVnr4pajy9 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:10:09 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.239.210.ip-pool.NEFkom.net [212.114.239.210]) by mail.lichtvoll.de (Postfix) with ESMTPSA id B567F5AD2F; Sat, 14 Mar 2009 20:10:06 +0100 (CET) From: Martin Steigerwald <Martin@lichtvoll.de> To: Eric Sandeen <sandeen@sandeen.net> X-ASG-Orig-Subj: Re: LWN article: 4K disk sectors Subject: Re: LWN article: 4K disk sectors Date: Sat, 14 Mar 2009 20:10:44 +0100 User-Agent: KMail/1.9.9 Cc: xfs@oss.sgi.com References: <200903121258.51497@zmi.at> <200903121517.48426.Martin@lichtvoll.de> <49B92449.90805@sandeen.net> (sfid-20090312_171312_078129_6F30934B) In-Reply-To: <49B92449.90805@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903142010.45564.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1237057809 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0186 1.0000 -1.9003 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.90 X-Barracuda-Spam-Status: No, SCORE=-1.90 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.20331 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: > Martin Steigerwald wrote: > > 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: > >>> > >>> -s sector_size > >>> This option specifies the fundamental sector size=20 > >>> of the filesystem. The sector_size is specified either as a value > >>> in bytes with size=3Dvalue or as a base two loga- rithm value with > >>> log=3Dvalue. 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=20 > >>> 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. Its a stick I got from a customer. shambhala:~> tail -fn0 /var/log/syslog Mar 14 20:07:53 localhost kernel: usb 2-4: new high speed USB device using= =20 ehci_hcd and address 18 Mar 14 20:07:53 localhost kernel: usb 2-4: configuration #1 chosen from 1=20 choice Mar 14 20:07:53 localhost kernel: scsi16 : SCSI emulation for USB Mass=20 Storage devices Mar 14 20:07:53 localhost kernel: usb 2-4: New USB device found,=20 idVendor=3D17ef, idProduct=3D3815 Mar 14 20:07:53 localhost kernel: usb 2-4: New USB device strings: Mfr=3D1,= =20 Product=3D2, SerialNumber=3D3 Mar 14 20:07:53 localhost kernel: usb 2-4: Product: Flash Disk Mar 14 20:07:53 localhost kernel: usb 2-4: Manufacturer: Mar 14 20:07:53 localhost kernel: usb 2-4: SerialNumber: ABCDEF1234000423 Mar 14 20:07:53 localhost kernel: usb-storage: device found at 18 Mar 14 20:07:53 localhost kernel: usb-storage: waiting for device to=20 settle before scanning Mar 14 20:07:58 localhost kernel: usb-storage: device scan complete Mar 14 20:07:58 localhost kernel: scsi 16:0:0:0: Direct-Access = =20 =46lash Disk 5.00 PQ: 0 ANSI: 2 Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] 504832 2048-byte=20 hardware sectors: (1.03 GB/986 MiB) Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Write Protect is off Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Mode Sense: 0b 00 00=20 08 Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Assuming drive cache:= =20 write through Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] 504832 2048-byte=20 hardware sectors: (1.03 GB/986 MiB) Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Write Protect is off Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Mode Sense: 0b 00 00=20 08 Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Assuming drive cache:= =20 write through Mar 14 20:07:58 localhost kernel: sdb: sdb1 Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: [sdb] Attached SCSI=20 removable disk Mar 14 20:07:58 localhost kernel: sd 16:0:0:0: Attached scsi generic sg2=20 type 0 ^C Hmmm, it appears to be from Lenovo. shambhala:~> lsusb | grep USB Bus 002 Device 018: ID 17ef:3815 Lenovo ChipsBnk 2GB USB Stick But its definately not 2 GB... strange. Its branded for the customer, no=20 manufacturer logo on it. =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From Martin@lichtvoll.de Sat Mar 14 14:42: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.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL 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 n2EJgdEd224063 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 14:42:59 -0500 X-ASG-Debug-ID: 1237059734-4aee019d0000-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 1939F1C42253 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:42:14 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id Hao09N3SbH6jC9FT for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:42:14 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.239.210.ip-pool.NEFkom.net [212.114.239.210]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 9D2775AD2F for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 20:42:12 +0100 (CET) From: Martin Steigerwald <Martin@lichtvoll.de> 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: Sat, 14 Mar 2009 20:42:51 +0100 User-Agent: KMail/1.9.9 References: <200903121239.35442@zmi.at> <200903121514.12732.Martin@lichtvoll.de> <49B92423.4020708@sandeen.net> (sfid-20090312_171308_416656_6FF6859A) In-Reply-To: <49B92423.4020708@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903142042.51574.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1237059735 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.20333 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: > Martin Steigerwald wrote: > > 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 > > 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. Well 2.6.28 and 2.6.27.7. See http://oss.sgi.com/archives/xfs/2008-12/msg00540.html > > 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. Hmmm, okay. So here is: http://bugs.kde.org/187172 =46eel free to add there. You'd need a bugzilla login tough. Ciao, =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From Martin@lichtvoll.de Sat Mar 14 14:43:37 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,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 n2EJhGx5224114 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 14:43:37 -0500 X-ASG-Debug-ID: 1237059752-2ebe02830000-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 08172198A2D for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:42:32 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 68idEszRA08mPjiJ for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 12:42:32 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.239.210.ip-pool.NEFkom.net [212.114.239.210]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 52FFE5AD2F; Sat, 14 Mar 2009 20:42:32 +0100 (CET) From: Martin Steigerwald <Martin@lichtvoll.de> 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: Sat, 14 Mar 2009 20:43:10 +0100 User-Agent: KMail/1.9.9 References: <200903121239.35442@zmi.at> (sfid-20090312_140116_228649_7791E639) In-Reply-To: <200903121239.35442@zmi.at> Cc: Michael Monnerie <michael.monnerie@is.it-management.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903142043.11638.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1237059774 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0028 1.0000 -2.0029 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.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.20333 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: > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ > > Very good, maybe similar patches for XFS would help? > IANA Coder, but could be a hint. BTW I think you gave away a subcriber only link. The article is not=20 officially available yet: http://lwn.net/Articles/322823/ LWN might not be too happy with this. Information about this is available elsewhere like on Heise: http://www.heise.de/english/newsticker/news/134483 =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From sandeen@sandeen.net Sat Mar 14 15:02:50 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 n2EK2Tai225110 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 15:02:50 -0500 X-ASG-Debug-ID: 1237060926-2ebf03390000-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 1D95F198F0C for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 13:02:06 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id FeXrbt9C2dr1EiX4 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 13:02:06 -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 n2EK23PB027052; Sat, 14 Mar 2009 16:02:04 -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 n2EK23PI028493; Sat, 14 Mar 2009 16:02:04 -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 n2EK21Wx016035; Sat, 14 Mar 2009 16:02:02 -0400 Message-ID: <49BC0D38.5060106@sandeen.net> Date: Sat, 14 Mar 2009 15:02:00 -0500 From: Eric Sandeen <sandeen@sandeen.net> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Martin Steigerwald <Martin@lichtvoll.de> 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> <200903121514.12732.Martin@lichtvoll.de> <49B92423.4020708@sandeen.net> (sfid-20090312_171308_416656_6FF6859A) <200903142042.51574.Martin@lichtvoll.de> In-Reply-To: <200903142042.51574.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: 1237060927 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.20335 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: ... >> 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. > > Hmmm, okay. So here is: > > http://bugs.kde.org/187172 > > Feel free to add there. You'd need a bugzilla login tough. > > Ciao, Perhaps you can try this and add info if you like. There is an environment variable KDE_EXTRA_FSYNC, put in with this changelog: Do not paranoidly sync every time, it causes I/O performance problems for some users. People who still want it for whatever reason like using XFS can set $KDE_EXTRA_FSYNC to 1." This is not "extra" - it is necessary if you actually want the data to be on-disk. See also: http://lists.kde.org/?l=kde-devel&m=120880682813170&w=2 (note however that xfs is _not_ "zeroing just to be sure...") http://api.kde.org/4.x-api/kdelibs-apidocs/kde3support/html/k3tempfile_8cpp-source.html bool K3TempFile::sync() int result = 0; if (mStream) { do { result = fflush(mStream); // We need to flush first otherwise fsync may not have our data } while ((result == -1) && (errno == EINTR)); if (result) { kWarning() << "K3TempFile: Error trying to flush " << mTmpName " << strerror(errno); mError = errno; } } if (mFd >= 0) { if( qgetenv( "KDE_EXTRA_FSYNC" ) == "1" ) { result = FDATASYNC(mFd); if (result) { kWarning() << "K3TempFile: Error trying to sync " << mTmpName << ": " << strerror(errno); mError = errno; } } } return (mError == 0); } So somebody knew it was the right thing to do, but then turned it off, probably because of ext3's painful behavior on fsync (see also: firefox "bug" from a while ago) what's interesting is that the sync() method isn't automatically called from the other methods, near as I can tell, so it's up to the api user to invoke it; and even then it only does fflush() not fsync() by default, which doesn't actually push things to disk. I'd suggest turning on this KDE_EXTRA_FSYNC and see how things go from there on. Although, the API refs say that this is deprecated in favor of KTemporaryFile, and I find no reference whatsoever to "sync" of any kind in ktemporaryfile.cpp. -Eric From sandeen@sandeen.net Sat Mar 14 15:17:28 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 n2EKH8K1225960 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 15:17:28 -0500 X-ASG-Debug-ID: 1237061805-04b0038b0000-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 ABFA71C4230B for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 13:16:46 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id SDwGHBK5zMxeFf6S for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 13:16:46 -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 n2EK8MgU028385; Sat, 14 Mar 2009 16:08:22 -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 n2EK8M8f029268; Sat, 14 Mar 2009 16:08:22 -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 n2EK8Loo018623; Sat, 14 Mar 2009 16:08:21 -0400 Message-ID: <49BC0EB4.7040308@sandeen.net> Date: Sat, 14 Mar 2009 15:08:20 -0500 From: Eric Sandeen <sandeen@sandeen.net> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Martin Steigerwald <Martin@lichtvoll.de> 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> <200903121514.12732.Martin@lichtvoll.de> <49B92423.4020708@sandeen.net> (sfid-20090312_171308_416656_6FF6859A) <200903142042.51574.Martin@lichtvoll.de> <49BC0D38.5060106@sandeen.net> In-Reply-To: <49BC0D38.5060106@sandeen.net> 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: 1237061806 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.20335 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: > Martin Steigerwald wrote: >> Am Donnerstag 12 März 2009 schrieb Eric Sandeen: > ... > >>> 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. >> Hmmm, okay. So here is: >> >> http://bugs.kde.org/187172 >> >> Feel free to add there. You'd need a bugzilla login tough. ... getting OT sorry but in case anyone else is interested, http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKSaveFile.html also seems relevant. I'd like to know just what KDE is doing here, so digging a little. -Eric From Martin@lichtvoll.de Sat Mar 14 17:03: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.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 n2EM3cBO230552 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 17:03:59 -0500 X-ASG-Debug-ID: 1237068175-32f400f40000-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 758161993DD for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 15:02:55 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id bI4CSVzKAvhfZtE3 for <xfs@oss.sgi.com>; Sat, 14 Mar 2009 15:02:55 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.83.171.156.159.ip-pool.NEFkom.net [83.171.156.159]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 5DBC45AD2F; Sat, 14 Mar 2009 23:02:23 +0100 (CET) From: Martin Steigerwald <Martin@lichtvoll.de> To: Eric Sandeen <sandeen@sandeen.net> X-ASG-Orig-Subj: Re: LWN article: ext4 and data loss Subject: Re: LWN article: ext4 and data loss Date: Sat, 14 Mar 2009 23:03:01 +0100 User-Agent: KMail/1.9.9 References: <200903121239.35442@zmi.at> <200903142042.51574.Martin@lichtvoll.de> <49BC0D38.5060106@sandeen.net> (sfid-20090314_215133_422517_98614840) In-Reply-To: <49BC0D38.5060106@sandeen.net> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903142303.01619.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1237068196 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.20343 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 Samstag 14 M=E4rz 2009 schrieben Sie: > Martin Steigerwald wrote: > > Am Donnerstag 12 M=E4rz 2009 schrieb Eric Sandeen: > > ... > > >> 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. > > > > Hmmm, okay. So here is: > > > > http://bugs.kde.org/187172 > > > > Feel free to add there. You'd need a bugzilla login tough. > > > > Ciao, > > Perhaps you can try this and add info if you like. > > There is an environment variable KDE_EXTRA_FSYNC, put in with this > changelog: [...] Added this and your other post and added export KDE_EXTRA_FSYNC=3D1 to my .zshrc. Just logged out and on and do not notice a difference in=20 speed. At least no abysmal performance degradation. Would need to switch of the machine hardly to see if it helps. Not today=20 anymore tough. =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From david@fromorbit.com Sun Mar 15 02:50: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.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 n2F7nu5h256630 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:50:17 -0500 X-ASG-Debug-ID: 1237103352-097a01e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 237AD199CB8 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:49:13 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id 7ELRlRxs2HpAapia for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:49:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHJNvEl5LAJ7/2dsb2JhbADQPYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338920166" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:19:10 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1Lil5q-0000jU-4C; Sun, 15 Mar 2009 18:49:10 +1100 Date: Sun, 15 Mar 2009 18:49:10 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/7] xfs: cleanup log unmount handling Subject: Re: [PATCH 1/7] xfs: cleanup log unmount handling Message-ID: <20090315074910.GP26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085228.602565000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085228.602565000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103375 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3233 1.0000 -0.2528 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.25 X-Barracuda-Spam-Status: No, SCORE=-0.25 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.20381 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 Fri, Feb 20, 2009 at 03:52:08AM -0500, Christoph Hellwig wrote: > Kill the current xfs_log_unmount wrapper and opencode the two function > calls in the only caller. Rename the current xfs_log_unmount_dealloc to > xfs_log_unmount as it undoes xfs_log_mount and the new name makes that > more clear. Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:50: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2F7nvBV256631 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:50:18 -0500 X-ASG-Debug-ID: 1237103352-097a01e60001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8577D199CB8 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:49:35 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id kx5bx4kFxFNEwRoG for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:49:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHJNvEl5LAJ7/2dsb2JhbADQPYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338920255" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:19:35 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1Lil6E-0000kC-Sh; Sun, 15 Mar 2009 18:49:34 +1100 Date: Sun, 15 Mar 2009 18:49:34 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/7] xfs: remove another leftover of the old inode log item format Subject: Re: [PATCH 2/7] xfs: remove another leftover of the old inode log item format Message-ID: <20090315074934.GQ26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085228.896448000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085228.896448000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103376 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2836 1.0000 -0.4195 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.42 X-Barracuda-Spam-Status: No, SCORE=-0.42 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.20381 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 Fri, Feb 20, 2009 at 03:52:09AM -0500, Christoph Hellwig wrote: > There's another little snipplet of code left from the handling of the old > inode log item format in xlog_recover_do_inode_trans. Kill it as it > can't be reached anymore. Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:51:04 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 n2F7ohve256690 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:51:04 -0500 X-ASG-Debug-ID: 1237103421-4aa1008a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7C46F199BEA for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:50:21 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id qdrdXXwD4V75c1Hg for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:50:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHJNvEl5LAJ7/2dsb2JhbADQPYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338920405" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:20:20 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1Lil6y-0000lL-2W; Sun, 15 Mar 2009 18:50:20 +1100 Date: Sun, 15 Mar 2009 18:50:20 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/7] xfs: cleanup xlog_recover_do_trans Subject: Re: [PATCH 3/7] xfs: cleanup xlog_recover_do_trans Message-ID: <20090315075020.GR26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085229.204188000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085229.204188000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103422 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1415 1.0000 -1.1494 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.15 X-Barracuda-Spam-Status: No, SCORE=-1.15 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.20383 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 Fri, Feb 20, 2009 at 03:52:10AM -0500, Christoph Hellwig wrote: > Change the big if-elsif-else block handling the different item types > into a more natural switch, remove assignments in conditionals and > remove an out of place comment from centuries ago on IRIX. Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:55:02 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 n2F7sfRF256913 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:55:01 -0500 X-ASG-Debug-ID: 1237103638-377000f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 291931C43052 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:53:58 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id eh1FZsIXCINzxcCy for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:53:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdQvEl5LAJ7/2dsb2JhbADQKYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338921226" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:23:56 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LilAS-0000pm-D0; Sun, 15 Mar 2009 18:53:56 +1100 Date: Sun, 15 Mar 2009 18:53:56 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/7] xfs: cleanup xlog_bread Subject: Re: [PATCH 4/7] xfs: cleanup xlog_bread Message-ID: <20090315075356.GS26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085229.488121000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085229.488121000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103660 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0020 1.0000 -2.0082 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 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.20383 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 Fri, Feb 20, 2009 at 03:52:11AM -0500, Christoph Hellwig wrote: > Most callers of xlog_bread need to call xlog_align to get the actual offset. > Consolidate that call into the main xlog_bread and provide a _xlog_bread > for those few that don't want the actual offset. > > > Signed-off-by: Christoph Hellwig <hch@lst.de> ..... > * nbblks should be uint, but oh well. Just want to catch that 32-bit length. > */ > -int > -xlog_bread( > +STATIC int > +_xlog_bread( > xlog_t *log, > xfs_daddr_t blk_no, > int nbblks, > @@ -137,6 +155,24 @@ xlog_bread( > return error; > } xlog_bread_noalign(). Otherwise looks good. Consider it: Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:55: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 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 n2F7slDD256917 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:55:07 -0500 X-ASG-Debug-ID: 1237103638-377000f10001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A298C1C43052 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:54:24 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id tkwwOoap6UGvv5Wh for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:54:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdQvEl5LAJ7/2dsb2JhbADQKYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338921319" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:24:23 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LilAs-0000qU-Pi; Sun, 15 Mar 2009 18:54:22 +1100 Date: Sun, 15 Mar 2009 18:54:22 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/7] xfs: kill vn_atime_* helpers. Subject: Re: [PATCH 5/7] xfs: kill vn_atime_* helpers. Message-ID: <20090315075422.GT26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085229.787651000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085229.787651000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103665 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2527 1.0000 -0.5625 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.56 X-Barracuda-Spam-Status: No, SCORE=-0.56 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.20383 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 Fri, Feb 20, 2009 at 03:52:12AM -0500, Christoph Hellwig wrote: > Two out of three are unused already, and the third is better done open-coded > with a comment describing what's going on here. Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:55:30 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 n2F7t9kb256954 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:55:30 -0500 X-ASG-Debug-ID: 1237103686-1afa01700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EE1791C43097 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:54:46 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id tQ0Mgy9B97KFjI2K for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:54:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdQvEl5LAJ7/2dsb2JhbADQKYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338921396" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:24:45 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LilBC-0000r0-0e; Sun, 15 Mar 2009 18:54:42 +1100 Date: Sun, 15 Mar 2009 18:54:41 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 6/7] xfs: kill VN_BAD Subject: Re: [PATCH 6/7] xfs: kill VN_BAD Message-ID: <20090315075441.GU26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220085207.663702000@bombadil.infradead.org> <20090220085229.964618000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085229.964618000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103687 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1769 1.0000 -0.9519 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.95 X-Barracuda-Spam-Status: No, SCORE=-0.95 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.20383 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 Fri, Feb 20, 2009 at 03:52:13AM -0500, Christoph Hellwig wrote: > Remove this rather pointless wrapper and use is_bad_inode directly. Reviewed-by: Dave Chinner <david@fromorbit.com> -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 02:59: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.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 n2F7wn5H257263 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 02:59:09 -0500 X-ASG-Debug-ID: 1237103906-4aa000bb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB4D5199C64 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:58:26 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id R6cujFeJpg3FPW1D for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 00:58:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdQvEl5LAJ7/2dsb2JhbADQKYN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338922464" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:28:25 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LilEm-0000vg-MQ; Sun, 15 Mar 2009 18:58:24 +1100 Date: Sun, 15 Mar 2009 18:58:24 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: xfs@oss.sgi.com, Dave Chinner <dgc@sgi.com> X-ASG-Orig-Subj: Re: [PATCH 7/7] xfs: factor out code to find the longest free extent in the AG Subject: Re: [PATCH 7/7] xfs: factor out code to find the longest free extent in the AG Message-ID: <20090315075824.GV26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com, Dave Chinner <dgc@sgi.com> References: <20090220085207.663702000@bombadil.infradead.org> <20090220085230.115970000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085230.115970000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237103907 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 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:52:14AM -0500, Christoph Hellwig wrote: > From: Dave Chinner <dgc@sgi.com> > > Signed-off-by: Dave Chinner <dgc@sgi.com> .... > /* > + * Find the length of the longest extent in an AG. > + */ > +xfs_extlen_t > +xfs_alloc_min_freelist( > + struct xfs_mount *mp, > + struct xfs_perag *pag) Looking at this again, I'd change the name of this function to xfs_alloc_ag_longest_free_extent(), because that is what it is actually returning.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Mar 15 03:19: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=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 n2F8JLh1258521 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:19:42 -0500 X-ASG-Debug-ID: 1237105138-599500800000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 788BA1C433B7 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 01:18:59 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id jS5GBbKJAbpFYtmy for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 01:18:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHtUvEl5LAJ7/2dsb2JhbADQLIN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338927478" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 18:48:57 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LilYe-0001Nn-9U; Sun, 15 Mar 2009 19:18:56 +1100 Date: Sun, 15 Mar 2009 19:18:56 +1100 From: Dave Chinner <david@fromorbit.com> To: Christoph Hellwig <hch@infradead.org> Cc: 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: <20090315081856.GW26138@disturbed> Mail-Followup-To: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com References: <20090220205117.GA7943@infradead.org> <20090304173008.GA32471@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304173008.GA32471@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237105140 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0017 1.0000 -2.0097 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.41 X-Barracuda-Spam-Status: No, SCORE=-1.41 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Mar 04, 2009 at 12:30:08PM -0500, Christoph Hellwig wrote: > 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 <hch@lst.de> I haven't done an in-depth review of this, but i can't find any glaring problems while reading over the diff. So, in the interests of moving this forward, you can add a: Acked-by: Dave Chinner <david@fromorbit.com> to this. I think at this point it probably should be pushed into the dev tree and aimed at 2.6.31.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05: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=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 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 n2FAocxH003925 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:50:58 -0500 X-ASG-Debug-ID: 1237114193-153b02b00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AFD3F199E17 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:49:54 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id dvUrVM7DyDZ5MIn3 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:49:54 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58258979-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:19:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinuX-0004nw-RM for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:49:41 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/3] [XFSQA] Test writing to ENOSPC Subject: [PATCH 3/3] [XFSQA] Test writing to ENOSPC Date: Sun, 15 Mar 2009 21:49:41 +1100 Message-Id: <1237114181-18431-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114181-18431-1-git-send-email-david@fromorbit.com> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237114216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0115 1.0000 -1.9462 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.95 X-Barracuda-Spam-Status: No, SCORE=-1.95 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.20395 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 Use larger files and different writing styles to fill a 100MB filesystem to being full. In each case we should get very close to the filesystem being full before getting ENOSPC. THis tests different types of ENOSPC failures to test 203 and requires more changes to pass. Signed-off-by: Dave Chinner <david@fromorbit.com> --- 015 | 11 --------- 204 | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 204.out | 4 +++ common.filter | 11 +++++++++ group | 1 + 5 files changed, 82 insertions(+), 11 deletions(-) mode change 100644 => 100755 141 mode change 100644 => 100755 164 mode change 100644 => 100755 165 mode change 100644 => 100755 166 mode change 100644 => 100755 167 mode change 100644 => 100755 170 mode change 100644 => 100755 171 mode change 100644 => 100755 172 mode change 100644 => 100755 173 mode change 100644 => 100755 174 mode change 100644 => 100755 179 mode change 100644 => 100755 180 mode change 100644 => 100755 182 mode change 100644 => 100755 183 mode change 100644 => 100755 184 mode change 100644 => 100755 185 mode change 100644 => 100755 188 mode change 100644 => 100755 189 mode change 100644 => 100755 194 mode change 100644 => 100755 195 mode change 100644 => 100755 196 mode change 100644 => 100755 197 mode change 100644 => 100755 199 mode change 100644 => 100755 200 create mode 100755 204 create mode 100644 204.out diff --git a/015 b/015 index 9b78837..f999732 100755 --- a/015 +++ b/015 @@ -33,17 +33,6 @@ _free() _df_dir $SCRATCH_MNT | $AWK_PROG '{ print $5 }' } -_filter_dd() -{ - $AWK_PROG ' - /records in/ { next } - /records out/ { next } - /No space left on device/ { print " !!! disk full (expected)" - next } - { print " *** " $0 } - ' -} - # real QA test starts here _supported_fs xfs _supported_os IRIX Linux diff --git a/141 b/141 old mode 100644 new mode 100755 diff --git a/164 b/164 old mode 100644 new mode 100755 diff --git a/165 b/165 old mode 100644 new mode 100755 diff --git a/166 b/166 old mode 100644 new mode 100755 diff --git a/167 b/167 old mode 100644 new mode 100755 diff --git a/170 b/170 old mode 100644 new mode 100755 diff --git a/171 b/171 old mode 100644 new mode 100755 diff --git a/172 b/172 old mode 100644 new mode 100755 diff --git a/173 b/173 old mode 100644 new mode 100755 diff --git a/174 b/174 old mode 100644 new mode 100755 diff --git a/179 b/179 old mode 100644 new mode 100755 diff --git a/180 b/180 old mode 100644 new mode 100755 diff --git a/182 b/182 old mode 100644 new mode 100755 diff --git a/183 b/183 old mode 100644 new mode 100755 diff --git a/184 b/184 old mode 100644 new mode 100755 diff --git a/185 b/185 old mode 100644 new mode 100755 diff --git a/188 b/188 old mode 100644 new mode 100755 diff --git a/189 b/189 old mode 100644 new mode 100755 diff --git a/194 b/194 old mode 100644 new mode 100755 diff --git a/195 b/195 old mode 100644 new mode 100755 diff --git a/196 b/196 old mode 100644 new mode 100755 diff --git a/197 b/197 old mode 100644 new mode 100755 diff --git a/199 b/199 old mode 100644 new mode 100755 diff --git a/200 b/200 old mode 100644 new mode 100755 diff --git a/204 b/204 new file mode 100755 index 0000000..2a0b94e --- /dev/null +++ b/204 @@ -0,0 +1,66 @@ +#! /bin/sh +# FS QA Test No. 203 +# +# Test out ENOSPC flushiung on small filesystems. +# +#----------------------------------------------------------------------- +# Copyright (c) 2009 Dave Chinner +#----------------------------------------------------------------------- +# +# creator +owner=david@fromorbit.com + +seq=`basename $0` +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +# real QA test starts here +_supported_fs xfs +_supported_os Linux + +_require_scratch + +_scratch_mkfs_xfs -d size=16m -b size=512 >/dev/null +_scratch_mount + +# on a 16MB filesystem, there's 32768x512byte blocks. used is: +# - 4944 in the log, +# - 32+1 for the root inode cluster +# - 4 for the AG header +# - 2 for free space btrees +# - 4 for the AGFL +# - min(%5, 1024) = 1024 blocks for the reserve pool +# - about 15 blocks I can't account for right now. +# That leaves ~26,745 blocks free to use. +# +# Writing the following three files fill the fs almost exactly. +# +# $ df -k /mnt/scratch +# Filesystem 1K-blocks Used Available Use% Mounted on +# /dev/ubdc 13912 13908 4 100% /mnt/scratch +# +dd if=/dev/zero of=$SCRATCH_MNT/fred bs=512 count=25000 2>&1 | _filter_dd +dd if=/dev/zero of=$SCRATCH_MNT/fred2 bs=512 count=500 2>&1 | _filter_dd +dd if=/dev/zero of=$SCRATCH_MNT/fred3 bs=512 count=245 2>&1 | _filter_dd +rm -f $SCRATCH_MNT/fred* + +echo "*** one file" +# now try a single file of that size +dd if=/dev/zero of=$SCRATCH_MNT/fred bs=512 count=26745 2>&1 | _filter_dd +#rm -f $SCRATCH_MNT/fred* + +echo "*** one file, a few bytes at a time" +# now try a single file of that size +dd if=/dev/zero of=$SCRATCH_MNT/fred bs=15 count=$[26745/15*512] 2>&1 | _filter_dd + +# success, all done +echo "*** done" +rm -f $seq.full +status=0 diff --git a/204.out b/204.out new file mode 100644 index 0000000..0962619 --- /dev/null +++ b/204.out @@ -0,0 +1,4 @@ +QA output created by 204 +*** one file +*** one file, a few bytes at a time +*** done diff --git a/common.filter b/common.filter index d1d4cb5..0e2d7ff 100644 --- a/common.filter +++ b/common.filter @@ -167,5 +167,16 @@ _filter_growfs() }' } +_filter_dd() +{ + $AWK_PROG ' + /records in/ { next } + /records out/ { next } + /No space left on device/ { print " !!! disk full (expected)" + next } + { print " *** " $0 } + ' +} + # make sure this script returns success /bin/true diff --git a/group b/group index 0a51d9a..63c4dad 100644 --- a/group +++ b/group @@ -308,3 +308,4 @@ atime 201 metadata auto quick 202 repair auto quick 203 metadata rw auto +204 metadata rw auto -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:50: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.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 n2FAobY9003924 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:50:58 -0500 X-ASG-Debug-ID: 1237114193-0f3202dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3EA8C199E15 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:49:54 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id ZZU2cWrYGZ0ChYem for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:49:54 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46130993-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:19:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinuX-0004ns-NQ for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:49:41 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/3] [XFSQA] Add simple delayed allocation ENOSPC test. Subject: [PATCH 2/3] [XFSQA] Add simple delayed allocation ENOSPC test. Date: Sun, 15 Mar 2009 21:49:40 +1100 Message-Id: <1237114181-18431-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114181-18431-1-git-send-email-david@fromorbit.com> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237114216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0202 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.20395 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 Using a small (100MB) filesystem and writing lots of single block files can result in spurious ENOSPCs being reported. Reproduce this test case so we can confirm that it gets fixed. Signed-off-by: Dave Chinner <david@fromorbit.com> --- 203 | 41 +++++++++++++++++++++++++++++++++++++++++ 203.out | 2 ++ group | 1 + 3 files changed, 44 insertions(+), 0 deletions(-) create mode 100755 203 create mode 100644 203.out diff --git a/203 b/203 new file mode 100755 index 0000000..16c5714 --- /dev/null +++ b/203 @@ -0,0 +1,41 @@ +#! /bin/sh +# FS QA Test No. 203 +# +# Test out ENOSPC flushiung on small filesystems. +# +#----------------------------------------------------------------------- +# Copyright (c) 2009 Christoph Hellwig. +#----------------------------------------------------------------------- +# +# creator +owner=hch@lst.de + +seq=`basename $0` +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +# real QA test starts here +_supported_fs xfs +_supported_os Linux + +_require_scratch + +_scratch_mkfs_xfs -d size=104m >/dev/null +_scratch_mount + +for i in `seq 1 22500`; do + echo -n > $SCRATCH_MNT/$i + echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i +done + +# success, all done +echo "*** done" +rm -f $seq.full +status=0 diff --git a/203.out b/203.out new file mode 100644 index 0000000..f7476c0 --- /dev/null +++ b/203.out @@ -0,0 +1,2 @@ +QA output created by 203 +*** done diff --git a/group b/group index 35f02fc..0a51d9a 100644 --- a/group +++ b/group @@ -307,3 +307,4 @@ atime 200 mount auto quick 201 metadata auto quick 202 repair auto quick +203 metadata rw auto -- 1.6.2 From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:53:31 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 n2FArBNw004036 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:53:31 -0500 X-ASG-Debug-ID: 1237114368-153d02d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7C2F3199FD6 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:52:49 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id I8VR5wOyfMSAsS6W for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:52:49 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58259140-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:22:46 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinxL-0004rG-Dk for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:52:35 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/2] [XFS] a couple of fixes Subject: [PATCH 0/2] [XFS] a couple of fixes Date: Sun, 15 Mar 2009 21:52:33 +1100 Message-Id: <1237114355-18647-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237114370 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3263 1.0000 -0.2409 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.24 X-Barracuda-Spam-Status: No, SCORE=-0.24 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.20395 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 The first fixes a fuzzer log corruption crash, and second is a null pointer dereference I found by inspection. From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:53:31 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 n2FArCw3004037 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:53:31 -0500 X-ASG-Debug-ID: 1237114368-3e2b013d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E3E4E199FD6 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:52:49 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id yGJhZCJvZCInCKRF for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:52:49 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44229080-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:22:46 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinxL-0004rI-H4 for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:52:35 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] [XFS] Validate log feature fields correctly Subject: [PATCH 1/2] [XFS] Validate log feature fields correctly Date: Sun, 15 Mar 2009 21:52:34 +1100 Message-Id: <1237114355-18647-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114355-18647-1-git-send-email-david@fromorbit.com> References: <1237114355-18647-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237114370 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.20395 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: Dave Chinner <dgc@evostor.com> If the large log sector size feature bit is set in the superblock by accident (say disk corruption), the then fields that are now considered valid are not checked on production kernels. The checks are present as ASSERT statements so cause a panic on a debug kernel. Change this so that the fields are validity checked if the feature bit is set and abort the log mount if the fields do not contain valid values. Reported-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_log.c | 41 ++++++++++++++++++++++++++++++----------- 1 files changed, 30 insertions(+), 11 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index c8f3008..60e6e63 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -562,9 +562,8 @@ xfs_log_mount( } mp->m_log = xlog_alloc_log(mp, log_target, blk_offset, num_bblks); - if (!mp->m_log) { - cmn_err(CE_WARN, "XFS: Log allocation failed: No memory!"); - error = ENOMEM; + if (IS_ERR(mp->m_log)) { + error = -PTR_ERR(mp->m_log); goto out; } @@ -1193,10 +1192,13 @@ xlog_alloc_log(xfs_mount_t *mp, xfs_buf_t *bp; int i; int iclogsize; + int error = ENOMEM; log = kmem_zalloc(sizeof(xlog_t), KM_MAYFAIL); - if (!log) - return NULL; + if (!log) { + xlog_warn("XFS: Log allocation failed: No memory!"); + goto out; + } log->l_mp = mp; log->l_targ = log_target; @@ -1214,19 +1216,35 @@ xlog_alloc_log(xfs_mount_t *mp, log->l_grant_reserve_cycle = 1; log->l_grant_write_cycle = 1; + error = EFSCORRUPTED; if (xfs_sb_version_hassector(&mp->m_sb)) { log->l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; - ASSERT(log->l_sectbb_log <= mp->m_sectbb_log); + if (log->l_sectbb_log < 0 || + log->l_sectbb_log > mp->m_sectbb_log) { + xlog_warn("XFS: Log sector size (0x%x) out of range.", + log->l_sectbb_log); + goto out_free_log; + } + /* for larger sector sizes, must have v2 or external log */ - ASSERT(log->l_sectbb_log == 0 || - log->l_logBBstart == 0 || - xfs_sb_version_haslogv2(&mp->m_sb)); - ASSERT(mp->m_sb.sb_logsectlog >= BBSHIFT); + if (log->l_sectbb_log != 0 && + (log->l_logBBstart != 0 && + !xfs_sb_version_haslogv2(&mp->m_sb))) { + xlog_warn("XFS: log sector size (0x%x) invalid " + "for configuration.", log->l_sectbb_log); + goto out_free_log; + } + if (mp->m_sb.sb_logsectlog < BBSHIFT) { + xlog_warn("XFS: Log sector log (0x%x) too small.", + mp->m_sb.sb_logsectlog); + goto out_free_log; + } } log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; xlog_get_iclog_buffer_size(mp, log); + error = ENOMEM; bp = xfs_buf_get_empty(log->l_iclog_size, mp->m_logdev_targp); if (!bp) goto out_free_log; @@ -1326,7 +1344,8 @@ out_free_iclog: xfs_buf_free(log->l_xbuf); out_free_log: kmem_free(log); - return NULL; +out: + return ERR_PTR(-error); } /* xlog_alloc_log */ -- 1.6.2 From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:59:13 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 n2FAwqds004533 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:59:13 -0500 X-ASG-Debug-ID: 1237114709-5545006a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 43D1B19A04D for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:30 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id suuC5YOix3pHzLr9 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:30 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58259417-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004u4-NH; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Subject: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Date: Sun, 15 Mar 2009 21:57:58 +1100 Message-Id: <1237114679-18808-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> References: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237114711 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.20395 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: Dave Chinner <dgc@evostor.com> If we are creating lots of small files, we can fail to get a reservation for inode create earlier than we should due to EOF preallocation done during delayed allocation reservation. Hence on the first reservation ENOSPC failure flush all the delayed allocation blocks out of the system and retry. This fixes the last commonly triggered spurious ENOSPC issue that has been reported. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_vnodeops.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c index 59de049..faf671b 100644 --- a/fs/xfs/xfs_vnodeops.c +++ b/fs/xfs/xfs_vnodeops.c @@ -1457,6 +1457,13 @@ xfs_create( error = xfs_trans_reserve(tp, resblks, log_res, 0, XFS_TRANS_PERM_LOG_RES, log_count); if (error == ENOSPC) { + /* flush outstanding delalloc blocks and retry */ + xfs_flush_inodes(dp); + error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); + } + if (error == ENOSPC) { + /* No space at all so try a "no-allocation" reservation */ resblks = 0; error = xfs_trans_reserve(tp, 0, log_res, 0, XFS_TRANS_PERM_LOG_RES, log_count); -- 1.6.2 From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:59:13 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 n2FAwqOK004536 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:59:13 -0500 X-ASG-Debug-ID: 1237114709-0f3203120000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4CFDE19A04E for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:30 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id XOYyze7l2Hcb0FcL for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:30 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44229396-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004u8-Ro; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 5/5] [XFS] Remove xfs_flush_space Subject: [PATCH 5/5] [XFS] Remove xfs_flush_space Date: Sun, 15 Mar 2009 21:57:59 +1100 Message-Id: <1237114679-18808-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> References: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237114711 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 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.20395 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: Dave Chinner <dgc@evostor.com> The only thing we need to do now when we get an ENOSPC condition during delayed allocation reservation is flush all the other inodes with delalloc blocks on them and retry without EOF preallocation. Remove the unneeded mess that is xfs_flush_space() and just call xfs_flush_inodes() directly from xfs_iomap_write_delay(). Also, change the location of the retry label to avoid trying to do EOF preallocation because we don't want to do that at ENOSPC. This enables us to remove the BMAPI_SYNC flag as it is no longer used. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_iomap.c | 61 ++++++++++++--------------------------------------- fs/xfs/xfs_iomap.h | 3 +- 2 files changed, 16 insertions(+), 48 deletions(-) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 7b8b170..5aaa2d7 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -338,38 +338,6 @@ xfs_iomap_eof_align_last_fsb( } STATIC int -xfs_flush_space( - xfs_inode_t *ip, - int *fsynced, - int *ioflags) -{ - switch (*fsynced) { - case 0: - if (ip->i_delayed_blks) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - delay(1); - xfs_ilock(ip, XFS_ILOCK_EXCL); - *fsynced = 1; - } else { - *ioflags |= BMAPI_SYNC; - *fsynced = 2; - } - return 0; - case 1: - *fsynced = 2; - *ioflags |= BMAPI_SYNC; - return 0; - case 2: - xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_inodes(ip); - xfs_ilock(ip, XFS_ILOCK_EXCL); - *fsynced = 3; - return 0; - } - return 1; -} - -STATIC int xfs_cmn_err_fsblock_zero( xfs_inode_t *ip, xfs_bmbt_irec_t *imap) @@ -538,15 +506,9 @@ error_out: } /* - * If the caller is doing a write at the end of the file, - * then extend the allocation out to the file system's write - * iosize. We clean up any extra space left over when the - * file is closed in xfs_inactive(). - * - * For sync writes, we are flushing delayed allocate space to - * try to make additional space available for allocation near - * the filesystem full boundary - preallocation hurts in that - * situation, of course. + * If the caller is doing a write at the end of the file, then extend the + * allocation out to the file system's write iosize. We clean up any extra + * space left over when the file is closed in xfs_inactive(). */ STATIC int xfs_iomap_eof_want_preallocate( @@ -565,7 +527,7 @@ xfs_iomap_eof_want_preallocate( int n, error, imaps; *prealloc = 0; - if ((ioflag & BMAPI_SYNC) || (offset + count) <= ip->i_size) + if ((offset + count) <= ip->i_size) return 0; /* @@ -611,7 +573,7 @@ xfs_iomap_write_delay( xfs_extlen_t extsz; int nimaps; xfs_bmbt_irec_t imap[XFS_WRITE_IMAPS]; - int prealloc, fsynced = 0; + int prealloc, flushed = 0; int error; ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); @@ -627,12 +589,12 @@ xfs_iomap_write_delay( extsz = xfs_get_extsz_hint(ip); offset_fsb = XFS_B_TO_FSBT(mp, offset); -retry: error = xfs_iomap_eof_want_preallocate(mp, ip, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); if (error) return error; +retry: if (prealloc) { aligned_offset = XFS_WRITEIO_ALIGN(mp, (offset + count - 1)); ioalign = XFS_B_TO_FSBT(mp, aligned_offset); @@ -659,15 +621,22 @@ retry: /* * If bmapi returned us nothing, and if we didn't get back EDQUOT, - * then we must have run out of space - flush delalloc, and retry.. + * then we must have run out of space - flush all other inodes with + * delalloc blocks and retry without EOF preallocation. */ if (nimaps == 0) { xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, ip, offset, count); - if (xfs_flush_space(ip, &fsynced, &ioflag)) + if (flushed) return XFS_ERROR(ENOSPC); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_flush_inodes(ip); + xfs_ilock(ip, XFS_ILOCK_EXCL); + + flushed = 1; error = 0; + prealloc = 0; goto retry; } diff --git a/fs/xfs/xfs_iomap.h b/fs/xfs/xfs_iomap.h index ee1a0c1..87fb9d1 100644 --- a/fs/xfs/xfs_iomap.h +++ b/fs/xfs/xfs_iomap.h @@ -40,8 +40,7 @@ typedef enum { BMAPI_IGNSTATE = (1 << 4), /* ignore unwritten state on read */ BMAPI_DIRECT = (1 << 5), /* direct instead of buffered write */ BMAPI_MMAP = (1 << 6), /* allocate for mmap write */ - BMAPI_SYNC = (1 << 7), /* sync write to flush delalloc space */ - BMAPI_TRYLOCK = (1 << 8), /* non-blocking request */ + BMAPI_TRYLOCK = (1 << 7), /* non-blocking request */ } bmapi_flags_t; -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:59:13 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 n2FAwqYm004534 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:59:13 -0500 X-ASG-Debug-ID: 1237114709-554600600000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2AC1119A049 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id ud6NFoIkqkTzoODt for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46131485-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004u0-Ix; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Subject: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Date: Sun, 15 Mar 2009 21:57:57 +1100 Message-Id: <1237114679-18808-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> References: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237114711 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.20395 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: Dave Chinner <dgc@evostor.com> xfs_flush_inodes() currently uses a magic timeout to wait for some inodes to be flushed before returning. This isn't really reliable but used to be the best that could be done due to deadlock potential of waiting for the entire flush. Now the inode flush is safe to execute while we hold page and inode locks, we can wait for all the inodes to flush synchronously. Convert the wait mechanism to a completion to do this efficiently. This should remove all remaining spurious ENOSPC errors from the delayed allocation reservation path. This is extracted almost line for line from a larger patch from Mikulas Patocka. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 12 +++++++++--- fs/xfs/linux-2.6/xfs_sync.h | 1 + 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 73cf8dc..f7ba766 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -404,7 +404,8 @@ STATIC void xfs_syncd_queue_work( struct xfs_mount *mp, void *data, - void (*syncer)(struct xfs_mount *, void *)) + void (*syncer)(struct xfs_mount *, void *), + struct completion *completion) { struct xfs_sync_work *work; @@ -413,6 +414,7 @@ xfs_syncd_queue_work( work->w_syncer = syncer; work->w_data = data; work->w_mount = mp; + work->w_completion = completion; spin_lock(&mp->m_sync_lock); list_add_tail(&work->w_list, &mp->m_sync_list); spin_unlock(&mp->m_sync_lock); @@ -441,10 +443,11 @@ xfs_flush_inodes( xfs_inode_t *ip) { struct inode *inode = VFS_I(ip); + DECLARE_COMPLETION_ONSTACK(completion); igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work); - delay(msecs_to_jiffies(500)); + xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work, &completion); + wait_for_completion(&completion); xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); } @@ -514,6 +517,8 @@ xfssyncd( list_del(&work->w_list); if (work == &mp->m_sync_work) continue; + if (work->w_completion) + complete(work->w_completion); kmem_free(work); } } @@ -527,6 +532,7 @@ xfs_syncd_init( { mp->m_sync_work.w_syncer = xfs_sync_worker; mp->m_sync_work.w_mount = mp; + mp->m_sync_work.w_completion = NULL; mp->m_sync_task = kthread_run(xfssyncd, mp, "xfssyncd"); if (IS_ERR(mp->m_sync_task)) return -PTR_ERR(mp->m_sync_task); diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index 6e83a35..308d5bf 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -26,6 +26,7 @@ typedef struct xfs_sync_work { struct xfs_mount *w_mount; void *w_data; /* syncer routine argument */ void (*w_syncer)(struct xfs_mount *, void *); + struct completion *w_completion; } xfs_sync_work_t; #define SYNC_ATTR 0x0001 /* sync attributes */ -- 1.6.2 From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:59:14 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 n2FAwrek004539 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:59:13 -0500 X-ASG-Debug-ID: 1237114709-153d02ff0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AD4B19A04E for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id PkgYHjaDA4BNjYMS for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44229394-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004tp-7a; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 0/5] [XFS] Spurious ENOSPC fixes Subject: [PATCH 0/5] [XFS] Spurious ENOSPC fixes Date: Sun, 15 Mar 2009 21:57:54 +1100 Message-Id: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237114712 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1003 1.0000 -1.3911 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.39 X-Barracuda-Spam-Status: No, SCORE=-1.39 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.20395 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 This series fix the spurious ENOSPC problems reported by and partially solved by Mikulas Patocka. This series makes the recently posted QA tests 203 and 204 pass. Mikulas, if I've got any of the attributions wrong for the bits of your code I used, let me know and I'll fix them. From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 05:59:34 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 n2FAxD39004564 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 05:59:34 -0500 X-ASG-Debug-ID: 1237114709-7343001e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D53A41C436D7 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id YWsoxvRhCK46MlKR for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 03:58:29 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354573083-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004tw-F4; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Subject: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Date: Sun, 15 Mar 2009 21:57:56 +1100 Message-Id: <1237114679-18808-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> References: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237114731 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.20395 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: Dave Chinner <dgc@evostor.com> When we are writing to a single file and hit ENOSPC, we trigger a background flush of the inode and try again. Because we hold page locks and the iolock, the flush won't proceed until after we release these locks. This occurs once we've given up and ENOSPC has been reported. Hence if this one is the only dirty inode in the system, we'll get an ENOSPC prematurely. To fix this, remove the async flush from the allocation routines and move it to the top of the write path where we can do a synchronous flush and retry the write again. Only retry once as a second ENOSPC indicates that we really are ENOSPC. This avoids a page cache deadlock when trying to do this flush synchronously in the allocation layer that was identified by Mikulas Patocka. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_lrw.c | 18 +++++++++++++++++- fs/xfs/linux-2.6/xfs_sync.c | 25 ------------------------- fs/xfs/linux-2.6/xfs_sync.h | 1 - fs/xfs/xfs_iomap.c | 2 +- 4 files changed, 18 insertions(+), 28 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_lrw.c b/fs/xfs/linux-2.6/xfs_lrw.c index 7e90daa..9142192 100644 --- a/fs/xfs/linux-2.6/xfs_lrw.c +++ b/fs/xfs/linux-2.6/xfs_lrw.c @@ -751,10 +751,26 @@ start: goto relock; } } else { + int enospc = 0; + ssize_t ret2 = 0; + +write_retry: xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, *offset, ioflags); - ret = generic_file_buffered_write(iocb, iovp, segs, + ret2 = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); + /* + * if we just got an ENOSPC, flush the inode now we + * aren't holding any page locks and retry *once* + */ + if (ret2 == -ENOSPC && !enospc) { + error = xfs_flush_pages(xip, 0, -1, 0, FI_NONE); + if (error) + goto out_unlock_internal; + enospc = 1; + goto write_retry; + } + ret = ret2; } current->backing_dev_info = NULL; diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 88caafc..73cf8dc 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -426,31 +426,6 @@ xfs_syncd_queue_work( * heads, looking about for more room... */ STATIC void -xfs_flush_inode_work( - struct xfs_mount *mp, - void *arg) -{ - struct inode *inode = arg; - filemap_flush(inode->i_mapping); - iput(inode); -} - -void -xfs_flush_inode( - xfs_inode_t *ip) -{ - struct inode *inode = VFS_I(ip); - - igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work); - delay(msecs_to_jiffies(500)); -} - -/* - * This is the "bigger hammer" version of xfs_flush_inode_work... - * (IOW, "If at first you don't succeed, use a Bigger Hammer"). - */ -STATIC void xfs_flush_inodes_work( struct xfs_mount *mp, void *arg) diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index ec95e26..6e83a35 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -44,7 +44,6 @@ int xfs_sync_fsdata(struct xfs_mount *mp, int flags); int xfs_quiesce_data(struct xfs_mount *mp); void xfs_quiesce_attr(struct xfs_mount *mp); -void xfs_flush_inode(struct xfs_inode *ip); void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 8b97d82..7b8b170 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -347,7 +347,7 @@ xfs_flush_space( case 0: if (ip->i_delayed_blks) { xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_inode(ip); + delay(1); xfs_ilock(ip, XFS_ILOCK_EXCL); *fsynced = 1; } else { -- 1.6.2 From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:06:26 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_62, J_CHICKENPOX_64,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 n2FB65eI005281 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:06:26 -0500 X-ASG-Debug-ID: 1237115141-0ec303980000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A33B919A0A0 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:05:41 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id yNBXay4htAoGl0jA for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:05:41 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354572691-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:19:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinuX-0004nn-JW for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:49:41 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/3] [XFSQA] Reduce the number of processes forked Subject: [PATCH 1/3] [XFSQA] Reduce the number of processes forked Date: Sun, 15 Mar 2009 21:49:39 +1100 Message-Id: <1237114181-18431-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114181-18431-1-git-send-email-david@fromorbit.com> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237115143 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0187 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.20395 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 One of the big cpu time consumers when running xfsqa on UML is forking of new processes. when looping lots of times, using 'expr' to calculate the loop counter increment means we fork at least once every loop. using shell builtins means that we don't fork and many tests run substantially faster. Some tests are even runnable with this modification. e.g. 110 went from taking 4500s to run down to 9s with the loop iterators changed to avoid forking. Signed-off-by: Dave Chinner <david@fromorbit.com> --- 007 | 2 +- 028 | 2 +- 031 | 2 +- 047 | 2 +- 053 | 4 ++-- 064 | 8 ++++---- 065 | 8 ++++---- 068 | 6 +++--- 071 | 2 +- 089 | 2 +- 109 | 8 ++++---- 110 | 6 +++--- 111 | 2 +- 113 | 2 +- 114 | 4 ++-- 117 | 2 +- 119 | 2 +- 136 | 14 +++++++------- 137 | 4 ++-- 138 | 4 ++-- 139 | 4 ++-- 140 | 4 ++-- 149 | 2 +- 165 | 8 ++++---- 179 | 4 ++-- 180 | 4 ++-- 182 | 4 ++-- common.attr | 6 +++--- common.dump | 12 ++++++------ common.rc | 10 +++++----- 30 files changed, 72 insertions(+), 72 deletions(-) diff --git a/007 b/007 index e8c6610..290f716 100755 --- a/007 +++ b/007 @@ -50,7 +50,7 @@ num_filenames=100 i=1 while [ $i -le $num_filenames ]; do echo "nametest.$i" >>$sourcefile - i=`expr $i + 1` + let i=$i+1 done mkdir $testdir/$seq diff --git a/028 b/028 index 1b679f2..2c353fa 100755 --- a/028 +++ b/028 @@ -44,7 +44,7 @@ while [ $i -lt 5 ]; do fi rm $dump_file sleep 2 - i=`expr $i + 1` + let i=$i+1 done echo "middate = $middate" >>$seq.full diff --git a/031 b/031 index 779cf27..7ddd842 100755 --- a/031 +++ b/031 @@ -71,7 +71,7 @@ EOF while [ $count -lt $total ] do - count=`expr $count + 1` + let count=$count+1 cat >>$tmp.proto <<EOF ${count}_of_${total}_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ---755 3 1 /bin/true EOF diff --git a/047 b/047 index 168ada1..7ee9ed5 100755 --- a/047 +++ b/047 @@ -44,7 +44,7 @@ while [ $i -lt 5 ]; do fi rm $dump_file sleep 2 - i=`expr $i + 1` + let i=$i+1 done echo "middate = $middate" >>$seq.full diff --git a/053 b/053 index f260e1a..dbd2d5d 100755 --- a/053 +++ b/053 @@ -54,7 +54,7 @@ for acl in $acls do _do "touch $test.$i" _do "chacl $acl $test.$i" - i=`expr $i + 1` + let i=$i+1 done list_acls() @@ -63,7 +63,7 @@ list_acls() for acl in $acls do chacl -l $test.$i | _acl_filter_id | sed -e "s!$SCRATCH_MNT!\$SCRATCH_MNT!" - i=`expr $i + 1` + let i=$i+1 done } diff --git a/064 b/064 index 27ee1da..5a7d4b4 100755 --- a/064 +++ b/064 @@ -58,7 +58,7 @@ while [ $i -le 9 ]; do date >>$seq.full find $SCRATCH_MNT -exec $here/src/lstat64 {} \; | sed 's/(00.*)//' >$tmp.dates.$i if [ $i -gt 0 ]; then - level_1=`expr $i - 1` + let level_1=$i-1 diff -c $tmp.dates.$level_1 $tmp.dates.$i >>$seq.full else cat $tmp.dates.$i >>$seq.full @@ -66,7 +66,7 @@ while [ $i -le 9 ]; do dump_file=$tmp.df.level$i _do_dump_file -l $i - i=`expr $i + 1` + let i=$i+1 done echo "Listing of what files we start with:" @@ -79,7 +79,7 @@ while [ $i -le 9 ]; do echo "restoring from df.level$i" dump_file=$tmp.df.level$i _do_restore_toc - i=`expr $i + 1` + let i=$i+1 done echo "Do the cumulative restores" @@ -91,7 +91,7 @@ while [ $i -le 9 ]; do _do_restore_file_cum -l $i echo "ls -l restore_dir" ls -lR $restore_dir | _ls_size_filter | _check_quota_file - i=`expr $i + 1` + let i=$i+1 done # success, all done diff --git a/065 b/065 index b193f28..4252b11 100755 --- a/065 +++ b/065 @@ -146,7 +146,7 @@ while [ $i -le $num_dumps ]; do dump_file=$tmp.df.level$i _do_dump_file -l $i - i=`expr $i + 1` + let i=$i+1 done echo "Look at what files are contained in the inc. dump" @@ -156,7 +156,7 @@ while [ $i -le $num_dumps ]; do echo "restoring from df.level$i" dump_file=$tmp.df.level$i _do_restore_toc - i=`expr $i + 1` + let i=$i+1 done echo "Do the cumulative restores" @@ -168,7 +168,7 @@ while [ $i -le $num_dumps ]; do _do_restore_file_cum -l $i echo "list restore_dir" _list_dir $restore_dir | _check_quota_file | tee $tmp.restorals.$i - i=`expr $i + 1` + let i=$i+1 done echo "" @@ -178,7 +178,7 @@ while [ $i -le $num_dumps ]; do echo "Comparing ls of FS with restored FS at level $i" diff -s $tmp.ls.$i $tmp.restorals.$i | sed "s#$tmp#TMP#g" echo "" - i=`expr $i + 1` + let i=$i+1 done diff --git a/068 b/068 index eb8b936..af060ae 100755 --- a/068 +++ b/068 @@ -75,7 +75,7 @@ touch $tmp.running } & i=0 -ITERATIONS=`expr $ITERATIONS - 1` +let ITERATIONS=$ITERATIONS-1 echo | tee -a $seq.full while [ $i -le $ITERATIONS ] @@ -94,7 +94,7 @@ do sleep 2 echo | tee -a $seq.full - i=`expr $i + 1` + let i=$i+1 done # stop fsstress iterations @@ -105,4 +105,4 @@ wait _check_scratch_fs -exit 1 \ No newline at end of file +exit 1 diff --git a/071 b/071 index 5e621ba..4e95804 100755 --- a/071 +++ b/071 @@ -137,7 +137,7 @@ do echo === Iterating, `expr $upperbound - $count` remains echo echo - count=`expr $count + 1` + let count=$count+1 done # success, all done diff --git a/089 b/089 index db7525b..9f77c05 100755 --- a/089 +++ b/089 @@ -30,7 +30,7 @@ addentries() while [ $count -gt 0 ]; do touch `printf $pattern $count` - count=`expr $count - 1` + let count=$count-1 done } diff --git a/109 b/109 index 913ceea..845f1f2 100755 --- a/109 +++ b/109 @@ -38,7 +38,7 @@ populate() while [ $i -le $files -a "X$faststart" = "X" ]; do file=$SCRATCH_MNT/f$i xfs_io -f -d -c 'pwrite -b 64k 0 64k' $file >/dev/null - i=`expr $i + 1` + let i=$i+1 done # remove every second file, freeing up lots of space @@ -46,7 +46,7 @@ populate() i=1 while [ $i -le $files -a "X$faststart" = "X" ]; do rm $SCRATCH_MNT/f$i - i=`expr $i + 2` + let i=$i+2 done echo "flushing changes via umount/mount." @@ -67,10 +67,10 @@ allocate() xfs_io -f -c 'pwrite -b 64k 0 16m' $file \ >/dev/null 2>&1 rm $file - j=`expr $j + 1` + let j=$j+1 done } & - i=`expr $i + 1` + let i=$i+1 done wait diff --git a/110 b/110 index c578d35..85b313c 100755 --- a/110 +++ b/110 @@ -52,8 +52,8 @@ E=10030600 while [ $I -le $E ] do echo > $SCRATCH_MNT/test/${STR1}${STR2}${STR3}${I} - I=`expr $I + 1` - [ `expr $I % 1000` -eq 0 ] && echo "Created $I/$E" + let I=$I+1 + [ $[$I % 1000] -eq 0 ] && echo "Created $I/$E" done sync @@ -63,7 +63,7 @@ E=10030599 while [ $I -le $E ] do rm $SCRATCH_MNT/test/${STR1}${STR2}${STR3}${I} & - I=`expr $I + 1` + let I=$I+1 done _check_scratch_fs diff --git a/111 b/111 index 46f1395..060c0bc 100755 --- a/111 +++ b/111 @@ -39,7 +39,7 @@ I=0 while [ $I -lt 1000 ] do cp src/itrash.c $SCRATCH_MNT/${I} - I=`expr $I + 1` + let I=$I+1 done umount $SCRATCH_DEV diff --git a/113 b/113 index 9c435cf..49c8cee 100755 --- a/113 +++ b/113 @@ -41,7 +41,7 @@ _do_test() [ $__proc -gt 1 ] && _param="-t $__proc $_param" while [ $__proc -gt 1 ]; do _files="$_files $testdir/aiostress.$$.$_n.$__proc" - __proc=`expr $__proc - 1` + let __proc=$__proc-1 done rm -f $_files diff --git a/114 b/114 index 5f7c23d..af8608c 100755 --- a/114 +++ b/114 @@ -135,8 +135,8 @@ _test_hardlink() paths="$d/l1 $d/l2 $d/l3 $d2/l4 $d2/l5 $d2/l6" i=0 for x in $paths; do - i=`expr $i + 1` - j=`expr $i % 2` + let i=$i+1 + let j=$i%2 if [ $j -eq 0 ]; then echo "rm'ing $x" rm $x diff --git a/117 b/117 index 5fee416..7cb91d1 100755 --- a/117 +++ b/117 @@ -71,7 +71,7 @@ while [ $i -lt $ITERATIONS ]; do -s $seed \ -S -p 1 -n 1000 >>$seq.full 2>&1 - i=`expr $i + 1` + let i=$i+1 done cd / diff --git a/119 b/119 index 8d23495..055928c 100755 --- a/119 +++ b/119 @@ -54,7 +54,7 @@ while [ $i -lt $max ]; do xfs_freeze -f $SCRATCH_MNT xfs_freeze -u $SCRATCH_MNT echo -n . - i=`expr $i + 1` + let i=$i+1 done echo "done" diff --git a/136 b/136 index 0978ac9..c3e010c 100755 --- a/136 +++ b/136 @@ -61,7 +61,7 @@ add_eas() i=$start while [ $i -le $end ]; do attr -s name.$i -V value $file >/dev/null - i=`expr $i + 1` + let i=$i+1 done } @@ -73,7 +73,7 @@ rm_eas() i=$start while [ $i -le $end ]; do attr -r name.$i $file >/dev/null - i=`expr $i + 1` + let i=$i+1 done } @@ -171,7 +171,7 @@ _test_add_extents() while [ $j -le 30 ]; do do_extents $j _print_inode - j=`expr $j + 2` + let j=$j+2 done #scale down @@ -179,7 +179,7 @@ _test_add_extents() while [ $j -ge 1 ]; do do_extents $j _print_inode - j=`expr $j - 2` + let j=$j-2 done #build up @@ -187,7 +187,7 @@ _test_add_extents() while [ $j -le 30 ]; do do_extents $j _print_inode - j=`expr $j + 2` + let j=$j+2 done } @@ -211,7 +211,7 @@ _test_extents_eas() _print_inode _print_inode_u > $tmp.u1 for j in `seq 1 $EAs_inc $EAs_max`; do - k=`expr $j + $EAs_inc - 1` + let k=$k+$EAs_inc-1 add_eas $j $k done # should have same extents @@ -256,7 +256,7 @@ _test_eas_extents() EAs_inc=5 for j in `seq 1 $EAs_inc $EAs_max`; do - k=`expr $j + $EAs_inc - 1` + let k=$k+$EAs_inc-1 add_eas $j $k echo "--- EAs: $j ---" diff --git a/137 b/137 index 4dbf847..f27a248 100755 --- a/137 +++ b/137 @@ -47,7 +47,7 @@ do echo error creating/writing file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # give the system a chance to write something out @@ -90,7 +90,7 @@ do rm -f $file fi fi - i=`expr $i + 1` + let i=$i+1 done status=0 diff --git a/138 b/138 index 7cf9020..bf36e3d 100755 --- a/138 +++ b/138 @@ -53,7 +53,7 @@ do echo error truncating file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # give the system a chance to write something out @@ -96,7 +96,7 @@ do rm -f $file fi fi - i=`expr $i + 1` + let i=$i+1 done status=0 diff --git a/139 b/139 index 4805279..5fd2a64 100755 --- a/139 +++ b/139 @@ -53,7 +53,7 @@ do echo error truncating file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # give the system a chance to write something out @@ -96,7 +96,7 @@ do rm -f $file fi fi - i=`expr $i + 1` + let i=$i+1 done status=0 diff --git a/140 b/140 index 797efc4..e5d63a6 100755 --- a/140 +++ b/140 @@ -53,7 +53,7 @@ do echo error truncating file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # give the system a chance to write something out @@ -93,7 +93,7 @@ do rm -f $file fi fi - i=`expr $i + 1` + let i=$i+1 done status=0 diff --git a/149 b/149 index 0e9d974..8fea8af 100755 --- a/149 +++ b/149 @@ -74,7 +74,7 @@ EOF while [ $count -lt $total ] do - count=`expr $count + 1` + let count=$count+1 cat >>$tmp.proto <<EOF ${count}_of_${total}_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ---755 3 1 /bin/true EOF diff --git a/165 b/165 index 9eda608..7356a4c 100644 --- a/165 +++ b/165 @@ -82,8 +82,8 @@ do $XFS_IO_PROG -c "unresvsp $offset $length" -c "bmap -vp" $testfile | _filter_bmap - off=`expr $off + $len` # skip over 1 - off=`expr $off + $len` + let off=$off+$len # skip over 1 + let off=$off+$len done off=0 @@ -111,8 +111,8 @@ do #$XFS_IO_PROG -r -c "pread -v -b $bufsize $offset $length" $testfile #sleep 5 - off=`expr $off + $len` # skip over 1 - off=`expr $off + $len` + let off=$off+$len # skip over 1 + let off=$off+$len done wait diff --git a/179 b/179 index 6efb70f..c7cd9a7 100644 --- a/179 +++ b/179 @@ -63,7 +63,7 @@ _check_files() else echo file $file missing - fsync failed fi - i=`expr $i + 1` + let i=$i+1 done } @@ -78,7 +78,7 @@ do echo error creating/writing file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # shutdown immediately after, then remount and test diff --git a/180 b/180 index 3ad7972..52a4f7c 100644 --- a/180 +++ b/180 @@ -68,7 +68,7 @@ _check_files() else echo file $file missing - sync failed fi - i=`expr $i + 1` + let i=$i+1 done } @@ -83,7 +83,7 @@ do echo error creating/writing file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # sync, then shutdown immediately after, then remount and test diff --git a/182 b/182 index fdede6d..f112f30 100644 --- a/182 +++ b/182 @@ -63,7 +63,7 @@ _check_files() else echo file $file missing - sync failed fi - i=`expr $i + 1` + let i=$i+1 done } @@ -78,7 +78,7 @@ do echo error creating/writing file $file exit fi - i=`expr $i + 1` + let i=$i+1 done # sync, then shutdown immediately after, then remount and test diff --git a/common.attr b/common.attr index 31f71f2..5f16273 100644 --- a/common.attr +++ b/common.attr @@ -77,11 +77,11 @@ _acl_list() # _create_n_aces() { - n=`expr $1 - 4` + let n=$1-4 acl='u::rwx,g::rwx,o::rwx,m::rwx' # 4 ace acl start while [ $n -ne 0 ]; do - acl="$acl,u:$n:rwx" - n=`expr $n - 1` + acl="$acl,u:$n:rwx" + let n=$n-1 done echo $acl } diff --git a/common.dump b/common.dump index c80a9c1..6d2f120 100644 --- a/common.dump +++ b/common.dump @@ -97,7 +97,7 @@ _check_onl() else sleep 1 fi - i=`expr $i + 1` + let i=$i+1 done @@ -135,7 +135,7 @@ _wait_tape() else sleep 1 fi - i=`expr $i + 1` + let i=$i+1 done } @@ -681,7 +681,7 @@ _create_hardlinks() _hardlink=$_fname$_suffix echo "creating hardlink $_hardlink to $_fname" ln $_fname $_hardlink - _j=`expr $_j + 1` + let _j=$_j+1 done } @@ -697,7 +697,7 @@ _create_hardset() _i=1 while [ $_i -le $_numsets ]; do _create_hardlinks file$_i 5 - _i=`expr $_i + 1` + let _i=$_i+1 done } @@ -973,7 +973,7 @@ _do_dump_multi_file() while [ $i -lt $multi ] do multi_args="$multi_args -f $dump_file.$i -M $media_label.$i" - i=`expr $i + 1` + let i=$i+1 done echo "Dumping to files..." @@ -1093,7 +1093,7 @@ _do_restore_multi_file() while [ $i -lt $multi ] do multi_args="$multi_args -f $dump_file.$i" - i=`expr $i + 1` + let i=$i+1 done echo "Restoring from file..." diff --git a/common.rc b/common.rc index a51ac70..36f978b 100644 --- a/common.rc +++ b/common.rc @@ -152,7 +152,7 @@ _mount_ops_filter() params="$*" #get mount point to handle dmapi mtpt option correctly - last_index=`expr $# - 1` + let last_index=$#-1 [ $last_index -gt 0 ] && shift $last_index FS_ESCAPED=$1 @@ -1114,11 +1114,11 @@ _nfiles() while [ $f -lt $1 ] do file=f$f - touch $file + echo > $file if [ $size -gt 0 ]; then dd if=/dev/zero of=$file bs=1024 count=$size fi - f=`expr $f + 1` + let f=$f+1 done } @@ -1132,7 +1132,7 @@ _descend() _nfiles $files # files for this dir [ $depth -eq 0 ] && return - deep=`expr $depth - 1` # go 1 down + let deep=$depth-1 # go 1 down [ $verbose = true ] && echo "descending, depth from leaves = $deep" @@ -1140,7 +1140,7 @@ _descend() while [ $d -lt $dirs ] do _descend d$d $deep & - d=`expr $d + 1` + let d=$d+1 wait done } -- 1.6.2 From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:14: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.7 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 n2FBEdtH005660 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:14:59 -0500 X-ASG-Debug-ID: 1237115655-6d5500140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 970EE19A12D for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:14:16 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id pzlZDe4wn7uhVF0m for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:14:16 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43728600-1927428 for multiple; Sun, 15 Mar 2009 21:28:10 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lio2Z-0004tr-Ax; Sun, 15 Mar 2009 21:57:59 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Date: Sun, 15 Mar 2009 21:57:55 +1100 Message-Id: <1237114679-18808-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> References: <1237114679-18808-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237115657 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.20395 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: Dave Chinner <dgc@evostor.com> Currently xfs_device_flush calls sync_blockdev() which is a no-op for XFS as all it's metadata is held in a different address to the one sync_blockdev() works on. Call xfs_sync_inodes() instead to flush all the delayed allocation blocks out. To do this as efficiently as possible, do it via two passes - one to do an async flush of all the dirty blocks and a second to wait for all the IO to complete. This requires some modification to the xfs-sync_inodes_ag() flush code to do efficiently. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++++------ fs/xfs/linux-2.6/xfs_sync.c | 43 +++++++++++++++++++++++---------------- fs/xfs/linux-2.6/xfs_sync.h | 7 +++-- fs/xfs/xfs_iomap.c | 2 +- fs/xfs/xfs_mount.h | 2 +- 5 files changed, 38 insertions(+), 30 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_fs_subr.c b/fs/xfs/linux-2.6/xfs_fs_subr.c index 5aeb777..08be36d 100644 --- a/fs/xfs/linux-2.6/xfs_fs_subr.c +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c @@ -74,14 +74,14 @@ xfs_flush_pages( if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { xfs_iflags_clear(ip, XFS_ITRUNCATED); - ret = filemap_fdatawrite(mapping); - if (flags & XFS_B_ASYNC) - return -ret; - ret2 = filemap_fdatawait(mapping); - if (!ret) - ret = ret2; + ret = -filemap_fdatawrite(mapping); } - return -ret; + if (flags & XFS_B_ASYNC) + return ret; + ret2 = xfs_wait_on_pages(ip, first, last); + if (!ret) + ret = ret2; + return ret; } int diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index a608e72..88caafc 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -62,12 +62,6 @@ xfs_sync_inodes_ag( uint32_t first_index = 0; int error = 0; int last_error = 0; - int fflag = XFS_B_ASYNC; - - if (flags & SYNC_DELWRI) - fflag = XFS_B_DELWRI; - if (flags & SYNC_WAIT) - fflag = 0; /* synchronous overrides all */ do { struct inode *inode; @@ -128,11 +122,23 @@ xfs_sync_inodes_ag( * If we have to flush data or wait for I/O completion * we need to hold the iolock. */ - if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) { - xfs_ilock(ip, XFS_IOLOCK_SHARED); - lock_flags |= XFS_IOLOCK_SHARED; - error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE); - if (flags & SYNC_IOWAIT) + if (flags & SYNC_DELWRI) { + if (VN_DIRTY(inode)) { + if (flags & SYNC_TRYLOCK) { + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) + lock_flags |= XFS_IOLOCK_SHARED; + } else { + xfs_ilock(ip, XFS_IOLOCK_SHARED); + lock_flags |= XFS_IOLOCK_SHARED; + } + if (lock_flags & XFS_IOLOCK_SHARED) { + error = xfs_flush_pages(ip, 0, -1, + (flags & SYNC_WAIT) ? 0 + : XFS_B_ASYNC, + FI_NONE); + } + } + if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) xfs_ioend_wait(ip); } xfs_ilock(ip, XFS_ILOCK_SHARED); @@ -400,9 +406,9 @@ xfs_syncd_queue_work( void *data, void (*syncer)(struct xfs_mount *, void *)) { - struct bhv_vfs_sync_work *work; + struct xfs_sync_work *work; - work = kmem_alloc(sizeof(struct bhv_vfs_sync_work), KM_SLEEP); + work = kmem_alloc(sizeof(struct xfs_sync_work), KM_SLEEP); INIT_LIST_HEAD(&work->w_list); work->w_syncer = syncer; work->w_data = data; @@ -445,23 +451,24 @@ xfs_flush_inode( * (IOW, "If at first you don't succeed, use a Bigger Hammer"). */ STATIC void -xfs_flush_device_work( +xfs_flush_inodes_work( struct xfs_mount *mp, void *arg) { struct inode *inode = arg; - sync_blockdev(mp->m_super->s_bdev); + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK); + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK | SYNC_IOWAIT); iput(inode); } void -xfs_flush_device( +xfs_flush_inodes( xfs_inode_t *ip) { struct inode *inode = VFS_I(ip); igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work); + xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work); delay(msecs_to_jiffies(500)); xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); } @@ -497,7 +504,7 @@ xfssyncd( { struct xfs_mount *mp = arg; long timeleft; - bhv_vfs_sync_work_t *work, *n; + xfs_sync_work_t *work, *n; LIST_HEAD (tmp); set_freezable(); diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index 04f058c..ec95e26 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -21,18 +21,19 @@ struct xfs_mount; struct xfs_perag; -typedef struct bhv_vfs_sync_work { +typedef struct xfs_sync_work { struct list_head w_list; struct xfs_mount *w_mount; void *w_data; /* syncer routine argument */ void (*w_syncer)(struct xfs_mount *, void *); -} bhv_vfs_sync_work_t; +} xfs_sync_work_t; #define SYNC_ATTR 0x0001 /* sync attributes */ #define SYNC_DELWRI 0x0002 /* look at delayed writes */ #define SYNC_WAIT 0x0004 /* wait for i/o to complete */ #define SYNC_BDFLUSH 0x0008 /* BDFLUSH is calling -- don't block */ #define SYNC_IOWAIT 0x0010 /* wait for all I/O to complete */ +#define SYNC_TRYLOCK 0x0020 /* only try to lock inodes */ int xfs_syncd_init(struct xfs_mount *mp); void xfs_syncd_stop(struct xfs_mount *mp); @@ -44,7 +45,7 @@ int xfs_quiesce_data(struct xfs_mount *mp); void xfs_quiesce_attr(struct xfs_mount *mp); void xfs_flush_inode(struct xfs_inode *ip); -void xfs_flush_device(struct xfs_inode *ip); +void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); int xfs_reclaim_inodes(struct xfs_mount *mp, int noblock, int mode); diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 08ce723..8b97d82 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -361,7 +361,7 @@ xfs_flush_space( return 0; case 2: xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_device(ip); + xfs_flush_inodes(ip); xfs_ilock(ip, XFS_ILOCK_EXCL); *fsynced = 3; return 0; diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 1438dd4..6df3a31 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -318,7 +318,7 @@ typedef struct xfs_mount { #endif struct xfs_mru_cache *m_filestream; /* per-mount filestream data */ struct task_struct *m_sync_task; /* generalised sync thread */ - bhv_vfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ + xfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ struct list_head m_sync_list; /* sync thread work item list */ spinlock_t m_sync_lock; /* work item list lock */ int m_sync_seq; /* sync thread generation no. */ -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:26: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.7 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 n2FBQHpO006414 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:26:38 -0500 X-ASG-Debug-ID: 1237116354-0e79002c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 186591C4369D for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:25:54 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id GyqJ2btznJfDNF5G for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:25:54 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46132950-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:55:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioTO-0006h8-Ek for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:25:42 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] [XFS] Validate log feature fields correctly Subject: [PATCH 1/2] [XFS] Validate log feature fields correctly Date: Sun, 15 Mar 2009 22:25:41 +1100 Message-Id: <1237116342-25701-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116342-25701-1-git-send-email-david@fromorbit.com> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237116356 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.20397 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 If the large log sector size feature bit is set in the superblock by accident (say disk corruption), the then fields that are now considered valid are not checked on production kernels. The checks are present as ASSERT statements so cause a panic on a debug kernel. Change this so that the fields are validity checked if the feature bit is set and abort the log mount if the fields do not contain valid values. Reported-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_log.c | 41 ++++++++++++++++++++++++++++++----------- 1 files changed, 30 insertions(+), 11 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index c8f3008..60e6e63 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -562,9 +562,8 @@ xfs_log_mount( } mp->m_log = xlog_alloc_log(mp, log_target, blk_offset, num_bblks); - if (!mp->m_log) { - cmn_err(CE_WARN, "XFS: Log allocation failed: No memory!"); - error = ENOMEM; + if (IS_ERR(mp->m_log)) { + error = -PTR_ERR(mp->m_log); goto out; } @@ -1193,10 +1192,13 @@ xlog_alloc_log(xfs_mount_t *mp, xfs_buf_t *bp; int i; int iclogsize; + int error = ENOMEM; log = kmem_zalloc(sizeof(xlog_t), KM_MAYFAIL); - if (!log) - return NULL; + if (!log) { + xlog_warn("XFS: Log allocation failed: No memory!"); + goto out; + } log->l_mp = mp; log->l_targ = log_target; @@ -1214,19 +1216,35 @@ xlog_alloc_log(xfs_mount_t *mp, log->l_grant_reserve_cycle = 1; log->l_grant_write_cycle = 1; + error = EFSCORRUPTED; if (xfs_sb_version_hassector(&mp->m_sb)) { log->l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; - ASSERT(log->l_sectbb_log <= mp->m_sectbb_log); + if (log->l_sectbb_log < 0 || + log->l_sectbb_log > mp->m_sectbb_log) { + xlog_warn("XFS: Log sector size (0x%x) out of range.", + log->l_sectbb_log); + goto out_free_log; + } + /* for larger sector sizes, must have v2 or external log */ - ASSERT(log->l_sectbb_log == 0 || - log->l_logBBstart == 0 || - xfs_sb_version_haslogv2(&mp->m_sb)); - ASSERT(mp->m_sb.sb_logsectlog >= BBSHIFT); + if (log->l_sectbb_log != 0 && + (log->l_logBBstart != 0 && + !xfs_sb_version_haslogv2(&mp->m_sb))) { + xlog_warn("XFS: log sector size (0x%x) invalid " + "for configuration.", log->l_sectbb_log); + goto out_free_log; + } + if (mp->m_sb.sb_logsectlog < BBSHIFT) { + xlog_warn("XFS: Log sector log (0x%x) too small.", + mp->m_sb.sb_logsectlog); + goto out_free_log; + } } log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; xlog_get_iclog_buffer_size(mp, log); + error = ENOMEM; bp = xfs_buf_get_empty(log->l_iclog_size, mp->m_logdev_targp); if (!bp) goto out_free_log; @@ -1326,7 +1344,8 @@ out_free_iclog: xfs_buf_free(log->l_xbuf); out_free_log: kmem_free(log); - return NULL; +out: + return ERR_PTR(-error); } /* xlog_alloc_log */ -- 1.6.2 From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:26: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.7 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 n2FBQItD006415 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:26:38 -0500 X-ASG-Debug-ID: 1237116354-0e8000320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1CB331C436A1 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:25:54 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id ZwihiYwFkRvd1ioV for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:25:54 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58260909-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:55:53 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioTO-0006hC-J8 for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:25:42 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] [XFS] Fix double free of inode Subject: [PATCH 2/2] [XFS] Fix double free of inode Date: Sun, 15 Mar 2009 22:25:42 +1100 Message-Id: <1237116342-25701-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116342-25701-1-git-send-email-david@fromorbit.com> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237116356 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.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20397 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean If we fail to initialise the VFS inode in inode_init_always(), it will call ->delete_inode internally resulting in the inode being freed. Hence we need to delay the call to inode_init_always() until after the XFS inode is sufficient set up to handle a call to ->delete_inode, and then if that fails do not touch the inode again at all as it has been freed. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_iget.c | 23 ++++++++++++++--------- 1 files changed, 14 insertions(+), 9 deletions(-) diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c index 478e587..89b81ee 100644 --- a/fs/xfs/xfs_iget.c +++ b/fs/xfs/xfs_iget.c @@ -69,15 +69,6 @@ xfs_inode_alloc( ASSERT(!spin_is_locked(&ip->i_flags_lock)); ASSERT(completion_done(&ip->i_flush)); - /* - * initialise the VFS inode here to get failures - * out of the way early. - */ - if (!inode_init_always(mp->m_super, VFS_I(ip))) { - kmem_zone_free(xfs_inode_zone, ip); - return NULL; - } - /* initialise the xfs inode */ ip->i_ino = ino; ip->i_mount = mp; @@ -113,6 +104,20 @@ xfs_inode_alloc( #ifdef XFS_DIR2_TRACE ip->i_dir_trace = ktrace_alloc(XFS_DIR2_KTRACE_SIZE, KM_NOFS); #endif + /* + * Now initialise the VFS inode. We do this after the xfs_inode + * initialisation as internal failures will result in ->destroy_inode + * being called and that will pass down through the reclaim path and + * free the XFS inode. This path requires the XFS inode to already be + * initialised. Hence if this call fails, the xfs_inode has already + * been freed and we should not reference it at all in the error + * handling. + */ + if (!inode_init_always(mp->m_super, VFS_I(ip))) + return NULL; + + /* prevent anyone from using this yet */ + VFS_I(ip)->i_state = I_NEW|I_LOCK; return ip; } -- 1.6.2 From david@fromorbit.com Sun Mar 15 06:30:53 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 n2FBUX7T006780 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:30:53 -0500 X-ASG-Debug-ID: 1237116609-0e8400350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3348A1C43838 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:30:10 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id meeS39OwI40SGZQ7 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:30:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALV+vEl5LAJ7/2dsb2JhbADQUoN/Bg X-IronPort-AV: E=Sophos;i="4.38,365,1233495000"; d="scan'208";a="338975461" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 15 Mar 2009 21:41:51 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1LioFx-0005Kg-Pg; Sun, 15 Mar 2009 22:11:49 +1100 Date: Sun, 15 Mar 2009 22:11:49 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 0/5] [XFS] Spurious ENOSPC fixes Subject: Re: [PATCH 0/5] [XFS] Spurious ENOSPC fixes Message-ID: <20090315111149.GX26138@disturbed> Mail-Followup-To: xfs@oss.sgi.com, mpatocka@redhat.com References: <1237114679-18808-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237114679-18808-1-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237116611 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1639 1.0000 -1.0232 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.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.20397 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 Sun, Mar 15, 2009 at 09:57:54PM +1100, Dave Chinner wrote: > This series fix the spurious ENOSPC problems reported by and > partially solved by Mikulas Patocka. This series makes the recently > posted QA tests 203 and 204 pass. > > Mikulas, if I've got any of the attributions wrong for the > bits of your code I used, let me know and I'll fix them. I'm about to resend these with the correct sign-off (i.e. david@fromorbit.com). Please ignore all the patches with a different signed-off by. [ I screwed up the .gitconfig earlier today when setting up a new build/test box and didn't notice that the local commits in the kernel tree had the wrong address... ] Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:33: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.7 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 n2FBWeBi006954 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:33:00 -0500 X-ASG-Debug-ID: 1237116736-6d5200380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C67E719A010 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id C4jM8ex01nOuT7xC for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43730340-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZI-0006ik-4j; Sun, 15 Mar 2009 22:31:48 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Subject: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Date: Sun, 15 Mar 2009 22:31:46 +1100 Message-Id: <1237116707-25793-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116707-25793-1-git-send-email-david@fromorbit.com> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237116738 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.20397 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 If we are creating lots of small files, we can fail to get a reservation for inode create earlier than we should due to EOF preallocation done during delayed allocation reservation. Hence on the first reservation ENOSPC failure flush all the delayed allocation blocks out of the system and retry. This fixes the last commonly triggered spurious ENOSPC issue that has been reported. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_vnodeops.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c index 59de049..faf671b 100644 --- a/fs/xfs/xfs_vnodeops.c +++ b/fs/xfs/xfs_vnodeops.c @@ -1457,6 +1457,13 @@ xfs_create( error = xfs_trans_reserve(tp, resblks, log_res, 0, XFS_TRANS_PERM_LOG_RES, log_count); if (error == ENOSPC) { + /* flush outstanding delalloc blocks and retry */ + xfs_flush_inodes(dp); + error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); + } + if (error == ENOSPC) { + /* No space at all so try a "no-allocation" reservation */ resblks = 0; error = xfs_trans_reserve(tp, 0, log_res, 0, XFS_TRANS_PERM_LOG_RES, log_count); -- 1.6.2 From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:33: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.7 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 n2FBWeGv006956 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:33:01 -0500 X-ASG-Debug-ID: 1237116737-733200940000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2C8431C43843 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id YmqwwLUFwJYMp4HM for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354574915-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZH-0006iV-KC; Sun, 15 Mar 2009 22:31:47 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 0/5, RESEND] [XFS] Spurious ENOSPC fixes Subject: [PATCH 0/5, RESEND] [XFS] Spurious ENOSPC fixes Date: Sun, 15 Mar 2009 22:31:42 +1100 Message-Id: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237116739 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1189 1.0000 -1.2808 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.28 X-Barracuda-Spam-Status: No, SCORE=-1.28 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.20397 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 This series fix the spurious ENOSPC problems reported by and partially solved by Mikulas Patocka. This series makes the recently posted QA tests 203 and 204 pass. Mikulas, if I've got any of the attributions wrong for the bits of your code I used, let me know and I'll fix them. This is a resend with the correct sign-offs on it. From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:33:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,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 n2FBWeTa006955 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:33:00 -0500 X-ASG-Debug-ID: 1237116736-6d4c003d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 67E1519A00D for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id Ehvqcx8TltceimVi for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44231237-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZI-0006ig-07; Sun, 15 Mar 2009 22:31:48 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Subject: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Date: Sun, 15 Mar 2009 22:31:45 +1100 Message-Id: <1237116707-25793-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116707-25793-1-git-send-email-david@fromorbit.com> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237116738 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.20397 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 xfs_flush_inodes() currently uses a magic timeout to wait for some inodes to be flushed before returning. This isn't really reliable but used to be the best that could be done due to deadlock potential of waiting for the entire flush. Now the inode flush is safe to execute while we hold page and inode locks, we can wait for all the inodes to flush synchronously. Convert the wait mechanism to a completion to do this efficiently. This should remove all remaining spurious ENOSPC errors from the delayed allocation reservation path. This is extracted almost line for line from a larger patch from Mikulas Patocka. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 12 +++++++++--- fs/xfs/linux-2.6/xfs_sync.h | 1 + 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 73cf8dc..f7ba766 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -404,7 +404,8 @@ STATIC void xfs_syncd_queue_work( struct xfs_mount *mp, void *data, - void (*syncer)(struct xfs_mount *, void *)) + void (*syncer)(struct xfs_mount *, void *), + struct completion *completion) { struct xfs_sync_work *work; @@ -413,6 +414,7 @@ xfs_syncd_queue_work( work->w_syncer = syncer; work->w_data = data; work->w_mount = mp; + work->w_completion = completion; spin_lock(&mp->m_sync_lock); list_add_tail(&work->w_list, &mp->m_sync_list); spin_unlock(&mp->m_sync_lock); @@ -441,10 +443,11 @@ xfs_flush_inodes( xfs_inode_t *ip) { struct inode *inode = VFS_I(ip); + DECLARE_COMPLETION_ONSTACK(completion); igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work); - delay(msecs_to_jiffies(500)); + xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work, &completion); + wait_for_completion(&completion); xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); } @@ -514,6 +517,8 @@ xfssyncd( list_del(&work->w_list); if (work == &mp->m_sync_work) continue; + if (work->w_completion) + complete(work->w_completion); kmem_free(work); } } @@ -527,6 +532,7 @@ xfs_syncd_init( { mp->m_sync_work.w_syncer = xfs_sync_worker; mp->m_sync_work.w_mount = mp; + mp->m_sync_work.w_completion = NULL; mp->m_sync_task = kthread_run(xfssyncd, mp, "xfssyncd"); if (IS_ERR(mp->m_sync_task)) return -PTR_ERR(mp->m_sync_task); diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index 6e83a35..308d5bf 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -26,6 +26,7 @@ typedef struct xfs_sync_work { struct xfs_mount *w_mount; void *w_data; /* syncer routine argument */ void (*w_syncer)(struct xfs_mount *, void *); + struct completion *w_completion; } xfs_sync_work_t; #define SYNC_ATTR 0x0001 /* sync attributes */ -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:33:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,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 n2FBWfm1006957 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:33:01 -0500 X-ASG-Debug-ID: 1237116737-0e7f00450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C4321C43845 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id whAFrjhNWvuhon9n for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:17 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46133263-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZH-0006iX-Na; Sun, 15 Mar 2009 22:31:47 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Date: Sun, 15 Mar 2009 22:31:43 +1100 Message-Id: <1237116707-25793-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116707-25793-1-git-send-email-david@fromorbit.com> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237116739 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.20397 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 Currently xfs_device_flush calls sync_blockdev() which is a no-op for XFS as all it's metadata is held in a different address to the one sync_blockdev() works on. Call xfs_sync_inodes() instead to flush all the delayed allocation blocks out. To do this as efficiently as possible, do it via two passes - one to do an async flush of all the dirty blocks and a second to wait for all the IO to complete. This requires some modification to the xfs-sync_inodes_ag() flush code to do efficiently. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++++------ fs/xfs/linux-2.6/xfs_sync.c | 43 +++++++++++++++++++++++---------------- fs/xfs/linux-2.6/xfs_sync.h | 7 +++-- fs/xfs/xfs_iomap.c | 2 +- fs/xfs/xfs_mount.h | 2 +- 5 files changed, 38 insertions(+), 30 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_fs_subr.c b/fs/xfs/linux-2.6/xfs_fs_subr.c index 5aeb777..08be36d 100644 --- a/fs/xfs/linux-2.6/xfs_fs_subr.c +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c @@ -74,14 +74,14 @@ xfs_flush_pages( if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { xfs_iflags_clear(ip, XFS_ITRUNCATED); - ret = filemap_fdatawrite(mapping); - if (flags & XFS_B_ASYNC) - return -ret; - ret2 = filemap_fdatawait(mapping); - if (!ret) - ret = ret2; + ret = -filemap_fdatawrite(mapping); } - return -ret; + if (flags & XFS_B_ASYNC) + return ret; + ret2 = xfs_wait_on_pages(ip, first, last); + if (!ret) + ret = ret2; + return ret; } int diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index a608e72..88caafc 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -62,12 +62,6 @@ xfs_sync_inodes_ag( uint32_t first_index = 0; int error = 0; int last_error = 0; - int fflag = XFS_B_ASYNC; - - if (flags & SYNC_DELWRI) - fflag = XFS_B_DELWRI; - if (flags & SYNC_WAIT) - fflag = 0; /* synchronous overrides all */ do { struct inode *inode; @@ -128,11 +122,23 @@ xfs_sync_inodes_ag( * If we have to flush data or wait for I/O completion * we need to hold the iolock. */ - if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) { - xfs_ilock(ip, XFS_IOLOCK_SHARED); - lock_flags |= XFS_IOLOCK_SHARED; - error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE); - if (flags & SYNC_IOWAIT) + if (flags & SYNC_DELWRI) { + if (VN_DIRTY(inode)) { + if (flags & SYNC_TRYLOCK) { + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) + lock_flags |= XFS_IOLOCK_SHARED; + } else { + xfs_ilock(ip, XFS_IOLOCK_SHARED); + lock_flags |= XFS_IOLOCK_SHARED; + } + if (lock_flags & XFS_IOLOCK_SHARED) { + error = xfs_flush_pages(ip, 0, -1, + (flags & SYNC_WAIT) ? 0 + : XFS_B_ASYNC, + FI_NONE); + } + } + if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) xfs_ioend_wait(ip); } xfs_ilock(ip, XFS_ILOCK_SHARED); @@ -400,9 +406,9 @@ xfs_syncd_queue_work( void *data, void (*syncer)(struct xfs_mount *, void *)) { - struct bhv_vfs_sync_work *work; + struct xfs_sync_work *work; - work = kmem_alloc(sizeof(struct bhv_vfs_sync_work), KM_SLEEP); + work = kmem_alloc(sizeof(struct xfs_sync_work), KM_SLEEP); INIT_LIST_HEAD(&work->w_list); work->w_syncer = syncer; work->w_data = data; @@ -445,23 +451,24 @@ xfs_flush_inode( * (IOW, "If at first you don't succeed, use a Bigger Hammer"). */ STATIC void -xfs_flush_device_work( +xfs_flush_inodes_work( struct xfs_mount *mp, void *arg) { struct inode *inode = arg; - sync_blockdev(mp->m_super->s_bdev); + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK); + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK | SYNC_IOWAIT); iput(inode); } void -xfs_flush_device( +xfs_flush_inodes( xfs_inode_t *ip) { struct inode *inode = VFS_I(ip); igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work); + xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work); delay(msecs_to_jiffies(500)); xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); } @@ -497,7 +504,7 @@ xfssyncd( { struct xfs_mount *mp = arg; long timeleft; - bhv_vfs_sync_work_t *work, *n; + xfs_sync_work_t *work, *n; LIST_HEAD (tmp); set_freezable(); diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index 04f058c..ec95e26 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -21,18 +21,19 @@ struct xfs_mount; struct xfs_perag; -typedef struct bhv_vfs_sync_work { +typedef struct xfs_sync_work { struct list_head w_list; struct xfs_mount *w_mount; void *w_data; /* syncer routine argument */ void (*w_syncer)(struct xfs_mount *, void *); -} bhv_vfs_sync_work_t; +} xfs_sync_work_t; #define SYNC_ATTR 0x0001 /* sync attributes */ #define SYNC_DELWRI 0x0002 /* look at delayed writes */ #define SYNC_WAIT 0x0004 /* wait for i/o to complete */ #define SYNC_BDFLUSH 0x0008 /* BDFLUSH is calling -- don't block */ #define SYNC_IOWAIT 0x0010 /* wait for all I/O to complete */ +#define SYNC_TRYLOCK 0x0020 /* only try to lock inodes */ int xfs_syncd_init(struct xfs_mount *mp); void xfs_syncd_stop(struct xfs_mount *mp); @@ -44,7 +45,7 @@ int xfs_quiesce_data(struct xfs_mount *mp); void xfs_quiesce_attr(struct xfs_mount *mp); void xfs_flush_inode(struct xfs_inode *ip); -void xfs_flush_device(struct xfs_inode *ip); +void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); int xfs_reclaim_inodes(struct xfs_mount *mp, int noblock, int mode); diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 08ce723..8b97d82 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -361,7 +361,7 @@ xfs_flush_space( return 0; case 2: xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_device(ip); + xfs_flush_inodes(ip); xfs_ilock(ip, XFS_ILOCK_EXCL); *fsynced = 3; return 0; diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 1438dd4..6df3a31 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -318,7 +318,7 @@ typedef struct xfs_mount { #endif struct xfs_mru_cache *m_filestream; /* per-mount filestream data */ struct task_struct *m_sync_task; /* generalised sync thread */ - bhv_vfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ + xfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ struct list_head m_sync_list; /* sync thread work item list */ spinlock_t m_sync_lock; /* work item list lock */ int m_sync_seq; /* sync thread generation no. */ -- 1.6.2 From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:33:02 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,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 n2FBWftQ006958 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:33:01 -0500 X-ASG-Debug-ID: 1237116737-0e91003d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9B4391C43846 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:18 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id oaFFkqvEey9Glfou for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:32:18 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354574917-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZI-0006io-99; Sun, 15 Mar 2009 22:31:48 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 5/5] [XFS] Remove xfs_flush_space Subject: [PATCH 5/5] [XFS] Remove xfs_flush_space Date: Sun, 15 Mar 2009 22:31:47 +1100 Message-Id: <1237116707-25793-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116707-25793-1-git-send-email-david@fromorbit.com> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237116739 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0205 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.20397 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 The only thing we need to do now when we get an ENOSPC condition during delayed allocation reservation is flush all the other inodes with delalloc blocks on them and retry without EOF preallocation. Remove the unneeded mess that is xfs_flush_space() and just call xfs_flush_inodes() directly from xfs_iomap_write_delay(). Also, change the location of the retry label to avoid trying to do EOF preallocation because we don't want to do that at ENOSPC. This enables us to remove the BMAPI_SYNC flag as it is no longer used. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_iomap.c | 61 ++++++++++++--------------------------------------- fs/xfs/xfs_iomap.h | 3 +- 2 files changed, 16 insertions(+), 48 deletions(-) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 7b8b170..5aaa2d7 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -338,38 +338,6 @@ xfs_iomap_eof_align_last_fsb( } STATIC int -xfs_flush_space( - xfs_inode_t *ip, - int *fsynced, - int *ioflags) -{ - switch (*fsynced) { - case 0: - if (ip->i_delayed_blks) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - delay(1); - xfs_ilock(ip, XFS_ILOCK_EXCL); - *fsynced = 1; - } else { - *ioflags |= BMAPI_SYNC; - *fsynced = 2; - } - return 0; - case 1: - *fsynced = 2; - *ioflags |= BMAPI_SYNC; - return 0; - case 2: - xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_inodes(ip); - xfs_ilock(ip, XFS_ILOCK_EXCL); - *fsynced = 3; - return 0; - } - return 1; -} - -STATIC int xfs_cmn_err_fsblock_zero( xfs_inode_t *ip, xfs_bmbt_irec_t *imap) @@ -538,15 +506,9 @@ error_out: } /* - * If the caller is doing a write at the end of the file, - * then extend the allocation out to the file system's write - * iosize. We clean up any extra space left over when the - * file is closed in xfs_inactive(). - * - * For sync writes, we are flushing delayed allocate space to - * try to make additional space available for allocation near - * the filesystem full boundary - preallocation hurts in that - * situation, of course. + * If the caller is doing a write at the end of the file, then extend the + * allocation out to the file system's write iosize. We clean up any extra + * space left over when the file is closed in xfs_inactive(). */ STATIC int xfs_iomap_eof_want_preallocate( @@ -565,7 +527,7 @@ xfs_iomap_eof_want_preallocate( int n, error, imaps; *prealloc = 0; - if ((ioflag & BMAPI_SYNC) || (offset + count) <= ip->i_size) + if ((offset + count) <= ip->i_size) return 0; /* @@ -611,7 +573,7 @@ xfs_iomap_write_delay( xfs_extlen_t extsz; int nimaps; xfs_bmbt_irec_t imap[XFS_WRITE_IMAPS]; - int prealloc, fsynced = 0; + int prealloc, flushed = 0; int error; ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); @@ -627,12 +589,12 @@ xfs_iomap_write_delay( extsz = xfs_get_extsz_hint(ip); offset_fsb = XFS_B_TO_FSBT(mp, offset); -retry: error = xfs_iomap_eof_want_preallocate(mp, ip, offset, count, ioflag, imap, XFS_WRITE_IMAPS, &prealloc); if (error) return error; +retry: if (prealloc) { aligned_offset = XFS_WRITEIO_ALIGN(mp, (offset + count - 1)); ioalign = XFS_B_TO_FSBT(mp, aligned_offset); @@ -659,15 +621,22 @@ retry: /* * If bmapi returned us nothing, and if we didn't get back EDQUOT, - * then we must have run out of space - flush delalloc, and retry.. + * then we must have run out of space - flush all other inodes with + * delalloc blocks and retry without EOF preallocation. */ if (nimaps == 0) { xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, ip, offset, count); - if (xfs_flush_space(ip, &fsynced, &ioflag)) + if (flushed) return XFS_ERROR(ENOSPC); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_flush_inodes(ip); + xfs_ilock(ip, XFS_ILOCK_EXCL); + + flushed = 1; error = 0; + prealloc = 0; goto retry; } diff --git a/fs/xfs/xfs_iomap.h b/fs/xfs/xfs_iomap.h index ee1a0c1..87fb9d1 100644 --- a/fs/xfs/xfs_iomap.h +++ b/fs/xfs/xfs_iomap.h @@ -40,8 +40,7 @@ typedef enum { BMAPI_IGNSTATE = (1 << 4), /* ignore unwritten state on read */ BMAPI_DIRECT = (1 << 5), /* direct instead of buffered write */ BMAPI_MMAP = (1 << 6), /* allocate for mmap write */ - BMAPI_SYNC = (1 << 7), /* sync write to flush delalloc space */ - BMAPI_TRYLOCK = (1 << 8), /* non-blocking request */ + BMAPI_TRYLOCK = (1 << 7), /* non-blocking request */ } bmapi_flags_t; -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:41: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.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_57 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 n2FBfJNc007742 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:41:39 -0500 X-ASG-Debug-ID: 1237117255-734f00c90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B30371C43931 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:40:56 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id OnG0a6GuzlawkmNS for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:40:56 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46133687-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:10:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Liohw-0006l3-0l for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:40:44 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Subject: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Date: Sun, 15 Mar 2009 22:40:43 +1100 Message-Id: <1237117243-25940-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117243-25940-1-git-send-email-david@fromorbit.com> References: <1237117243-25940-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237117257 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0425 1.0000 -1.7469 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.75 X-Barracuda-Spam-Status: No, SCORE=-1.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.20397 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 When trying to reserve log space, we find the amount of space we need, then go to sleep waiting for space. When we are woken, we try to push the tail of the log forward to make sure we have space available. Unfortunately, this means that if there is not space available, and everyone who needs space goes to sleep there is no-one left to push the tail of the log to make space available. Once we have a thread waiting for space to become available, the others queue up behind it in a FIFO, and none of them push the tail of the log. This can result in everyone going to sleep in xlog_grant_log_space() if the first sleeper races with the last I/O that moves the tail of the log forward. With no further I/O tomove the tail of the log, there is nothing to wake the sleepers and hence all transactions just stop. Fix this by making sure the xfsaild will create enough space for the transaction that is about to sleep by moving the push target far enough forwards to ensure that that the curent proceeees will have enough space available when it is woken. That is, we push the AIL before we go to sleep. Because we've inserted the log ticket into the queue before we've pushed and gone to sleep, subsequent transactions will wait behind this one. Hence we are guaranteed to have space available when we are woken. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_log.c | 37 +++++++++++++++++++------------------ 1 files changed, 19 insertions(+), 18 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 60e6e63..278960c 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -2573,18 +2573,19 @@ redo: xlog_ins_ticketq(&log->l_reserve_headq, tic); xlog_trace_loggrant(log, tic, "xlog_grant_log_space: sleep 2"); + spin_unlock(&log->l_grant_lock); + xlog_grant_push_ail(log->l_mp, need_bytes); + spin_lock(&log->l_grant_lock); + XFS_STATS_INC(xs_sleep_logspace); sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); - if (XLOG_FORCED_SHUTDOWN(log)) { - spin_lock(&log->l_grant_lock); + spin_lock(&log->l_grant_lock); + if (XLOG_FORCED_SHUTDOWN(log)) goto error_return; - } xlog_trace_loggrant(log, tic, "xlog_grant_log_space: wake 2"); - xlog_grant_push_ail(log->l_mp, need_bytes); - spin_lock(&log->l_grant_lock); goto redo; } else if (tic->t_flags & XLOG_TIC_IN_Q) xlog_del_ticketq(&log->l_reserve_headq, tic); @@ -2663,7 +2664,7 @@ xlog_regrant_write_log_space(xlog_t *log, * for more free space, otherwise try to get some space for * this transaction. */ - + need_bytes = tic->t_unit_res; if ((ntic = log->l_write_headq)) { free_bytes = xlog_space_left(log, log->l_grant_write_cycle, log->l_grant_write_bytes); @@ -2683,26 +2684,25 @@ xlog_regrant_write_log_space(xlog_t *log, xlog_trace_loggrant(log, tic, "xlog_regrant_write_log_space: sleep 1"); + spin_unlock(&log->l_grant_lock); + xlog_grant_push_ail(log->l_mp, need_bytes); + spin_lock(&log->l_grant_lock); + XFS_STATS_INC(xs_sleep_logspace); sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already * off the queue */ - if (XLOG_FORCED_SHUTDOWN(log)) { - spin_lock(&log->l_grant_lock); + spin_lock(&log->l_grant_lock); + if (XLOG_FORCED_SHUTDOWN(log)) goto error_return; - } xlog_trace_loggrant(log, tic, "xlog_regrant_write_log_space: wake 1"); - xlog_grant_push_ail(log->l_mp, tic->t_unit_res); - spin_lock(&log->l_grant_lock); } } - need_bytes = tic->t_unit_res; - redo: if (XLOG_FORCED_SHUTDOWN(log)) goto error_return; @@ -2712,19 +2712,20 @@ redo: if (free_bytes < need_bytes) { if ((tic->t_flags & XLOG_TIC_IN_Q) == 0) xlog_ins_ticketq(&log->l_write_headq, tic); + spin_unlock(&log->l_grant_lock); + xlog_grant_push_ail(log->l_mp, need_bytes); + spin_lock(&log->l_grant_lock); + XFS_STATS_INC(xs_sleep_logspace); sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already off the queue */ - if (XLOG_FORCED_SHUTDOWN(log)) { - spin_lock(&log->l_grant_lock); + spin_lock(&log->l_grant_lock); + if (XLOG_FORCED_SHUTDOWN(log)) goto error_return; - } xlog_trace_loggrant(log, tic, "xlog_regrant_write_log_space: wake 2"); - xlog_grant_push_ail(log->l_mp, need_bytes); - spin_lock(&log->l_grant_lock); goto redo; } else if (tic->t_flags & XLOG_TIC_IN_Q) xlog_del_ticketq(&log->l_write_headq, tic); -- 1.6.2 From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:47: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.9 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 n2FBlIHB008380 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:47:38 -0500 X-ASG-Debug-ID: 1237117614-6d2f006b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D00A419A0E1 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id Q9wkNqzvwueMpbR2 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44231941-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:53 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006n8-84 for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/6] [XFS] introduce a AG inode tree walker Subject: [PATCH 0/6] [XFS] introduce a AG inode tree walker Date: Sun, 15 Mar 2009 22:46:37 +1100 Message-Id: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237117616 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3415 1.0000 -0.1833 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.18 X-Barracuda-Spam-Status: No, SCORE=-0.18 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.20397 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 This series splits up the sync and reclaim code into three separate actions. The first is the tree walker, the second is the inode validation and the third is the operation to execute on the inode. This allows us to somewhat abstract the radix tree away from the act of walking the cached inodes and puts in place mechanisms that can be extended for bulk inode cache lookups. This also splits the inode writeback into separate data and metadata sync operations and optimises them a little...... From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:47: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.9 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 n2FBlIoQ008379 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:47:38 -0500 X-ASG-Debug-ID: 1237117614-6d3100650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B99E419A0DE for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id ygvAPB6UxrxtD87e for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58261949-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:53 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nN-Od for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 4/6] [XFS] Factor out inode validation for reclaim Subject: [PATCH 4/6] [XFS] Factor out inode validation for reclaim Date: Sun, 15 Mar 2009 22:46:41 +1100 Message-Id: <1237117603-26071-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237117616 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.20397 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 Separate the validation of inodes found by the radix tree walk from the radix tree lookup. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 18 ++++++++++++++++-- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index a83438a..1fa29de 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -711,6 +711,18 @@ xfs_inode_clear_reclaim_tag( xfs_put_perag(mp, pag); } +static int +xfs_reclaim_inode_valid( + xfs_mount_t *mp, + xfs_inode_t *ip) +{ + ASSERT(xfs_iflags_test(ip, (XFS_IRECLAIMABLE|XFS_IRECLAIM))); + + /* ignore if already under reclaim */ + if (xfs_iflags_test(ip, XFS_IRECLAIM)) + return -ENOENT; + return 0; +} STATIC void xfs_reclaim_inodes_ag( @@ -729,6 +741,8 @@ restart: first_index = 0; skipped = 0; do { + int error; + /* * use a gang lookup to find the next inode in the tree * as the tree is sparse and a gang lookup walks to find @@ -756,8 +770,8 @@ restart: break; } - /* ignore if already under reclaim */ - if (xfs_iflags_test(ip, XFS_IRECLAIM)) { + error = xfs_reclaim_inode_valid(mp, ip); + if (error) { read_unlock(&pag->pag_ici_lock); continue; } -- 1.6.2 From SRS0+K6qf+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:47: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.9 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 n2FBlI94008381 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:47:38 -0500 X-ASG-Debug-ID: 1237117615-6d2b006e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB9C619A0E2 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from mail.internode.on.net (bld-mail08.adl2.internode.on.net [203.16.214.72]) by cuda.sgi.com with ESMTP id QEermwpQRRQgzHRF for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 44231942-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nR-SV for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 5/6] [XFS] Remove unused parameter from xfs_reclaim_inodes Subject: [PATCH 5/6] [XFS] Remove unused parameter from xfs_reclaim_inodes Date: Sun, 15 Mar 2009 22:46:42 +1100 Message-Id: <1237117603-26071-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail08.adl2.internode.on.net[203.16.214.72] X-Barracuda-Start-Time: 1237117616 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.20397 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 The noblock parameter of xfs_reclaim_inodes() is only ever set to zero. Remove it and all the conditional code that is never executed. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 23 ++++------------------- fs/xfs/linux-2.6/xfs_sync.h | 2 +- fs/xfs/xfs_mount.c | 2 +- 3 files changed, 6 insertions(+), 21 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 1fa29de..f9c2a56 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -398,7 +398,7 @@ xfs_quiesce_fs( int count = 0, pincount; xfs_flush_buftarg(mp->m_ddev_targp, 0); - xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_DELWRI_ELSE_ASYNC); + xfs_reclaim_inodes(mp, XFS_IFLUSH_DELWRI_ELSE_ASYNC); /* * This loop must run at least twice. The first instance of the loop @@ -522,7 +522,7 @@ xfs_sync_worker( if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE); - xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_DELWRI_ELSE_ASYNC); + xfs_reclaim_inodes(mp, XFS_IFLUSH_DELWRI_ELSE_ASYNC); /* dgc: errors ignored here */ error = XFS_QM_DQSYNC(mp, SYNC_BDFLUSH); error = xfs_sync_fsdata(mp, SYNC_BDFLUSH); @@ -728,7 +728,6 @@ STATIC void xfs_reclaim_inodes_ag( xfs_mount_t *mp, int ag, - int noblock, int mode) { xfs_inode_t *ip = NULL; @@ -775,26 +774,13 @@ restart: read_unlock(&pag->pag_ici_lock); continue; } - - if (noblock) { - if (!xfs_ilock_nowait(ip, XFS_ILOCK_EXCL)) { - read_unlock(&pag->pag_ici_lock); - continue; - } - if (xfs_ipincount(ip) || - !xfs_iflock_nowait(ip)) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - read_unlock(&pag->pag_ici_lock); - continue; - } - } read_unlock(&pag->pag_ici_lock); /* * hmmm - this is an inode already in reclaim. Do * we even bother catching it here? */ - if (xfs_reclaim_inode(ip, noblock, mode)) + if (xfs_reclaim_inode(ip, 0, mode)) skipped++; } while (nr_found); @@ -809,7 +795,6 @@ restart: int xfs_reclaim_inodes( xfs_mount_t *mp, - int noblock, int mode) { int i; @@ -817,7 +802,7 @@ xfs_reclaim_inodes( for (i = 0; i < mp->m_sb.sb_agcount; i++) { if (!mp->m_perag[i].pag_ici_init) continue; - xfs_reclaim_inodes_ag(mp, i, noblock, mode); + xfs_reclaim_inodes_ag(mp, i, mode); } return 0; } diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index 308d5bf..d7b2b5f 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -48,7 +48,7 @@ void xfs_quiesce_attr(struct xfs_mount *mp); void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); -int xfs_reclaim_inodes(struct xfs_mount *mp, int noblock, int mode); +int xfs_reclaim_inodes(struct xfs_mount *mp, int mode); void xfs_inode_set_reclaim_tag(struct xfs_inode *ip); void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip); diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 664961e..30918da 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -1235,7 +1235,7 @@ xfs_unmountfs( * need to force the log first. */ xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); - xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_ASYNC); + xfs_reclaim_inodes(mp, XFS_IFLUSH_ASYNC); XFS_QM_DQPURGEALL(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); -- 1.6.2 From SRS0+Ah5V+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:47: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.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 n2FBlIVi008382 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:47:40 -0500 X-ASG-Debug-ID: 1237117615-735900ac0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2574C1C4395B for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from mail.internode.on.net (bld-mail11.adl2.internode.on.net [203.16.214.75]) by cuda.sgi.com with ESMTP id JGpZ7xW4ujrdGCRy for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:46:55 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 46133987-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nJ-K7 for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/6] [XFS] Factor out inode validation for sync Subject: [PATCH 3/6] [XFS] Factor out inode validation for sync Date: Sun, 15 Mar 2009 22:46:40 +1100 Message-Id: <1237117603-26071-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail11.adl2.internode.on.net[203.16.214.75] X-Barracuda-Start-Time: 1237117617 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.20397 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 Separate the validation of inodes found by the radix tree walk from the radix tree lookup. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 56 ++++++++++++++++++++++++++---------------- 1 files changed, 35 insertions(+), 21 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index b3d4f7a..a83438a 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -120,6 +120,37 @@ out: return error; } +int +xfs_sync_inode_valid( + xfs_mount_t *mp, + xfs_inode_t *ip) +{ + struct inode *inode; + int error; + + /* nothing to sync during shutdown */ + if (XFS_FORCED_SHUTDOWN(mp)) + return EFSCORRUPTED; + + /* + * If we can't get a reference on the inode, it must be in reclaim. + * Leave it for the reclaim code to flush. Also avoid inodes that + * haven't been fully initialised. + */ + error = ENOENT; + inode = VFS_I(ip); + if (!igrab(inode)) + goto error; + if (is_bad_inode(inode) || + xfs_iflags_test(ip, XFS_INEW)) + goto rele; + return 0; +rele: + IRELE(ip); +error: + return error; +} + /* * Sync all the inodes in the given AG according to the * direction given by the flags. @@ -137,7 +168,6 @@ xfs_sync_inodes_ag( int last_error = 0; do { - struct inode *inode; xfs_inode_t *ip = NULL; /* @@ -166,27 +196,11 @@ xfs_sync_inodes_ag( break; } - /* nothing to sync during shutdown */ - if (XFS_FORCED_SHUTDOWN(mp)) { + error = xfs_sync_inode_valid(mp, ip); + if (error) { read_unlock(&pag->pag_ici_lock); - return 0; - } - - /* - * If we can't get a reference on the inode, it must be - * in reclaim. Leave it for the reclaim code to flush. - */ - inode = VFS_I(ip); - if (!igrab(inode)) { - read_unlock(&pag->pag_ici_lock); - continue; - } - read_unlock(&pag->pag_ici_lock); - - /* avoid new or bad inodes */ - if (is_bad_inode(inode) || - xfs_iflags_test(ip, XFS_INEW)) { - IRELE(ip); + if (error == EFSCORRUPTED) + return 0; continue; } -- 1.6.2 From SRS0+WOLF+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:48:33 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,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 n2FBmDXX008515 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:48:33 -0500 X-ASG-Debug-ID: 1237117669-6d3b00740000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A75D519A0E7 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:47:50 -0700 (PDT) Received: from mail.internode.on.net (bld-mail09.adl2.internode.on.net [203.16.214.73]) by cuda.sgi.com with ESMTP id RdwDfOizHsrKyqtl for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:47:50 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 58261159-1927428 for multiple; Sun, 15 Mar 2009 22:01:58 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioZH-0006ic-Rj; Sun, 15 Mar 2009 22:31:47 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com Cc: mpatocka@redhat.com X-ASG-Orig-Subj: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Subject: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Date: Sun, 15 Mar 2009 22:31:44 +1100 Message-Id: <1237116707-25793-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237116707-25793-1-git-send-email-david@fromorbit.com> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail09.adl2.internode.on.net[203.16.214.73] X-Barracuda-Start-Time: 1237117671 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.20397 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 When we are writing to a single file and hit ENOSPC, we trigger a background flush of the inode and try again. Because we hold page locks and the iolock, the flush won't proceed until after we release these locks. This occurs once we've given up and ENOSPC has been reported. Hence if this one is the only dirty inode in the system, we'll get an ENOSPC prematurely. To fix this, remove the async flush from the allocation routines and move it to the top of the write path where we can do a synchronous flush and retry the write again. Only retry once as a second ENOSPC indicates that we really are ENOSPC. This avoids a page cache deadlock when trying to do this flush synchronously in the allocation layer that was identified by Mikulas Patocka. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_lrw.c | 18 +++++++++++++++++- fs/xfs/linux-2.6/xfs_sync.c | 25 ------------------------- fs/xfs/linux-2.6/xfs_sync.h | 1 - fs/xfs/xfs_iomap.c | 2 +- 4 files changed, 18 insertions(+), 28 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_lrw.c b/fs/xfs/linux-2.6/xfs_lrw.c index 7e90daa..9142192 100644 --- a/fs/xfs/linux-2.6/xfs_lrw.c +++ b/fs/xfs/linux-2.6/xfs_lrw.c @@ -751,10 +751,26 @@ start: goto relock; } } else { + int enospc = 0; + ssize_t ret2 = 0; + +write_retry: xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, *offset, ioflags); - ret = generic_file_buffered_write(iocb, iovp, segs, + ret2 = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); + /* + * if we just got an ENOSPC, flush the inode now we + * aren't holding any page locks and retry *once* + */ + if (ret2 == -ENOSPC && !enospc) { + error = xfs_flush_pages(xip, 0, -1, 0, FI_NONE); + if (error) + goto out_unlock_internal; + enospc = 1; + goto write_retry; + } + ret = ret2; } current->backing_dev_info = NULL; diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 88caafc..73cf8dc 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -426,31 +426,6 @@ xfs_syncd_queue_work( * heads, looking about for more room... */ STATIC void -xfs_flush_inode_work( - struct xfs_mount *mp, - void *arg) -{ - struct inode *inode = arg; - filemap_flush(inode->i_mapping); - iput(inode); -} - -void -xfs_flush_inode( - xfs_inode_t *ip) -{ - struct inode *inode = VFS_I(ip); - - igrab(inode); - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work); - delay(msecs_to_jiffies(500)); -} - -/* - * This is the "bigger hammer" version of xfs_flush_inode_work... - * (IOW, "If at first you don't succeed, use a Bigger Hammer"). - */ -STATIC void xfs_flush_inodes_work( struct xfs_mount *mp, void *arg) diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index ec95e26..6e83a35 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -44,7 +44,6 @@ int xfs_sync_fsdata(struct xfs_mount *mp, int flags); int xfs_quiesce_data(struct xfs_mount *mp); void xfs_quiesce_attr(struct xfs_mount *mp); -void xfs_flush_inode(struct xfs_inode *ip); void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 8b97d82..7b8b170 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -347,7 +347,7 @@ xfs_flush_space( case 0: if (ip->i_delayed_blks) { xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_flush_inode(ip); + delay(1); xfs_ilock(ip, XFS_ILOCK_EXCL); *fsynced = 1; } else { -- 1.6.2 From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 06:57: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.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 n2FBv5V2009208 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 06:57:25 -0500 X-ASG-Debug-ID: 1237118201-0e81008b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9EF521C437E1 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:56:42 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id hc0F0FPGxfvHvTlb for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 04:56:42 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43730838-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:10:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Liohv-0006kw-PH for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:40:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/2] Fix a couple of random hangs. Subject: [PATCH 0/2] Fix a couple of random hangs. Date: Sun, 15 Mar 2009 22:40:41 +1100 Message-Id: <1237117243-25940-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237118203 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0695 1.0000 -1.5782 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.58 X-Barracuda-Spam-Status: No, SCORE=-1.58 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.20399 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 The first patch fixes a low memory hang where I/O completion processing triggers memory reclaim which hangs waiting for I/O completion. The trigger is unwritten extent conversion blocking completion of normal writes. The second fixes a log hang which results from excessive load; we update the push target after we go to sleep so if we are unlucky enough not to have a current push target far enough advanced we'll hang. From felixb@oss.sgi.com Sun Mar 15 08:15:35 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 n2FDFZgb013355 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:15:35 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2FDFUha013322; Sun, 15 Mar 2009 08:15:30 -0500 Date: Sun, 15 Mar 2009 08:15:30 -0500 Message-Id: <200903151315.n2FDFUha013322@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-13883-gda5309c X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: f3697bc314e912599f422cc5c6e53c7382c0aeb2 X-Git-Newrev: da5309cd28ffda6ed8a4147bd14f1e4fbbd6503d 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 da5309c Fix xfs debug build breakage by pushing xfs_error.h after from f3697bc314e912599f422cc5c6e53c7382c0aeb2 (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 da5309cd28ffda6ed8a4147bd14f1e4fbbd6503d Author: Felix Blyakher <felixb@sgi.com> Date: Thu Mar 12 09:33:37 2009 -0500 Fix xfs debug build breakage by pushing xfs_error.h after xfs_mount.h, which it depends on. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Alex Elder <aelder@sgi.com> Signed-off-by: Felix Blyakher <felixb@sgi.com> ----------------------------------------------------------------------- Summary of changes: fs/xfs/support/debug.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- XFS development tree From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 09:08: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.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 n2FE83OG015745 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 09:08:23 -0500 X-ASG-Debug-ID: 1237126039-735602b10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DF1751C43AAE for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 07:07:19 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id vSCACkWcA4z5Y97H for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 07:07:19 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43728152-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:19:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinuX-0004nl-Fn for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:49:41 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/3] [XFSQA] Optimisations and ENOSPC tests Subject: [PATCH 0/3] [XFSQA] Optimisations and ENOSPC tests Date: Sun, 15 Mar 2009 21:49:38 +1100 Message-Id: <1237114181-18431-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237126061 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3884 1.0000 -0.0309 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.03 X-Barracuda-Spam-Status: No, SCORE=-0.03 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.20407 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 The first patch reduces the number of forks required by some qa tests by using shell builtins. Tests run faster on UML if they fork less. The other two patches introduce tests that trip over spurious ENOSPC errors. A followup patch series will fix these test failures. From pg_mh@sabi.co.UK Sun Mar 15 09:28:33 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 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 n2FESCXX016873 for <xfs@OSS.SGI.com>; Sun, 15 Mar 2009 09:28:32 -0500 X-ASG-Debug-ID: 1237127244-6d52030e0000-ps1ADW X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ty.sabi.co.UK (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5A11919A3B2 for <xfs@OSS.SGI.com>; Sun, 15 Mar 2009 07:27:24 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by cuda.sgi.com with ESMTP id 3okBKNFRvUw3BCSd for <xfs@OSS.SGI.com>; Sun, 15 Mar 2009 07:27:24 -0700 (PDT) Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.uk) by ty.sabi.co.UK with esmtp(Exim 4.68 #1) id 1LirIZ-0006le-Ah for <xfs@OSS.SGI.com>; Sun, 15 Mar 2009 14:26:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18877.4130.99779.929416@tree.ty.sabi.co.uk> Date: Sun, 15 Mar 2009 14:26:42 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H<GG"+i\3#fp@@EeWZWBv;]LA5n1pS2VO%Vv[yH?kY'lEWr30WfIU?%>&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f><W}Ck9%2?H"AEM)+9<@D;3Kv=^?4$1/+#Qs:-aSsBTUS]iJ$6 Precedence: air-mail To: Linux XFS <xfs@OSS.SGI.com> X-ASG-Orig-Subj: Re: LWN article: ext4 and data loss Subject: Re: LWN article: ext4 and data loss In-Reply-To: <200903142042.51574.Martin@lichtvoll.de> References: <200903121239.35442@zmi.at> <200903121514.12732.Martin@lichtvoll.de> <49B92423.4020708@sandeen.net> <200903142042.51574.Martin@lichtvoll.de> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xf2@xf2.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Barracuda-Connect: 82-69-39-138.dsl.in-addr.zen.co.uk[82.69.39.138] X-Barracuda-Start-Time: 1237127266 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2180 1.0000 -0.7343 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.63 X-Barracuda-Spam-Status: No, SCORE=-0.63 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.20409 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 [ ... usual misunderstanding about caching and transactions ... ] >>>> 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, >> 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. > Well 2.6.28 and 2.6.27.7. See > http://oss.sgi.com/archives/xfs/2008-12/msg00540.html >>> [ ... ] 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. This discussion is partially misguided, but then how many people study storage system semantics... The goal is to do atomic transactions: within a transaction there are no guarantees, but at the end of transaction things get stored permanently. Unfortunately as described 'ext3' has historically done ''rolling'' auto-saving, so many people and application developers have not appreciated the need for transaction semantics (common attitude, for example how many programmers for example check the return code of 'close'?). Now under Linux and POSIX it is essentially impossible to do atomic, persistent transactions, because: * 'fsync' does NOT guarantee persistency. Only that *RAM* buffers are flushed; therefore host adapter and disk buffers are not required to be flushed. * Linux write barriers also only guaranteeq ordering and not persistence, and there is a number of misguided people who think that this is how things should be. > Hmmm, okay. So here is: > http://bugs.kde.org/187172 In practice, for systems without caching host adapters, and with 'ext3', most of the time informal ''rolling'' transactions every 5s fool most people/work as if they were right, and as asserted this has lulled developers into thinking that transactions don't matter. Too bad this kills performance and/or reliability on anything else. This is just another example of how much userspace sucks http://lwn.net/Articles/192214/ http://kernelslacker.livejournal.com/81262.html http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/38.pdf Note that in a proper design where 'fsync' would guarantee persistence, like in every transactional systems, lots of small transactions have very sharp performance implications. People who earn a living doing transactional systems therefore spend a great deal of money and effort designing them to perform well despite lots of small transactions, with 15k drives, vast parallel RAID, bettery backed logs, etc. You cannot have all of these: * Reliable transactions. * Fast with lots of small transactions. * With cheap hardware. In the end one must decided whether to follow the Microsoft strategy (f*ck doing the right thing, cultivate bugs that users are relying on) or the UNIX one (try to do the right thing). From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 09:59: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.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 n2FEx4Ak019320 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 09:59:25 -0500 X-ASG-Debug-ID: 1237129121-1dab01290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0AA661C43C44 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 07:58:41 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id nCKFtbZpyLuiYsUu for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 07:58:41 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354575425-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:10:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Liohv-0006ky-SV for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:40:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Subject: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Date: Sun, 15 Mar 2009 22:40:42 +1100 Message-Id: <1237117243-25940-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117243-25940-1-git-send-email-david@fromorbit.com> References: <1237117243-25940-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237129123 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.20411 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 Unwritten extent conversion can recurse back into the filesystem due to memory allocation. Memory reclaim requires I/O completions to be processed to allow the callers to make progress. If the I/O completion workqueue thread is doing the recursion, then we have a deadlock situation. Move unwritten extent completion into it's own workqueue so it doesn't block I/O completions for normal delayed allocation or overwrite data. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_aops.c | 38 +++++++++++++++++++++----------------- fs/xfs/linux-2.6/xfs_aops.h | 1 + fs/xfs/linux-2.6/xfs_buf.c | 9 +++++++++ 3 files changed, 31 insertions(+), 17 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_aops.c b/fs/xfs/linux-2.6/xfs_aops.c index de3a198..763201d 100644 --- a/fs/xfs/linux-2.6/xfs_aops.c +++ b/fs/xfs/linux-2.6/xfs_aops.c @@ -153,23 +153,6 @@ xfs_find_bdev_for_inode( } /* - * Schedule IO completion handling on a xfsdatad if this was - * the final hold on this ioend. If we are asked to wait, - * flush the workqueue. - */ -STATIC void -xfs_finish_ioend( - xfs_ioend_t *ioend, - int wait) -{ - if (atomic_dec_and_test(&ioend->io_remaining)) { - queue_work(xfsdatad_workqueue, &ioend->io_work); - if (wait) - flush_workqueue(xfsdatad_workqueue); - } -} - -/* * We're now finished for good with this ioend structure. * Update the page state via the associated buffer_heads, * release holds on the inode and bio, and finally free @@ -310,6 +293,27 @@ xfs_end_bio_read( } /* + * Schedule IO completion handling on a xfsdatad if this was + * the final hold on this ioend. If we are asked to wait, + * flush the workqueue. + */ +STATIC void +xfs_finish_ioend( + xfs_ioend_t *ioend, + int wait) +{ + if (atomic_dec_and_test(&ioend->io_remaining)) { + struct workqueue_struct *wq = xfsdatad_workqueue; + if (ioend->io_work.func == xfs_end_bio_unwritten) + wq = xfsconvertd_workqueue; + + queue_work(wq, &ioend->io_work); + if (wait) + flush_workqueue(wq); + } +} + +/* * Allocate and initialise an IO completion structure. * We need to track unwritten extent write completion here initially. * We'll need to extend this for updating the ondisk inode size later diff --git a/fs/xfs/linux-2.6/xfs_aops.h b/fs/xfs/linux-2.6/xfs_aops.h index 1dd5288..221b3e6 100644 --- a/fs/xfs/linux-2.6/xfs_aops.h +++ b/fs/xfs/linux-2.6/xfs_aops.h @@ -19,6 +19,7 @@ #define __XFS_AOPS_H__ extern struct workqueue_struct *xfsdatad_workqueue; +extern struct workqueue_struct *xfsconvertd_workqueue; extern mempool_t *xfs_ioend_pool; /* diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c index aa1016b..e28800a 100644 --- a/fs/xfs/linux-2.6/xfs_buf.c +++ b/fs/xfs/linux-2.6/xfs_buf.c @@ -51,6 +51,7 @@ static struct shrinker xfs_buf_shake = { static struct workqueue_struct *xfslogd_workqueue; struct workqueue_struct *xfsdatad_workqueue; +struct workqueue_struct *xfsconvertd_workqueue; #ifdef XFS_BUF_TRACE void @@ -1775,6 +1776,7 @@ xfs_flush_buftarg( xfs_buf_t *bp, *n; int pincount = 0; + xfs_buf_runall_queues(xfsconvertd_workqueue); xfs_buf_runall_queues(xfsdatad_workqueue); xfs_buf_runall_queues(xfslogd_workqueue); @@ -1831,9 +1833,15 @@ xfs_buf_init(void) if (!xfsdatad_workqueue) goto out_destroy_xfslogd_workqueue; + xfsconvertd_workqueue = create_workqueue("xfsconvertd"); + if (!xfsconvertd_workqueue) + goto out_destroy_xfsdatad_workqueue; + register_shrinker(&xfs_buf_shake); return 0; + out_destroy_xfsdatad_workqueue: + destroy_workqueue(xfsdatad_workqueue); out_destroy_xfslogd_workqueue: destroy_workqueue(xfslogd_workqueue); out_free_buf_zone: @@ -1849,6 +1857,7 @@ void xfs_buf_terminate(void) { unregister_shrinker(&xfs_buf_shake); + destroy_workqueue(xfsconvertd_workqueue); destroy_workqueue(xfsdatad_workqueue); destroy_workqueue(xfslogd_workqueue); kmem_zone_destroy(xfs_buf_zone); -- 1.6.2 From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 10:05: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.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 n2FF4rK2019618 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:05:10 -0500 X-ASG-Debug-ID: 1237129470-683402140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 792051C43C9E for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:04:31 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id EFQhc6olmB01QGlF for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:04:31 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43731177-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:53 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nA-Br for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Subject: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Date: Sun, 15 Mar 2009 22:46:38 +1100 Message-Id: <1237117603-26071-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237129472 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.20411 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 In many cases we only want to sync inode data. Start spliting the inode sync into data sync and inode sync by factoring out the inode data flush. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 54 +++++++++++++++++++++++++++---------------- 1 files changed, 34 insertions(+), 20 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index f7ba766..fd024e2 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -47,6 +47,37 @@ #include <linux/kthread.h> #include <linux/freezer.h> +static int +xfs_sync_inode_data( + struct xfs_inode *ip, + int flags) +{ + struct inode *inode = VFS_I(ip); + int error = 0; + + if (VN_DIRTY(inode)) { + int locked = 0; + if (flags & SYNC_TRYLOCK) { + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) + locked = 1; + } else { + xfs_ilock(ip, XFS_IOLOCK_SHARED); + locked = 1; + } + if (locked) { + error = xfs_flush_pages(ip, 0, -1, + (flags & SYNC_WAIT) ? 0 : XFS_B_ASYNC, + FI_NONE); + xfs_iunlock(ip, XFS_IOLOCK_SHARED); + } + } + + if (flags & SYNC_IOWAIT) + xfs_ioend_wait(ip); + + return error; +} + /* * Sync all the inodes in the given AG according to the * direction given by the flags. @@ -122,27 +153,10 @@ xfs_sync_inodes_ag( * If we have to flush data or wait for I/O completion * we need to hold the iolock. */ - if (flags & SYNC_DELWRI) { - if (VN_DIRTY(inode)) { - if (flags & SYNC_TRYLOCK) { - if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) - lock_flags |= XFS_IOLOCK_SHARED; - } else { - xfs_ilock(ip, XFS_IOLOCK_SHARED); - lock_flags |= XFS_IOLOCK_SHARED; - } - if (lock_flags & XFS_IOLOCK_SHARED) { - error = xfs_flush_pages(ip, 0, -1, - (flags & SYNC_WAIT) ? 0 - : XFS_B_ASYNC, - FI_NONE); - } - } - if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) - xfs_ioend_wait(ip); - } - xfs_ilock(ip, XFS_ILOCK_SHARED); + if (flags & SYNC_DELWRI) + error = xfs_sync_inode_data(ip, flags); + xfs_ilock(ip, XFS_ILOCK_SHARED); if ((flags & SYNC_ATTR) && !xfs_inode_clean(ip)) { if (flags & SYNC_WAIT) { xfs_iflock(ip); -- 1.6.2 From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 10: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.9 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 n2FF4sV9019619 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:05:15 -0500 X-ASG-Debug-ID: 1237129471-6d4c03d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2EB4219A47E for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:04:32 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id OnUDtZFTiBiZYosr for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:04:32 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354575713-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nF-Fy for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:43 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/6] [XFS] Use xfs_inode_flush() in xfs_sync_inodes_ag() Subject: [PATCH 2/6] [XFS] Use xfs_inode_flush() in xfs_sync_inodes_ag() Date: Sun, 15 Mar 2009 22:46:39 +1100 Message-Id: <1237117603-26071-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237129473 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.20411 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 xfs_sync_inodes_ag() effectively open-codes xfs_inode_flush() to do blocking vs non-blocking inode flushing. It doesn't have all the optimisations that xfs_inode_flush() has but does the same thing. Call xfs_inode_flush() instead. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 63 +++++++++++++++++++++++++++++++----------- 1 files changed, 46 insertions(+), 17 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index fd024e2..b3d4f7a 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -43,6 +43,7 @@ #include "xfs_buf_item.h" #include "xfs_inode_item.h" #include "xfs_rw.h" +#include "linux-2.6/xfs_vnode.h" #include <linux/kthread.h> #include <linux/freezer.h> @@ -78,6 +79,47 @@ xfs_sync_inode_data( return error; } +static int +xfs_sync_inode_flush( + struct xfs_inode *ip, + int flags) +{ + int error = 0; + + /* + * Bypass inodes which have already been cleaned by + * the inode flush clustering code inside xfs_iflush + */ + if (xfs_inode_clean(ip)) + return 0; + + /* + * We make this non-blocking if the inode is contended, + * return EAGAIN to indicate to the caller that they + * did not succeed. This prevents the flush path from + * blocking on inodes inside another operation right + * now, they get caught later by xfs_sync. + */ + if (flags & SYNC_WAIT) { + xfs_ilock(ip, XFS_ILOCK_SHARED); + xfs_iflock(ip); + + error = xfs_iflush(ip, XFS_IFLUSH_SYNC); + } else { + if (!xfs_ilock_nowait(ip, XFS_ILOCK_SHARED)) + goto out; + if (xfs_ipincount(ip) || !xfs_iflock_nowait(ip)) + goto out_unlock; + + error = xfs_iflush(ip, XFS_IFLUSH_ASYNC_NOBLOCK); + } + +out_unlock: + xfs_iunlock(ip, XFS_ILOCK_SHARED); +out: + return error; +} + /* * Sync all the inodes in the given AG according to the * direction given by the flags. @@ -97,7 +139,6 @@ xfs_sync_inodes_ag( do { struct inode *inode; xfs_inode_t *ip = NULL; - int lock_flags = XFS_ILOCK_SHARED; /* * use a gang lookup to find the next inode in the tree @@ -156,22 +197,10 @@ xfs_sync_inodes_ag( if (flags & SYNC_DELWRI) error = xfs_sync_inode_data(ip, flags); - xfs_ilock(ip, XFS_ILOCK_SHARED); - if ((flags & SYNC_ATTR) && !xfs_inode_clean(ip)) { - if (flags & SYNC_WAIT) { - xfs_iflock(ip); - if (!xfs_inode_clean(ip)) - error = xfs_iflush(ip, XFS_IFLUSH_SYNC); - else - xfs_ifunlock(ip); - } else if (xfs_iflock_nowait(ip)) { - if (!xfs_inode_clean(ip)) - error = xfs_iflush(ip, XFS_IFLUSH_DELWRI); - else - xfs_ifunlock(ip); - } - } - xfs_iput(ip, lock_flags); + if (flags & SYNC_ATTR) + error = xfs_sync_inode_flush(ip, flags); + + IRELE(ip); if (error) last_error = error; -- 1.6.2 From SRS0+98b5f99703435d99d434+2030+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 15 10:14: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2FFEY67020139 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:14:54 -0500 X-ASG-Debug-ID: 1237130052-68a4016d0000-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 0E54E19A4A3 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:14:12 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id eyz1F0wR2Vz6dNjv for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:14:12 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lis21-0005lG-AO; Sun, 15 Mar 2009 15:13:41 +0000 Date: Sun, 15 Mar 2009 11:13:41 -0400 From: Christoph Hellwig <hch@infradead.org> To: Dave Chinner <david@fromorbit.com> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] [XFS] Fix double free of inode Subject: Re: [PATCH 2/2] [XFS] Fix double free of inode Message-ID: <20090315151340.GA7145@infradead.org> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <1237116342-25701-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116342-25701-3-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1237130053 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 15, 2009 at 10:25:42PM +1100, Dave Chinner wrote: > If we fail to initialise the VFS inode in inode_init_always(), > it will call ->delete_inode internally resulting in the inode being > freed. Hence we need to delay the call to inode_init_always() > until after the XFS inode is sufficient set up to handle a > call to ->delete_inode, and then if that fails do not touch > the inode again at all as it has been freed. Looks good, but the changelog should mention the setting of the I_NEW bit, too. Reviewed-by: Christoph Hellwig <hch@lst.de> I suspect this should go into 2.6.29-stable after some testing, too. From SRS0+98b5f99703435d99d434+2030+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 15 10:16:37 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 n2FFGGBZ020591 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:16:37 -0500 X-ASG-Debug-ID: 1237130153-0e8103830000-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 4D9FA1C43CDF for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:15:53 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RarymU3SQx36uHqo for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 08:15:53 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lis47-0008B9-5A; Sun, 15 Mar 2009 15:15:51 +0000 Date: Sun, 15 Mar 2009 11:15:51 -0400 From: Christoph Hellwig <hch@infradead.org> To: Dave Chinner <david@fromorbit.com> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Subject: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Message-ID: <20090315151546.GB7145@infradead.org> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <1237116342-25701-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116342-25701-2-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1237130153 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 15, 2009 at 10:25:41PM +1100, Dave Chinner wrote: > If the large log sector size feature bit is set in the > superblock by accident (say disk corruption), the then > fields that are now considered valid are not checked on > production kernels. The checks are present as ASSERT > statements so cause a panic on a debug kernel. > > Change this so that the fields are validity checked if > the feature bit is set and abort the log mount if the > fields do not contain valid values. > > Reported-by: Eric Sesterhenn <snakebyte@gmx.de> > Signed-off-by: Dave Chinner <david@fromorbit.com> Looks good to me, but wouldn't be easier to rad if the various sizes in the error messages were reported decimal instead of in hex? Reviewed-by: Christoph Hellwig <hch@lst.de> > } /* xlog_alloc_log */ any maybe remove this comment while you're at it? From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 12:13: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.9 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 n2FHCsWs026236 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 12:13:14 -0500 X-ASG-Debug-ID: 1237137150-29ad01d10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C313F19A1E9 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:12:31 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id 1WBnhwbciKKkFHMv for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:12:31 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43728335-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:22:46 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LinxL-0004rO-MA for xfs@oss.sgi.com; Sun, 15 Mar 2009 21:52:35 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] [XFS] Fix double free of inode Subject: [PATCH 2/2] [XFS] Fix double free of inode Date: Sun, 15 Mar 2009 21:52:35 +1100 Message-Id: <1237114355-18647-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237114355-18647-1-git-send-email-david@fromorbit.com> References: <1237114355-18647-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237137152 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.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20419 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner <dgc@evostor.com> If we fail to initialise the VFS inode in inode_init_always(), it will call ->delete_inode internally resulting in the inode being freed. Hence we need to delay the call to inode_init_always() until after the XFS inode is sufficient set up to handle a call to ->delete_inode, and then if that fails do not touch the inode again at all as it has been freed. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/xfs_iget.c | 23 ++++++++++++++--------- 1 files changed, 14 insertions(+), 9 deletions(-) diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c index 478e587..89b81ee 100644 --- a/fs/xfs/xfs_iget.c +++ b/fs/xfs/xfs_iget.c @@ -69,15 +69,6 @@ xfs_inode_alloc( ASSERT(!spin_is_locked(&ip->i_flags_lock)); ASSERT(completion_done(&ip->i_flush)); - /* - * initialise the VFS inode here to get failures - * out of the way early. - */ - if (!inode_init_always(mp->m_super, VFS_I(ip))) { - kmem_zone_free(xfs_inode_zone, ip); - return NULL; - } - /* initialise the xfs inode */ ip->i_ino = ino; ip->i_mount = mp; @@ -113,6 +104,20 @@ xfs_inode_alloc( #ifdef XFS_DIR2_TRACE ip->i_dir_trace = ktrace_alloc(XFS_DIR2_KTRACE_SIZE, KM_NOFS); #endif + /* + * Now initialise the VFS inode. We do this after the xfs_inode + * initialisation as internal failures will result in ->destroy_inode + * being called and that will pass down through the reclaim path and + * free the XFS inode. This path requires the XFS inode to already be + * initialised. Hence if this call fails, the xfs_inode has already + * been freed and we should not reference it at all in the error + * handling. + */ + if (!inode_init_always(mp->m_super, VFS_I(ip))) + return NULL; + + /* prevent anyone from using this yet */ + VFS_I(ip)->i_state = I_NEW|I_LOCK; return ip; } -- 1.6.2 From SRS0+16YW+8+fromorbit.com=dave@internode.on.net Sun Mar 15 12:46:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 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 n2FHk9ZQ027787 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 12:46:30 -0500 X-ASG-Debug-ID: 1237139125-686802cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 589771C43DEE for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:45:25 -0700 (PDT) Received: from mail.internode.on.net (bld-mail02.adl2.internode.on.net [203.16.214.66]) by cuda.sgi.com with ESMTP id W7Rh1NAEtEUQuFfj for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 10:45:25 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 354574612-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:55:52 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1LioTO-0006h6-B9 for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:25:42 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/2, RESEND] [XFS] a couple of fixes Subject: [PATCH 0/2, RESEND] [XFS] a couple of fixes Date: Sun, 15 Mar 2009 22:25:40 +1100 Message-Id: <1237116342-25701-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 X-Barracuda-Connect: bld-mail02.adl2.internode.on.net[203.16.214.66] X-Barracuda-Start-Time: 1237139148 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4745 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.20421 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 The first fixes a fuzzer log corruption crash, and second is a null pointer dereference I found by inspection. These should now have the correct sign-off on them. From SRS0+Xu2U+8+fromorbit.com=dave@internode.on.net Sun Mar 15 14:08: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.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, J_CHICKENPOX_72 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 n2FJ7x14032114 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 14:08:20 -0500 X-ASG-Debug-ID: 1237144035-05c1013b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4E1BA19ABB0 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 12:07:16 -0700 (PDT) Received: from mail.internode.on.net (bld-mail05.adl2.internode.on.net [203.16.214.69]) by cuda.sgi.com with ESMTP id Y4nHgbi75qZECCMf for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 12:07:16 -0700 (PDT) Received: from destruction.internal (unverified [203.206.165.193]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 43731180-1927428 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:16:54 +1030 (CDT) Received: from dave by destruction.internal with local (Exim 4.69) (envelope-from <dave@destruction>) id 1Lionj-0006nV-WF for xfs@oss.sgi.com; Sun, 15 Mar 2009 22:46:44 +1100 From: Dave Chinner <david@fromorbit.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 6/6] [XFS] introduce a per-ag inode iterator Subject: [PATCH 6/6] [XFS] introduce a per-ag inode iterator Date: Sun, 15 Mar 2009 22:46:43 +1100 Message-Id: <1237117603-26071-7-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.6.2 In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.com> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: bld-mail05.adl2.internode.on.net[203.16.214.69] X-Barracuda-Start-Time: 1237144058 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.20427 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 Given that we walk across the per-ag inode lists so often, it makes sense to introduce an iterator for this. Break the operations on each inode into two operations - a lookup validation step to confirm the inode is good to be used and an execution step that performs the operation on the inode. Convert the sync and reclaim code to use this new iterator. At some point the quota sync needs to be converted as well. Signed-off-by: Dave Chinner <david@fromorbit.com> --- fs/xfs/linux-2.6/xfs_sync.c | 320 ++++++++++++++++++++----------------------- 1 files changed, 149 insertions(+), 171 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index f9c2a56..45dfff9 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -48,6 +48,132 @@ #include <linux/kthread.h> #include <linux/freezer.h> + +STATIC xfs_inode_t * +xfs_inode_ag_lookup( + xfs_mount_t *mp, + xfs_perag_t *pag, + int (*lookup)(xfs_mount_t *mp, xfs_inode_t *ip), + uint32_t *first_index, + int tag) +{ + int nr_found; + xfs_inode_t *ip; + int error = -ENOENT; + + /* + * use a gang lookup to find the next inode in the tree + * as the tree is sparse and a gang lookup walks to find + * the number of objects requested. + */ + read_lock(&pag->pag_ici_lock); + if (tag == -1) { + nr_found = radix_tree_gang_lookup(&pag->pag_ici_root, + (void**)&ip, *first_index, 1); + } else { + nr_found = radix_tree_gang_lookup_tag(&pag->pag_ici_root, + (void**)&ip, *first_index, 1, tag); + } + if (!nr_found) + goto unlock; + + /* + * Update the index for the next lookup. Catch overflows + * into the next AG range which can occur if we have inodes + * in the last block of the AG and we are currently + * pointing to the last inode. + */ + *first_index = XFS_INO_TO_AGINO(mp, ip->i_ino + 1); + if (*first_index < XFS_INO_TO_AGINO(mp, ip->i_ino)) + goto unlock; + + + error = lookup(mp, ip); + read_unlock(&pag->pag_ici_lock); + if (error) + return ERR_PTR(error); + return ip; + +unlock: + read_unlock(&pag->pag_ici_lock); + return NULL; +} + +STATIC int +xfs_inode_ag_walk( + xfs_mount_t *mp, + xfs_agnumber_t ag, + int (*lookup)(xfs_mount_t *mp, xfs_inode_t *ip), + int (*execute)(xfs_inode_t *ip, int flags), + int flags, + int tag) +{ + xfs_perag_t *pag = &mp->m_perag[ag]; + uint32_t first_index; + int last_error = 0; + int skipped; + +restart: + skipped = 0; + first_index = 0; + do { + int error = 0; + xfs_inode_t *ip; + + ip = xfs_inode_ag_lookup(mp, pag, lookup, &first_index, tag); + if (!ip) + break; + if (IS_ERR(ip)) + continue; + + error = execute(ip, flags); + if (error == EAGAIN) { + skipped++; + continue; + } + if (error) + last_error = error; + /* + * bail out if the filesystem is corrupted. + */ + if (error == EFSCORRUPTED) + break; + + } while (1); + + if (skipped) { + delay(1); + goto restart; + } + + xfs_put_perag(mp, pag); + return last_error; +} + +STATIC int +xfs_inode_ag_iterator( + xfs_mount_t *mp, + int (*lookup)(xfs_mount_t *mp, xfs_inode_t *ip), + int (*execute)(xfs_inode_t *ip, int flags), + int flags, + int tag) +{ + int error = 0; + int last_error = 0; + xfs_agnumber_t ag; + + for (ag = 0; ag < mp->m_sb.sb_agcount; ag++) { + if (!mp->m_perag[ag].pag_ici_init) + continue; + error = xfs_inode_ag_walk(mp, ag, lookup, execute, flags, tag); + if (error) + last_error = error; + if (error == EFSCORRUPTED) + break; + } + return XFS_ERROR(last_error); +} + static int xfs_sync_inode_data( struct xfs_inode *ip, @@ -76,6 +202,7 @@ xfs_sync_inode_data( if (flags & SYNC_IOWAIT) xfs_ioend_wait(ip); + IRELE(ip); return error; } @@ -91,7 +218,7 @@ xfs_sync_inode_flush( * the inode flush clustering code inside xfs_iflush */ if (xfs_inode_clean(ip)) - return 0; + goto out_rele; /* * We make this non-blocking if the inode is contended, @@ -107,7 +234,7 @@ xfs_sync_inode_flush( error = xfs_iflush(ip, XFS_IFLUSH_SYNC); } else { if (!xfs_ilock_nowait(ip, XFS_ILOCK_SHARED)) - goto out; + goto out_rele; if (xfs_ipincount(ip) || !xfs_iflock_nowait(ip)) goto out_unlock; @@ -116,7 +243,8 @@ xfs_sync_inode_flush( out_unlock: xfs_iunlock(ip, XFS_ILOCK_SHARED); -out: +out_rele: + IRELE(ip); return error; } @@ -151,115 +279,32 @@ error: return error; } -/* - * Sync all the inodes in the given AG according to the - * direction given by the flags. - */ -STATIC int -xfs_sync_inodes_ag( - xfs_mount_t *mp, - int ag, - int flags) -{ - xfs_perag_t *pag = &mp->m_perag[ag]; - int nr_found; - uint32_t first_index = 0; - int error = 0; - int last_error = 0; - - do { - xfs_inode_t *ip = NULL; - - /* - * use a gang lookup to find the next inode in the tree - * as the tree is sparse and a gang lookup walks to find - * the number of objects requested. - */ - read_lock(&pag->pag_ici_lock); - nr_found = radix_tree_gang_lookup(&pag->pag_ici_root, - (void**)&ip, first_index, 1); - - if (!nr_found) { - read_unlock(&pag->pag_ici_lock); - break; - } - - /* - * Update the index for the next lookup. Catch overflows - * into the next AG range which can occur if we have inodes - * in the last block of the AG and we are currently - * pointing to the last inode. - */ - first_index = XFS_INO_TO_AGINO(mp, ip->i_ino + 1); - if (first_index < XFS_INO_TO_AGINO(mp, ip->i_ino)) { - read_unlock(&pag->pag_ici_lock); - break; - } - - error = xfs_sync_inode_valid(mp, ip); - if (error) { - read_unlock(&pag->pag_ici_lock); - if (error == EFSCORRUPTED) - return 0; - continue; - } - - /* - * If we have to flush data or wait for I/O completion - * we need to hold the iolock. - */ - if (flags & SYNC_DELWRI) - error = xfs_sync_inode_data(ip, flags); - - if (flags & SYNC_ATTR) - error = xfs_sync_inode_flush(ip, flags); - - IRELE(ip); - - if (error) - last_error = error; - /* - * bail out if the filesystem is corrupted. - */ - if (error == EFSCORRUPTED) - return XFS_ERROR(error); - - } while (nr_found); - - return last_error; -} - int xfs_sync_inodes( xfs_mount_t *mp, int flags) { - int error; - int last_error; - int i; + int error = 0; int lflags = XFS_LOG_FORCE; if (mp->m_flags & XFS_MOUNT_RDONLY) return 0; - error = 0; - last_error = 0; if (flags & SYNC_WAIT) lflags |= XFS_LOG_SYNC; - for (i = 0; i < mp->m_sb.sb_agcount; i++) { - if (!mp->m_perag[i].pag_ici_init) - continue; - error = xfs_sync_inodes_ag(mp, i, flags); - if (error) - last_error = error; - if (error == EFSCORRUPTED) - break; - } if (flags & SYNC_DELWRI) + error = xfs_inode_ag_iterator(mp, xfs_sync_inode_valid, + xfs_sync_inode_data, flags, -1); + + if (flags & SYNC_ATTR) + error = xfs_inode_ag_iterator(mp, xfs_sync_inode_valid, + xfs_sync_inode_flush, flags, -1); + + if (!error && (flags & SYNC_DELWRI)) xfs_log_force(mp, 0, lflags); - return XFS_ERROR(last_error); + return XFS_ERROR(error); } STATIC int @@ -724,72 +769,12 @@ xfs_reclaim_inode_valid( return 0; } -STATIC void -xfs_reclaim_inodes_ag( - xfs_mount_t *mp, - int ag, - int mode) +static int +xfs_reclaim_inode_now( + xfs_inode_t *ip, + int flags) { - xfs_inode_t *ip = NULL; - xfs_perag_t *pag = &mp->m_perag[ag]; - int nr_found; - uint32_t first_index; - int skipped; - -restart: - first_index = 0; - skipped = 0; - do { - int error; - - /* - * use a gang lookup to find the next inode in the tree - * as the tree is sparse and a gang lookup walks to find - * the number of objects requested. - */ - read_lock(&pag->pag_ici_lock); - nr_found = radix_tree_gang_lookup_tag(&pag->pag_ici_root, - (void**)&ip, first_index, 1, - XFS_ICI_RECLAIM_TAG); - - if (!nr_found) { - read_unlock(&pag->pag_ici_lock); - break; - } - - /* - * Update the index for the next lookup. Catch overflows - * into the next AG range which can occur if we have inodes - * in the last block of the AG and we are currently - * pointing to the last inode. - */ - first_index = XFS_INO_TO_AGINO(mp, ip->i_ino + 1); - if (first_index < XFS_INO_TO_AGINO(mp, ip->i_ino)) { - read_unlock(&pag->pag_ici_lock); - break; - } - - error = xfs_reclaim_inode_valid(mp, ip); - if (error) { - read_unlock(&pag->pag_ici_lock); - continue; - } - read_unlock(&pag->pag_ici_lock); - - /* - * hmmm - this is an inode already in reclaim. Do - * we even bother catching it here? - */ - if (xfs_reclaim_inode(ip, 0, mode)) - skipped++; - } while (nr_found); - - if (skipped) { - delay(1); - goto restart; - } - return; - + return xfs_reclaim_inode(ip, 0, flags); } int @@ -797,14 +782,7 @@ xfs_reclaim_inodes( xfs_mount_t *mp, int mode) { - int i; - - for (i = 0; i < mp->m_sb.sb_agcount; i++) { - if (!mp->m_perag[i].pag_ici_init) - continue; - xfs_reclaim_inodes_ag(mp, i, mode); - } - return 0; + return xfs_inode_ag_iterator(mp, xfs_reclaim_inode_valid, + xfs_reclaim_inode_now, mode, + XFS_ICI_RECLAIM_TAG); } - - -- 1.6.2 From david@fromorbit.com Sun Mar 15 17:21:32 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 n2FMLBmE042296 for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 17:21:31 -0500 X-ASG-Debug-ID: 1237155646-7f0c014a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8B0781C448AE for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 15:20:48 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id mlO7bf1sMpNR8IfF for <xfs@oss.sgi.com>; Sun, 15 Mar 2009 15:20:48 -0700 (PDT) Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 08:49:35 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from <david@fromorbit.com>) id 1Liyfx-0002hj-V2; Mon, 16 Mar 2009 09:19:21 +1100 Date: Mon, 16 Mar 2009 09:19:21 +1100 From: Dave Chinner <david@fromorbit.com> To: Denys Fedoryschenko <denys@visp.net.lb> Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: XFS lock warning, 2.6.29-rc8 Subject: Re: XFS lock warning, 2.6.29-rc8 Message-ID: <20090315221921.GY26138@disturbed> Mail-Followup-To: Denys Fedoryschenko <denys@visp.net.lb>, xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <200903151459.01320.denys@visp.net.lb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903151459.01320.denys@visp.net.lb> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237155649 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.20441 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 [ changed cc to xfs@oss.sgi.com. linux-xfs@vger.kernel.org does not exist. ] On Sun, Mar 15, 2009 at 02:59:01PM +0200, Denys Fedoryschenko wrote: > hi > > Here is what i got suddently. But seems everything is working. > If any other information required, please let me know. Known issue. > [39993.560234] the existing dependency chain (in reverse order) is: > [39993.560236] > [39993.560236] -> #1 (&mm->mmap_sem){----}: > [39993.560240] [<ffffffff8105b9fc>] __lock_acquire+0x12b0/0x161a > [39993.560244] [<ffffffff8105bdbb>] lock_acquire+0x55/0x71 > [39993.560247] [<ffffffff813fc2a5>] down_read+0x34/0x41 > [39993.560252] [<ffffffff813ffbfe>] do_page_fault+0x3fa/0x848 > [39993.560256] [<ffffffff813fda2f>] page_fault+0x1f/0x30 > [39993.560258] [<ffffffff8107e13d>] generic_file_aio_read+0x35f/0x5da > [39993.560268] [<ffffffff811650d8>] xfs_read+0x17d/0x1f5 > [39993.560272] [<ffffffff81161646>] xfs_file_aio_read+0x5f/0x61 > [39993.560275] [<ffffffff810a88ff>] do_sync_read+0xe7/0x12d > [39993.560284] [<ffffffff810a928c>] vfs_read+0xab/0x134 > [39993.560287] [<ffffffff810a93d9>] sys_read+0x47/0x6f > [39993.560289] [<ffffffff8100c0db>] system_call_fastpath+0x16/0x1b > [39993.560293] [<ffffffffffffffff>] 0xffffffffffffffff > [39993.560302] > [39993.560302] -> #0 (&(&ip->i_iolock)->mr_lock){----}: > [39993.560306] [<ffffffff8105b6cb>] __lock_acquire+0xf7f/0x161a > [39993.560309] [<ffffffff8105bdbb>] lock_acquire+0x55/0x71 > [39993.560312] [<ffffffff8104ebde>] down_write_nested+0x37/0x46 > [39993.560316] [<ffffffff811426aa>] xfs_ilock+0x27/0x79 > [39993.560318] [<ffffffff8115b40e>] xfs_inactive+0x14d/0x411 > [39993.560322] [<ffffffff8116552f>] xfs_fs_clear_inode+0x83/0x85 > [39993.560325] [<ffffffff810ba8f7>] clear_inode+0x8a/0xe3 > [39993.560329] [<ffffffff810bb044>] generic_delete_inode+0xf8/0x173 > [39993.560332] [<ffffffff810bb0d6>] generic_drop_inode+0x17/0x1d5 > [39993.560335] [<ffffffff810ba1c7>] iput+0x61/0x65 > [39993.560338] [<ffffffff810b7554>] dentry_iput+0xa9/0xc1 > [39993.560341] [<ffffffff810b7651>] d_kill+0x40/0x60 > [39993.560344] [<ffffffff810b942d>] dput+0x141/0x14e > [39993.560347] [<ffffffff810a9a85>] __fput+0x173/0x198 > [39993.560350] [<ffffffff810a9ac2>] fput+0x18/0x1a > [39993.560353] [<ffffffff8109411e>] remove_vma+0x3e/0x63 > [39993.560355] [<ffffffff8109503c>] do_munmap+0x2e9/0x30b > [39993.560358] [<ffffffff8109509e>] sys_munmap+0x40/0x59 > [39993.560361] [<ffffffff8100c0db>] system_call_fastpath+0x16/0x1b > [39993.560363] [<ffffffffffffffff>] 0xffffffffffffffff This is a VM problem where it calls fput() with the mmap_sem() held in remove_vma(). It makes the incorrect assumption that filesystems will never use the same lock in the IO path and the inode release path. This can deadlock if you are really unlucky. Cheers, Dave. -- Dave Chinner david@fromorbit.com From campaign@online.intelestream.net Sun Mar 15 23:54:51 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=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 n2G4sUDK064728 for <linux-xfs@oss.sgi.com>; Sun, 15 Mar 2009 23:54:50 -0500 X-ASG-Debug-ID: 1237179227-0226032c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.opendataonline.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A94B19B7A2 for <linux-xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:53:47 -0700 (PDT) Received: from mail.opendataonline.com (mail.opendataonline.com [208.71.148.187]) by cuda.sgi.com with ESMTP id r1pus2HMy4skncYZ for <linux-xfs@oss.sgi.com>; Sun, 15 Mar 2009 21:53:47 -0700 (PDT) Received: from online.intelestream.net (localhost [127.0.0.1]) by mail.opendataonline.com (Postfix) with ESMTP id 421A329943E for <linux-xfs@oss.sgi.com>; Sun, 15 Mar 2009 22:54:01 -0500 (CDT) To: "Sven Hyberts" <linux-xfs@oss.sgi.com> X-ASG-Orig-Subj: Webinar: Learning About CRM Subject: Webinar: Learning About CRM Message-ID: <5b9c1def94af34c8a4437d8df923192c@online.intelestream.net> Date: Thu, 12 Mar 2009 07:05:30 -0500 From: "Matthew Kallas" <matthew.kallas@online.intelestream.net> Reply-To: matthew.kallas@online.intelestream.net MIME-Version: 1.0 X-Mailer-LID: 9,8,8 X-Mailer-SID: 247 X-Mailer-Sent-By: 1 Content-Type: multipart/alternative; charset="UTF-8"; boundary="b1_03f15b6320b1c2dcc1024d54508fc4cf" Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mail.opendataonline.com[208.71.148.187] X-Barracuda-Start-Time: 1237179248 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5004 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.20467 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 --b1_03f15b6320b1c2dcc1024d54508fc4cf Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Your invitation to join our webinar: Everything you always wanted to know about CRM (But Were Afraid to Ask) Thu, Mar 19, 2009 No cost to attendees, but space is limited. Sign up here: http://online.intelestream.net/em/link.php?M=451659&N=247&L=52&F=T Intelestream's Chief Operating Officer Richard Baldwin will address five key aspects of CRM with which all businesses should be familiar: - Defining CRM and why businesses use it - CRM processes involving sales, marketing, customer support, e-commerce, and reporting - Implementation best practices and encouraging user adoption - Customizations, maintenance, and enhancement - Overview of the CRM marketplace: matching specific business needs with the right CRM platform There will be a question and answer session focusing on the specific business case scenarios of attendees. More about Intelestream To learn more about Intelestream, go to www.intelestream.net Click this link to unsubscribe: http://online.intelestream.net/em/unsubscribe.php?M=451659&C=e6d33ee2b44a5455050561c37045ba98&L=8&N=247 --b1_03f15b6320b1c2dcc1024d54508fc4cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html xmlns="http://www.w3.org/1999/xhtml"><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Email


Your invitation to join our webinar:

Everything you always wanted to know about CRM
(But Were Afraid to Ask)

Thursday, March 19
No cost to attendees, but space is limited. Sign up by clicking here.
  
Intelestream's Chief Operating Officer Richard Baldwin will address five key aspects of CRM with which all businesses should be familiar:

- Defining CRM and why businesses use it
- CRM processes involving sales, marketing, customer support, e-commerce, and reporting
- Implementation best practices and encouraging user adoption
- Customizations, maintenance, and enhancement
- Overview of the CRM marketplace: matching specific business needs with the right CRM platform

There will be a question and answer session focusing on the specific business case scenarios of attendees.

More about Intelestream

To learn more about Intelestream, go to www.intelestream.net
 
To unsubscribe, please click here.
Intelestream Inc - Phone: (800) 391.4055 - Fax: (312) 244.3765
Address: 27 North Wacker Drive Suite 370 Chicago IL 60606
 
--b1_03f15b6320b1c2dcc1024d54508fc4cf-- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:23: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.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 n2G6NZVR071788 for ; Mon, 16 Mar 2009 01:23:56 -0500 X-ASG-Debug-ID: 1237184594-313003630000-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 7C16E1C452EF for ; Sun, 15 Mar 2009 23:23:14 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ZXQNHBxKwt6KVoAj for ; Sun, 15 Mar 2009 23:23:14 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6ED-0005cg-On; Mon, 16 Mar 2009 06:23:13 +0000 Date: Mon, 16 Mar 2009 02:23:13 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/3] [XFSQA] Reduce the number of processes forked Subject: Re: [PATCH 1/3] [XFSQA] Reduce the number of processes forked Message-ID: <20090316062313.GA30641@infradead.org> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> <1237114181-18431-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237114181-18431-2-git-send-email-david@fromorbit.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: 1237184594 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 15, 2009 at 09:49:39PM +1100, Dave Chinner wrote: > One of the big cpu time consumers when running xfsqa on UML > is forking of new processes. when looping lots of times, > using 'expr' to calculate the loop counter increment means > we fork at least once every loop. using shell builtins means > that we don't fork and many tests run substantially faster. > > Some tests are even runnable with this modification. e.g. 110 > went from taking 4500s to run down to 9s with the loop iterators > changed to avoid forking. Looks good. Care to see if any tests should be added to the quick group after this? The above 110 sounds like a candidate for that. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:24: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 n2G6NvDC071804 for ; Mon, 16 Mar 2009 01:24:18 -0500 X-ASG-Debug-ID: 1237184616-313003650000-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 B4BE91C452F0 for ; Sun, 15 Mar 2009 23:23:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id i8Rh2V7BLADp8gU6 for ; Sun, 15 Mar 2009 23:23:36 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Ea-0005rx-Eg; Mon, 16 Mar 2009 06:23:36 +0000 Date: Mon, 16 Mar 2009 02:23:36 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/3] [XFSQA] Add simple delayed allocation ENOSPC test. Subject: Re: [PATCH 2/3] [XFSQA] Add simple delayed allocation ENOSPC test. Message-ID: <20090316062336.GB30641@infradead.org> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> <1237114181-18431-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237114181-18431-3-git-send-email-david@fromorbit.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: 1237184616 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 15, 2009 at 09:49:40PM +1100, Dave Chinner wrote: > Using a small (100MB) filesystem and writing lots of > single block files can result in spurious ENOSPCs > being reported. Reproduce this test case so we can confirm > that it gets fixed. Looks good. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:28: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 n2G6Rvpx072095 for ; Mon, 16 Mar 2009 01:28:18 -0500 X-ASG-Debug-ID: 1237184856-313003780000-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 CE4A41C452FF for ; Sun, 15 Mar 2009 23:27:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Hy7g8WfPinZ8jgCR for ; Sun, 15 Mar 2009 23:27:36 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Hy-0003UV-1J; Mon, 16 Mar 2009 06:27:06 +0000 Date: Mon, 16 Mar 2009 02:27:06 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/3] [XFSQA] Test writing to ENOSPC Subject: Re: [PATCH 3/3] [XFSQA] Test writing to ENOSPC Message-ID: <20090316062706.GC30641@infradead.org> References: <1237114181-18431-1-git-send-email-david@fromorbit.com> <1237114181-18431-4-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237114181-18431-4-git-send-email-david@fromorbit.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: 1237184856 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 15, 2009 at 09:49:41PM +1100, Dave Chinner wrote: > Use larger files and different writing styles to fill > a 100MB filesystem to being full. In each case we should > get very close to the filesystem being full before getting > ENOSPC. THis tests different types of ENOSPC failures to > test 203 and requires more changes to pass. Looks good. But don't we actually need a trap handler to unmount the scratch partitions if the test gets intterupted? I always added them to my tests, copying that fragment from older patches. (also applies to the previous patch) From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:31:53 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_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 n2G6VWeA072301 for ; Mon, 16 Mar 2009 01:31:52 -0500 X-ASG-Debug-ID: 1237185071-7a3702210000-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 640231C45398 for ; Sun, 15 Mar 2009 23:31:11 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id gm7bEFwwbClCmRZf for ; Sun, 15 Mar 2009 23:31:11 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6LQ-0001hm-K8 for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:30:40 +0000 Date: Mon, 16 Mar 2009 02:30:40 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfsdump: make sure Makpekgs is complete Subject: Re: [PATCH] xfsdump: make sure Makpekgs is complete Message-ID: <20090316063040.GA4957@infradead.org> References: <20090224183819.GA25706@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224183819.GA25706@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: 1237185071 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 ping? On Tue, Feb 24, 2009 at 01:38:19PM -0500, Christoph Hellwig wrote: > > Signed-off-by: Christoph Hellwig > > Index: xfsdump-dev/doc/Makefile > =================================================================== > --- xfsdump-dev.orig/doc/Makefile 2009-02-24 19:31:07.048152638 +0100 > +++ xfsdump-dev/doc/Makefile 2009-02-24 19:31:34.859030054 +0100 > @@ -7,13 +7,8 @@ include $(TOPDIR)/include/builddefs > > README = README.xfsdump > LSRCFILES = INSTALL PORTING CHANGES COPYING $(README) \ > - directories.gif directories.obj \ > - files.gif files.obj \ > - global_hdr.gif global_hdr.obj \ > - inode_map.gif inode_map.obj \ > - media_files.gif media_files.obj \ > - split_algorithm.gif split_algorithm.obj \ > - xfsdump.html xfsdump_ts.txt > + xfsdump.html xfsdump_ts.txt \ > + *.obj *.gif > > LDIRT = *.gz > > Index: xfsdump-dev/include/Makefile > =================================================================== > --- xfsdump-dev.orig/include/Makefile 2009-02-24 19:31:49.244027259 +0100 > +++ xfsdump-dev/include/Makefile 2009-02-24 19:37:18.132152625 +0100 > @@ -5,7 +5,7 @@ > TOPDIR = .. > include $(TOPDIR)/include/builddefs > > -HFILES = swap.h > +HFILES = swab.h swap.h > LSRCFILES = builddefs.in buildmacros buildrules config.h.in > > default install install-dev : > Index: xfsdump-dev/inventory/Makefile > =================================================================== > --- xfsdump-dev.orig/inventory/Makefile 2009-02-24 19:32:17.497028005 +0100 > +++ xfsdump-dev/inventory/Makefile 2009-02-24 19:34:01.969057100 +0100 > @@ -7,7 +7,7 @@ include $(TOPDIR)/include/builddefs > > LSRCFILES = inv_api.c inv_core.c inv_fstab.c inv_idx.c inv_mgr.c \ > inv_oref.c inv_oref.h inv_priv.h inv_stobj.c inv_files.c \ > - inventory.h > + inventory.h getopt.h testmain.c > > default install install-dev: > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:32:00 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_64, J_CHICKENPOX_66 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 n2G6Vd3R072310 for ; Mon, 16 Mar 2009 01:32:00 -0500 X-ASG-Debug-ID: 1237185057-3f5502a10000-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 DEA3019BBE3 for ; Sun, 15 Mar 2009 23:30:58 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id bIn4JHlUd0CT9fZe for ; Sun, 15 Mar 2009 23:30:58 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Lh-0001iC-Rx for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:30:57 +0000 Date: Mon, 16 Mar 2009 02:30:57 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Message-ID: <20090316063057.GC4957@infradead.org> References: <20090224133902.GC15820@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224133902.GC15820@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: 1237185078 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 ping? On Tue, Feb 24, 2009 at 08:39:02AM -0500, Christoph Hellwig wrote: > xfs_getbmap (or rather the formatters called by it) copy out the getbmap > structures under the ilock, which can deadlock against mmap. This has > been reported via bugzilla a while ago (#717) and has recently also > shown up via lockdep. > > So allocate a temporary buffer to format the kernel getbmap structures > into and then copy them out after dropping the locks. > > A little problem with this is that we limit the number of extents we > can copy out by the maximum allocation size, but I see no real way > around that. > > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 20:38:27.512925014 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 20:40:46.720926193 +0100 > @@ -5867,12 +5867,13 @@ xfs_getbmap( > int nexleft; /* # of user extents left */ > int subnex; /* # of bmapi's can do */ > int nmap; /* number of map entries */ > - struct getbmapx out; /* output structure */ > + struct getbmapx *out; /* output structure */ > int whichfork; /* data or attr fork */ > int prealloced; /* this is a file with > * preallocated data space */ > int iflags; /* interface flags */ > int bmapi_flags; /* flags for xfs_bmapi */ > + int cur_ext = 0; > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > @@ -5948,6 +5949,13 @@ xfs_getbmap( > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > + > + if (bmv->bmv_count > ULONG_MAX / sizeof(struct getbmapx)) > + return XFS_ERROR(ENOMEM); > + out = kmem_zalloc(bmv->bmv_count * sizeof(struct getbmapx), KM_MAYFAIL); > + if (!out) > + return XFS_ERROR(ENOMEM); > + > xfs_ilock(ip, XFS_IOLOCK_SHARED); > if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > @@ -6001,39 +6009,39 @@ xfs_getbmap( > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > - int full = 0; /* user array is full */ > - > - out.bmv_oflags = 0; > + out[cur_ext].bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > - out.bmv_oflags |= BMV_OF_PREALLOC; > + out[cur_ext].bmv_oflags |= BMV_OF_PREALLOC; > else if (map[i].br_startblock == DELAYSTARTBLOCK) > - out.bmv_oflags |= BMV_OF_DELALLOC; > - out.bmv_offset = XFS_FSB_TO_BB(mp, map[i].br_startoff); > - out.bmv_length = XFS_FSB_TO_BB(mp, map[i].br_blockcount); > - out.bmv_unused1 = out.bmv_unused2 = 0; > + out[cur_ext].bmv_oflags |= BMV_OF_DELALLOC; > + out[cur_ext].bmv_offset = > + XFS_FSB_TO_BB(mp, map[i].br_startoff); > + out[cur_ext].bmv_length = > + XFS_FSB_TO_BB(mp, map[i].br_blockcount); > + out[cur_ext].bmv_unused1 = 0; > + out[cur_ext].bmv_unused2 = 0; > ASSERT(((iflags & BMV_IF_DELALLOC) != 0) || > (map[i].br_startblock != DELAYSTARTBLOCK)); > if (map[i].br_startblock == HOLESTARTBLOCK && > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > - out.bmv_oflags |= BMV_OF_LAST; > + out[cur_ext].bmv_oflags |= BMV_OF_LAST; > goto out_free_map; > } > > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > - bmvend, map[i].br_startblock)) > + if (!xfs_getbmapx_fix_eof_hole(ip, &out[cur_ext], > + prealloced, bmvend, > + map[i].br_startblock)) > goto out_free_map; > > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto out_free_map; > nexleft--; > bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > + out[cur_ext].bmv_offset + > + out[cur_ext].bmv_length; > bmv->bmv_length = > max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > bmv->bmv_entries++; > + cur_ext++; > } > } while (nmap && nexleft && bmv->bmv_length); > > @@ -6043,6 +6051,16 @@ xfs_getbmap( > xfs_iunlock_map_shared(ip, lock); > out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > + > + for (i = 0; i < cur_ext; i++) { > + int full = 0; /* user array is full */ > + > + /* format results & advance arg */ > + error = formatter(&arg, &out[i], &full); > + if (error || full) > + break; > + } > + > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:31: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64 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 n2G6VYE0072306 for ; Mon, 16 Mar 2009 01:31:54 -0500 X-ASG-Debug-ID: 1237185053-77cb01470000-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 17F6519BAD6 for ; Sun, 15 Mar 2009 23:30:53 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id uIw2VBjgHBUphEeP for ; Sun, 15 Mar 2009 23:30:53 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Ld-0001i0-3M for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:30:53 +0000 Date: Mon, 16 Mar 2009 02:30:53 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Subject: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Message-ID: <20090316063053.GB4957@infradead.org> References: <20090224133858.GB15820@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224133858.GB15820@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: 1237185074 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 ping? On Tue, Feb 24, 2009 at 08:38:58AM -0500, Christoph Hellwig wrote: > - reshuffle various conditionals for data vs attr fork to make the code > more readable > - do fine-grainded goto-based error handling > - exit early from conditionals instead of keeping a long else branch > around > - allow kmem_alloc to fail > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 18:08:35.352924726 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 18:23:49.527051836 +0100 > @@ -5857,7 +5857,7 @@ xfs_getbmap( > void *arg) /* formatter arg */ > { > __int64_t bmvend; /* last block requested */ > - int error; /* return value */ > + int error = 0; /* return value */ > __int64_t fixlen; /* length for -1 case */ > int i; /* extent number */ > int lock; /* lock state */ > @@ -5876,30 +5876,8 @@ xfs_getbmap( > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > - > whichfork = iflags & BMV_IF_ATTRFORK ? XFS_ATTR_FORK : XFS_DATA_FORK; > > - /* If the BMV_IF_NO_DMAPI_READ interface bit specified, do not > - * generate a DMAPI read event. Otherwise, if the DM_EVENT_READ > - * bit is set for the file, generate a read event in order > - * that the DMAPI application may do its thing before we return > - * the extents. Usually this means restoring user file data to > - * regions of the file that look like holes. > - * > - * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > - * BMV_IF_NO_DMAPI_READ so that read events are generated. > - * If this were not true, callers of ioctl( XFS_IOC_GETBMAP ) > - * could misinterpret holes in a DMAPI file as true holes, > - * when in fact they may represent offline user data. > - */ > - if ((iflags & BMV_IF_NO_DMAPI_READ) == 0 && > - DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > - whichfork == XFS_DATA_FORK) { > - error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, 0, 0, 0, NULL); > - if (error) > - return XFS_ERROR(error); > - } > - > if (whichfork == XFS_ATTR_FORK) { > if (XFS_IFORK_Q(ip)) { > if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS && > @@ -5913,11 +5891,37 @@ xfs_getbmap( > ip->i_mount); > return XFS_ERROR(EFSCORRUPTED); > } > - } else if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > - ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > - return XFS_ERROR(EINVAL); > - if (whichfork == XFS_DATA_FORK) { > + > + prealloced = 0; > + fixlen = 1LL << 32; > + } else { > + /* > + * If the BMV_IF_NO_DMAPI_READ interface bit specified, do > + * not generate a DMAPI read event. Otherwise, if the > + * DM_EVENT_READ bit is set for the file, generate a read > + * event in order that the DMAPI application may do its thing > + * before we return the extents. Usually this means restoring > + * user file data to regions of the file that look like holes. > + * > + * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > + * BMV_IF_NO_DMAPI_READ so that read events are generated. > + * If this were not true, callers of ioctl(XFS_IOC_GETBMAP) > + * could misinterpret holes in a DMAPI file as true holes, > + * when in fact they may represent offline user data. > + */ > + if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > + !(iflags & BMV_IF_NO_DMAPI_READ)) { > + error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, > + 0, 0, 0, NULL); > + if (error) > + return XFS_ERROR(error); > + } > + > + if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > + ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > + ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > + return XFS_ERROR(EINVAL); > + > if (xfs_get_extsz_hint(ip) || > ip->i_d.di_flags & (XFS_DIFLAG_PREALLOC|XFS_DIFLAG_APPEND)){ > prealloced = 1; > @@ -5926,42 +5930,34 @@ xfs_getbmap( > prealloced = 0; > fixlen = ip->i_size; > } > - } else { > - prealloced = 0; > - fixlen = 1LL << 32; > } > > if (bmv->bmv_length == -1) { > fixlen = XFS_FSB_TO_BB(mp, XFS_B_TO_FSB(mp, fixlen)); > - bmv->bmv_length = MAX( (__int64_t)(fixlen - bmv->bmv_offset), > - (__int64_t)0); > - } else if (bmv->bmv_length < 0) > - return XFS_ERROR(EINVAL); > - if (bmv->bmv_length == 0) { > + bmv->bmv_length = > + max_t(__int64_t, fixlen - bmv->bmv_offset, 0); > + } else if (bmv->bmv_length == 0) { > bmv->bmv_entries = 0; > return 0; > + } else if (bmv->bmv_length < 0) { > + return XFS_ERROR(EINVAL); > } > + > nex = bmv->bmv_count - 1; > if (nex <= 0) > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > xfs_ilock(ip, XFS_IOLOCK_SHARED); > - > - if (((iflags & BMV_IF_DELALLOC) == 0) && > - (whichfork == XFS_DATA_FORK) && > - (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size)) { > - /* xfs_fsize_t last_byte = xfs_file_last_byte(ip); */ > - error = xfs_flush_pages(ip, (xfs_off_t)0, > - -1, 0, FI_REMAPF); > - if (error) { > - xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - return error; > + if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > + if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > + error = xfs_flush_pages(ip, 0, -1, 0, FI_REMAPF); > + if (error) > + goto out_unlock_iolock; > } > - } > > - ASSERT(whichfork == XFS_ATTR_FORK || (iflags & BMV_IF_DELALLOC) || > - ip->i_delayed_blks == 0); > + ASSERT(ip->i_delayed_blks == 0); > + } > > lock = xfs_ilock_map_shared(ip); > > @@ -5972,23 +5968,24 @@ xfs_getbmap( > if (nex > XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1) > nex = XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1; > > - bmapi_flags = xfs_bmapi_aflag(whichfork) | > - ((iflags & BMV_IF_PREALLOC) ? 0 : XFS_BMAPI_IGSTATE); > + bmapi_flags = xfs_bmapi_aflag(whichfork); > + if (!(iflags & BMV_IF_PREALLOC)) > + bmapi_flags |= XFS_BMAPI_IGSTATE; > > /* > * Allocate enough space to handle "subnex" maps at a time. > */ > subnex = 16; > - map = kmem_alloc(subnex * sizeof(*map), KM_SLEEP); > + map = kmem_alloc(subnex * sizeof(*map), KM_MAYFAIL); > + if (!map) > + goto out_unlock_ilock; > > bmv->bmv_entries = 0; > > - if ((XFS_IFORK_NEXTENTS(ip, whichfork) == 0)) { > - if (((iflags & BMV_IF_DELALLOC) == 0) || > - whichfork == XFS_ATTR_FORK) { > - error = 0; > - goto unlock_and_return; > - } > + if (XFS_IFORK_NEXTENTS(ip, whichfork) == 0 && > + (whichfork == XFS_ATTR_FORK || !(iflags & BMV_IF_DELALLOC))) { > + error = 0; > + goto out_free_map; > } > > nexleft = nex; > @@ -6000,10 +5997,12 @@ xfs_getbmap( > bmapi_flags, NULL, 0, map, &nmap, > NULL, NULL); > if (error) > - goto unlock_and_return; > + goto out_free_map; > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > + int full = 0; /* user array is full */ > + > out.bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > out.bmv_oflags |= BMV_OF_PREALLOC; > @@ -6018,36 +6017,32 @@ xfs_getbmap( > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > out.bmv_oflags |= BMV_OF_LAST; > - goto unlock_and_return; > - } else { > - int full = 0; /* user array is full */ > - > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, > - prealloced, bmvend, > - map[i].br_startblock)) { > - goto unlock_and_return; > - } > - > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto unlock_and_return; > - nexleft--; > - bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > - bmv->bmv_length = MAX((__int64_t)0, > - (__int64_t)(bmvend - bmv->bmv_offset)); > - bmv->bmv_entries++; > + goto out_free_map; > } > + > + if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > + bmvend, map[i].br_startblock)) > + goto out_free_map; > + > + /* format results & advance arg */ > + error = formatter(&arg, &out, &full); > + if (error || full) > + goto out_free_map; > + nexleft--; > + bmv->bmv_offset = > + out.bmv_offset + out.bmv_length; > + bmv->bmv_length = > + max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > + bmv->bmv_entries++; > } > } while (nmap && nexleft && bmv->bmv_length); > > -unlock_and_return: > + out_free_map: > + kmem_free(map); > + out_unlock_ilock: > xfs_iunlock_map_shared(ip, lock); > + out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - > - kmem_free(map); > - > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:32:31 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_61, J_CHICKENPOX_71,J_CHICKENPOX_72 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 n2G6WAxX072370 for ; Mon, 16 Mar 2009 01:32:31 -0500 X-ASG-Debug-ID: 1237185109-77ce014c0000-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 EAD9719BBEA for ; Sun, 15 Mar 2009 23:31:49 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id CdVSsHjNV65QhI8p for ; Sun, 15 Mar 2009 23:31:49 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6M3-0001ib-5Y for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:31:19 +0000 Date: Mon, 16 Mar 2009 02:31:19 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: a couple of fixes for external logs Subject: Re: [PATCH] xfstests: a couple of fixes for external logs Message-ID: <20090316063119.GD4957@infradead.org> References: <20090224131847.GB1579@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224131847.GB1579@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: 1237185109 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 ping? On Tue, Feb 24, 2009 at 08:18:47AM -0500, Christoph Hellwig wrote: > Fix a couple of issues when running xfsqa with external logs: > > - update the 096 golden output for the external log case > - add a new _scratch_xfs_check similar to _scratch_xfs_logprint and > _scratch_xfs_repair that take the log device into account and use it > in test 134 > - use _scratch_xfs_repair in test 202 to fix it for external log > devices > > Signed-off-by: Christoph Hellwig > > Index: xfstests-dev/017 > =================================================================== > --- xfstests-dev.orig/017 2009-02-23 21:05:07.000000000 +0000 > +++ xfstests-dev/017 2009-02-23 21:08:46.000000000 +0000 > @@ -67,7 +67,7 @@ > echo "" >>$seq.full > echo "*** XFS_CHECK ***" >>$seq.full > echo "" >>$seq.full > - xfs_check $checkopts $SCRATCH_DEV >>$seq.full 2>&1 \ > + _scratch_xfs_check $checkopts >>$seq.full 2>&1 \ > || _fail "xfs_check $checkopts failed" > _scratch_mount -o remount,rw \ > || _fail "remount rw failed" > Index: xfstests-dev/common.rc > =================================================================== > --- xfstests-dev.orig/common.rc 2009-02-23 21:05:07.000000000 +0000 > +++ xfstests-dev/common.rc 2009-02-24 00:09:39.000000000 +0000 > @@ -268,6 +268,14 @@ > $XFS_LOGPRINT_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV > } > > +_scratch_xfs_check() > +{ > + SCRATCH_OPTIONS="" > + [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \ > + SCRATCH_OPTIONS="-l $SCRATCH_LOGDEV" > + $XFS_CHECK_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV > +} > + > _scratch_xfs_repair() > { > SCRATCH_OPTIONS="" > Index: xfstests-dev/202 > =================================================================== > --- xfstests-dev.orig/202 2009-02-23 21:15:56.000000000 +0000 > +++ xfstests-dev/202 2009-02-23 21:20:12.000000000 +0000 > @@ -20,6 +20,7 @@ > # get standard environment, filters and checks > . ./common.rc > . ./common.filter > +. ./common.repair > > # real QA test starts here > _supported_fs xfs > @@ -31,10 +32,10 @@ > _scratch_mkfs_xfs -d agcount=1 >/dev/null 2>&1 > > echo "== Trying to repair it (should fail) ==" > -xfs_repair $SCRATCH_DEV > +_scratch_xfs_repair > > echo "== Trying to repair it with -o force_geometry ==" > -xfs_repair -o force_geometry $SCRATCH_DEV > +_scratch_xfs_repair -o force_geometry 2>&1 | _filter_repair > > # success, all done > echo "*** done" > Index: xfstests-dev/202.out > =================================================================== > --- xfstests-dev.orig/202.out 2009-02-23 21:18:49.000000000 +0000 > +++ xfstests-dev/202.out 2009-02-23 21:20:46.000000000 +0000 > @@ -6,19 +6,17 @@ > Use the -o force_geometry option to proceed. > == Trying to repair it with -o force_geometry == > Phase 1 - find and verify superblock... > -Phase 2 - using internal log > +Phase 2 - using log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - - agno = 0 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - - agno = 0 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > Index: xfstests-dev/096.external > =================================================================== > --- xfstests-dev.orig/096.external 2009-02-23 21:23:19.000000000 +0000 > +++ xfstests-dev/096.external 2009-02-23 21:24:38.000000000 +0000 > @@ -30,7 +30,7 @@ > > > # test out data stripe > ---- mkfs=-d su=266240,sw=1 --- > +--- mkfs=-l version=1 -d su=266240,sw=1 --- > meta-data=DEV isize=256 agcount=N, agsize=N blks > data = bsize=4096 blocks=N, imaxpct=25 > = sunit=65 swidth=65 blks, unwritten=1 > @@ -41,7 +41,7 @@ > > > # test out data stripe the same but using sunit & swidth > ---- mkfs=-d sunit=520,swidth=520 --- > +--- mkfs=-l version=1 -d sunit=520,swidth=520 --- > meta-data=DEV isize=256 agcount=N, agsize=N blks > data = bsize=4096 blocks=N, imaxpct=25 > = sunit=65 swidth=65 blks, unwritten=1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:33: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 n2G6Wv96072478 for ; Mon, 16 Mar 2009 01:33:17 -0500 X-ASG-Debug-ID: 1237185156-312a034e0000-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 B1C521C453AC for ; Sun, 15 Mar 2009 23:32:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id C4ypt8m9vzAWEPxT for ; Sun, 15 Mar 2009 23:32:36 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Mn-0001kL-VN for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:32:05 +0000 Date: Mon, 16 Mar 2009 02:32:05 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: tarballs generated by Makepkgs Subject: Re: tarballs generated by Makepkgs Message-ID: <20090316063205.GE4957@infradead.org> References: <20090215202125.GA18218@infradead.org> <20090224184252.GA28007@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224184252.GA28007@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: 1237185156 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 ping? On Tue, Feb 24, 2009 at 01:42:52PM -0500, Christoph Hellwig wrote: > On Sun, Feb 15, 2009 at 03:21:25PM -0500, Christoph Hellwig wrote: > > currently Makepkgs generats the source tarball as > > package-version.src.tar.gz, which is not what we used for recent > > releases and not what most other open source packages do. I'd like to > > change it to package-version.tar.gz, but that currently collides with > > the binary tar packages. > > > > Does anyone still need those binary tar packages? If yes we should > > rename them, too or otherwise just remove them. > > This would be the easiest way, renaming the binary packages to > xfsprogs-$ver.bin.tar.gz and the source to the expected > xfsprogs-$ver.tar.gz. Same patch would also go into xfsdump and dmapi. > > > Index: xfsprogs-dev/build/Makefile > =================================================================== > --- xfsprogs-dev.orig/build/Makefile 2009-02-24 19:39:37.259153164 +0100 > +++ xfsprogs-dev/build/Makefile 2009-02-24 19:39:58.817035065 +0100 > @@ -6,7 +6,7 @@ TOPDIR = .. > include $(TOPDIR)/include/builddefs > > MANIFEST=src-manifest > -SRCTAR=$(PKG_NAME)-$(PKG_VERSION).src.tar.gz > +SRCTAR=$(PKG_NAME)-$(PKG_VERSION).tar.gz > > LDIRT = *-manifest *.gz $(TOPDIR)/$(PKG_NAME)-* > > Index: xfsprogs-dev/build/tar/Makefile > =================================================================== > --- xfsprogs-dev.orig/build/tar/Makefile 2009-02-24 19:40:08.459152818 +0100 > +++ xfsprogs-dev/build/tar/Makefile 2009-02-24 19:40:13.721029934 +0100 > @@ -5,7 +5,7 @@ > TOPDIR = ../.. > include $(TOPDIR)/include/builddefs > > -BINTAR=$(PKG_NAME)-$(PKG_VERSION).tar.gz > +BINTAR=$(PKG_NAME)-$(PKG_VERSION).bin.tar.gz > LDIRT = *.gz > > default install install-dev install-lib: > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:34: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.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 n2G6YQEj072675 for ; Mon, 16 Mar 2009 01:34:42 -0500 X-ASG-Debug-ID: 1237185245-3cf500f60000-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 255A21C453FF for ; Sun, 15 Mar 2009 23:34:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id EB1w1MrFACjbhlSU for ; Sun, 15 Mar 2009 23:34:06 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6Oj-0002HA-Qn for xfs@oss.sgi.com; Mon, 16 Mar 2009 06:34:05 +0000 Date: Mon, 16 Mar 2009 02:34:05 -0400 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: <20090316063405.GA7413@infradead.org> References: <20090224132737.GA8161@infradead.org> <20090304173224.GB32471@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304173224.GB32471@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: 1237185246 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 ping? On Wed, Mar 04, 2009 at 12:32:24PM -0500, Christoph Hellwig wrote: > 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). > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 01:52: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.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 n2G6qMnf073745 for ; Mon, 16 Mar 2009 01:52:43 -0500 X-ASG-Debug-ID: 1237186321-313203bd0000-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 158C31C452CE for ; Sun, 15 Mar 2009 23:52:01 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Gg9XD4oZeI6JA8pK for ; Sun, 15 Mar 2009 23:52:01 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6fz-0002J7-9u; Mon, 16 Mar 2009 06:51:55 +0000 Date: Mon, 16 Mar 2009 02:51:55 -0400 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , Eric Sandeen , Mike Frysinger , 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: <20090316065155.GA5659@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200902271835.30912.agruen@suse.de> <20090304172727.GA21463@infradead.org> <200903081409.28808.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903081409.28808.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: 1237186322 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 08, 2009 at 02:09:28PM +0100, 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 Thank, I've pushed this patch to the xfsprogs, xfsdump and dmapi -dev repositories. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 02:06:34 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 n2G76Dkb074339 for ; Mon, 16 Mar 2009 02:06:34 -0500 X-ASG-Debug-ID: 1237187152-112200050000-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 CA2E61C44E9E for ; Mon, 16 Mar 2009 00:05:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 9C0UBqmtDIFCCiKc for ; Mon, 16 Mar 2009 00:05:52 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj6tS-0002Ts-BT; Mon, 16 Mar 2009 07:05:50 +0000 Date: Mon, 16 Mar 2009 03:05:50 -0400 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , Eric Sandeen , Mike Frysinger , 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: <20090316070550.GA628@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <20090304172727.GA21463@infradead.org> <200903081409.28808.agruen@suse.de> <200903101741.07043.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903101741.07043.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: 1237187152 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 10, 2009 at 05:41:06PM +0100, Andreas Gruenbacher wrote: > 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 That patch breaks the commit for me: hch@brick:~/work/attr$ make libtoolize -c -i -f libtoolize: unrecognized option `-i' Try `libtoolize --help' for more information. make: *** [include/builddefs] Error 1 This is on debian -testing with libtool 1.5.26 From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 02:28: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 (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2G7SLbn075463 for ; Mon, 16 Mar 2009 02:28:41 -0500 X-ASG-Debug-ID: 1237188459-6785014f0000-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 75D881C44777 for ; Mon, 16 Mar 2009 00:27:39 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id rCmdLTkpZZNZFzyI for ; Mon, 16 Mar 2009 00:27:39 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj7EY-00027l-Hc; Mon, 16 Mar 2009 07:27:38 +0000 Date: Mon, 16 Mar 2009 03:27:38 -0400 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com, Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 7/7] xfs: factor out code to find the longest free extent in the AG Subject: Re: [PATCH 7/7] xfs: factor out code to find the longest free extent in the AG Message-ID: <20090316072738.GA16563@infradead.org> References: <20090220085207.663702000@bombadil.infradead.org> <20090220085230.115970000@bombadil.infradead.org> <20090315075824.GV26138@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090315075824.GV26138@disturbed> 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: 1237188480 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 15, 2009 at 06:58:24PM +1100, Dave Chinner wrote: > > Looking at this again, I'd change the name of this function > to xfs_alloc_ag_longest_free_extent(), because that is what it > is actually returning.... I've left the _ag out and made it xfs_alloc_longest_free_extent. The ag is kinda implicit by the perag argument.. From vapier@gentoo.org Mon Mar 16 02:32:37 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 n2G7WGGc075664 for ; Mon, 16 Mar 2009 02:32:37 -0500 X-ASG-Debug-ID: 1237188715-77c902280000-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 BEA8519BF32 for ; Mon, 16 Mar 2009 00:31:55 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by cuda.sgi.com with ESMTP id 5H5bCayR0BIi2afN for ; Mon, 16 Mar 2009 00:31:55 -0700 (PDT) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5286B64613; Mon, 16 Mar 2009 07:31:54 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org 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: Mon, 16 Mar 2009 03:31:48 -0400 User-Agent: KMail/1.11.1 (Linux/2.6.28; KDE/4.2.1; x86_64; ; ) Cc: Andreas Gruenbacher , Eric Sandeen , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <200903101741.07043.agruen@suse.de> <20090316070550.GA628@infradead.org> In-Reply-To: <20090316070550.GA628@infradead.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3454592.GTvVCzAhX9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903160331.53142.vapier@gentoo.org> X-Barracuda-Connect: smtp.gentoo.org[140.211.166.183] X-Barracuda-Start-Time: 1237188715 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.20477 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 --nextPart3454592.GTvVCzAhX9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 16 March 2009 03:05:50 Christoph Hellwig wrote: > On Tue, Mar 10, 2009 at 05:41:06PM +0100, Andreas Gruenbacher wrote: > > 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 > > That patch breaks the commit for me: > > hch@brick:~/work/attr$ make > libtoolize -c -i -f > libtoolize: unrecognized option `-i' > Try `libtoolize --help' for more information. > make: *** [include/builddefs] Error 1 -i is new to libtool-2 usually what i do is something like: args= libtoolize -n --install 2>/dev/null && args="-i" libtoolize -c -f $args -mike --nextPart3454592.GTvVCzAhX9 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) iQIcBAABAgAGBQJJvgBpAAoJEEFjO5/oN/WBZqkP/1b9jQbhXd8Kg+Xo33BxkODR dTRDF95ejmwIZCkhSy2wyiyEvfCZd6c0JRtmnSXZVvN6dkAfhOh3jMTc4wjRgkMv +1mR+D1RybB6AM/tKw7w9oOIYwrYX54LsVl0Jo+kRMijXRY9wfPFoe28fUo4U87/ yKy029i4j8YVEW2oj5gPyDJAO+LVQE1sraCAfnqfwoO5NZ6E2pZVjpFV8atW7bwr 7ZKm9kbaZf92LECqPDGfc0ZHjozZDMOwkzGN071QYH+EUOI9oLT3cFBgs93DY4ya GaDJXA2NOflkis6vYDXZMVW+kshapu1rGLK9RthELV8G3IeuQBXZinPa134zigQt deqAmS7nGbw+cMp9eVE/vDWRkEo7BDXVvELC/E3miPZHrA5rLJGJymcLxoa7ebOI DN+VbfjZiVrtL2HY/0qAQX3opROpw3X/c/tbWTEEZKHMvKuFgS7nSplcNDAcs4uH dKuuIzKmRQ76TAaUkli0gIoOrFEglYYZLnQ1ZPYIH/O+T/w+D7TCvD0PXjPdwvRJ MdQAHtj0Guk4yeX9AI5m3DT9yrZIsu2MsTeJXVgb3AwIFMm+fhizl3v8uQMK4oRU SaEWDy/ZbCHbcri28QSUEmoEmSrOe3QXj9ZKjgMzNnjwA0zPIQ0IJRdpT5HbEamj rrTxfSiDWIS5BO5R5xG8 =Lo6q -----END PGP SIGNATURE----- --nextPart3454592.GTvVCzAhX9-- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 02:54: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23 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 n2G7rx3M076642 for ; Mon, 16 Mar 2009 02:54:20 -0500 X-ASG-Debug-ID: 1237190018-77cd029d0000-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 B73C519BE01 for ; Mon, 16 Mar 2009 00:53:38 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id lexPL4IBO4bCbjLf for ; Mon, 16 Mar 2009 00:53:38 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj7di-0005Et-Bg; Mon, 16 Mar 2009 07:53:38 +0000 Date: Mon, 16 Mar 2009 03:53:38 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Subject: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Message-ID: <20090316075338.GA19858@infradead.org> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237117603-26071-1-git-send-email-david@fromorbit.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: 1237190018 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 15, 2009 at 10:46:37PM +1100, Dave Chinner wrote: > This series splits up the sync and reclaim code into three > separate actions. The first is the tree walker, the second is > the inode validation and the third is the operation to execute > on the inode. > > This allows us to somewhat abstract the radix tree away from the > act of walking the cached inodes and puts in place mechanisms that > can be extended for bulk inode cache lookups. > > This also splits the inode writeback into separate data and metadata > sync operations and optimises them a little...... Just did a quick XFSQA run with your whole patch series applied and I get this oops in 001: [ 37.023076] Filesystem "vdb": Disabling barriers, not supported with external log device [ 37.055812] XFS mounting filesystem vdb 001 9s ... [ 46.688828] BUG: unable to handle kernel NULL pointer dereference at 00000332 [ 46.711217] IP: [] xfs_sync_inode_data+0x15/0xd0 [ 46.733131] *pde = 00000000 [ 46.744335] Oops: 0000 [#1] SMP [ 46.748325] last sysfs file: /sys/class/net/lo/operstate [ 46.748325] Modules linked in: [ 46.748325] [ 46.748325] Pid: 5229, comm: umount Not tainted (2.6.29-rc7-xfs #207) [ 46.748325] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 46.748325] EIP is at xfs_sync_inode_data+0x15/0xd0 [ 46.748325] EAX: 00000002 EBX: 00000002 ECX: f2784530 EDX: 00000000 [ 46.748325] ESI: c04777c0 EDI: 0000000a EBP: f2799df8 ESP: f2799dd8 [ 46.748325] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 46.748325] Process umount (pid: 5229, ti=f2798000 task=f2784530 task.ti=f2798000) [ 46.748325] Stack: [ 46.748325] 00000001 f2799e04 c04777c0 f57b168c f6fc99d0 f57b1638 c04777c0 f5654230 [ 46.748325] f2799e20 c0477de3 f2799e10 ffffffff 00000000 00000000 00000084 00000000 [ 46.748325] f5654230 00000000 f2799e48 c0477eae c0477bd0 0000000a ffffffff c0477bd0 [ 46.748325] Call Trace: [ 46.748325] [] ? xfs_sync_inode_valid+0x0/0xa0 [ 46.748325] [] ? xfs_sync_inode_valid+0x0/0xa0 [ 46.748325] [] ? xfs_inode_ag_walk+0x63/0xd0 [ 46.748325] [] ? xfs_inode_ag_iterator+0x5e/0xa0 [ 46.748325] [] ? xfs_sync_inode_data+0x0/0xd0 [ 46.748325] [] ? xfs_sync_inode_data+0x0/0xd0 [ 46.748325] [] ? xfs_sync_inode_valid+0x0/0xa0 [ 46.748325] [] ? xfs_sync_inodes+0x7c/0xc0 [ 46.748325] [] ? xfs_quiesce_data+0x11/0x70 [ 46.748325] [] ? xfs_fs_sync_super+0x3f/0xe0 [ 46.748325] [] ? xfs_fs_quota_sync+0x0/0x40 [ 46.748325] [] ? quota_sync_sb+0x35/0xf0 [ 46.748325] [] ? xfs_fs_quota_sync+0x0/0x40 [ 46.748325] [] ? sync_dquots+0x23/0x140 [ 46.748325] [] ? __fsync_super+0x19/0x70 [ 46.748325] [] ? fsync_super+0xb/0x20 [ 46.748325] [] ? generic_shutdown_super+0x22/0xf0 [ 46.748325] [] ? down_write+0x80/0x90 [ 46.748325] [] ? kill_block_super+0x25/0x40 [ 46.748325] [] ? deactivate_super+0x7a/0x90 [ 46.748325] [] ? mntput_no_expire+0xe2/0x110 [ 46.748325] [] ? sys_umount+0x4f/0x310 [ 46.748325] [] ? sys_oldumount+0x19/0x20 [ 46.748325] [] ? syscall_call+0x7/0xb [ 46.748325] [] ? sys_sigreturn+0x20/0xe0 [ 46.748325] Code: ff 84 c0 74 ed ba 06 00 00 00 89 d8 e8 d5 10 fd ff 89 c6 eb b3 90 55 89 e5 83 ec 20 89 5d f4 89 c3 89 7d fc 89 d7 31 d2 89 75 f8 <8b> 80 30 03 00 00 e8 40 75 d2 ff 85 c0 74 6e f7 c7 20 00 00 00 [ 46.748325] EIP: [] xfs_sync_inode_data+0x15/0xd0 SS:ESP 0068:f2799dd8 [ 47.513225] ---[ end trace 4957da56f1d7015c ]--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 02:55: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.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 n2G7sxmm076690 for ; Mon, 16 Mar 2009 02:55:20 -0500 X-ASG-Debug-ID: 1237190078-3cf302b20000-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 B433B1C454AC for ; Mon, 16 Mar 2009 00:54:38 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ePRph06MFAEt0Rg6 for ; Mon, 16 Mar 2009 00:54:38 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj7eB-0005JI-VF for xfs@oss.sgi.com; Mon, 16 Mar 2009 07:54:07 +0000 Date: Mon, 16 Mar 2009 03:54:07 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: validate quota log items during log recovery Subject: Re: [PATCH] xfs: validate quota log items during log recovery Message-ID: <20090316075407.GB19858@infradead.org> References: <20090303175427.GA20582@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090303175427.GA20582@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: 1237190078 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 ping? On Tue, Mar 03, 2009 at 12:54:27PM -0500, Christoph Hellwig wrote: > 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< + > + memcpy(xfs_buf_offset(bp, > + (uint)bit << XFS_BLI_SHIFT), /* dest */ > + item->ri_buf[i].i_addr, /* source */ > + nbits< + next: > i++; > bit += nbits; > } > @@ -2615,7 +2625,15 @@ xlog_recover_do_dquot_trans( > return (0); > > recddq = (xfs_disk_dquot_t *)item->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. > */ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 02:56:11 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_42, J_CHICKENPOX_45,J_CHICKENPOX_63,J_CHICKENPOX_64 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 n2G7topu076778 for ; Mon, 16 Mar 2009 02:56:11 -0500 X-ASG-Debug-ID: 1237190129-3cf402a00000-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 0B74B1C45511 for ; Mon, 16 Mar 2009 00:55:29 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id VJDo2SJxNBPD6xPv for ; Mon, 16 Mar 2009 00:55:29 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj7fV-0005p0-Ij for xfs@oss.sgi.com; Mon, 16 Mar 2009 07:55:29 +0000 Date: Mon, 16 Mar 2009 03:55:29 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: kill xfs_qmops Subject: Re: [PATCH] xfs: kill xfs_qmops Message-ID: <20090316075529.GA22373@infradead.org> References: <20090224143736.GA16616@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224143736.GA16616@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: 1237190130 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 ping? On Tue, Feb 24, 2009 at 09:37:36AM -0500, Christoph Hellwig wrote: > > Kill the quota ops function vector and replace it with direct calls or > stubs in the CONFIG_XFS_QUOTA=n case. > > Make sure we check XFS_IS_QUOTA_RUNNING in the right spots. We can remove > the number of those checks because the XFS_TRANS_DQ_DIRTY flag can't be set > otherwise. > > This brings us back closer to the way this code worked in IRIX and earlier > Linux versions, but we keep a lot of the more useful factoring of common > code. > > Eventually we should also kill xfs_qm_bhv.c, but that's left for a later > patch. > > Reduces the size of the source code by about 250 lines and the size of > XFS module by about 1.5 kilobytes with quotas enabled: > > text data bss dec hex filename > 615957 2960 3848 622765 980ad fs/xfs/xfs.o > 617231 3152 3848 624231 98667 fs/xfs/xfs.o.old > > > Fallout: > > - xfs_qm_dqattach is split into xfs_qm_dqattach_locked which expects > the inode locked and xfs_qm_dqattach which does the locking around it, > thus removing XFS_QMOPT_ILOCKED. > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/quota/xfs_trans_dquot.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2009-02-24 15:32:16.063369993 +0100 > +++ xfs/fs/xfs/quota/xfs_trans_dquot.c 2009-02-24 15:32:35.845494182 +0100 > @@ -111,7 +111,7 @@ xfs_trans_log_dquot( > * Carry forward whatever is left of the quota blk reservation to > * the spanky new transaction > */ > -STATIC void > +void > xfs_trans_dup_dqinfo( > xfs_trans_t *otp, > xfs_trans_t *ntp) > @@ -167,19 +167,17 @@ xfs_trans_dup_dqinfo( > /* > * Wrap around mod_dquot to account for both user and group quotas. > */ > -STATIC void > +void > xfs_trans_mod_dquot_byino( > xfs_trans_t *tp, > xfs_inode_t *ip, > uint field, > long delta) > { > - xfs_mount_t *mp; > + xfs_mount_t *mp = tp->t_mountp; > > - ASSERT(tp); > - mp = tp->t_mountp; > - > - if (!XFS_IS_QUOTA_ON(mp) || > + if (!XFS_IS_QUOTA_RUNNING(mp) || > + !XFS_IS_QUOTA_ON(mp) || > ip->i_ino == mp->m_sb.sb_uquotino || > ip->i_ino == mp->m_sb.sb_gquotino) > return; > @@ -229,6 +227,7 @@ xfs_trans_mod_dquot( > xfs_dqtrx_t *qtrx; > > ASSERT(tp); > + ASSERT(XFS_IS_QUOTA_RUNNING(tp->t_mountp)); > qtrx = NULL; > > if (tp->t_dqinfo == NULL) > @@ -346,7 +345,7 @@ xfs_trans_dqlockedjoin( > * Unreserve just the reservations done by this transaction. > * dquot is still left locked at exit. > */ > -STATIC void > +void > xfs_trans_apply_dquot_deltas( > xfs_trans_t *tp) > { > @@ -357,7 +356,7 @@ xfs_trans_apply_dquot_deltas( > long totalbdelta; > long totalrtbdelta; > > - if (! (tp->t_flags & XFS_TRANS_DQ_DIRTY)) > + if (!(tp->t_flags & XFS_TRANS_DQ_DIRTY)) > return; > > ASSERT(tp->t_dqinfo); > @@ -531,7 +530,7 @@ xfs_trans_apply_dquot_deltas( > * we simply throw those away, since that's the expected behavior > * when a transaction is curtailed without a commit. > */ > -STATIC void > +void > xfs_trans_unreserve_and_mod_dquots( > xfs_trans_t *tp) > { > @@ -768,6 +767,8 @@ xfs_trans_reserve_quota_bydquots( > { > int resvd = 0, error; > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return 0; > if (!XFS_IS_QUOTA_ON(mp)) > return 0; > > @@ -811,17 +812,18 @@ xfs_trans_reserve_quota_bydquots( > * This doesn't change the actual usage, just the reservation. > * The inode sent in is locked. > */ > -STATIC int > +int > xfs_trans_reserve_quota_nblks( > - xfs_trans_t *tp, > - xfs_mount_t *mp, > - xfs_inode_t *ip, > - long nblks, > - long ninos, > - uint flags) > + struct xfs_trans *tp, > + struct xfs_inode *ip, > + long nblks, > + long ninos, > + uint flags) > { > - int error; > + struct xfs_mount *mp = ip->i_mount; > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return 0; > if (!XFS_IS_QUOTA_ON(mp)) > return 0; > if (XFS_IS_PQUOTA_ON(mp)) > @@ -831,7 +833,6 @@ xfs_trans_reserve_quota_nblks( > ASSERT(ip->i_ino != mp->m_sb.sb_gquotino); > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > - ASSERT(XFS_IS_QUOTA_RUNNING(ip->i_mount)); > ASSERT((flags & ~(XFS_QMOPT_FORCE_RES | XFS_QMOPT_ENOSPC)) == > XFS_TRANS_DQ_RES_RTBLKS || > (flags & ~(XFS_QMOPT_FORCE_RES | XFS_QMOPT_ENOSPC)) == > @@ -840,11 +841,9 @@ xfs_trans_reserve_quota_nblks( > /* > * Reserve nblks against these dquots, with trans as the mediator. > */ > - error = xfs_trans_reserve_quota_bydquots(tp, mp, > - ip->i_udquot, ip->i_gdquot, > - nblks, ninos, > - flags); > - return error; > + return xfs_trans_reserve_quota_bydquots(tp, mp, > + ip->i_udquot, ip->i_gdquot, > + nblks, ninos, flags); > } > > /* > @@ -895,25 +894,15 @@ STATIC void > xfs_trans_alloc_dqinfo( > xfs_trans_t *tp) > { > - (tp)->t_dqinfo = kmem_zone_zalloc(xfs_Gqm->qm_dqtrxzone, KM_SLEEP); > + tp->t_dqinfo = kmem_zone_zalloc(xfs_Gqm->qm_dqtrxzone, KM_SLEEP); > } > > -STATIC void > +void > xfs_trans_free_dqinfo( > xfs_trans_t *tp) > { > if (!tp->t_dqinfo) > return; > - kmem_zone_free(xfs_Gqm->qm_dqtrxzone, (tp)->t_dqinfo); > - (tp)->t_dqinfo = NULL; > + kmem_zone_free(xfs_Gqm->qm_dqtrxzone, tp->t_dqinfo); > + tp->t_dqinfo = NULL; > } > - > -xfs_dqtrxops_t xfs_trans_dquot_ops = { > - .qo_dup_dqinfo = xfs_trans_dup_dqinfo, > - .qo_free_dqinfo = xfs_trans_free_dqinfo, > - .qo_mod_dquot_byino = xfs_trans_mod_dquot_byino, > - .qo_apply_dquot_deltas = xfs_trans_apply_dquot_deltas, > - .qo_reserve_quota_nblks = xfs_trans_reserve_quota_nblks, > - .qo_reserve_quota_bydquots = xfs_trans_reserve_quota_bydquots, > - .qo_unreserve_and_mod_dquots = xfs_trans_unreserve_and_mod_dquots, > -}; > Index: xfs/fs/xfs/xfs_quota.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_quota.h 2009-02-24 15:32:16.089369812 +0100 > +++ xfs/fs/xfs/xfs_quota.h 2009-02-24 15:32:35.846494310 +0100 > @@ -197,7 +197,6 @@ typedef struct xfs_qoff_logformat { > #define XFS_QMOPT_UMOUNTING 0x0000100 /* filesys is being unmounted */ > #define XFS_QMOPT_DOLOG 0x0000200 /* log buf changes (in quotacheck) */ > #define XFS_QMOPT_DOWARN 0x0000400 /* increase warning cnt if needed */ > -#define XFS_QMOPT_ILOCKED 0x0000800 /* inode is already locked (excl) */ > #define XFS_QMOPT_DQREPAIR 0x0001000 /* repair dquot if damaged */ > #define XFS_QMOPT_GQUOTA 0x0002000 /* group dquot requested */ > #define XFS_QMOPT_ENOSPC 0x0004000 /* enospc instead of edquot (prj) */ > @@ -302,69 +301,72 @@ typedef struct xfs_dqtrx { > long qt_delrtb_delta; /* delayed RT blk count changes */ > } xfs_dqtrx_t; > > -/* > - * Dquot transaction functions, used if quota is enabled. > - */ > -typedef void (*qo_dup_dqinfo_t)(struct xfs_trans *, struct xfs_trans *); > -typedef void (*qo_mod_dquot_byino_t)(struct xfs_trans *, > - struct xfs_inode *, uint, long); > -typedef void (*qo_free_dqinfo_t)(struct xfs_trans *); > -typedef void (*qo_apply_dquot_deltas_t)(struct xfs_trans *); > -typedef void (*qo_unreserve_and_mod_dquots_t)(struct xfs_trans *); > -typedef int (*qo_reserve_quota_nblks_t)( > - struct xfs_trans *, struct xfs_mount *, > - struct xfs_inode *, long, long, uint); > -typedef int (*qo_reserve_quota_bydquots_t)( > - struct xfs_trans *, struct xfs_mount *, > - struct xfs_dquot *, struct xfs_dquot *, > - long, long, uint); > -typedef struct xfs_dqtrxops { > - qo_dup_dqinfo_t qo_dup_dqinfo; > - qo_free_dqinfo_t qo_free_dqinfo; > - qo_mod_dquot_byino_t qo_mod_dquot_byino; > - qo_apply_dquot_deltas_t qo_apply_dquot_deltas; > - qo_reserve_quota_nblks_t qo_reserve_quota_nblks; > - qo_reserve_quota_bydquots_t qo_reserve_quota_bydquots; > - qo_unreserve_and_mod_dquots_t qo_unreserve_and_mod_dquots; > -} xfs_dqtrxops_t; > - > -#define XFS_DQTRXOP(mp, tp, op, args...) \ > - ((mp)->m_qm_ops->xfs_dqtrxops ? \ > - ((mp)->m_qm_ops->xfs_dqtrxops->op)(tp, ## args) : 0) > - > -#define XFS_DQTRXOP_VOID(mp, tp, op, args...) \ > - ((mp)->m_qm_ops->xfs_dqtrxops ? \ > - ((mp)->m_qm_ops->xfs_dqtrxops->op)(tp, ## args) : (void)0) > - > -#define XFS_TRANS_DUP_DQINFO(mp, otp, ntp) \ > - XFS_DQTRXOP_VOID(mp, otp, qo_dup_dqinfo, ntp) > -#define XFS_TRANS_FREE_DQINFO(mp, tp) \ > - XFS_DQTRXOP_VOID(mp, tp, qo_free_dqinfo) > -#define XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, field, delta) \ > - XFS_DQTRXOP_VOID(mp, tp, qo_mod_dquot_byino, ip, field, delta) > -#define XFS_TRANS_APPLY_DQUOT_DELTAS(mp, tp) \ > - XFS_DQTRXOP_VOID(mp, tp, qo_apply_dquot_deltas) > -#define XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, nblks, ninos, fl) \ > - XFS_DQTRXOP(mp, tp, qo_reserve_quota_nblks, mp, ip, nblks, ninos, fl) > -#define XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, nb, ni, fl) \ > - XFS_DQTRXOP(mp, tp, qo_reserve_quota_bydquots, mp, ud, gd, nb, ni, fl) > -#define XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp) \ > - XFS_DQTRXOP_VOID(mp, tp, qo_unreserve_and_mod_dquots) > - > -#define XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, nblks, ninos, flags) \ > - XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, -(nblks), -(ninos), flags) > -#define XFS_TRANS_RESERVE_QUOTA(mp, tp, ud, gd, nb, ni, f) \ > - XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, nb, ni, \ > - f | XFS_QMOPT_RES_REGBLKS) > -#define XFS_TRANS_UNRESERVE_QUOTA(mp, tp, ud, gd, nb, ni, f) \ > - XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, -(nb), -(ni), \ > +#ifdef CONFIG_XFS_QUOTA > +extern void xfs_trans_dup_dqinfo(struct xfs_trans *, struct xfs_trans *); > +extern void xfs_trans_free_dqinfo(struct xfs_trans *); > +extern void xfs_trans_mod_dquot_byino(struct xfs_trans *, struct xfs_inode *, > + uint, long); > +extern void xfs_trans_apply_dquot_deltas(struct xfs_trans *); > +extern void xfs_trans_unreserve_and_mod_dquots(struct xfs_trans *); > +extern int xfs_trans_reserve_quota_nblks(struct xfs_trans *, > + struct xfs_inode *, long, long, uint); > +extern int xfs_trans_reserve_quota_bydquots(struct xfs_trans *, > + struct xfs_mount *, struct xfs_dquot *, > + struct xfs_dquot *, long, long, uint); > + > +extern int xfs_qm_vop_dqalloc(struct xfs_inode *, uid_t, gid_t, prid_t, uint, > + struct xfs_dquot **, struct xfs_dquot **); > +extern void xfs_qm_vop_create_dqattach(struct xfs_trans *, struct xfs_inode *, > + struct xfs_dquot *, struct xfs_dquot *); > +extern int xfs_qm_vop_rename_dqattach(struct xfs_inode **); > +extern struct xfs_dquot *xfs_qm_vop_chown(struct xfs_trans *, > + struct xfs_inode *, struct xfs_dquot **, struct xfs_dquot *); > +extern int xfs_qm_vop_chown_reserve(struct xfs_trans *, struct xfs_inode *, > + struct xfs_dquot *, struct xfs_dquot *, uint); > +extern int xfs_qm_dqattach(struct xfs_inode *, uint); > +extern int xfs_qm_dqattach_locked(struct xfs_inode *, uint); > +extern void xfs_qm_dqdetach(struct xfs_inode *); > +extern void xfs_qm_dqrele(struct xfs_dquot *); > +extern void xfs_qm_statvfs(struct xfs_inode *, struct kstatfs *); > +extern int xfs_qm_sync(struct xfs_mount *, int); > +extern int xfs_qm_newmount(struct xfs_mount *, uint *, uint *); > +extern void xfs_qm_mount_quotas(struct xfs_mount *); > +extern void xfs_qm_unmount(struct xfs_mount *); > +extern void xfs_qm_unmount_quotas(struct xfs_mount *); > + > +#else > +#define xfs_trans_dup_dqinfo(tp, tp2) > +#define xfs_trans_free_dqinfo(tp) > +#define xfs_trans_mod_dquot_byino(tp, ip, fields, delta) > +#define xfs_trans_apply_dquot_deltas(tp) > +#define xfs_trans_unreserve_and_mod_dquots(tp) > +#define xfs_trans_reserve_quota_nblks(tp, ip, nblks, ninos, flags) (0) > +#define xfs_trans_reserve_quota_bydquots(tp, mp, u, g, nb, ni, fl) (0) > +#define xfs_qm_vop_dqalloc(ip, uid, gid, prid, fl, ou, og) (0) > +#define xfs_qm_vop_create_dqattach(tp, ip, u, g) > +#define xfs_qm_vop_rename_dqattach(it) (0) > +#define xfs_qm_vop_chown(tp, ip, old, new) (NULL) > +#define xfs_qm_vop_chown_reserve(tp, ip, u, g, fl) (0) > +#define xfs_qm_dqattach(ip, fl) (0) > +#define xfs_qm_dqattach_locked(ip, fl) (0) > +#define xfs_qm_dqdetach(ip) > +#define xfs_qm_dqrele(d) > +#define xfs_qm_statvfs(ip, s) > +#define xfs_qm_sync(mp, fl) (0) > +#define xfs_qm_newmount(mp, a, b) (0) > +#define xfs_qm_mount_quotas(mp) > +#define xfs_qm_unmount(mp) > +#define xfs_qm_unmount_quotas(mp) (0) > +#endif /* CONFIG_XFS_QUOTA */ > + > +#define xfs_trans_unreserve_quota_nblks(tp, ip, nblks, ninos, flags) \ > + xfs_trans_reserve_quota_nblks(tp, ip, -(nblks), -(ninos), flags) > +#define xfs_trans_reserve_quota(tp, mp, ud, gd, nb, ni, f) \ > + xfs_trans_reserve_quota_bydquots(tp, mp, ud, gd, nb, ni, \ > f | XFS_QMOPT_RES_REGBLKS) > > extern int xfs_qm_dqcheck(xfs_disk_dquot_t *, xfs_dqid_t, uint, uint, char *); > extern int xfs_mount_reset_sbqflags(struct xfs_mount *); > > -extern struct xfs_qmops xfs_qmcore_xfs; > - > #endif /* __KERNEL__ */ > - > #endif /* __XFS_QUOTA_H__ */ > Index: xfs/fs/xfs/xfs_trans.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_trans.c 2009-02-24 15:32:16.093370321 +0100 > +++ xfs/fs/xfs/xfs_trans.c 2009-02-24 15:32:35.847494368 +0100 > @@ -297,7 +297,7 @@ xfs_trans_dup( > tp->t_rtx_res = tp->t_rtx_res_used; > ntp->t_pflags = tp->t_pflags; > > - XFS_TRANS_DUP_DQINFO(tp->t_mountp, tp, ntp); > + xfs_trans_dup_dqinfo(tp, ntp); > > atomic_inc(&tp->t_mountp->m_active_trans); > return ntp; > @@ -831,7 +831,7 @@ shut_us_down: > * means is that we have some (non-persistent) quota > * reservations that need to be unreserved. > */ > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp); > + xfs_trans_unreserve_and_mod_dquots(tp); > if (tp->t_ticket) { > commit_lsn = xfs_log_done(mp, tp->t_ticket, > NULL, log_flags); > @@ -850,10 +850,9 @@ shut_us_down: > /* > * If we need to update the superblock, then do it now. > */ > - if (tp->t_flags & XFS_TRANS_SB_DIRTY) { > + if (tp->t_flags & XFS_TRANS_SB_DIRTY) > xfs_trans_apply_sb_deltas(tp); > - } > - XFS_TRANS_APPLY_DQUOT_DELTAS(mp, tp); > + xfs_trans_apply_dquot_deltas(tp); > > /* > * Ask each log item how many log_vector entries it will > @@ -1058,7 +1057,7 @@ xfs_trans_uncommit( > } > > xfs_trans_unreserve_and_mod_sb(tp); > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(tp->t_mountp, tp); > + xfs_trans_unreserve_and_mod_dquots(tp); > > xfs_trans_free_items(tp, flags); > xfs_trans_free_busy(tp); > @@ -1183,7 +1182,7 @@ xfs_trans_cancel( > } > #endif > xfs_trans_unreserve_and_mod_sb(tp); > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp); > + xfs_trans_unreserve_and_mod_dquots(tp); > > if (tp->t_ticket) { > if (flags & XFS_TRANS_RELEASE_LOG_RES) { > @@ -1213,7 +1212,7 @@ xfs_trans_free( > xfs_trans_t *tp) > { > atomic_dec(&tp->t_mountp->m_active_trans); > - XFS_TRANS_FREE_DQINFO(tp->t_mountp, tp); > + xfs_trans_free_dqinfo(tp); > kmem_zone_free(xfs_trans_zone, tp); > } > > Index: xfs/fs/xfs/xfs_utils.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_utils.c 2009-02-24 15:32:16.098369701 +0100 > +++ xfs/fs/xfs/xfs_utils.c 2009-02-24 15:32:35.848494914 +0100 > @@ -166,7 +166,7 @@ xfs_dir_ialloc( > xfs_buf_relse(ialloc_context); > if (dqinfo) { > tp->t_dqinfo = dqinfo; > - XFS_TRANS_FREE_DQINFO(tp->t_mountp, tp); > + xfs_trans_free_dqinfo(tp); > } > *tpp = ntp; > *ipp = NULL; > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-24 15:32:16.102370140 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-24 15:32:35.853494922 +0100 > @@ -2691,7 +2691,7 @@ xfs_bmap_rtalloc( > * Adjust the disk quota also. This was reserved > * earlier. > */ > - XFS_TRANS_MOD_DQUOT_BYINO(mp, ap->tp, ap->ip, > + xfs_trans_mod_dquot_byino(ap->tp, ap->ip, > ap->wasdel ? XFS_TRANS_DQ_DELRTBCOUNT : > XFS_TRANS_DQ_RTBCOUNT, (long) ralen); > } else { > @@ -2995,7 +2995,7 @@ xfs_bmap_btalloc( > * Adjust the disk quota also. This was reserved > * earlier. > */ > - XFS_TRANS_MOD_DQUOT_BYINO(mp, ap->tp, ap->ip, > + xfs_trans_mod_dquot_byino(ap->tp, ap->ip, > ap->wasdel ? XFS_TRANS_DQ_DELBCOUNT : > XFS_TRANS_DQ_BCOUNT, > (long) args.len); > @@ -3066,7 +3066,7 @@ xfs_bmap_btree_to_extents( > return error; > xfs_bmap_add_free(cbno, 1, cur->bc_private.b.flist, mp); > ip->i_d.di_nblocks--; > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > xfs_trans_binval(tp, cbp); > if (cur->bc_bufs[0] == cbp) > cur->bc_bufs[0] = NULL; > @@ -3386,7 +3386,7 @@ xfs_bmap_del_extent( > * Adjust quota data. > */ > if (qfield) > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, qfield, (long)-nblks); > + xfs_trans_mod_dquot_byino(tp, ip, qfield, (long)-nblks); > > /* > * Account for change in delayed indirect blocks. > @@ -3523,7 +3523,7 @@ xfs_bmap_extents_to_btree( > *firstblock = cur->bc_private.b.firstblock = args.fsbno; > cur->bc_private.b.allocated++; > ip->i_d.di_nblocks++; > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, 1L); > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, 1L); > abp = xfs_btree_get_bufl(mp, tp, args.fsbno, 0); > /* > * Fill in the child block. > @@ -3666,7 +3666,7 @@ xfs_bmap_local_to_extents( > XFS_BMAP_TRACE_POST_UPDATE("new", ip, 0, whichfork); > XFS_IFORK_NEXT_SET(ip, whichfork, 1); > ip->i_d.di_nblocks = 1; > - XFS_TRANS_MOD_DQUOT_BYINO(args.mp, tp, ip, > + xfs_trans_mod_dquot_byino(tp, ip, > XFS_TRANS_DQ_BCOUNT, 1L); > flags |= xfs_ilog_fext(whichfork); > } else { > @@ -4024,7 +4024,7 @@ xfs_bmap_add_attrfork( > XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) > goto error0; > xfs_ilock(ip, XFS_ILOCK_EXCL); > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? > + error = xfs_trans_reserve_quota_nblks(tp, ip, blks, 0, rsvd ? > XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : > XFS_QMOPT_RES_REGBLKS); > if (error) { > @@ -4959,10 +4959,11 @@ xfs_bmapi( > * adjusted later. We return if we haven't > * allocated blocks already inside this loop. > */ > - if ((error = XFS_TRANS_RESERVE_QUOTA_NBLKS( > - mp, NULL, ip, (long)alen, 0, > + error = xfs_trans_reserve_quota_nblks( > + NULL, ip, (long)alen, 0, > rt ? XFS_QMOPT_RES_RTBLKS : > - XFS_QMOPT_RES_REGBLKS))) { > + XFS_QMOPT_RES_REGBLKS); > + if (error) { > if (n == 0) { > *nmap = 0; > ASSERT(cur == NULL); > @@ -5011,8 +5012,8 @@ xfs_bmapi( > if (XFS_IS_QUOTA_ON(mp)) > /* unreserve the blocks now */ > (void) > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS( > - mp, NULL, ip, > + xfs_trans_unreserve_quota_nblks( > + NULL, ip, > (long)alen, 0, rt ? > XFS_QMOPT_RES_RTBLKS : > XFS_QMOPT_RES_REGBLKS); > @@ -5667,14 +5668,14 @@ xfs_bunmapi( > do_div(rtexts, mp->m_sb.sb_rextsize); > xfs_mod_incore_sb(mp, XFS_SBS_FREXTENTS, > (int64_t)rtexts, rsvd); > - (void)XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, > - NULL, ip, -((long)del.br_blockcount), 0, > + (void)xfs_trans_reserve_quota_nblks(NULL, > + ip, -((long)del.br_blockcount), 0, > XFS_QMOPT_RES_RTBLKS); > } else { > xfs_mod_incore_sb(mp, XFS_SBS_FDBLOCKS, > (int64_t)del.br_blockcount, rsvd); > - (void)XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, > - NULL, ip, -((long)del.br_blockcount), 0, > + (void)xfs_trans_reserve_quota_nblks(NULL, > + ip, -((long)del.br_blockcount), 0, > XFS_QMOPT_RES_REGBLKS); > } > ip->i_delayed_blks -= del.br_blockcount; > Index: xfs/fs/xfs/xfs_bmap_btree.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap_btree.c 2009-02-24 15:32:16.106369811 +0100 > +++ xfs/fs/xfs/xfs_bmap_btree.c 2009-02-24 15:32:35.854494491 +0100 > @@ -590,7 +590,7 @@ xfs_bmbt_alloc_block( > cur->bc_private.b.allocated++; > cur->bc_private.b.ip->i_d.di_nblocks++; > xfs_trans_log_inode(args.tp, cur->bc_private.b.ip, XFS_ILOG_CORE); > - XFS_TRANS_MOD_DQUOT_BYINO(args.mp, args.tp, cur->bc_private.b.ip, > + xfs_trans_mod_dquot_byino(args.tp, cur->bc_private.b.ip, > XFS_TRANS_DQ_BCOUNT, 1L); > > new->l = cpu_to_be64(args.fsbno); > @@ -618,7 +618,7 @@ xfs_bmbt_free_block( > ip->i_d.di_nblocks--; > > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > xfs_trans_binval(tp, bp); > return 0; > } > Index: xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_vnodeops.c 2009-02-24 15:32:16.111370238 +0100 > +++ xfs/fs/xfs/xfs_vnodeops.c 2009-02-24 15:32:35.855495805 +0100 > @@ -118,7 +118,7 @@ xfs_setattr( > */ > ASSERT(udqp == NULL); > ASSERT(gdqp == NULL); > - code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, ip->i_d.di_projid, > + code = xfs_qm_vop_dqalloc(ip, uid, gid, ip->i_d.di_projid, > qflags, &udqp, &gdqp); > if (code) > return code; > @@ -183,7 +183,7 @@ xfs_setattr( > if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) || > (XFS_IS_GQUOTA_ON(mp) && igid != gid)) { > ASSERT(tp); > - code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > + code = xfs_qm_vop_chown_reserve(tp, ip, udqp, gdqp, > capable(CAP_FOWNER) ? > XFS_QMOPT_FORCE_RES : 0); > if (code) /* out of quota */ > @@ -217,7 +217,7 @@ xfs_setattr( > /* > * Make sure that the dquots are attached to the inode. > */ > - code = XFS_QM_DQATTACH(mp, ip, XFS_QMOPT_ILOCKED); > + code = xfs_qm_dqattach_locked(ip, 0); > if (code) > goto error_return; > > @@ -354,7 +354,7 @@ xfs_setattr( > if (XFS_IS_UQUOTA_ON(mp)) { > ASSERT(mask & ATTR_UID); > ASSERT(udqp); > - olddquot1 = XFS_QM_DQVOPCHOWN(mp, tp, ip, > + olddquot1 = xfs_qm_vop_chown(tp, ip, > &ip->i_udquot, udqp); > } > ip->i_d.di_uid = uid; > @@ -365,7 +365,7 @@ xfs_setattr( > ASSERT(!XFS_IS_PQUOTA_ON(mp)); > ASSERT(mask & ATTR_GID); > ASSERT(gdqp); > - olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, > + olddquot2 = xfs_qm_vop_chown(tp, ip, > &ip->i_gdquot, gdqp); > } > ip->i_d.di_gid = gid; > @@ -461,10 +461,10 @@ xfs_setattr( > /* > * Release any dquot(s) the inode had kept before chown. > */ > - XFS_QM_DQRELE(mp, olddquot1); > - XFS_QM_DQRELE(mp, olddquot2); > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(olddquot1); > + xfs_qm_dqrele(olddquot2); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > if (code) { > return code; > @@ -482,8 +482,8 @@ xfs_setattr( > commit_flags |= XFS_TRANS_ABORT; > /* FALLTHROUGH */ > error_return: > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > if (tp) { > xfs_trans_cancel(tp, commit_flags); > } > @@ -739,7 +739,8 @@ xfs_free_eofblocks( > /* > * Attach the dquots to the inode up front. > */ > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > + error = xfs_qm_dqattach(ip, 0); > + if (error) > return error; > > /* > @@ -1181,7 +1182,8 @@ xfs_inactive( > > ASSERT(ip->i_d.di_nlink == 0); > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > + error = xfs_qm_dqattach(ip, 0); > + if (error) > return VN_INACTIVE_CACHE; > > tp = xfs_trans_alloc(mp, XFS_TRANS_INACTIVE); > @@ -1307,7 +1309,7 @@ xfs_inactive( > /* > * Credit the quota account(s). The inode is gone. > */ > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_ICOUNT, -1); > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_ICOUNT, -1); > > /* > * Just ignore errors at this point. There is nothing we can > @@ -1323,11 +1325,11 @@ xfs_inactive( > xfs_fs_cmn_err(CE_NOTE, mp, "xfs_inactive: " > "xfs_trans_commit() returned error %d", error); > } > + > /* > * Release the dquots held by inode, if any. > */ > - XFS_QM_DQDETACH(mp, ip); > - > + xfs_qm_dqdetach(ip); > xfs_iunlock(ip, XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL); > > out: > @@ -1398,14 +1400,16 @@ xfs_create( > uint cancel_flags; > int committed; > xfs_prid_t prid; > - struct xfs_dquot *udqp = NULL; > - struct xfs_dquot *gdqp = NULL; > + struct xfs_dquot *udqp, *gdqp; > uint resblks; > uint log_res; > uint log_count; > > xfs_itrace_entry(dp); > > + udqp = NULL; > + gdqp = NULL; > + > if (XFS_FORCED_SHUTDOWN(mp)) > return XFS_ERROR(EIO); > > @@ -1427,8 +1431,7 @@ xfs_create( > /* > * Make sure that we have allocated dquot(s) on disk. > */ > - error = XFS_QM_DQVOPALLOC(mp, dp, > - current_fsuid(), current_fsgid(), prid, > + error = xfs_qm_vop_dqalloc(dp, current_fsuid(), current_fsgid(), prid, > XFS_QMOPT_QUOTALL | XFS_QMOPT_INHERIT, &udqp, &gdqp); > if (error) > goto std_return; > @@ -1482,7 +1485,7 @@ xfs_create( > /* > * Reserve disk quota and the inode. > */ > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, udqp, gdqp, resblks, 1, 0); > + error = xfs_trans_reserve_quota(tp, mp, udqp, gdqp, resblks, 1, 0); > if (error) > goto out_trans_cancel; > > @@ -1554,7 +1557,7 @@ xfs_create( > * These ids of the inode couldn't have changed since the new > * inode has been locked ever since it was created. > */ > - XFS_QM_DQVOPCREATE(mp, tp, ip, udqp, gdqp); > + xfs_qm_vop_create_dqattach(tp, ip, udqp, gdqp); > > /* > * xfs_trans_commit normally decrements the vnode ref count > @@ -1573,8 +1576,8 @@ xfs_create( > goto out_dqrele; > } > > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > *ipp = ip; > > @@ -1595,8 +1598,8 @@ xfs_create( > out_trans_cancel: > xfs_trans_cancel(tp, cancel_flags); > out_dqrele: > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > if (unlock_dp_on_error) > xfs_iunlock(dp, XFS_ILOCK_EXCL); > @@ -1830,11 +1833,11 @@ xfs_remove( > return error; > } > > - error = XFS_QM_DQATTACH(mp, dp, 0); > + error = xfs_qm_dqattach(dp, 0); > if (error) > goto std_return; > > - error = XFS_QM_DQATTACH(mp, ip, 0); > + error = xfs_qm_dqattach(ip, 0); > if (error) > goto std_return; > > @@ -2021,11 +2024,11 @@ xfs_link( > > /* Return through std_return after this point. */ > > - error = XFS_QM_DQATTACH(mp, sip, 0); > + error = xfs_qm_dqattach(sip, 0); > if (error) > goto std_return; > > - error = XFS_QM_DQATTACH(mp, tdp, 0); > + error = xfs_qm_dqattach(tdp, 0); > if (error) > goto std_return; > > @@ -2198,8 +2201,7 @@ xfs_symlink( > /* > * Make sure that we have allocated dquot(s) on disk. > */ > - error = XFS_QM_DQVOPALLOC(mp, dp, > - current_fsuid(), current_fsgid(), prid, > + error = xfs_qm_vop_dqalloc(dp, current_fsuid(), current_fsgid(), prid, > XFS_QMOPT_QUOTALL | XFS_QMOPT_INHERIT, &udqp, &gdqp); > if (error) > goto std_return; > @@ -2241,7 +2243,7 @@ xfs_symlink( > /* > * Reserve disk quota : blocks and inode. > */ > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, udqp, gdqp, resblks, 1, 0); > + error = xfs_trans_reserve_quota(tp, mp, udqp, gdqp, resblks, 1, 0); > if (error) > goto error_return; > > @@ -2281,7 +2283,7 @@ xfs_symlink( > /* > * Also attach the dquot(s) to it, if applicable. > */ > - XFS_QM_DQVOPCREATE(mp, tp, ip, udqp, gdqp); > + xfs_qm_vop_create_dqattach(tp, ip, udqp, gdqp); > > if (resblks) > resblks -= XFS_IALLOC_SPACE_RES(mp); > @@ -2369,8 +2371,8 @@ xfs_symlink( > goto error2; > } > error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > /* Fall through to std_return with error = 0 or errno from > * xfs_trans_commit */ > @@ -2394,8 +2396,8 @@ std_return: > cancel_flags |= XFS_TRANS_ABORT; > error_return: > xfs_trans_cancel(tp, cancel_flags); > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > if (unlock_dp_on_error) > xfs_iunlock(dp, XFS_ILOCK_EXCL); > @@ -2534,7 +2536,8 @@ xfs_alloc_file_space( > if (XFS_FORCED_SHUTDOWN(mp)) > return XFS_ERROR(EIO); > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > + error = xfs_qm_dqattach(ip, 0); > + if (error) > return error; > > if (len <= 0) > @@ -2621,8 +2624,8 @@ retry: > break; > } > xfs_ilock(ip, XFS_ILOCK_EXCL); > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, > - qblocks, 0, quota_flag); > + error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks, > + 0, quota_flag); > if (error) > goto error1; > > @@ -2681,7 +2684,7 @@ dmapi_enospc_check: > > error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ > xfs_bmap_cancel(&free_list); > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, qblocks, 0, quota_flag); > + xfs_trans_unreserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > > error1: /* Just cancel transaction */ > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT); > @@ -2820,7 +2823,8 @@ xfs_free_file_space( > > xfs_itrace_entry(ip); > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > + error = xfs_qm_dqattach(ip, 0); > + if (error) > return error; > > error = 0; > @@ -2946,9 +2950,9 @@ xfs_free_file_space( > break; > } > xfs_ilock(ip, XFS_ILOCK_EXCL); > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, > - ip->i_udquot, ip->i_gdquot, resblks, 0, > - XFS_QMOPT_RES_REGBLKS); > + error = xfs_trans_reserve_quota(tp, mp, > + ip->i_udquot, ip->i_gdquot, > + resblks, 0, XFS_QMOPT_RES_REGBLKS); > if (error) > goto error1; > > Index: xfs/fs/xfs/quota/xfs_qm.h > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm.h 2009-02-24 15:32:16.067369944 +0100 > +++ xfs/fs/xfs/quota/xfs_qm.h 2009-02-24 15:32:35.856495653 +0100 > @@ -127,8 +127,6 @@ typedef struct xfs_quotainfo { > } xfs_quotainfo_t; > > > -extern xfs_dqtrxops_t xfs_trans_dquot_ops; > - > extern void xfs_trans_mod_dquot(xfs_trans_t *, xfs_dquot_t *, uint, long); > extern int xfs_trans_reserve_quota_bydquots(xfs_trans_t *, xfs_mount_t *, > xfs_dquot_t *, xfs_dquot_t *, long, long, uint); > @@ -159,17 +157,11 @@ typedef struct xfs_dquot_acct { > #define XFS_QM_RTBWARNLIMIT 5 > > extern void xfs_qm_destroy_quotainfo(xfs_mount_t *); > -extern void xfs_qm_mount_quotas(xfs_mount_t *); > extern int xfs_qm_quotacheck(xfs_mount_t *); > -extern void xfs_qm_unmount_quotadestroy(xfs_mount_t *); > -extern void xfs_qm_unmount_quotas(xfs_mount_t *); > extern int xfs_qm_write_sb_changes(xfs_mount_t *, __int64_t); > -extern int xfs_qm_sync(xfs_mount_t *, int); > > /* dquot stuff */ > extern boolean_t xfs_qm_dqalloc_incore(xfs_dquot_t **); > -extern int xfs_qm_dqattach(xfs_inode_t *, uint); > -extern void xfs_qm_dqdetach(xfs_inode_t *); > extern int xfs_qm_dqpurge_all(xfs_mount_t *, uint); > extern void xfs_qm_dqrele_all_inodes(xfs_mount_t *, uint); > > @@ -183,19 +175,6 @@ extern int xfs_qm_scall_getqstat(xfs_mo > extern int xfs_qm_scall_quotaon(xfs_mount_t *, uint); > extern int xfs_qm_scall_quotaoff(xfs_mount_t *, uint); > > -/* vop stuff */ > -extern int xfs_qm_vop_dqalloc(xfs_mount_t *, xfs_inode_t *, > - uid_t, gid_t, prid_t, uint, > - xfs_dquot_t **, xfs_dquot_t **); > -extern void xfs_qm_vop_dqattach_and_dqmod_newinode( > - xfs_trans_t *, xfs_inode_t *, > - xfs_dquot_t *, xfs_dquot_t *); > -extern int xfs_qm_vop_rename_dqattach(xfs_inode_t **); > -extern xfs_dquot_t * xfs_qm_vop_chown(xfs_trans_t *, xfs_inode_t *, > - xfs_dquot_t **, xfs_dquot_t *); > -extern int xfs_qm_vop_chown_reserve(xfs_trans_t *, xfs_inode_t *, > - xfs_dquot_t *, xfs_dquot_t *, uint); > - > /* list stuff */ > extern void xfs_qm_freelist_append(xfs_frlist_t *, xfs_dquot_t *); > extern void xfs_qm_freelist_unlink(xfs_dquot_t *); > Index: xfs/fs/xfs/quota/xfs_qm_bhv.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2009-02-24 15:32:16.071370174 +0100 > +++ xfs/fs/xfs/quota/xfs_qm_bhv.c 2009-02-24 15:32:35.856495653 +0100 > @@ -84,7 +84,7 @@ xfs_fill_statvfs_from_dquot( > * return a statvfs of the project, not the entire filesystem. > * This makes such trees appear as if they are filesystems in themselves. > */ > -STATIC void > +void > xfs_qm_statvfs( > xfs_inode_t *ip, > struct kstatfs *statp) > @@ -92,20 +92,13 @@ xfs_qm_statvfs( > xfs_mount_t *mp = ip->i_mount; > xfs_dquot_t *dqp; > > - if (!(ip->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) || > - !((mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD))) == > - (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD)) > - return; > - > if (!xfs_qm_dqget(mp, NULL, ip->i_d.di_projid, XFS_DQ_PROJ, 0, &dqp)) { > - xfs_disk_dquot_t *dp = &dqp->q_core; > - > - xfs_fill_statvfs_from_dquot(statp, dp); > + xfs_fill_statvfs_from_dquot(statp, &dqp->q_core); > xfs_qm_dqput(dqp); > } > } > > -STATIC int > +int > xfs_qm_newmount( > xfs_mount_t *mp, > uint *needquotamount, > @@ -114,9 +107,6 @@ xfs_qm_newmount( > uint quotaondisk; > uint uquotaondisk = 0, gquotaondisk = 0, pquotaondisk = 0; > > - *quotaflags = 0; > - *needquotamount = B_FALSE; > - > quotaondisk = xfs_sb_version_hasquota(&mp->m_sb) && > (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT); > > @@ -179,66 +169,6 @@ xfs_qm_newmount( > return 0; > } > > -STATIC int > -xfs_qm_endmount( > - xfs_mount_t *mp, > - uint needquotamount, > - uint quotaflags) > -{ > - if (needquotamount) { > - ASSERT(mp->m_qflags == 0); > - mp->m_qflags = quotaflags; > - xfs_qm_mount_quotas(mp); > - } > - > -#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) > - if (! (XFS_IS_QUOTA_ON(mp))) > - xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas not turned on"); > - else > - xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas turned on"); > -#endif > - > -#ifdef QUOTADEBUG > - if (XFS_IS_QUOTA_ON(mp) && xfs_qm_internalqcheck(mp)) > - cmn_err(CE_WARN, "XFS: mount internalqcheck failed"); > -#endif > - > - return 0; > -} > - > -STATIC void > -xfs_qm_dqrele_null( > - xfs_dquot_t *dq) > -{ > - /* > - * Called from XFS, where we always check first for a NULL dquot. > - */ > - if (!dq) > - return; > - xfs_qm_dqrele(dq); > -} > - > - > -struct xfs_qmops xfs_qmcore_xfs = { > - .xfs_qminit = xfs_qm_newmount, > - .xfs_qmdone = xfs_qm_unmount_quotadestroy, > - .xfs_qmmount = xfs_qm_endmount, > - .xfs_qmunmount = xfs_qm_unmount_quotas, > - .xfs_dqrele = xfs_qm_dqrele_null, > - .xfs_dqattach = xfs_qm_dqattach, > - .xfs_dqdetach = xfs_qm_dqdetach, > - .xfs_dqpurgeall = xfs_qm_dqpurge_all, > - .xfs_dqvopalloc = xfs_qm_vop_dqalloc, > - .xfs_dqvopcreate = xfs_qm_vop_dqattach_and_dqmod_newinode, > - .xfs_dqvoprename = xfs_qm_vop_rename_dqattach, > - .xfs_dqvopchown = xfs_qm_vop_chown, > - .xfs_dqvopchownresv = xfs_qm_vop_chown_reserve, > - .xfs_dqstatvfs = xfs_qm_statvfs, > - .xfs_dqsync = xfs_qm_sync, > - .xfs_dqtrxops = &xfs_trans_dquot_ops, > -}; > -EXPORT_SYMBOL(xfs_qmcore_xfs); > - > void __init > xfs_qm_init(void) > { > Index: xfs/fs/xfs/xfs_attr.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_attr.c 2009-02-24 15:32:16.115370119 +0100 > +++ xfs/fs/xfs/xfs_attr.c 2009-02-24 15:32:35.857495152 +0100 > @@ -249,8 +249,9 @@ xfs_attr_set_int(xfs_inode_t *dp, struct > /* > * Attach the dquots to the inode. > */ > - if ((error = XFS_QM_DQATTACH(mp, dp, 0))) > - return (error); > + error = xfs_qm_dqattach(dp, 0); > + if (error) > + return error; > > /* > * If the inode doesn't have an attribute fork, add one. > @@ -311,7 +312,7 @@ xfs_attr_set_int(xfs_inode_t *dp, struct > } > xfs_ilock(dp, XFS_ILOCK_EXCL); > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, > + error = xfs_trans_reserve_quota_nblks(args.trans, dp, args.total, 0, > rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : > XFS_QMOPT_RES_REGBLKS); > if (error) { > @@ -501,8 +502,9 @@ xfs_attr_remove_int(xfs_inode_t *dp, str > /* > * Attach the dquots to the inode. > */ > - if ((error = XFS_QM_DQATTACH(mp, dp, 0))) > - return (error); > + error = xfs_qm_dqattach(dp, 0); > + if (error) > + return error; > > /* > * Start our first transaction of the day. > Index: xfs/fs/xfs/xfs_iomap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_iomap.c 2009-02-24 15:32:16.119370349 +0100 > +++ xfs/fs/xfs/xfs_iomap.c 2009-02-24 15:32:35.858495489 +0100 > @@ -417,7 +417,7 @@ xfs_iomap_write_direct( > * Make sure that the dquots are there. This doesn't hold > * the ilock across a disk read. > */ > - error = XFS_QM_DQATTACH(ip->i_mount, ip, XFS_QMOPT_ILOCKED); > + error = xfs_qm_dqattach_locked(ip, 0); > if (error) > return XFS_ERROR(error); > > @@ -476,8 +476,7 @@ xfs_iomap_write_direct( > if (error) > goto error_out; > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, > - qblocks, 0, quota_flag); > + error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > if (error) > goto error1; > > @@ -527,7 +526,7 @@ xfs_iomap_write_direct( > > error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ > xfs_bmap_cancel(&free_list); > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, qblocks, 0, quota_flag); > + xfs_trans_unreserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > > error1: /* Just cancel transaction */ > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT); > @@ -620,7 +619,7 @@ xfs_iomap_write_delay( > * Make sure that the dquots are there. This doesn't hold > * the ilock across a disk read. > */ > - error = XFS_QM_DQATTACH(mp, ip, XFS_QMOPT_ILOCKED); > + error = xfs_qm_dqattach_locked(ip, 0); > if (error) > return XFS_ERROR(error); > > @@ -715,7 +714,8 @@ xfs_iomap_write_allocate( > /* > * Make sure that the dquots are there. > */ > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > + error = xfs_qm_dqattach(ip, 0); > + if (error) > return XFS_ERROR(error); > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > Index: xfs/fs/xfs/xfs_mount.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.h 2009-02-24 15:32:16.124369938 +0100 > +++ xfs/fs/xfs/xfs_mount.h 2009-02-24 15:32:35.859495267 +0100 > @@ -18,6 +18,7 @@ > #ifndef __XFS_MOUNT_H__ > #define __XFS_MOUNT_H__ > > + > typedef struct xfs_trans_reservations { > uint tr_write; /* extent alloc trans */ > uint tr_itruncate; /* truncate trans */ > @@ -64,6 +65,8 @@ struct xfs_swapext; > struct xfs_mru_cache; > struct xfs_nameops; > struct xfs_ail; > +struct xfs_quotainfo; > + > > /* > * Prototypes and functions for the Data Migration subsystem. > @@ -107,86 +110,6 @@ typedef struct xfs_dmops { > (*(mp)->m_dm_ops->xfs_send_unmount)(mp,ip,right,mode,rval,fl) > > > -/* > - * Prototypes and functions for the Quota Management subsystem. > - */ > - > -struct xfs_dquot; > -struct xfs_dqtrxops; > -struct xfs_quotainfo; > - > -typedef int (*xfs_qminit_t)(struct xfs_mount *, uint *, uint *); > -typedef int (*xfs_qmmount_t)(struct xfs_mount *, uint, uint); > -typedef void (*xfs_qmunmount_t)(struct xfs_mount *); > -typedef void (*xfs_qmdone_t)(struct xfs_mount *); > -typedef void (*xfs_dqrele_t)(struct xfs_dquot *); > -typedef int (*xfs_dqattach_t)(struct xfs_inode *, uint); > -typedef void (*xfs_dqdetach_t)(struct xfs_inode *); > -typedef int (*xfs_dqpurgeall_t)(struct xfs_mount *, uint); > -typedef int (*xfs_dqvopalloc_t)(struct xfs_mount *, > - struct xfs_inode *, uid_t, gid_t, prid_t, uint, > - struct xfs_dquot **, struct xfs_dquot **); > -typedef void (*xfs_dqvopcreate_t)(struct xfs_trans *, struct xfs_inode *, > - struct xfs_dquot *, struct xfs_dquot *); > -typedef int (*xfs_dqvoprename_t)(struct xfs_inode **); > -typedef struct xfs_dquot * (*xfs_dqvopchown_t)( > - struct xfs_trans *, struct xfs_inode *, > - struct xfs_dquot **, struct xfs_dquot *); > -typedef int (*xfs_dqvopchownresv_t)(struct xfs_trans *, struct xfs_inode *, > - struct xfs_dquot *, struct xfs_dquot *, uint); > -typedef void (*xfs_dqstatvfs_t)(struct xfs_inode *, struct kstatfs *); > -typedef int (*xfs_dqsync_t)(struct xfs_mount *, int flags); > - > -typedef struct xfs_qmops { > - xfs_qminit_t xfs_qminit; > - xfs_qmdone_t xfs_qmdone; > - xfs_qmmount_t xfs_qmmount; > - xfs_qmunmount_t xfs_qmunmount; > - xfs_dqrele_t xfs_dqrele; > - xfs_dqattach_t xfs_dqattach; > - xfs_dqdetach_t xfs_dqdetach; > - xfs_dqpurgeall_t xfs_dqpurgeall; > - xfs_dqvopalloc_t xfs_dqvopalloc; > - xfs_dqvopcreate_t xfs_dqvopcreate; > - xfs_dqvoprename_t xfs_dqvoprename; > - xfs_dqvopchown_t xfs_dqvopchown; > - xfs_dqvopchownresv_t xfs_dqvopchownresv; > - xfs_dqstatvfs_t xfs_dqstatvfs; > - xfs_dqsync_t xfs_dqsync; > - struct xfs_dqtrxops *xfs_dqtrxops; > -} xfs_qmops_t; > - > -#define XFS_QM_INIT(mp, mnt, fl) \ > - (*(mp)->m_qm_ops->xfs_qminit)(mp, mnt, fl) > -#define XFS_QM_MOUNT(mp, mnt, fl) \ > - (*(mp)->m_qm_ops->xfs_qmmount)(mp, mnt, fl) > -#define XFS_QM_UNMOUNT(mp) \ > - (*(mp)->m_qm_ops->xfs_qmunmount)(mp) > -#define XFS_QM_DONE(mp) \ > - (*(mp)->m_qm_ops->xfs_qmdone)(mp) > -#define XFS_QM_DQRELE(mp, dq) \ > - (*(mp)->m_qm_ops->xfs_dqrele)(dq) > -#define XFS_QM_DQATTACH(mp, ip, fl) \ > - (*(mp)->m_qm_ops->xfs_dqattach)(ip, fl) > -#define XFS_QM_DQDETACH(mp, ip) \ > - (*(mp)->m_qm_ops->xfs_dqdetach)(ip) > -#define XFS_QM_DQPURGEALL(mp, fl) \ > - (*(mp)->m_qm_ops->xfs_dqpurgeall)(mp, fl) > -#define XFS_QM_DQVOPALLOC(mp, ip, uid, gid, prid, fl, dq1, dq2) \ > - (*(mp)->m_qm_ops->xfs_dqvopalloc)(mp, ip, uid, gid, prid, fl, dq1, dq2) > -#define XFS_QM_DQVOPCREATE(mp, tp, ip, dq1, dq2) \ > - (*(mp)->m_qm_ops->xfs_dqvopcreate)(tp, ip, dq1, dq2) > -#define XFS_QM_DQVOPRENAME(mp, ip) \ > - (*(mp)->m_qm_ops->xfs_dqvoprename)(ip) > -#define XFS_QM_DQVOPCHOWN(mp, tp, ip, dqp, dq) \ > - (*(mp)->m_qm_ops->xfs_dqvopchown)(tp, ip, dqp, dq) > -#define XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, dq1, dq2, fl) \ > - (*(mp)->m_qm_ops->xfs_dqvopchownresv)(tp, ip, dq1, dq2, fl) > -#define XFS_QM_DQSTATVFS(ip, statp) \ > - (*(ip)->i_mount->m_qm_ops->xfs_dqstatvfs)(ip, statp) > -#define XFS_QM_DQSYNC(mp, flags) \ > - (*(mp)->m_qm_ops->xfs_dqsync)(mp, flags) > - > #ifdef HAVE_PERCPU_SB > > /* > @@ -516,8 +439,6 @@ extern int xfs_sb_validate_fsb_count(str > > extern int xfs_dmops_get(struct xfs_mount *); > extern void xfs_dmops_put(struct xfs_mount *); > -extern int xfs_qmops_get(struct xfs_mount *); > -extern void xfs_qmops_put(struct xfs_mount *); > > extern struct xfs_dmops xfs_dmcore_xfs; > > Index: xfs/fs/xfs/Makefile > =================================================================== > --- xfs.orig/fs/xfs/Makefile 2009-02-24 15:32:16.158369937 +0100 > +++ xfs/fs/xfs/Makefile 2009-02-24 15:32:35.859495267 +0100 > @@ -88,8 +88,7 @@ xfs-y += xfs_alloc.o \ > xfs_utils.o \ > xfs_vnodeops.o \ > xfs_rw.o \ > - xfs_dmops.o \ > - xfs_qmops.o > + xfs_dmops.o > > xfs-$(CONFIG_XFS_TRACE) += xfs_btree_trace.o \ > xfs_dir2_trace.o > 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:16.137370546 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2009-02-24 15:32:35.865370666 +0100 > @@ -907,7 +907,7 @@ xfs_ioctl_setattr( > struct xfs_mount *mp = ip->i_mount; > struct xfs_trans *tp; > unsigned int lock_flags = 0; > - struct xfs_dquot *udqp = NULL, *gdqp = NULL; > + struct xfs_dquot *udqp, *gdqp; > struct xfs_dquot *olddquot = NULL; > int code; > > @@ -918,6 +918,9 @@ xfs_ioctl_setattr( > if (XFS_FORCED_SHUTDOWN(mp)) > return XFS_ERROR(EIO); > > + udqp = NULL; > + gdqp = NULL; > + > /* > * If disk quotas is on, we make sure that the dquots do exist on disk, > * before we start any other transactions. Trying to do this later > @@ -927,7 +930,7 @@ xfs_ioctl_setattr( > * because the i_*dquot fields will get updated anyway. > */ > if (XFS_IS_QUOTA_ON(mp) && (mask & FSX_PROJID)) { > - code = XFS_QM_DQVOPALLOC(mp, ip, ip->i_d.di_uid, > + code = xfs_qm_vop_dqalloc(ip, ip->i_d.di_uid, > ip->i_d.di_gid, fa->fsx_projid, > XFS_QMOPT_PQUOTA, &udqp, &gdqp); > if (code) > @@ -965,7 +968,7 @@ xfs_ioctl_setattr( > if (XFS_IS_PQUOTA_ON(mp) && > ip->i_d.di_projid != fa->fsx_projid) { > ASSERT(tp); > - code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > + code = xfs_qm_vop_chown_reserve(tp, ip, udqp, gdqp, > capable(CAP_FOWNER) ? > XFS_QMOPT_FORCE_RES : 0); > if (code) /* out of quota */ > @@ -1068,7 +1071,7 @@ xfs_ioctl_setattr( > */ > if (ip->i_d.di_projid != fa->fsx_projid) { > if (XFS_IS_PQUOTA_ON(mp)) { > - olddquot = XFS_QM_DQVOPCHOWN(mp, tp, ip, > + olddquot = xfs_qm_vop_chown(tp, ip, > &ip->i_gdquot, gdqp); > } > ip->i_d.di_projid = fa->fsx_projid; > @@ -1114,9 +1117,9 @@ xfs_ioctl_setattr( > /* > * Release any dquot(s) the inode had kept before chown. > */ > - XFS_QM_DQRELE(mp, olddquot); > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(olddquot); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > > if (code) > return code; > @@ -1130,8 +1133,8 @@ xfs_ioctl_setattr( > return 0; > > error_return: > - XFS_QM_DQRELE(mp, udqp); > - XFS_QM_DQRELE(mp, gdqp); > + xfs_qm_dqrele(udqp); > + xfs_qm_dqrele(gdqp); > xfs_trans_cancel(tp, 0); > if (lock_flags) > xfs_iunlock(ip, lock_flags); > 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:16.141370566 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-02-24 15:32:35.866394539 +0100 > @@ -416,6 +416,14 @@ xfs_parseargs( > return EINVAL; > } > > +#ifndef CONFIG_XFS_QUOTA > + if (XFS_IS_QUOTA_RUNNING(mp)) { > + cmn_err(CE_WARN, > + "XFS: quota support not available in this kernel."); > + return EINVAL; > + } > +#endif > + > if ((mp->m_qflags & (XFS_GQUOTA_ACCT | XFS_GQUOTA_ACTIVE)) && > (mp->m_qflags & (XFS_PQUOTA_ACCT | XFS_PQUOTA_ACTIVE))) { > cmn_err(CE_WARN, > @@ -1110,7 +1118,6 @@ xfs_fs_put_super( > xfs_freesb(mp); > xfs_icsb_destroy_counters(mp); > xfs_close_devices(mp); > - xfs_qmops_put(mp); > xfs_dmops_put(mp); > xfs_free_fsname(mp); > kfree(mp); > @@ -1180,6 +1187,7 @@ xfs_fs_statfs( > { > struct xfs_mount *mp = XFS_M(dentry->d_sb); > xfs_sb_t *sbp = &mp->m_sb; > + struct xfs_inode *ip = XFS_I(dentry->d_inode); > __uint64_t fakeinos, id; > xfs_extlen_t lsize; > > @@ -1214,7 +1222,10 @@ xfs_fs_statfs( > statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); > spin_unlock(&mp->m_sb_lock); > > - XFS_QM_DQSTATVFS(XFS_I(dentry->d_inode), statp); > + if ((ip->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) || > + ((mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD))) == > + (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD)) > + xfs_qm_statvfs(ip, statp); > return 0; > } > > @@ -1422,16 +1433,13 @@ xfs_fs_fill_super( > error = xfs_dmops_get(mp); > if (error) > goto out_free_fsname; > - error = xfs_qmops_get(mp); > - if (error) > - goto out_put_dmops; > > if (silent) > flags |= XFS_MFSI_QUIET; > > error = xfs_open_devices(mp); > if (error) > - goto out_put_qmops; > + goto out_put_dmops; > > if (xfs_icsb_init_counters(mp)) > mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; > @@ -1500,8 +1508,6 @@ xfs_fs_fill_super( > out_destroy_counters: > xfs_icsb_destroy_counters(mp); > xfs_close_devices(mp); > - out_put_qmops: > - xfs_qmops_put(mp); > out_put_dmops: > xfs_dmops_put(mp); > out_free_fsname: > Index: xfs/fs/xfs/linux-2.6/xfs_sync.c > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_sync.c 2009-02-24 15:32:16.149399312 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_sync.c 2009-02-24 15:32:35.867425537 +0100 > @@ -43,6 +43,7 @@ > #include "xfs_buf_item.h" > #include "xfs_inode_item.h" > #include "xfs_rw.h" > +#include "xfs_quota.h" > > #include > #include > @@ -311,12 +312,12 @@ xfs_quiesce_data( > > /* push non-blocking */ > xfs_sync_inodes(mp, SYNC_DELWRI|SYNC_BDFLUSH); > - XFS_QM_DQSYNC(mp, SYNC_BDFLUSH); > + xfs_qm_sync(mp, SYNC_BDFLUSH); > xfs_filestream_flush(mp); > > /* push and block */ > xfs_sync_inodes(mp, SYNC_DELWRI|SYNC_WAIT|SYNC_IOWAIT); > - XFS_QM_DQSYNC(mp, SYNC_WAIT); > + xfs_qm_sync(mp, SYNC_WAIT); > > /* write superblock and hoover up shutdown errors */ > error = xfs_sync_fsdata(mp, 0); > @@ -482,7 +483,7 @@ xfs_sync_worker( > xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE); > xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_DELWRI_ELSE_ASYNC); > /* dgc: errors ignored here */ > - error = XFS_QM_DQSYNC(mp, SYNC_BDFLUSH); > + error = xfs_qm_sync(mp, SYNC_BDFLUSH); > error = xfs_sync_fsdata(mp, SYNC_BDFLUSH); > if (xfs_log_need_covered(mp)) > error = xfs_commit_dummy_trans(mp, XFS_LOG_FORCE); > Index: xfs/fs/xfs/quota/xfs_dquot.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_dquot.c 2009-02-24 15:32:16.080370342 +0100 > +++ xfs/fs/xfs/quota/xfs_dquot.c 2009-02-24 15:32:35.867425537 +0100 > @@ -1194,7 +1194,9 @@ void > xfs_qm_dqrele( > xfs_dquot_t *dqp) > { > - ASSERT(dqp); > + if (!dqp) > + return; > + > xfs_dqtrace_entry(dqp, "DQRELE"); > > xfs_dqlock(dqp); > Index: xfs/fs/xfs/quota/xfs_dquot.h > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_dquot.h 2009-02-24 15:32:16.085370350 +0100 > +++ xfs/fs/xfs/quota/xfs_dquot.h 2009-02-24 15:32:35.868518762 +0100 > @@ -181,7 +181,6 @@ extern void xfs_qm_adjust_dqlimits(xfs_ > extern int xfs_qm_dqget(xfs_mount_t *, xfs_inode_t *, > xfs_dqid_t, uint, uint, xfs_dquot_t **); > extern void xfs_qm_dqput(xfs_dquot_t *); > -extern void xfs_qm_dqrele(xfs_dquot_t *); > extern void xfs_dqlock(xfs_dquot_t *); > extern void xfs_dqlock2(xfs_dquot_t *, xfs_dquot_t *); > extern void xfs_dqunlock(xfs_dquot_t *); > Index: xfs/fs/xfs/quota/xfs_qm.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm.c 2009-02-24 15:32:16.076370112 +0100 > +++ xfs/fs/xfs/quota/xfs_qm.c 2009-02-24 15:32:35.869518471 +0100 > @@ -287,11 +287,13 @@ xfs_qm_rele_quotafs_ref( > * Just destroy the quotainfo structure. > */ > void > -xfs_qm_unmount_quotadestroy( > - xfs_mount_t *mp) > +xfs_qm_unmount( > + struct xfs_mount *mp) > { > - if (mp->m_quotainfo) > + if (mp->m_quotainfo) { > + xfs_qm_dqpurge_all(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); > xfs_qm_destroy_quotainfo(mp); > + } > } > > > @@ -311,6 +313,9 @@ xfs_qm_mount_quotas( > int error = 0; > uint sbf; > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return; > + > /* > * If quotas on realtime volumes is not supported, we disable > * quotas immediately. > @@ -323,8 +328,6 @@ xfs_qm_mount_quotas( > goto write_changes; > } > > - ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > - > /* > * Allocate the quotainfo structure inside the mount struct, and > * create quotainode(s), and change/rev superblock if necessary. > @@ -385,8 +388,13 @@ xfs_qm_mount_quotas( > if (error) { > xfs_fs_cmn_err(CE_WARN, mp, > "Failed to initialize disk quotas."); > + return; > } > - return; > + > +#ifdef QUOTADEBUG > + if (XFS_IS_QUOTA_ON(mp)) > + xfs_qm_internalqcheck(mp); > +#endif > } > > /* > @@ -774,12 +782,11 @@ xfs_qm_dqattach_grouphint( > * Given a locked inode, attach dquot(s) to it, taking U/G/P-QUOTAON > * into account. > * If XFS_QMOPT_DQALLOC, the dquot(s) will be allocated if needed. > - * If XFS_QMOPT_ILOCKED, then inode sent is already locked EXCL. > * Inode may get unlocked and relocked in here, and the caller must deal with > * the consequences. > */ > int > -xfs_qm_dqattach( > +xfs_qm_dqattach_locked( > xfs_inode_t *ip, > uint flags) > { > @@ -787,17 +794,14 @@ xfs_qm_dqattach( > uint nquotas = 0; > int error = 0; > > - if ((! XFS_IS_QUOTA_ON(mp)) || > - (! XFS_NOT_DQATTACHED(mp, ip)) || > - (ip->i_ino == mp->m_sb.sb_uquotino) || > - (ip->i_ino == mp->m_sb.sb_gquotino)) > + if (!XFS_IS_QUOTA_RUNNING(mp) || > + !XFS_IS_QUOTA_ON(mp) || > + !XFS_NOT_DQATTACHED(mp, ip) || > + ip->i_ino == mp->m_sb.sb_uquotino || > + ip->i_ino == mp->m_sb.sb_gquotino) > return 0; > > - ASSERT((flags & XFS_QMOPT_ILOCKED) == 0 || > - xfs_isilocked(ip, XFS_ILOCK_EXCL)); > - > - if (! (flags & XFS_QMOPT_ILOCKED)) > - xfs_ilock(ip, XFS_ILOCK_EXCL); > + ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > if (XFS_IS_UQUOTA_ON(mp)) { > error = xfs_qm_dqattach_one(ip, ip->i_d.di_uid, XFS_DQ_USER, > @@ -849,8 +853,7 @@ xfs_qm_dqattach( > xfs_qm_dqattach_grouphint(ip->i_udquot, ip->i_gdquot); > } > > - done: > - > + done: > #ifdef QUOTADEBUG > if (! error) { > if (XFS_IS_UQUOTA_ON(mp)) > @@ -858,15 +861,22 @@ xfs_qm_dqattach( > if (XFS_IS_OQUOTA_ON(mp)) > ASSERT(ip->i_gdquot); > } > + ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > #endif > + return error; > +} > + > +int > +xfs_qm_dqattach( > + struct xfs_inode *ip, > + uint flags) > +{ > + int error; > > - if (! (flags & XFS_QMOPT_ILOCKED)) > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > + xfs_ilock(ip, XFS_ILOCK_EXCL); > + error = xfs_qm_dqattach_locked(ip, flags); > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > > -#ifdef QUOTADEBUG > - else > - ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > -#endif > return error; > } > > @@ -912,7 +922,7 @@ xfs_qm_sync( > boolean_t nowait; > int error; > > - if (! XFS_IS_QUOTA_ON(mp)) > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > return 0; > > restarts = 0; > @@ -2319,20 +2329,20 @@ xfs_qm_write_sb_changes( > */ > int > xfs_qm_vop_dqalloc( > - xfs_mount_t *mp, > - xfs_inode_t *ip, > - uid_t uid, > - gid_t gid, > - prid_t prid, > - uint flags, > - xfs_dquot_t **O_udqpp, > - xfs_dquot_t **O_gdqpp) > -{ > - int error; > - xfs_dquot_t *uq, *gq; > - uint lockflags; > + struct xfs_inode *ip, > + uid_t uid, > + gid_t gid, > + prid_t prid, > + uint flags, > + struct xfs_dquot **O_udqpp, > + struct xfs_dquot **O_gdqpp) > +{ > + struct xfs_mount *mp = ip->i_mount; > + struct xfs_dquot *uq, *gq; > + int error; > + uint lockflags; > > - if (!XFS_IS_QUOTA_ON(mp)) > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > return 0; > > lockflags = XFS_ILOCK_EXCL; > @@ -2346,8 +2356,8 @@ xfs_qm_vop_dqalloc( > * if necessary. The dquot(s) will not be locked. > */ > if (XFS_NOT_DQATTACHED(mp, ip)) { > - if ((error = xfs_qm_dqattach(ip, XFS_QMOPT_DQALLOC | > - XFS_QMOPT_ILOCKED))) { > + error = xfs_qm_dqattach_locked(ip, XFS_QMOPT_DQALLOC); > + if (error) { > xfs_iunlock(ip, lockflags); > return error; > } > @@ -2469,8 +2479,10 @@ xfs_qm_vop_chown( > uint bfield = XFS_IS_REALTIME_INODE(ip) ? > XFS_TRANS_DQ_RTBCOUNT : XFS_TRANS_DQ_BCOUNT; > > + if (!XFS_IS_QUOTA_RUNNING(ip->i_mount)) > + return NULL; > + > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > - ASSERT(XFS_IS_QUOTA_RUNNING(ip->i_mount)); > > /* old dquot */ > prevdq = *IO_olddq; > @@ -2508,14 +2520,15 @@ xfs_qm_vop_chown_reserve( > xfs_dquot_t *gdqp, > uint flags) > { > - int error; > - xfs_mount_t *mp; > + xfs_mount_t *mp = ip->i_mount; > uint delblks, blkflags, prjflags = 0; > xfs_dquot_t *unresudq, *unresgdq, *delblksudq, *delblksgdq; > + int error; > + > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return 0; > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); > - mp = ip->i_mount; > - ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > > delblks = ip->i_delayed_blks; > delblksudq = delblksgdq = unresudq = unresgdq = NULL; > @@ -2582,28 +2595,23 @@ xfs_qm_vop_chown_reserve( > > int > xfs_qm_vop_rename_dqattach( > - xfs_inode_t **i_tab) > + struct xfs_inode **i_tab) > { > - xfs_inode_t *ip; > - int i; > - int error; > - > - ip = i_tab[0]; > + struct xfs_mount *mp = i_tab[0]->i_mount; > + int i; > > - if (! XFS_IS_QUOTA_ON(ip->i_mount)) > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > return 0; > > - if (XFS_NOT_DQATTACHED(ip->i_mount, ip)) { > - error = xfs_qm_dqattach(ip, 0); > - if (error) > - return error; > - } > for (i = 1; (i < 4 && i_tab[i]); i++) { > + struct xfs_inode *ip = i_tab[i]; > + int error; > + > /* > * Watch out for duplicate entries in the table. > */ > - if ((ip = i_tab[i]) != i_tab[i-1]) { > - if (XFS_NOT_DQATTACHED(ip->i_mount, ip)) { > + if (i == 0 || ip != i_tab[i-1]) { > + if (XFS_NOT_DQATTACHED(mp, ip)) { > error = xfs_qm_dqattach(ip, 0); > if (error) > return error; > @@ -2614,17 +2622,19 @@ xfs_qm_vop_rename_dqattach( > } > > void > -xfs_qm_vop_dqattach_and_dqmod_newinode( > - xfs_trans_t *tp, > - xfs_inode_t *ip, > - xfs_dquot_t *udqp, > - xfs_dquot_t *gdqp) > +xfs_qm_vop_create_dqattach( > + struct xfs_trans *tp, > + struct xfs_inode *ip, > + struct xfs_dquot *udqp, > + struct xfs_dquot *gdqp) > { > - if (!XFS_IS_QUOTA_ON(tp->t_mountp)) > + struct xfs_mount *mp = tp->t_mountp; > + > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > return; > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > - ASSERT(XFS_IS_QUOTA_RUNNING(tp->t_mountp)); > + ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > > if (udqp) { > xfs_dqlock(udqp); > @@ -2632,7 +2642,7 @@ xfs_qm_vop_dqattach_and_dqmod_newinode( > xfs_dqunlock(udqp); > ASSERT(ip->i_udquot == NULL); > ip->i_udquot = udqp; > - ASSERT(XFS_IS_UQUOTA_ON(tp->t_mountp)); > + ASSERT(XFS_IS_UQUOTA_ON(mp)); > ASSERT(ip->i_d.di_uid == be32_to_cpu(udqp->q_core.d_id)); > xfs_trans_mod_dquot(tp, udqp, XFS_TRANS_DQ_ICOUNT, 1); > } > @@ -2642,8 +2652,8 @@ xfs_qm_vop_dqattach_and_dqmod_newinode( > xfs_dqunlock(gdqp); > ASSERT(ip->i_gdquot == NULL); > ip->i_gdquot = gdqp; > - ASSERT(XFS_IS_OQUOTA_ON(tp->t_mountp)); > - ASSERT((XFS_IS_GQUOTA_ON(tp->t_mountp) ? > + ASSERT(XFS_IS_OQUOTA_ON(mp)); > + ASSERT((XFS_IS_GQUOTA_ON(mp) ? > ip->i_d.di_gid : ip->i_d.di_projid) == > be32_to_cpu(gdqp->q_core.d_id)); > xfs_trans_mod_dquot(tp, gdqp, XFS_TRANS_DQ_ICOUNT, 1); > Index: xfs/fs/xfs/xfs_iget.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 15:32:16.153369650 +0100 > +++ xfs/fs/xfs/xfs_iget.c 2009-02-24 15:32:35.870518109 +0100 > @@ -490,10 +490,7 @@ xfs_ireclaim( > * ilock one but will still hold the iolock. > */ > xfs_ilock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); > - /* > - * Release dquots (and their references) if any. > - */ > - XFS_QM_DQDETACH(ip->i_mount, ip); > + xfs_qm_dqdetach(ip); > xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); > > switch (ip->i_d.di_mode & S_IFMT) { > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2009-02-24 15:32:16.164399755 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2009-02-24 15:32:35.871518446 +0100 > @@ -886,6 +886,53 @@ xfs_check_sizes(xfs_mount_t *mp) > } > > /* > + * Clear the quotaflags in memory and in the superblock. > + */ > +int > +xfs_mount_reset_sbqflags( > + struct xfs_mount *mp) > +{ > + int error; > + struct xfs_trans *tp; > + > + mp->m_qflags = 0; > + > + /* > + * It is OK to look at sb_qflags here in mount path, > + * without m_sb_lock. > + */ > + if (mp->m_sb.sb_qflags == 0) > + return 0; > + spin_lock(&mp->m_sb_lock); > + mp->m_sb.sb_qflags = 0; > + spin_unlock(&mp->m_sb_lock); > + > + /* > + * If the fs is readonly, let the incore superblock run > + * with quotas off but don't flush the update out to disk > + */ > + if (mp->m_flags & XFS_MOUNT_RDONLY) > + return 0; > + > +#ifdef QUOTADEBUG > + xfs_fs_cmn_err(CE_NOTE, mp, "Writing superblock quota changes"); > +#endif > + > + tp = xfs_trans_alloc(mp, XFS_TRANS_QM_SBCHANGE); > + error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0, > + XFS_DEFAULT_LOG_COUNT); > + if (error) { > + xfs_trans_cancel(tp, 0); > + xfs_fs_cmn_err(CE_ALERT, mp, > + "xfs_mount_reset_sbqflags: Superblock update failed!"); > + return error; > + } > + > + xfs_mod_sb(tp, XFS_SB_QFLAGS); > + return xfs_trans_commit(tp, 0); > +} > + > +/* > * This function does the following on an initial mount of a file system: > * - reads the superblock from disk and init the mount struct > * - if we're a 32-bit kernel, do a size check on the superblock > @@ -902,7 +949,8 @@ xfs_mountfs( > xfs_sb_t *sbp = &(mp->m_sb); > xfs_inode_t *rip; > __uint64_t resblks; > - uint quotamount, quotaflags; > + uint quotamount = 0; > + uint quotaflags = 0; > int error = 0; > > xfs_mount_common(mp, sbp); > @@ -1145,9 +1193,28 @@ xfs_mountfs( > /* > * Initialise the XFS quota management subsystem for this mount > */ > - error = XFS_QM_INIT(mp, "amount, "aflags); > - if (error) > - goto out_rtunmount; > + if (XFS_IS_QUOTA_RUNNING(mp)) { > + error = xfs_qm_newmount(mp, "amount, "aflags); > + if (error) > + goto out_rtunmount; > + } else { > + ASSERT(!XFS_IS_QUOTA_ON(mp)); > + > + /* > + * If a file system had quotas running earlier, but decided to > + * mount without -o uquota/pquota/gquota options, revoke the > + * quotachecked license. > + */ > + if (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT) { > + cmn_err(CE_NOTE, > + "XFS: resetting qflags for filesystem %s", > + mp->m_fsname); > + > + error = xfs_mount_reset_sbqflags(mp); > + if (error) > + return error; > + } > + } > > /* > * Finish recovering the file system. This part needed to be > @@ -1163,9 +1230,19 @@ xfs_mountfs( > /* > * Complete the quota initialisation, post-log-replay component. > */ > - error = XFS_QM_MOUNT(mp, quotamount, quotaflags); > - if (error) > - goto out_rtunmount; > + if (quotamount) { > + ASSERT(mp->m_qflags == 0); > + mp->m_qflags = quotaflags; > + > + xfs_qm_mount_quotas(mp); > + } > + > +#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) > + if (XFS_IS_QUOTA_ON(mp)) > + xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas turned on"); > + else > + xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas not turned on"); > +#endif > > /* > * Now we are mounted, reserve a small amount of unused space for > @@ -1215,12 +1292,7 @@ xfs_unmountfs( > __uint64_t resblks; > int error; > > - /* > - * Release dquot that rootinode, rbmino and rsumino might be holding, > - * and release the quota inodes. > - */ > - XFS_QM_UNMOUNT(mp); > - > + xfs_qm_unmount_quotas(mp); > xfs_rtunmount_inodes(mp); > IRELE(mp->m_rootip); > > @@ -1237,10 +1309,7 @@ xfs_unmountfs( > xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); > xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_ASYNC); > > - XFS_QM_DQPURGEALL(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); > - > - if (mp->m_quotainfo) > - XFS_QM_DONE(mp); > + xfs_qm_unmount(mp); > > /* > * Flush out the log synchronously so that we know for sure > Index: xfs/fs/xfs/xfs_qmops.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_qmops.c 2009-02-24 15:32:16.128369539 +0100 > +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 > @@ -1,152 +0,0 @@ > -/* > - * Copyright (c) 2000-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_log.h" > -#include "xfs_inum.h" > -#include "xfs_trans.h" > -#include "xfs_sb.h" > -#include "xfs_ag.h" > -#include "xfs_dir2.h" > -#include "xfs_dmapi.h" > -#include "xfs_mount.h" > -#include "xfs_quota.h" > -#include "xfs_error.h" > - > - > -STATIC struct xfs_dquot * > -xfs_dqvopchown_default( > - struct xfs_trans *tp, > - struct xfs_inode *ip, > - struct xfs_dquot **dqp, > - struct xfs_dquot *dq) > -{ > - return NULL; > -} > - > -/* > - * Clear the quotaflags in memory and in the superblock. > - */ > -int > -xfs_mount_reset_sbqflags(xfs_mount_t *mp) > -{ > - int error; > - xfs_trans_t *tp; > - > - mp->m_qflags = 0; > - /* > - * It is OK to look at sb_qflags here in mount path, > - * without m_sb_lock. > - */ > - if (mp->m_sb.sb_qflags == 0) > - return 0; > - spin_lock(&mp->m_sb_lock); > - mp->m_sb.sb_qflags = 0; > - spin_unlock(&mp->m_sb_lock); > - > - /* > - * if the fs is readonly, let the incore superblock run > - * with quotas off but don't flush the update out to disk > - */ > - if (mp->m_flags & XFS_MOUNT_RDONLY) > - return 0; > -#ifdef QUOTADEBUG > - xfs_fs_cmn_err(CE_NOTE, mp, "Writing superblock quota changes"); > -#endif > - tp = xfs_trans_alloc(mp, XFS_TRANS_QM_SBCHANGE); > - if ((error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0, > - XFS_DEFAULT_LOG_COUNT))) { > - xfs_trans_cancel(tp, 0); > - xfs_fs_cmn_err(CE_ALERT, mp, > - "xfs_mount_reset_sbqflags: Superblock update failed!"); > - return error; > - } > - xfs_mod_sb(tp, XFS_SB_QFLAGS); > - error = xfs_trans_commit(tp, 0); > - return error; > -} > - > -STATIC int > -xfs_noquota_init( > - xfs_mount_t *mp, > - uint *needquotamount, > - uint *quotaflags) > -{ > - int error = 0; > - > - *quotaflags = 0; > - *needquotamount = B_FALSE; > - > - ASSERT(!XFS_IS_QUOTA_ON(mp)); > - > - /* > - * If a file system had quotas running earlier, but decided to > - * mount without -o uquota/pquota/gquota options, revoke the > - * quotachecked license. > - */ > - if (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT) { > - cmn_err(CE_NOTE, > - "XFS resetting qflags for filesystem %s", > - mp->m_fsname); > - > - error = xfs_mount_reset_sbqflags(mp); > - } > - return error; > -} > - > -static struct xfs_qmops xfs_qmcore_stub = { > - .xfs_qminit = (xfs_qminit_t) xfs_noquota_init, > - .xfs_qmdone = (xfs_qmdone_t) fs_noerr, > - .xfs_qmmount = (xfs_qmmount_t) fs_noerr, > - .xfs_qmunmount = (xfs_qmunmount_t) fs_noerr, > - .xfs_dqrele = (xfs_dqrele_t) fs_noerr, > - .xfs_dqattach = (xfs_dqattach_t) fs_noerr, > - .xfs_dqdetach = (xfs_dqdetach_t) fs_noerr, > - .xfs_dqpurgeall = (xfs_dqpurgeall_t) fs_noerr, > - .xfs_dqvopalloc = (xfs_dqvopalloc_t) fs_noerr, > - .xfs_dqvopcreate = (xfs_dqvopcreate_t) fs_noerr, > - .xfs_dqvoprename = (xfs_dqvoprename_t) fs_noerr, > - .xfs_dqvopchown = xfs_dqvopchown_default, > - .xfs_dqvopchownresv = (xfs_dqvopchownresv_t) fs_noerr, > - .xfs_dqstatvfs = (xfs_dqstatvfs_t) fs_noval, > - .xfs_dqsync = (xfs_dqsync_t) fs_noerr, > -}; > - > -int > -xfs_qmops_get(struct xfs_mount *mp) > -{ > - if (XFS_IS_QUOTA_RUNNING(mp)) { > -#ifdef CONFIG_XFS_QUOTA > - mp->m_qm_ops = &xfs_qmcore_xfs; > -#else > - cmn_err(CE_WARN, > - "XFS: qouta support not available in this kernel."); > - return EINVAL; > -#endif > - } else { > - mp->m_qm_ops = &xfs_qmcore_stub; > - } > - > - return 0; > -} > - > -void > -xfs_qmops_put(struct xfs_mount *mp) > -{ > -} > Index: xfs/fs/xfs/xfs_rename.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_rename.c 2009-02-24 15:32:16.132369560 +0100 > +++ xfs/fs/xfs/xfs_rename.c 2009-02-24 15:32:35.872519970 +0100 > @@ -166,7 +166,8 @@ xfs_rename( > /* > * Attach the dquots to the inodes > */ > - if ((error = XFS_QM_DQVOPRENAME(mp, inodes))) { > + error = xfs_qm_vop_rename_dqattach(inodes); > + if (error) { > xfs_trans_cancel(tp, cancel_flags); > goto std_return; > } > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 03:48: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.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 n2G8m4ww079557 for ; Mon, 16 Mar 2009 03:48:25 -0500 X-ASG-Debug-ID: 1237193241-3ed303240000-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 ECD6719C170 for ; Mon, 16 Mar 2009 01:47:22 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id XMU1xeFx5PQCqzJb for ; Mon, 16 Mar 2009 01:47:22 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8TD-0000xz-Df for xfs@oss.sgi.com; Mon, 16 Mar 2009 08:46:51 +0000 Date: Mon, 16 Mar 2009 04:46:51 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/7] a couple more random cleanups for 2.6.30 Subject: Re: [PATCH 0/7] a couple more random cleanups for 2.6.30 Message-ID: <20090316084651.GA22430@infradead.org> References: <20090220085207.663702000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220085207.663702000@bombadil.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: 1237193263 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 All patches are now available to pull from git://git.kernel.org/pub/scm/fs/xfs/xfs.git with the minor review comments from Dave incorporated. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:10:02 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 n2G99ff3080395 for ; Mon, 16 Mar 2009 04:10:02 -0500 X-ASG-Debug-ID: 1237194560-670300cc0000-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 0F5071C45B9C for ; Mon, 16 Mar 2009 02:09:20 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id OTyAS8pj5EngmhYU for ; Mon, 16 Mar 2009 02:09:20 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8oR-00084X-MR; Mon, 16 Mar 2009 09:08:47 +0000 Date: Mon, 16 Mar 2009 05:08:47 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Message-ID: <20090316090847.GA2636@infradead.org> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116707-25793-2-git-send-email-david@fromorbit.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: 1237194561 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 15, 2009 at 10:31:43PM +1100, Dave Chinner wrote: > index 5aeb777..08be36d 100644 > --- a/fs/xfs/linux-2.6/xfs_fs_subr.c > +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c > @@ -74,14 +74,14 @@ xfs_flush_pages( > > if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > xfs_iflags_clear(ip, XFS_ITRUNCATED); > - ret = filemap_fdatawrite(mapping); > - if (flags & XFS_B_ASYNC) > - return -ret; > - ret2 = filemap_fdatawait(mapping); > - if (!ret) > - ret = ret2; > + ret = -filemap_fdatawrite(mapping); > } > - return -ret; > + if (flags & XFS_B_ASYNC) > + return ret; > + ret2 = xfs_wait_on_pages(ip, first, last); > + if (!ret) > + ret = ret2; > + return ret; > } How does this belong into this patch series? Also I think the sync code should just use filemap_fdatawait and filemap_fdatawait directly. It's at a high enough level that we don't need all these obsfucations. > + if (flags & SYNC_DELWRI) { > + if (VN_DIRTY(inode)) { > + if (flags & SYNC_TRYLOCK) { > + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) > + lock_flags |= XFS_IOLOCK_SHARED; > + } else { > + xfs_ilock(ip, XFS_IOLOCK_SHARED); > + lock_flags |= XFS_IOLOCK_SHARED; > + } > + if (lock_flags & XFS_IOLOCK_SHARED) { Too long line and pretty ugly use of the lock_flags variable, but given that it gets sorted out in the sync series I think we can leave it that way. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:13:48 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 n2G9DRG1080605 for ; Mon, 16 Mar 2009 04:13:47 -0500 X-ASG-Debug-ID: 1237194786-121b015b0000-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 9D69819C306 for ; Mon, 16 Mar 2009 02:13:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id valv3AZ9SvpjwsDP for ; Mon, 16 Mar 2009 02:13:06 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8s7-0004TP-S5; Mon, 16 Mar 2009 09:12:35 +0000 Date: Mon, 16 Mar 2009 05:12:35 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Subject: Re: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Message-ID: <20090316091235.GB2636@infradead.org> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116707-25793-3-git-send-email-david@fromorbit.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: 1237194786 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 15, 2009 at 10:31:44PM +1100, Dave Chinner wrote: > } else { > + int enospc = 0; > + ssize_t ret2 = 0; > + > +write_retry: > xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, > *offset, ioflags); > - ret = generic_file_buffered_write(iocb, iovp, segs, > + ret2 = generic_file_buffered_write(iocb, iovp, segs, > pos, offset, count, ret); > + /* > + * if we just got an ENOSPC, flush the inode now we > + * aren't holding any page locks and retry *once* > + */ > + if (ret2 == -ENOSPC && !enospc) { > + error = xfs_flush_pages(xip, 0, -1, 0, FI_NONE); > + if (error) > + goto out_unlock_internal; > + enospc = 1; > + goto write_retry; > + } > + ret = ret2; Just use filemap_fdatawrite here directly.. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:14:14 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 n2G9DroE080635 for ; Mon, 16 Mar 2009 04:14:13 -0500 X-ASG-Debug-ID: 1237194812-162901480000-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 73F3519C308 for ; Mon, 16 Mar 2009 02:13:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id bHg7VpbEl1j7SN4Q for ; Mon, 16 Mar 2009 02:13:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8t1-0005Uq-Uw; Mon, 16 Mar 2009 09:13:32 +0000 Date: Mon, 16 Mar 2009 05:13:31 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Subject: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Message-ID: <20090316091331.GC2636@infradead.org> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-4-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116707-25793-4-git-send-email-david@fromorbit.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: 1237194812 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 15, 2009 at 10:31:45PM +1100, Dave Chinner wrote: > xfs_flush_inodes() currently uses a magic timeout to wait for > some inodes to be flushed before returning. This isn't > really reliable but used to be the best that could be done > due to deadlock potential of waiting for the entire flush. > > Now the inode flush is safe to execute while we hold page > and inode locks, we can wait for all the inodes to flush > synchronously. Convert the wait mechanism to a completion > to do this efficiently. This should remove all remaining > spurious ENOSPC errors from the delayed allocation reservation > path. Why do we queue it up to a different thread if we synchronously wait for it anyway? From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:14: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2G9EVZI080718 for ; Mon, 16 Mar 2009 04:14:52 -0500 X-ASG-Debug-ID: 1237194850-3ed2039a0000-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 C363A19C326 for ; Mon, 16 Mar 2009 02:14:10 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id fwih9EYgllGUvPbf for ; Mon, 16 Mar 2009 02:14:10 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8te-0006AX-Fu; Mon, 16 Mar 2009 09:14:10 +0000 Date: Mon, 16 Mar 2009 05:14:10 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Subject: Re: [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Message-ID: <20090316091410.GD2636@infradead.org> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-5-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116707-25793-5-git-send-email-david@fromorbit.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: 1237194850 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 15, 2009 at 10:31:46PM +1100, Dave Chinner wrote: > If we are creating lots of small files, we can fail to get > a reservation for inode create earlier than we should due to > EOF preallocation done during delayed allocation reservation. > Hence on the first reservation ENOSPC failure flush all the > delayed allocation blocks out of the system and retry. > > This fixes the last commonly triggered spurious ENOSPC issue > that has been reported. Looks good. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:16: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 n2G9FeD0080931 for ; Mon, 16 Mar 2009 04:16:01 -0500 X-ASG-Debug-ID: 1237194919-1122032e0000-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 BA0481C454B9 for ; Mon, 16 Mar 2009 02:15:19 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id le0dn75vaXizkzSa for ; Mon, 16 Mar 2009 02:15:19 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8ul-0000Lr-8M; Mon, 16 Mar 2009 09:15:19 +0000 Date: Mon, 16 Mar 2009 05:15:19 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 5/5] [XFS] Remove xfs_flush_space Subject: Re: [PATCH 5/5] [XFS] Remove xfs_flush_space Message-ID: <20090316091513.GE2636@infradead.org> References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-6-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116707-25793-6-git-send-email-david@fromorbit.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: 1237194919 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 15, 2009 at 10:31:47PM +1100, Dave Chinner wrote: > The only thing we need to do now when we get an ENOSPC condition during delayed > allocation reservation is flush all the other inodes with delalloc blocks on > them and retry without EOF preallocation. Remove the unneeded mess that is > xfs_flush_space() and just call xfs_flush_inodes() directly from > xfs_iomap_write_delay(). > > Also, change the location of the retry label to avoid trying to do EOF > preallocation because we don't want to do that at ENOSPC. This enables us to > remove the BMAPI_SYNC flag as it is no longer used. Looks good. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:17: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=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 n2G9GnE8081350 for ; Mon, 16 Mar 2009 04:17:09 -0500 X-ASG-Debug-ID: 1237194967-670400f10000-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 2A9391C45BE6; Mon, 16 Mar 2009 02:16:07 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id FUiqHuEBvgCNm4qu; Mon, 16 Mar 2009 02:16:07 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj8vW-00017d-F0; Mon, 16 Mar 2009 09:16:06 +0000 Date: Mon, 16 Mar 2009 05:16:06 -0400 From: Christoph Hellwig To: Hisashi Hifumi Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] XFS: Pagecache usage optimization on XFS Subject: Re: [PATCH] XFS: Pagecache usage optimization on XFS Message-ID: <20090316091606.GA1720@infradead.org> References: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> 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: 1237194988 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 This looks like it should work. did you run XFSQA on a small blocksize filesystem with this applied? From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 04:22:37 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 n2G9MGCU081688 for ; Mon, 16 Mar 2009 04:22:37 -0500 X-ASG-Debug-ID: 1237195315-31b9006d0000-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 D4A4819C197 for ; Mon, 16 Mar 2009 02:21:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ALVggIs20PGnktVh for ; Mon, 16 Mar 2009 02:21:55 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj90e-0007rz-57; Mon, 16 Mar 2009 09:21:24 +0000 Date: Mon, 16 Mar 2009 05:21:24 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Subject: Re: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Message-ID: <20090316092124.GA21496@infradead.org> References: <1237117243-25940-1-git-send-email-david@fromorbit.com> <1237117243-25940-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237117243-25940-2-git-send-email-david@fromorbit.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: 1237195315 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 15, 2009 at 10:40:42PM +1100, Dave Chinner wrote: > Unwritten extent conversion can recurse back into the filesystem due > to memory allocation. Memory reclaim requires I/O completions to be > processed to allow the callers to make progress. If the I/O > completion workqueue thread is doing the recursion, then we have a > deadlock situation. > > Move unwritten extent completion into it's own workqueue so it > doesn't block I/O completions for normal delayed allocation or > overwrite data. Hmm. That was the original reason behind splitting the data from xfsbufd queue. So maybe the split should be just unwritten vs the rest and three queues? Btw, do you have a testcase that can reproduce this? From SEMA-CR-1-3ZWP5R@ptcmarketing.com Mon Mar 16 04:29:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_8BIT_HEADER 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 n2G9Tbmp081869 for ; Mon, 16 Mar 2009 04:29:59 -0500 X-ASG-Debug-ID: 1237195735-111f03340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 232151C45444 for ; Mon, 16 Mar 2009 02:28:55 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id njfAVByWXuuHa1gL for ; Mon, 16 Mar 2009 02:28:55 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,372,1233550800"; d="scan'208,217";a="291788641" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 16 Mar 2009 05:07:29 -0400 Date: Mon, 16 Mar 2009 04:57:47 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: New Enhancements in Pro/ENGINEER Wildfire =?utf-8?q?4.0=E2=80=94Attend?= Live Webcast to Learn More Subject: New Enhancements in Pro/ENGINEER Wildfire =?utf-8?q?4.0=E2=80=94Attend?= Live Webcast to Learn More Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1237192216893_1594896538 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1237195757 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 --BF_1237192216893_1594896538 Content-Type: text/plain; charset=UTF-8 PRODUCT ANNOUNCEMENT Pro/ENGINEER Wildfire 4.0 dramatically reduces hours, hurdles and processing time - see for yourself. What is it about the latest release of Pro/ENGINEER that makes it worthwhile to upgrade? Here is how one of our customers improved their productivity with Pro/ENGINEER Wildfire 4.0. "Importing a complex design that used to take over 3 hours to complete now only takes 13 minutes in Pro/ENGINEER Wildfire4.0!"- Daktronics The breadth of productivity improvements is enough to entice many current customers like you to upgrade. Factor in the inclusion of CAE Lite, CAM Lite, and Manikin Lite at no extra charge, and the reasons not to upgrade quickly fall by the wayside. Pro/ENGINEER Wildfire 4.0 Highlights * 20 times faster design with Auto Round * Clean up models in just 10% of the time with Remove Surface Feature * Reduce retrieval times by up to 50% and memory usage reduction of up to 60% with on-demand loading of full model data Attend the "What's New in Pro/ENGINEER" live webcast and Q&A session led by Mike Campbell, Senior Vice President Pro/ENGINEER Product Management. When: Wednesday, March 25th, 2009 Time: 2:00 - 3:00 p.m. ET How to register: http://www.ptc.com/go/proengineer/webcast (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDJ&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) The productivity enhancements added to Pro/ENGINEER Wildfire 4.0 are best explained by example. Experience them first-hand in our "What's New in Pro/ENGINEER" webcast. (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDJ&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) Simply click here to register. (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDJ&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) ------------------------------------------------------------------------------- "Not an active Maintenance Support customer? Please contact us so you can access the preproduction release and take advantage of all or the Maintenance Support benefits." (http://www.ptc.com/read?&u=&c=&o=&w=&t=http%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D35338) =========================================================================== contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3ZCY9R&campd=1-3XLSDJ&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3ZCY9R&campd=1-3XLSDJ&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com edit profile http://www.ptc.com/read?&w=2354034&t=/common/account/index.htm ------------------------------------------------------------------------------- This email was sent to: xfs@oss.sgi.com PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com. --BF_1237192216893_1594896538 Content-Type: text/html; charset=UTF-8 Receive CAE/CAM/Manikin Lite with Pro/ENGINEER Wildfire 4.0 M070
PTC.com

Product Announcement

Pro/ENGINEER Wildfire 4.0 dramatically reduces hours, hurdles and processing time - see for yourself.

What is it about the latest release of Pro/ENGINEER that makes it worthwhile to upgrade? Here is how one of our customers improved their productivity with Pro/ENGINEER Wildfire 4.0.

 "Importing a complex design that used to take over 3 hours to complete now only takes 13 minutes in Pro/ENGINEER Wildfire 4.0!" - Daktronics

The breadth of productivity improvements is enough to entice many current customers like you to upgrade. Factor in the inclusion of CAE Lite, CAM Lite, and Manikin Lite at no extra charge, and the reasons not to upgrade quickly fall by the wayside.

Pro/ENGINEER Wildfire 4.0 Highlights

  • 20 times faster design with Auto Round
  • Clean up models in just 10% of the time with Remove Surface Feature
  • Reduce retrieval times by up to 50% and memory usage reduction of up to 60% with on-demand loading of full model data

Attend the "What's New in Pro/ENGINEER" live webcast and Q&A session led by Mike Campbell, Senior Vice President Pro/ENGINEER Product Management.

When:   Wednesday, March 25th, 2009
Time:   2:00 - 3:00 p.m. ET
How to register:   http://www.ptc.com/go/proengineer/webcast

The productivity enhancements added to Pro/ENGINEER Wildfire 4.0 are best explained by example. Experience them first-hand in our "What's New in Pro/ENGINEER" webcast.

Simply click here to register.

"Not an active Maintenance Support customer?  Please contact us so you can access the preproduction release and take advantage of all or the Maintenance Support benefits."

contact PTC | privacy policy | unsubscribe | change preferences | edit profile
This email was sent to: xfs@oss.sgi.com     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com.
--BF_1237192216893_1594896538-- From david@fromorbit.com Mon Mar 16 04:41:04 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 n2G9ehSq082213 for ; Mon, 16 Mar 2009 04:41:03 -0500 X-ASG-Debug-ID: 1237196421-121c02760000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9532319BDCA for ; Mon, 16 Mar 2009 02:40:21 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id IL8m4gSCV3I3HwhF for ; Mon, 16 Mar 2009 02:40:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABS7vUl5LAJ7/2dsb2JhbADSbYN/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339637284" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 20:10:19 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1Lj9Ix-0000Ea-2y; Mon, 16 Mar 2009 20:40:19 +1100 Date: Mon, 16 Mar 2009 20:40:19 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Subject: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Message-ID: <20090316094019.GD26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237117603-26071-1-git-send-email-david@fromorbit.com> <20090316075338.GA19858@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316075338.GA19858@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237196422 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0034 1.0000 -1.9986 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.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.20485 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, Mar 16, 2009 at 03:53:38AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:46:37PM +1100, Dave Chinner wrote: > > This series splits up the sync and reclaim code into three > > separate actions. The first is the tree walker, the second is > > the inode validation and the third is the operation to execute > > on the inode. > > > > This allows us to somewhat abstract the radix tree away from the > > act of walking the cached inodes and puts in place mechanisms that > > can be extended for bulk inode cache lookups. > > > > This also splits the inode writeback into separate data and metadata > > sync operations and optimises them a little...... > > Just did a quick XFSQA run with your whole patch series applied and > I get this oops in 001: I haven't seen that - it runs through a UML test run just fine. I'll see if I can reproduce it... If you drop the last patch (the iterator patch) does it work ok? Cheers, Dave. -- Dave Chinner david@fromorbit.com From agruen@suse.de Mon Mar 16 04:56: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 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 n2G9u0vx082992 for ; Mon, 16 Mar 2009 04:56:20 -0500 X-ASG-Debug-ID: 1237197338-670901dc0000-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 4BE441C45B20 for ; Mon, 16 Mar 2009 02:55:38 -0700 (PDT) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id CIgRZxLgcSPKF1XO for ; Mon, 16 Mar 2009 02:55:38 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from Relay2.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 76FD855B47; Mon, 16 Mar 2009 10:55:37 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: Mike Frysinger 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: Mon, 16 Mar 2009 10:53:32 +0100 User-Agent: KMail/1.9.9 Cc: Christoph Hellwig , Eric Sandeen , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <20090316070550.GA628@infradead.org> <200903160331.53142.vapier@gentoo.org> In-Reply-To: <200903160331.53142.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903161053.32745.agruen@suse.de> X-Barracuda-Connect: ns1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1237197339 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 Monday, 16 March 2009 8:31:48 Mike Frysinger wrote: > usually what i do is something like: > args= > libtoolize -n --install 2>/dev/null && args="-i" > libtoolize -c -f $args Sigh, the usual GNU utility problem. I've added a compatibility fix to attr and acl now. Thanks! Andreas From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 05:02:28 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 n2GA27iV083231 for ; Mon, 16 Mar 2009 05:02:28 -0500 X-ASG-Debug-ID: 1237197706-4379013f0000-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 18B3419C544 for ; Mon, 16 Mar 2009 03:01:46 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 9MxphkuGDuNq32lR for ; Mon, 16 Mar 2009 03:01:46 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj9dE-0004qm-5x; Mon, 16 Mar 2009 10:01:16 +0000 Date: Mon, 16 Mar 2009 06:01:16 -0400 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Subject: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Message-ID: <20090316100116.GA16218@infradead.org> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> <20090316075338.GA19858@infradead.org> <20090316094019.GD26138@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316094019.GD26138@disturbed> 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: 1237197707 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, Mar 16, 2009 at 08:40:19PM +1100, Dave Chinner wrote: > If you drop the last patch (the iterator patch) does it work > ok? No. With patches 1-5 applied we deadlock early on because pag_ici_lock never gets released in xfs_sync_inodes_ag for the normal non-error case. From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 05:10:50 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 n2GAATNj083525 for ; Mon, 16 Mar 2009 05:10:50 -0500 X-ASG-Debug-ID: 1237198208-31b802660000-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 1965A19C7D0 for ; Mon, 16 Mar 2009 03:10:08 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id FTi0MUil3pnJO2f6 for ; Mon, 16 Mar 2009 03:10:08 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lj9lo-0008IW-Kr; Mon, 16 Mar 2009 10:10:08 +0000 Date: Mon, 16 Mar 2009 06:10:08 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Subject: Re: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Message-ID: <20090316101008.GA2874@infradead.org> References: <1237117603-26071-1-git-send-email-david@fromorbit.com> <1237117603-26071-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237117603-26071-2-git-send-email-david@fromorbit.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: 1237198209 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 > +static int > +xfs_sync_inode_data( > + struct xfs_inode *ip, > + int flags) > +{ > + struct inode *inode = VFS_I(ip); > + int error = 0; > + > + if (VN_DIRTY(inode)) { > + int locked = 0; > + if (flags & SYNC_TRYLOCK) { > + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) > + locked = 1; > + } else { > + xfs_ilock(ip, XFS_IOLOCK_SHARED); > + locked = 1; > + } > + if (locked) { > + error = xfs_flush_pages(ip, 0, -1, > + (flags & SYNC_WAIT) ? 0 : XFS_B_ASYNC, > + FI_NONE); > + xfs_iunlock(ip, XFS_IOLOCK_SHARED); > + } > + } > + > + if (flags & SYNC_IOWAIT) > + xfs_ioend_wait(ip); > + > + return error; > +} In the end this should look more like: static int xfs_sync_inode_data( struct xfs_inode *ip, int flags) { struct inode *inode = VFS_I(ip); struct address_space *mapping = inode->i_mapping; int error = 0; if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { if (!xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) { if (flags & SYNC_TRYLOCK) goto out; xfs_ilock(ip, XFS_IOLOCK_SHARED); } if (flags & SYNC_WAIT) { error = filemap_write_and_wait(mapping); else error = filemap_fdatawrite(mapping); xfs_iflags_clear(ip, XFS_ITRUNCATED); xfs_iunlock(ip, XFS_IOLOCK_SHARED); } out: if (flags & SYNC_IOWAIT) xfs_ioend_wait(ip); return -error; } From david@fromorbit.com Mon Mar 16 05:28:08 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 n2GARj2m084340 for ; Mon, 16 Mar 2009 05:28:08 -0500 X-ASG-Debug-ID: 1237199243-66fd02960000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BED2B1C45F53 for ; Mon, 16 Mar 2009 03:27:23 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id qU8EqzSaQ5hrn4Qb for ; Mon, 16 Mar 2009 03:27:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKDFvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339654265" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 20:57:21 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjA2R-0001K3-CI; Mon, 16 Mar 2009 21:27:19 +1100 Date: Mon, 16 Mar 2009 21:27:19 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Subject: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Message-ID: <20090316102719.GE26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, mpatocka@redhat.com References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-4-git-send-email-david@fromorbit.com> <20090316091331.GC2636@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316091331.GC2636@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237199244 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0077 1.0000 -1.9705 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.97 X-Barracuda-Spam-Status: No, SCORE=-1.97 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.20489 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, Mar 16, 2009 at 05:13:31AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:31:45PM +1100, Dave Chinner wrote: > > xfs_flush_inodes() currently uses a magic timeout to wait for > > some inodes to be flushed before returning. This isn't > > really reliable but used to be the best that could be done > > due to deadlock potential of waiting for the entire flush. > > > > Now the inode flush is safe to execute while we hold page > > and inode locks, we can wait for all the inodes to flush > > synchronously. Convert the wait mechanism to a completion > > to do this efficiently. This should remove all remaining > > spurious ENOSPC errors from the delayed allocation reservation > > path. > > Why do we queue it up to a different thread if we synchronously wait > for it anyway? To avoid competing with flushes that may already be in progress. This way all the concurrent ENOSPC flushes are serialised by the xfssyncd so it can do optimal flushing without being interfered with.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Mar 16 05:38: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.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 n2GAcJNl084737 for ; Mon, 16 Mar 2009 05:38:40 -0500 X-ASG-Debug-ID: 1237199877-670502fb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A5B751C45FD1 for ; Mon, 16 Mar 2009 03:37:57 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id u4qp2hv4XMufCuqo for ; Mon, 16 Mar 2009 03:37:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3JvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339657294" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:07:55 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjACg-0001Zi-PS; Mon, 16 Mar 2009 21:37:54 +1100 Date: Mon, 16 Mar 2009 21:37:53 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Subject: Re: [PATCH 1/2] XFS: Prevent unwritten extent conversion from blocking I/O completion Message-ID: <20090316103753.GG26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237117243-25940-1-git-send-email-david@fromorbit.com> <1237117243-25940-2-git-send-email-david@fromorbit.com> <20090316092124.GA21496@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316092124.GA21496@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237199878 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.20489 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, Mar 16, 2009 at 05:21:24AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:40:42PM +1100, Dave Chinner wrote: > > Unwritten extent conversion can recurse back into the filesystem due > > to memory allocation. Memory reclaim requires I/O completions to be > > processed to allow the callers to make progress. If the I/O > > completion workqueue thread is doing the recursion, then we have a > > deadlock situation. > > > > Move unwritten extent completion into it's own workqueue so it > > doesn't block I/O completions for normal delayed allocation or > > overwrite data. > > Hmm. That was the original reason behind splitting the data from > xfsbufd queue. So maybe the split should be just unwritten vs the > rest and three queues? > > Btw, do you have a testcase that can reproduce this? No, I hit it a couple of times running xfsqa on a low memory UML image - 256MB of RAM, IIRC - during one of the fstress tests. I got enough information to determine this was the problem and it hasn't showed up since. I think someone also posted a lockdep trace on LKML a couple of months back as well... Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 05:39: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 n2GAcv30084798 for ; Mon, 16 Mar 2009 05:39:18 -0500 X-ASG-Debug-ID: 1237199916-670503050000-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 E5E981C45FEB for ; Mon, 16 Mar 2009 03:38:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LaQROv0rOFDyM10V for ; Mon, 16 Mar 2009 03:38:36 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjADM-00070t-HS; Mon, 16 Mar 2009 10:38:36 +0000 Date: Mon, 16 Mar 2009 06:38:36 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Subject: Re: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Message-ID: <20090316103836.GA24744@infradead.org> References: <1237117243-25940-1-git-send-email-david@fromorbit.com> <1237117243-25940-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237117243-25940-3-git-send-email-david@fromorbit.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: 1237199916 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 This looks good to me. Reviewed-by: Christoph Hellwig But looking at that area I must say I'm not happy with it in general. There are tons of useless roundtrips l_grant_lock because we drop it just before calling xlog_grant_push_ail which needs it for most of it's operation, and because we acquire it just before sv_wait just to drop it. And the duplication between xlog_grant_log_space xlog_regrant_write_log_space is quite ugly, too. From david@fromorbit.com Mon Mar 16 05:46:50 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 n2GAkWsI085645 for ; Mon, 16 Mar 2009 05:46:50 -0500 X-ASG-Debug-ID: 1237200370-66fa03210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8F3731C46032 for ; Mon, 16 Mar 2009 03:46:10 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id 23CSu3qnjVYvJ56F for ; Mon, 16 Mar 2009 03:46:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3JvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339660020" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:16:07 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjAKd-0001kA-Bp; Mon, 16 Mar 2009 21:46:07 +1100 Date: Mon, 16 Mar 2009 21:46:06 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Subject: Re: [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Message-ID: <20090316104606.GI26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, mpatocka@redhat.com References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-3-git-send-email-david@fromorbit.com> <20090316091235.GB2636@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316091235.GB2636@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237200371 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.20489 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, Mar 16, 2009 at 05:12:35AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:31:44PM +1100, Dave Chinner wrote: > > } else { > > + int enospc = 0; > > + ssize_t ret2 = 0; > > + > > +write_retry: > > xfs_rw_enter_trace(XFS_WRITE_ENTER, xip, (void *)iovp, segs, > > *offset, ioflags); > > - ret = generic_file_buffered_write(iocb, iovp, segs, > > + ret2 = generic_file_buffered_write(iocb, iovp, segs, > > pos, offset, count, ret); > > + /* > > + * if we just got an ENOSPC, flush the inode now we > > + * aren't holding any page locks and retry *once* > > + */ > > + if (ret2 == -ENOSPC && !enospc) { > > + error = xfs_flush_pages(xip, 0, -1, 0, FI_NONE); > > + if (error) > > + goto out_unlock_internal; > > + enospc = 1; > > + goto write_retry; > > + } > > + ret = ret2; > > Just use filemap_fdatawrite here directly.. OK. will fix. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Mar 16 05:48: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.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 n2GAlec9085758 for ; Mon, 16 Mar 2009 05:48:00 -0500 X-ASG-Debug-ID: 1237200437-670903360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 796F01C46041 for ; Mon, 16 Mar 2009 03:47:18 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id lXeQq0OPRWQSLzKY for ; Mon, 16 Mar 2009 03:47:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3JvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339660386" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:17:13 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjALg-0001lh-R8; Mon, 16 Mar 2009 21:47:12 +1100 Date: Mon, 16 Mar 2009 21:47:12 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Subject: Re: [PATCH 1/6] [XFS] Split inode data writeback from inode sync. Message-ID: <20090316104712.GJ26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237117603-26071-1-git-send-email-david@fromorbit.com> <1237117603-26071-2-git-send-email-david@fromorbit.com> <20090316101008.GA2874@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316101008.GA2874@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237200439 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.20489 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, Mar 16, 2009 at 06:10:08AM -0400, Christoph Hellwig wrote: > > +static int > > +xfs_sync_inode_data( > > + struct xfs_inode *ip, > > + int flags) > > +{ > > + struct inode *inode = VFS_I(ip); > > + int error = 0; > > + > > + if (VN_DIRTY(inode)) { > > + int locked = 0; > > + if (flags & SYNC_TRYLOCK) { > > + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) > > + locked = 1; > > + } else { > > + xfs_ilock(ip, XFS_IOLOCK_SHARED); > > + locked = 1; > > + } > > + if (locked) { > > + error = xfs_flush_pages(ip, 0, -1, > > + (flags & SYNC_WAIT) ? 0 : XFS_B_ASYNC, > > + FI_NONE); > > + xfs_iunlock(ip, XFS_IOLOCK_SHARED); > > + } > > + } > > + > > + if (flags & SYNC_IOWAIT) > > + xfs_ioend_wait(ip); > > + > > + return error; > > +} > > In the end this should look more like: > > > > static int > xfs_sync_inode_data( > struct xfs_inode *ip, > int flags) > { > struct inode *inode = VFS_I(ip); > struct address_space *mapping = inode->i_mapping; > int error = 0; > > if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > if (!xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) { > if (flags & SYNC_TRYLOCK) > goto out; > xfs_ilock(ip, XFS_IOLOCK_SHARED); > } > > if (flags & SYNC_WAIT) { > error = filemap_write_and_wait(mapping); > else > error = filemap_fdatawrite(mapping); > > xfs_iflags_clear(ip, XFS_ITRUNCATED); > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > } > > out: > if (flags & SYNC_IOWAIT) > xfs_ioend_wait(ip); > return -error; > } Seems sane. I'll rework it around this. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Mar 16 05:50: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 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 n2GAnomX085944 for ; Mon, 16 Mar 2009 05:50:09 -0500 X-ASG-Debug-ID: 1237200546-61d201cc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3A3C019C76F for ; Mon, 16 Mar 2009 03:49:07 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id v2MxxlNosPjFkbFQ for ; Mon, 16 Mar 2009 03:49:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3JvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339661063" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:19:05 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjANV-0001o9-IX; Mon, 16 Mar 2009 21:49:05 +1100 Date: Mon, 16 Mar 2009 21:49:04 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Subject: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Message-ID: <20090316104904.GK26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <1237116342-25701-2-git-send-email-david@fromorbit.com> <20090315151546.GB7145@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090315151546.GB7145@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237200569 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0022 1.0000 -2.0069 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 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.20489 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 Sun, Mar 15, 2009 at 11:15:51AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:25:41PM +1100, Dave Chinner wrote: > > If the large log sector size feature bit is set in the > > superblock by accident (say disk corruption), the then > > fields that are now considered valid are not checked on > > production kernels. The checks are present as ASSERT > > statements so cause a panic on a debug kernel. > > > > Change this so that the fields are validity checked if > > the feature bit is set and abort the log mount if the > > fields do not contain valid values. > > > > Reported-by: Eric Sesterhenn > > Signed-off-by: Dave Chinner > > Looks good to me, but wouldn't be easier to rad if the various sizes > in the error messages were reported decimal instead of in hex? I just find large numbers easier to parse in hex, especially as we are expecting power-of-2 type numbers to come out of this. I'll change it.... > Reviewed-by: Christoph Hellwig > > > } /* xlog_alloc_log */ > > any maybe remove this comment while you're at it? Ok. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 05:51: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 n2GAot4K086044 for ; Mon, 16 Mar 2009 05:51:15 -0500 X-ASG-Debug-ID: 1237200634-66fa033f0000-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 8CFCD1C460DD for ; Mon, 16 Mar 2009 03:50:34 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id rEH7L4zEE47yoMFr for ; Mon, 16 Mar 2009 03:50:34 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjAOw-0007If-5y; Mon, 16 Mar 2009 10:50:34 +0000 Date: Mon, 16 Mar 2009 06:50:34 -0400 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Subject: Re: [PATCH 1/2] [XFS] Validate log feature fields correctly Message-ID: <20090316105034.GA13508@infradead.org> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <1237116342-25701-2-git-send-email-david@fromorbit.com> <20090315151546.GB7145@infradead.org> <20090316104904.GK26138@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316104904.GK26138@disturbed> 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: 1237200634 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, Mar 16, 2009 at 09:49:04PM +1100, Dave Chinner wrote: > I just find large numbers easier to parse in hex, especially as > we are expecting power-of-2 type numbers to come out of this. > I'll change it.... True, the power of two would be an argument for hex. Feel free to keep it. From david@fromorbit.com Mon Mar 16 05:51: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.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 n2GApasp086116 for ; Mon, 16 Mar 2009 05:51:56 -0500 X-ASG-Debug-ID: 1237200673-781e00650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 251AD19C8BF for ; Mon, 16 Mar 2009 03:51:14 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id eArla3lweTXVnGJM for ; Mon, 16 Mar 2009 03:51:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3JvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339659862" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:15:39 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjAK9-0001jT-EJ; Mon, 16 Mar 2009 21:45:37 +1100 Date: Mon, 16 Mar 2009 21:45:37 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, mpatocka@redhat.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Message-ID: <20090316104537.GH26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, mpatocka@redhat.com References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-2-git-send-email-david@fromorbit.com> <20090316090847.GA2636@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316090847.GA2636@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237200675 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.20491 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, Mar 16, 2009 at 05:08:47AM -0400, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:31:43PM +1100, Dave Chinner wrote: > > index 5aeb777..08be36d 100644 > > --- a/fs/xfs/linux-2.6/xfs_fs_subr.c > > +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c > > @@ -74,14 +74,14 @@ xfs_flush_pages( > > > > if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > > xfs_iflags_clear(ip, XFS_ITRUNCATED); > > - ret = filemap_fdatawrite(mapping); > > - if (flags & XFS_B_ASYNC) > > - return -ret; > > - ret2 = filemap_fdatawait(mapping); > > - if (!ret) > > - ret = ret2; > > + ret = -filemap_fdatawrite(mapping); > > } > > - return -ret; > > + if (flags & XFS_B_ASYNC) > > + return ret; > > + ret2 = xfs_wait_on_pages(ip, first, last); > > + if (!ret) > > + ret = ret2; > > + return ret; > > } > > How does this belong into this patch series? So xfs_flush_pages waits on writeback pages which aren't caught by mapping_tagged(mapping, PAGECACHE_TAG_DIRTY). If we are waiting for a flush to complete, we should be waiting for all pages under IO to complete regardless of whether there are dirty pages or not. That matters if we are doing 2 passes to flush everything and then wait; the wait won't see dirty mappings, but there might still be pages under IO.... > Also I think the sync code should just use filemap_fdatawait and > filemap_fdatawait directly. It's at a high enough level that we don't > need all these obsfucations. OK. I'll rework it so that: > > + if (flags & SYNC_DELWRI) { > > + if (VN_DIRTY(inode)) { > > + if (flags & SYNC_TRYLOCK) { > > + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) > > + lock_flags |= XFS_IOLOCK_SHARED; > > + } else { > > + xfs_ilock(ip, XFS_IOLOCK_SHARED); > > + lock_flags |= XFS_IOLOCK_SHARED; > > + } > > > + if (lock_flags & XFS_IOLOCK_SHARED) { > > Too long line and pretty ugly use of the lock_flags variable, but given > that it gets sorted out in the sync series I think we can leave it that way. This gets done early and the later patches become simpler. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Mar 16 05:54: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.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 n2GAs27B086358 for ; Mon, 16 Mar 2009 05:54:23 -0500 X-ASG-Debug-ID: 1237200820-7836005c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CE50819C8E8 for ; Mon, 16 Mar 2009 03:53:40 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id iAAP9GVmfQy8WaOy for ; Mon, 16 Mar 2009 03:53:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKDFvUl5LAJ7/2dsb2JhbADTB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="329560638" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail04.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:05:20 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjAAA-0001Vn-7S; Mon, 16 Mar 2009 21:35:18 +1100 Date: Mon, 16 Mar 2009 21:35:18 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Subject: Re: [PATCH 0/6] [XFS] introduce a AG inode tree walker Message-ID: <20090316103518.GF26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237117603-26071-1-git-send-email-david@fromorbit.com> <20090316075338.GA19858@infradead.org> <20090316094019.GD26138@disturbed> <20090316100116.GA16218@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316100116.GA16218@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1237200821 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0011 1.0000 -2.0136 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 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.20491 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, Mar 16, 2009 at 06:01:16AM -0400, Christoph Hellwig wrote: > On Mon, Mar 16, 2009 at 08:40:19PM +1100, Dave Chinner wrote: > > If you drop the last patch (the iterator patch) does it work > > ok? > > No. With patches 1-5 applied we deadlock early on because pag_ici_lock > never gets released in xfs_sync_inodes_ag for the normal non-error case. Ah, then I screwed up the migration of the patches from one set of trees to another. I'll go back and rework this one, including your feedback and repost when done. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Mar 16 06:01: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.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 n2GB1ICu087094 for ; Mon, 16 Mar 2009 06:01:38 -0500 X-ASG-Debug-ID: 1237201255-670803740000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E83C1C4558D for ; Mon, 16 Mar 2009 04:00:56 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id l5PvA3aifjwKR4Nh for ; Mon, 16 Mar 2009 04:00:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKfMvUl5LAJ7/2dsb2JhbADTCIN/Bg X-IronPort-AV: E=Sophos;i="4.38,372,1233495000"; d="scan'208";a="339665147" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 16 Mar 2009 21:30:54 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjAYv-00024Z-Ol; Mon, 16 Mar 2009 22:00:53 +1100 Date: Mon, 16 Mar 2009 22:00:52 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Subject: Re: [PATCH 2/2] XFS: Inform the xfsaild of the push target before sleeping Message-ID: <20090316110052.GL26138@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <1237117243-25940-1-git-send-email-david@fromorbit.com> <1237117243-25940-3-git-send-email-david@fromorbit.com> <20090316103836.GA24744@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316103836.GA24744@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237201257 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.20491 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, Mar 16, 2009 at 06:38:36AM -0400, Christoph Hellwig wrote: > This looks good to me. > > > Reviewed-by: Christoph Hellwig > > But looking at that area I must say I'm not happy with it in general. > There are tons of useless roundtrips l_grant_lock because we drop > it just before calling xlog_grant_push_ail which needs it for > most of it's operation, and because we acquire it just before > sv_wait just to drop it. > > And the duplication between xlog_grant_log_space > xlog_regrant_write_log_space is quite ugly, too. I totally agree, but I don't feel like trying to rewrite this code right now. Maybe some rainy day.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From felixb@oss.sgi.com Mon Mar 16 09:16: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.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 n2GEGRdZ094747 for ; Mon, 16 Mar 2009 09:16:27 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2GEGNBH094707; Mon, 16 Mar 2009 09:16:23 -0500 Date: Mon, 16 Mar 2009 09:16:23 -0500 Message-Id: <200903161416.n2GEGNBH094707@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-14018-g5bee17f X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 16b71fdf97599f1b1b7f38418ee9922d9f117396 X-Git-Newrev: 5bee17f18b595937e6beafeee5197868a3f74a06 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 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 16b71fdf97599f1b1b7f38418ee9922d9f117396 (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 | 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 felixb@oss.sgi.com Mon Mar 16 09:16:31 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_24 autolearn=no 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 n2GEGVb0094817 for ; Mon, 16 Mar 2009 09:16:31 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2GEGSiL094752; Mon, 16 Mar 2009 09:16:28 -0500 Date: Mon, 16 Mar 2009 09:16:28 -0500 Message-Id: <200903161416.n2GEGSiL094752@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-14090-g4740cd8 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: da5309cd28ffda6ed8a4147bd14f1e4fbbd6503d X-Git-Newrev: 4740cd8b4f27d6ac11e76c432d5d03fb780b2596 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 6cc8764 xfs: factor out code to find the longest free extent in the AG cb4c8cc xfs: kill VN_BAD 8fab451 xfs: kill vn_atime_* helpers. 076e6ac xfs: cleanup xlog_bread ff0205e xfs: cleanup xlog_recover_do_trans dd0bbad xfs: remove another leftover of the old inode log item format 21b699c xfs: cleanup log unmount handling from da5309cd28ffda6ed8a4147bd14f1e4fbbd6503d (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 6cc87645e2a3c28d857b074e90bf88bfcd117afa Author: Dave Chinner Date: Mon Mar 16 08:29:46 2009 +0100 xfs: factor out code to find the longest free extent in the AG Signed-off-by: Dave Chinner Signed-off-by: Christoph Hellwig commit cb4c8cc1e92bc68c952e9a81a9fb9736bd8150de Author: Christoph Hellwig Date: Mon Mar 16 08:25:25 2009 +0100 xfs: kill VN_BAD Remove this rather pointless wrapper and use is_bad_inode directly. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 8fab451e3cfe02a5e3dfc4bab3cfb975bc11fc09 Author: Christoph Hellwig Date: Mon Mar 16 08:24:46 2009 +0100 xfs: kill vn_atime_* helpers. Two out of three are unused already, and the third is better done open-coded with a comment describing what's going on here. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 076e6acb8f0d9532ee6c50512c1927c0a8e34f2f Author: Christoph Hellwig Date: Mon Mar 16 08:24:13 2009 +0100 xfs: cleanup xlog_bread Most callers of xlog_bread need to call xlog_align to get the actual offset. Consolidate that call into the main xlog_bread and provide a _xlog_bread for those few that don't want the actual offset. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit ff0205e032b9733bb634ad5dadc79a0f6d30c721 Author: Christoph Hellwig Date: Mon Mar 16 08:20:52 2009 +0100 xfs: cleanup xlog_recover_do_trans Change the big if-elsif-else block handling the different item types into a more natural switch, remove assignments in conditionals and remove an out of place comment from centuries ago on IRIX. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit dd0bbad81c8d02315a5035d3d6ea441dd1254dc1 Author: Christoph Hellwig Date: Mon Mar 16 08:19:59 2009 +0100 xfs: remove another leftover of the old inode log item format There's another little snipplet of code left from the handling of the old inode log item format in xlog_recover_do_inode_trans. Kill it as it can't be reached anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 21b699c89545ed94d9a1c6fcc8ac704784f68f40 Author: Christoph Hellwig Date: Mon Mar 16 08:19:29 2009 +0100 xfs: cleanup log unmount handling Kill the current xfs_log_unmount wrapper and opencode the two function calls in the only caller. Rename the current xfs_log_unmount_dealloc to xfs_log_unmount as it undoes xfs_log_mount and the new name makes that more clear. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_vnode.h | 27 ---- fs/xfs/xfs_alloc.c | 26 +++- fs/xfs/xfs_alloc.h | 6 + fs/xfs/xfs_bmap.c | 12 +-- fs/xfs/xfs_filestream.c | 9 +- fs/xfs/xfs_itable.c | 7 +- fs/xfs/xfs_log.c | 15 +-- fs/xfs/xfs_log.h | 3 +- fs/xfs/xfs_log_priv.h | 1 - fs/xfs/xfs_log_recover.c | 304 ++++++++++++++++++++++++------------------ fs/xfs/xfs_mount.c | 5 +- fs/xfs/xfs_vnodeops.c | 4 +- 12 files changed, 217 insertions(+), 202 deletions(-) hooks/post-receive -- XFS development tree From Steffen.Knauf@renderforce.de Mon Mar 16 09:19: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.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 n2GEJ4mg094945 for ; Mon, 16 Mar 2009 09:19:24 -0500 X-ASG-Debug-ID: 1237213101-2335028f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p05-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 76DDD19D655 for ; Mon, 16 Mar 2009 07:18:22 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by cuda.sgi.com with ESMTP id KAERm8tBToZqm0Jj for ; Mon, 16 Mar 2009 07:18:22 -0700 (PDT) X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo05 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (mrclete mo56) (RZmta 18.26) with ESMTP id 500ecbl2GDtNBh for ; Mon, 16 Mar 2009 15:07:09 +0100 (MET) Message-ID: <49BE5CC9.9000605@renderforce.de> Date: Mon, 16 Mar 2009 15:06:01 +0100 From: Steffen Knauf Reply-To: steffen.knauf@renderforce.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Multiple Mounting of one XFS Partition Subject: Multiple Mounting of one XFS Partition Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p05-ob.rzone.de[81.169.146.181] X-Barracuda-Start-Time: 1237213123 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4982 1.0000 0.0000 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=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20503 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello, i have 2 Servers which are connected with a raid via FibreChannel. Both of them have mounted the same XFS-Partition. But if i change a Filepermission or add some Files at the Partition of server1, the partition of server2 don't show the modifications until i remount the Partitions. I don't know how whether it is a cache Option or something else. Perhaps someone have an idea. Thanks! greets Steffen From felixb@sgi.com Mon Mar 16 09:51:50 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 n2GEpTuo097399 for ; Mon, 16 Mar 2009 09:51:49 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id ECD3630408B for ; Mon, 16 Mar 2009 07:51:08 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id 404BF700016A; Mon, 16 Mar 2009 09:38:23 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <97425114-90E3-4421-9737-FD6ABF1860AE@sgi.com> From: Felix Blyakher To: steffen.knauf@renderforce.de In-Reply-To: <49BE5CC9.9000605@renderforce.de> 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: Multiple Mounting of one XFS Partition Date: Mon, 16 Mar 2009 09:38:21 -0500 References: <49BE5CC9.9000605@renderforce.de> 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 16, 2009, at 9:06 AM, Steffen Knauf wrote: > Hello, > > i have 2 Servers which are connected with a raid via FibreChannel. Unless you have some sort of cluster filesystem, it's not going to work. > > Both of them have mounted the same XFS-Partition. But if i change a > Filepermission > or add some Files at the Partition of server1, the partition of > server2 don't show the modifications > until i remount the Partitions. The changes done by server1 won't be flushed to disk, where they could be seen by server2, till much later, or on unmount. > I don't know how whether it is a cache Option or something else. That's how any modern filesystem work. Cheers, Felix > > Perhaps someone have an idea. > Thanks! > > greets > > Steffen > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From michael.monnerie@is.it-management.at Mon Mar 16 11:18:06 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 n2GGHiun101731 for ; Mon, 16 Mar 2009 11:18:05 -0500 X-ASG-Debug-ID: 1237220240-6d4402080000-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 B854819E06E for ; Mon, 16 Mar 2009 09:17:21 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id 1GvkQ3em8oLVdc2G for ; Mon, 16 Mar 2009 09:17:21 -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 00CD3461C for ; Mon, 16 Mar 2009 17:17:20 +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 B2E4540017F for ; Mon, 16 Mar 2009 17:17:19 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at 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: Mon, 16 Mar 2009 17:17:19 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.28.7-ZMI; KDE/4.1.3; x86_64; ; ) References: <200903121239.35442@zmi.at> <200903142043.11638.Martin@lichtvoll.de> In-Reply-To: <200903142043.11638.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903161717.19362@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1237220241 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0148 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 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.20506 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 Samstag 14 M=E4rz 2009 Martin Steigerwald wrote: > Am Donnerstag 12 M=E4rz 2009 schrieb Michael Monnerie: > > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ > BTW I think you gave away a subcriber only link. The article is not > officially available yet: > http://lwn.net/Articles/322823/ > LWN might not be too happy with this. Nope. I am a subscriber, and can generate such Links in order to=20 provider an article to others. If you read that, they offer a "Free=20 trial subscription" for 3 months, and encourage you to pay then. I can=20 recommend lwn.net a lot, so maybe some people subscribe there because of=20 my posting :-) 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 SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 16:04:00 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_54, J_CHICKENPOX_62,J_CHICKENPOX_63,J_CHICKENPOX_65,J_CHICKENPOX_66, J_CHICKENPOX_73,J_CHICKENPOX_75 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 n2GL3dn8113933 for ; Mon, 16 Mar 2009 16:03:59 -0500 X-ASG-Debug-ID: 1237237377-7a4f01fd0000-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 B752E19F24E for ; Mon, 16 Mar 2009 14:02:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id HkHWrQyFceJ0p34w for ; Mon, 16 Mar 2009 14:02:57 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjJxR-0003v5-N0; Mon, 16 Mar 2009 21:02:49 +0000 Date: Mon, 16 Mar 2009 17:02:49 -0400 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: <20090316210249.GA2641@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <20090316070550.GA628@infradead.org> <200903160331.53142.vapier@gentoo.org> <200903161053.32745.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903161053.32745.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: 1237237398 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, Mar 16, 2009 at 10:53:32AM +0100, Andreas Gruenbacher wrote: > On Monday, 16 March 2009 8:31:48 Mike Frysinger wrote: > > usually what i do is something like: > > args= > > libtoolize -n --install 2>/dev/null && args="-i" > > libtoolize -c -f $args > > Sigh, the usual GNU utility problem. I've added a compatibility fix to attr > and acl now. Thanks! Ok. Can anyone review the cumulated autotools/libtool patch for xfsprogs below? Subject: Automake and libtool fixes From: Andreas Gruenbacher Remove aclocal.m4 from the repository and generate it when needed. Move the AC_PROG_LIBTOOL autoconf macro and use libtoolize according to the libtool info pages. 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 Signed-off-by: Christoph Hellwig Index: xfsprogs-dev/Makefile =================================================================== --- xfsprogs-dev.orig/Makefile 2009-03-16 07:57:07.891007993 +0100 +++ xfsprogs-dev/Makefile 2009-03-16 21:58:18.036977931 +0100 @@ -9,11 +9,18 @@ ifeq ($(HAVE_BUILDDEFS), yes) include $(TOPDIR)/include/builddefs endif -CONFIGURE = configure include/builddefs include/platform_defs.h -LSRCFILES = configure configure.in Makepkgs aclocal.m4 install-sh README VERSION +CONFIGURE = \ + aclocal.m4 \ + configure config.guess config.sub \ + ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \ + m4/ltversion.m4 m4/lt~obsolete.m4 \ + include/builddefs include/platform_defs.h +LSRCFILES = \ + configure.in Makepkgs install-sh README VERSION \ + configure aclocal.m4 -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 confdefs.h 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 +28,7 @@ TOOL_SUBDIRS = copy db estimate fsck fsr 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 @@ -45,7 +52,15 @@ else clean: # if configure hasn't run, nothing to clean endif +# Recent versions of libtool require the -i option for copying auxiliary +# files (config.sub, config.guess, install-sh, ltmain.sh), while older +# versions will copy those files anyway, and don't understand -i. +LIBTOOLIZE_INSTALL = `libtoolize -n -i >/dev/null 2>/dev/null && echo -i` + configure include/builddefs: + libtoolize -c $(LIBTOOLIZE_INSTALL) -f + cp include/install-sh . + aclocal -I m4 autoconf ./configure \ --prefix=/ \ @@ -68,9 +83,6 @@ include/platform_defs.h: include/buildde $(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) @@ -90,4 +102,5 @@ install-qa: install $(addsuffix -install realclean distclean: clean rm -f $(LDIRT) $(CONFIGURE) + rm -f include/builddefs include/config.h install-sh libtool rm -rf autom4te.cache Logs Index: xfsprogs-dev/configure.in =================================================================== --- xfsprogs-dev.orig/configure.in 2009-03-16 07:57:07.898984077 +0100 +++ xfsprogs-dev/configure.in 2009-03-16 21:58:18.036977931 +0100 @@ -1,6 +1,10 @@ AC_INIT(include/libxfs.h) +AC_CONFIG_AUX_DIR([.]) +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) Index: xfsprogs-dev/m4/package_utilies.m4 =================================================================== --- xfsprogs-dev.orig/m4/package_utilies.m4 2009-03-16 07:57:07.903978218 +0100 +++ xfsprogs-dev/m4/package_utilies.m4 2009-03-16 07:57:09.538978690 +0100 @@ -32,8 +32,6 @@ AC_DEFUN([AC_PACKAGE_UTILITIES], AC_SUBST(make) AC_PACKAGE_NEED_UTILITY($1, "$make", make, [GNU make]) - AC_PROG_LIBTOOL - if test -z "$TAR"; then AC_PATH_PROG(TAR, tar,, /usr/freeware/bin:/bin:/usr/local/bin:/usr/bin) fi Index: xfsprogs-dev/include/Makefile =================================================================== --- xfsprogs-dev.orig/include/Makefile 2009-03-16 21:58:09.403978018 +0100 +++ xfsprogs-dev/include/Makefile 2009-03-16 21:58:18.036977931 +0100 @@ -36,8 +36,8 @@ HFILES += $(PKG_PLATFORM).h PHFILES = darwin.h freebsd.h irix.h linux.h DKHFILES = volume.h fstyp.h dvh.h LSRCFILES = $(shell echo $(PHFILES) | sed -e "s/$(PKG_PLATFORM).h//g") -LSRCFILES += platform_defs.h.in builddefs.in buildmacros buildrules $(DKHFILES) -LSRCFILES += command.h input.h path.h project.h unaligned.h +LSRCFILES += platform_defs.h.in builddefs.in buildmacros buildrules install-sh +LSRCFILES += $(DKHFILES) command.h input.h path.h project.h unaligned.h LDIRT = xfs disk default install: xfs disk Index: xfsprogs-dev/include/install-sh =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs-dev/include/install-sh 2009-03-16 21:58:18.037978687 +0100 @@ -0,0 +1,349 @@ +#! /bin/sh +# +# Copyright (c) 2000-2001 Silicon Graphics, Inc. All Rights Reserved. +# +# This script emulates bsd install and also recognises +# two environment variables, with the following semantics :- +# +# $DIST_MANIFEST - if set, the name of the file to append manifest +# information in the following format: +# File : f mode owner group src target +# Directory: d mode owner group target +# Symlink : l linkval target +# +# $DIST_ROOT - if set, prepend to target +# +# The sematics of all combinations of these two variables +# are as follows: +# +# $DIST_MANIFEST? $DIST_ROOT? | Copy? Append Manifest? +# -----------------------------+-------------------------- +# not set not set | yes no +# not set set | yes no +# set not set | no yes +# set set | yes yes +# +_usage() { + echo "Usage: $prog [-o owner] [-g group] [-m mode] -d directory" + echo "or $prog [-D] [-o owner] [-g group] [-m mode] file directory/file" + echo "or $prog [-o owner] [-g group] [-m mode] file [file ...] directory" + echo "or $prog -S file target (creates \"target\" symlink)" + echo "or $prog -T lt_arg [-o owner] [-g group] [-m mode] libtool.lai directory" + echo "" + echo "The \$DIST_MANIFEST and \$DIST_ROOT environment variables affect the" + echo "behaviour of this command - see comments in the script." + echo "The -D flag is only available for the second usage, and causes" + echo "the target directory to be created before installing the file." + echo "" + exit 1 +} + +_chown () +{ + _st=255 + if [ $# -eq 3 ] ; then + chown $1:$2 $3 + _st=$? + if [ $_st -ne 0 ] ; then + if [ $REAL_UID != '0' ] ; then + if [ ! -f $DIST_ROOT/.chown.quiet ] ; then + echo '===============================================' + echo Ownership of files under ${DIST_ROOT:-/} + echo cannot be changed + echo '===============================================' + if [ -n "$DIST_ROOT" ] ; then + touch $DIST_ROOT/.chown.quiet + fi + fi + _st=0 + fi + fi + fi + + return $_st +} + + +_manifest () +{ + echo $* | sed -e 's/\/\//\//g' >>${DIST_MANIFEST:-/dev/null} +} + +prog=`basename $0` +HERE=`pwd` +dflag=false +Dflag=false +Sflag=false +Tflag=false +DIRMODE=755 +FILEMODE=644 +OWNER=`id -u` +GROUP=`id -g` +REAL_UID=$OWNER + +# default is to install and don't append manifest +INSTALL=true +MANIFEST=: + +[ -n "$DIST_MANIFEST" -a -z "$DIST_ROOT" ] && INSTALL=false +[ -n "$DIST_MANIFEST" ] && MANIFEST="_manifest" + +[ $# -eq 0 ] && _usage + +if $INSTALL +then + CP=cp; LN=ln; MKDIR=mkdir; CHMOD=chmod; CHOWN=_chown +else + CP=true; LN=true; MKDIR=true; CHMOD=true; CHOWN=true +fi + +[ -n "$DIST_ROOT" -a $REAL_UID -ne 0 ] && CHOWN=true + +while getopts "Dcm:d:S:o:g:T:" c $* +do + case $c in + c) + ;; + g) + GROUP=$OPTARG + ;; + o) + OWNER=$OPTARG + ;; + m) + DIRMODE=`expr $OPTARG` + FILEMODE=$DIRMODE + ;; + D) + Dflag=true + ;; + S) + symlink=$OPTARG + Sflag=true + ;; + d) + dir=$DIST_ROOT/$OPTARG + dflag=true + ;; + T) + lt_install=$OPTARG + Tflag=true + ;; + *) + _usage + ;; + esac +done + +shift `expr $OPTIND - 1` + +status=0 +if $dflag +then + # + # first usage + # + $MKDIR -p $dir + status=$? + if [ $status -eq 0 ] + then + $CHMOD $DIRMODE $dir + status=$? + fi + if [ $status -eq 0 ] + then + $CHOWN $OWNER $GROUP $dir + status=$? + fi + $MANIFEST d $DIRMODE $OWNER $GROUP ${dir#$DIST_ROOT} +elif $Sflag +then + # + # fourth usage (symlink) + # + if [ $# -ne 1 ] + then + _usage + else + target=$DIST_ROOT/$1 + fi + $LN -s -f $symlink $target + status=$? + $MANIFEST l $symlink ${target#$DIST_ROOT} +elif $Tflag +then + # + # -T (install libs built by libtool) + # + if [ $# -ne 2 ] + then + _usage + else + libtool_lai=$1 + # source the libtool variables + if [ ! -f $libtool_lai ] + then + echo "$prog: Unable to find libtool library file $libtool_lai" + exit 2 + fi + . ./$libtool_lai + target=$DIST_ROOT/$2 + fi + case $lt_install in + so_dot_version) + # Loop until we find libfoo.so.x.y.z, then break out. + for solib in $library_names + do + # does it have enough parts? libfoo.so.x.y.z == 5 + cnt=`echo "$solib" | sed -e 's/\./ /g' | wc -w` + if [ $cnt -eq 5 ] + then + install_name=$target/$solib + $CP $solib $install_name + status=$? + $MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$solib ${install_name#$DIST_ROOT} + break + fi + done + ;; + + so_*) + case $lt_install in + so_dot_current) + # ln -s libfoo.so.x.y.z to libfoo.so.x + from_parts=5 # libfoo.so.x.y.z + to_parts=3 # libfoo.so.x + ;; + so_base) + # ln -s libfoo.so.x to libfoo.so + from_parts=3 # libfoo.so.x + to_parts=2 # libfoo.so + ;; + *) + echo "$prog: -T $lt_install invalid" + exit 2 + ;; + esac + + # Loop until we find the names, then break out. + for solib in $library_names + do + # does it have enough parts? + cnt=`echo "$solib" | sed -e 's/\./ /g' | wc -w` + if [ $cnt -eq $from_parts ] + then + from_name=$solib + elif [ $cnt -eq $to_parts ] + then + to_name=$solib + fi + + if [ -n "$from_name" ] && [ -n "$to_name" ] + then + install_name=$target/$to_name + $LN -s -f $from_name $install_name + status=$? + $MANIFEST l $from_name ${install_name#$DIST_ROOT} + break + fi + done + ;; + old_lib) + install_name=$target/$old_library + $CP $old_library $install_name + status=$? + $MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$old_library ${install_name#$DIST_ROOT} + ;; + *) + echo "$prog: -T $lt_install invalid" + exit 2 + ;; + esac + + case $lt_install in + old_lib|so_dot_version) + if [ $status -eq 0 ] + then + $CHMOD $FILEMODE $install_name + $CHOWN $OWNER $GROUP $install_name + fi + ;; + esac + +else + list="" + dir="" + if [ $# -eq 2 ] + then + # + # second usage + # + f=$1 + dir=$DIST_ROOT/$2 + if $Dflag + then + mkdir -p `dirname $dir` + fi + $CP $f $dir + status=$? + if [ $status -eq 0 ] + then + if [ -f $dir/$f ] + then + $CHMOD $FILEMODE $dir/$f + status=$? + if [ $status -eq 0 ] + then + $CHOWN $OWNER $GROUP $dir/$f + status=$? + fi + $MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$f ${dir#$DIST_ROOT}/$f + else + $CHMOD $FILEMODE $dir + status=$? + if [ $status -eq 0 ] + then + $CHOWN $OWNER $GROUP $dir + status=$? + fi + $MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$dir ${dir#$DIST_ROOT} + fi + fi + else + # + # third usage + # + n=1 + while [ $# -gt 0 ] + do + if [ $# -gt 1 ] + then + list="$list $1" + else + dir=$DIST_ROOT/$1 + fi + shift + done + + # echo DIR=$dir list=\"$list\" + for f in $list + do + $CP $f $dir + status=$? + if [ $status -eq 0 ] + then + $CHMOD $FILEMODE $dir/$f + status=$? + if [ $status -eq 0 ] + then + $CHOWN $OWNER $GROUP $dir/$f + status=$? + fi + $MANIFEST f $FILEMODE $OWNER $GROUP $HERE/$f ${dir#$DIST_ROOT}/$f + fi + [ $status -ne 0 ] && break + done + fi +fi + +exit $status From SRS0+bb5643a01525f31165fd+2031+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 16 16:24:14 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 n2GLNrZt115180 for ; Mon, 16 Mar 2009 16:24:14 -0500 X-ASG-Debug-ID: 1237238612-1bcf014e0000-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 063FB19F60E for ; Mon, 16 Mar 2009 14:23:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id FYLioMtlQ0zrUo9H for ; Mon, 16 Mar 2009 14:23:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjKHU-0007KE-F6; Mon, 16 Mar 2009 21:23:32 +0000 Date: Mon, 16 Mar 2009 17:23:32 -0400 From: Christoph Hellwig To: "Nathaniel W. Turner" Cc: 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 Message-ID: <20090316212332.GA8496@infradead.org> References: <49B48B8E.3030602@houseofnate.net> <49B491EA.4090003@houseofnate.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B491EA.4090003@houseofnate.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: 1237238613 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 08, 2009 at 11:50:02PM -0400, Nathaniel W. Turner wrote: > (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; Given that we skip it for -d and -n this is fine with me. I think we might want to delay this change in the way xfs_repair operates until after we get a 3.0.1 release out with all the build system fixes (hopefully really soon) From felixb@sgi.com Mon Mar 16 17:01:08 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 n2GM0lw3116776 for ; Mon, 16 Mar 2009 17:01:07 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1974D8F80BA for ; Mon, 16 Mar 2009 15:00:27 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id 5DA69700016A; Mon, 16 Mar 2009 15:55:33 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <6BDA2FB2-83C0-4627-A485-0CBC80FA47A2@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090316084651.GA22430@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH 0/7] a couple more random cleanups for 2.6.30 Date: Mon, 16 Mar 2009 15:55:32 -0500 References: <20090220085207.663702000@bombadil.infradead.org> <20090316084651.GA22430@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 Mar 16, 2009, at 3:46 AM, Christoph Hellwig wrote: > All patches are now available to pull from > > git://git.kernel.org/pub/scm/fs/xfs/xfs.git I pushed them to oss this morning. Felix > > > with the minor review comments from Dave incorporated. > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Mar 16 21:18: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.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 n2H2IS0f128566 for ; Mon, 16 Mar 2009 21:18:49 -0500 X-ASG-Debug-ID: 1237256266-5ace00210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E60081C49EFB for ; Mon, 16 Mar 2009 19:17:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id qLziALAqDSObAayT for ; Mon, 16 Mar 2009 19:17:46 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2H2HjsL027388; Mon, 16 Mar 2009 22:17:45 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2H2HkLP025101; Mon, 16 Mar 2009 22:17:46 -0400 Message-ID: <49BF0848.1050909@sandeen.net> Date: Mon, 16 Mar 2009 21:17:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: steffen.knauf@renderforce.de CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Multiple Mounting of one XFS Partition Subject: Re: Multiple Mounting of one XFS Partition References: <49BE5CC9.9000605@renderforce.de> In-Reply-To: <49BE5CC9.9000605@renderforce.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237256287 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0189 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20543 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Steffen Knauf wrote: > Hello, > > i have 2 Servers which are connected with a raid via FibreChannel. > Both of them have mounted the same XFS-Partition. But if i change a > Filepermission > or add some Files at the Partition of server1, the partition of server2 > don't show the modifications > until i remount the Partitions. I don't know how whether it is a cache > Option or something else. > Perhaps someone have an idea. > Thanks! > > greets You can't do this. It will corrupt your filesystem; there is *nothing* which will give you coherency between the nodes. This is what SGI sells CXFS for (for big $$$) -Eric From hifumi.hisashi@oss.ntt.co.jp Mon Mar 16 23:07: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.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 n2H47SEU133379 for ; Mon, 16 Mar 2009 23:07:49 -0500 X-ASG-Debug-ID: 1237262806-5cd500d80000-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 40A9C1A09F0; Mon, 16 Mar 2009 21:06:46 -0700 (PDT) Received: from serv2.oss.ntt.co.jp (serv2.oss.ntt.co.jp [222.151.198.100]) by cuda.sgi.com with ESMTP id v1PcqB5f3FCIWOWf; Mon, 16 Mar 2009 21:06:46 -0700 (PDT) Received: from serv2.oss.ntt.co.jp (localhost [127.0.0.1]) by serv2.oss.ntt.co.jp (Postfix) with ESMTP id 9CB6E2480CE; Tue, 17 Mar 2009 13:06:44 +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 8BC152480CB; Tue, 17 Mar 2009 13:06:44 +0900 (JST) Received: from hifumi-PC.oss.ntt.co.jp (unknown [172.17.1.20]) by serv1.oss.ntt.co.jp (Postfix) with ESMTP id D88B3104165; Tue, 17 Mar 2009 13:06:42 +0900 (JST) Message-Id: <6.0.0.20.2.20090317102134.06e60b30@172.19.0.2> X-Sender: hhifumi@172.19.0.2 X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Tue, 17 Mar 2009 13:03:08 +0900 To: Christoph Hellwig From: Hisashi Hifumi X-ASG-Orig-Subj: Re: [PATCH] XFS: Pagecache usage optimization on XFS Subject: Re: [PATCH] XFS: Pagecache usage optimization on XFS Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com In-Reply-To: <20090316091606.GA1720@infradead.org> References: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> <20090316091606.GA1720@infradead.org> 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: 1237262828 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Whitelist: BODY (http://marc\.info/\?) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean At 18:16 09/03/16, Christoph Hellwig wrote: >This looks like it should work. did you run XFSQA on a small blocksize >filesystem with this applied? Hi. I did XFSQA test on XFS partition with this patch applied. arch:ia64 pagesize:16K blocksize:2K The result of XFSQA test 001~ 202 except 182 was OK. It was discussed about the failure of test 182 as follows. http://marc.info/?l=linux-fsdevel&m=122535673232638&w=2 Subject: do_sync() and XFSQA test 182 failures.... From SRS0+326e7d8f0257c4878c57+2032+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 17 01:43:13 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=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 n2H6gqL0143125 for ; Tue, 17 Mar 2009 01:43:13 -0500 X-ASG-Debug-ID: 1237272151-1e23012f0000-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 E1A541A0C31; Mon, 16 Mar 2009 23:42:31 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id DpRxn7bwD5ypbMaz; Mon, 16 Mar 2009 23:42:31 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjT0Q-0003jv-F6; Tue, 17 Mar 2009 06:42:30 +0000 Date: Tue, 17 Mar 2009 02:42:30 -0400 From: Christoph Hellwig To: Hisashi Hifumi Cc: Christoph Hellwig , xfs-masters@oss.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] XFS: Pagecache usage optimization on XFS Subject: Re: [PATCH] XFS: Pagecache usage optimization on XFS Message-ID: <20090317064230.GA26111@infradead.org> References: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> <20090316091606.GA1720@infradead.org> <6.0.0.20.2.20090317102134.06e60b30@172.19.0.2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20090317102134.06e60b30@172.19.0.2> 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: 1237272151 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 17, 2009 at 01:03:08PM +0900, Hisashi Hifumi wrote: > > At 18:16 09/03/16, Christoph Hellwig wrote: > >This looks like it should work. did you run XFSQA on a small blocksize > >filesystem with this applied? > > Hi. > I did XFSQA test on XFS partition with this patch applied. > > arch:ia64 > pagesize:16K > blocksize:2K Thanks a lot. In that case the patch is fine with me. Reviewed-by: Christoph Hellwig (as in reviewing the generic function to make sense with XFS :)) From mpatocka@redhat.com Tue Mar 17 08:10:50 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 n2HDATDx158725 for ; Tue, 17 Mar 2009 08:10:50 -0500 X-ASG-Debug-ID: 1237295387-244c02c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8D07F1C4B68C for ; Tue, 17 Mar 2009 06:09:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id Da48w9MMAroKag11 for ; Tue, 17 Mar 2009 06:09:47 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2HD8cjV016484; Tue, 17 Mar 2009 09:08:38 -0400 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2HD8dff026454; Tue, 17 Mar 2009 09:08:39 -0400 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n2HD8clg003322; Tue, 17 Mar 2009 09:08:38 -0400 Received: from localhost (mpatocka@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n2HD8ade003316; Tue, 17 Mar 2009 09:08:36 -0400 X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs Date: Tue, 17 Mar 2009 09:08:36 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner , Christoph Hellwig cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing In-Reply-To: <1237114679-18808-2-git-send-email-david@fromorbit.com> Message-ID: References: <1237114679-18808-1-git-send-email-david@fromorbit.com> <1237114679-18808-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237295408 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.20585 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 Sun, 15 Mar 2009, Dave Chinner wrote: > From: Dave Chinner > > Currently xfs_device_flush calls sync_blockdev() which is > a no-op for XFS as all it's metadata is held in a different > address to the one sync_blockdev() works on. > > Call xfs_sync_inodes() instead to flush all the delayed > allocation blocks out. To do this as efficiently as possible, > do it via two passes - one to do an async flush of all the > dirty blocks and a second to wait for all the IO to complete. > This requires some modification to the xfs-sync_inodes_ag() > flush code to do efficiently. > > Signed-off-by: Dave Chinner > --- > fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++++------ > fs/xfs/linux-2.6/xfs_sync.c | 43 +++++++++++++++++++++++---------------- > fs/xfs/linux-2.6/xfs_sync.h | 7 +++-- > fs/xfs/xfs_iomap.c | 2 +- > fs/xfs/xfs_mount.h | 2 +- > 5 files changed, 38 insertions(+), 30 deletions(-) > > diff --git a/fs/xfs/linux-2.6/xfs_fs_subr.c b/fs/xfs/linux-2.6/xfs_fs_subr.c > index 5aeb777..08be36d 100644 > --- a/fs/xfs/linux-2.6/xfs_fs_subr.c > +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c > @@ -74,14 +74,14 @@ xfs_flush_pages( > > if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > xfs_iflags_clear(ip, XFS_ITRUNCATED); > - ret = filemap_fdatawrite(mapping); > - if (flags & XFS_B_ASYNC) > - return -ret; > - ret2 = filemap_fdatawait(mapping); > - if (!ret) > - ret = ret2; > + ret = -filemap_fdatawrite(mapping); > } > - return -ret; > + if (flags & XFS_B_ASYNC) > + return ret; > + ret2 = xfs_wait_on_pages(ip, first, last); > + if (!ret) > + ret = ret2; > + return ret; > } > > int > diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c > index a608e72..88caafc 100644 > --- a/fs/xfs/linux-2.6/xfs_sync.c > +++ b/fs/xfs/linux-2.6/xfs_sync.c > @@ -62,12 +62,6 @@ xfs_sync_inodes_ag( > uint32_t first_index = 0; > int error = 0; > int last_error = 0; > - int fflag = XFS_B_ASYNC; > - > - if (flags & SYNC_DELWRI) > - fflag = XFS_B_DELWRI; > - if (flags & SYNC_WAIT) > - fflag = 0; /* synchronous overrides all */ > > do { > struct inode *inode; > @@ -128,11 +122,23 @@ xfs_sync_inodes_ag( > * If we have to flush data or wait for I/O completion > * we need to hold the iolock. > */ > - if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) { > - xfs_ilock(ip, XFS_IOLOCK_SHARED); > - lock_flags |= XFS_IOLOCK_SHARED; > - error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE); > - if (flags & SYNC_IOWAIT) > + if (flags & SYNC_DELWRI) { > + if (VN_DIRTY(inode)) { > + if (flags & SYNC_TRYLOCK) { > + if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED)) > + lock_flags |= XFS_IOLOCK_SHARED; > + } else { > + xfs_ilock(ip, XFS_IOLOCK_SHARED); > + lock_flags |= XFS_IOLOCK_SHARED; > + } > + if (lock_flags & XFS_IOLOCK_SHARED) { > + error = xfs_flush_pages(ip, 0, -1, > + (flags & SYNC_WAIT) ? 0 > + : XFS_B_ASYNC, > + FI_NONE); > + } > + } > + if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) > xfs_ioend_wait(ip); > } > xfs_ilock(ip, XFS_ILOCK_SHARED); > @@ -400,9 +406,9 @@ xfs_syncd_queue_work( > void *data, > void (*syncer)(struct xfs_mount *, void *)) > { > - struct bhv_vfs_sync_work *work; > + struct xfs_sync_work *work; > > - work = kmem_alloc(sizeof(struct bhv_vfs_sync_work), KM_SLEEP); > + work = kmem_alloc(sizeof(struct xfs_sync_work), KM_SLEEP); > INIT_LIST_HEAD(&work->w_list); > work->w_syncer = syncer; > work->w_data = data; > @@ -445,23 +451,24 @@ xfs_flush_inode( > * (IOW, "If at first you don't succeed, use a Bigger Hammer"). > */ > STATIC void > -xfs_flush_device_work( > +xfs_flush_inodes_work( > struct xfs_mount *mp, > void *arg) > { > struct inode *inode = arg; > - sync_blockdev(mp->m_super->s_bdev); > + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK); > + xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK | SYNC_IOWAIT); > iput(inode); > } I tested the code and it works fine. But I'm not somehow convinced that that TRYLOCK is right ... that it will avoid that pagelock-deadlock that I found before. What is the ordering of pagelock, ILOCK and IOLOCK? If you keep the ordering right, you don't need trylock. And if the ordering is wrong, trylock will only lower the probability of a deadlock, not avoid it completely. Mikulas > void > -xfs_flush_device( > +xfs_flush_inodes( > xfs_inode_t *ip) > { > struct inode *inode = VFS_I(ip); > > igrab(inode); > - xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work); > + xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inodes_work); > delay(msecs_to_jiffies(500)); > xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); > } > @@ -497,7 +504,7 @@ xfssyncd( > { > struct xfs_mount *mp = arg; > long timeleft; > - bhv_vfs_sync_work_t *work, *n; > + xfs_sync_work_t *work, *n; > LIST_HEAD (tmp); > > set_freezable(); > diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h > index 04f058c..ec95e26 100644 > --- a/fs/xfs/linux-2.6/xfs_sync.h > +++ b/fs/xfs/linux-2.6/xfs_sync.h > @@ -21,18 +21,19 @@ > struct xfs_mount; > struct xfs_perag; > > -typedef struct bhv_vfs_sync_work { > +typedef struct xfs_sync_work { > struct list_head w_list; > struct xfs_mount *w_mount; > void *w_data; /* syncer routine argument */ > void (*w_syncer)(struct xfs_mount *, void *); > -} bhv_vfs_sync_work_t; > +} xfs_sync_work_t; > > #define SYNC_ATTR 0x0001 /* sync attributes */ > #define SYNC_DELWRI 0x0002 /* look at delayed writes */ > #define SYNC_WAIT 0x0004 /* wait for i/o to complete */ > #define SYNC_BDFLUSH 0x0008 /* BDFLUSH is calling -- don't block */ > #define SYNC_IOWAIT 0x0010 /* wait for all I/O to complete */ > +#define SYNC_TRYLOCK 0x0020 /* only try to lock inodes */ > > int xfs_syncd_init(struct xfs_mount *mp); > void xfs_syncd_stop(struct xfs_mount *mp); > @@ -44,7 +45,7 @@ int xfs_quiesce_data(struct xfs_mount *mp); > void xfs_quiesce_attr(struct xfs_mount *mp); > > void xfs_flush_inode(struct xfs_inode *ip); > -void xfs_flush_device(struct xfs_inode *ip); > +void xfs_flush_inodes(struct xfs_inode *ip); > > int xfs_reclaim_inode(struct xfs_inode *ip, int locked, int sync_mode); > int xfs_reclaim_inodes(struct xfs_mount *mp, int noblock, int mode); > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > index 08ce723..8b97d82 100644 > --- a/fs/xfs/xfs_iomap.c > +++ b/fs/xfs/xfs_iomap.c > @@ -361,7 +361,7 @@ xfs_flush_space( > return 0; > case 2: > xfs_iunlock(ip, XFS_ILOCK_EXCL); > - xfs_flush_device(ip); > + xfs_flush_inodes(ip); > xfs_ilock(ip, XFS_ILOCK_EXCL); > *fsynced = 3; > return 0; > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h > index 1438dd4..6df3a31 100644 > --- a/fs/xfs/xfs_mount.h > +++ b/fs/xfs/xfs_mount.h > @@ -318,7 +318,7 @@ typedef struct xfs_mount { > #endif > struct xfs_mru_cache *m_filestream; /* per-mount filestream data */ > struct task_struct *m_sync_task; /* generalised sync thread */ > - bhv_vfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ > + xfs_sync_work_t m_sync_work; /* work item for VFS_SYNC */ > struct list_head m_sync_list; /* sync thread work item list */ > spinlock_t m_sync_lock; /* work item list lock */ > int m_sync_seq; /* sync thread generation no. */ > -- > 1.6.2 > From mpatocka@redhat.com Tue Mar 17 08:21: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.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 n2HDKjU3159338 for ; Tue, 17 Mar 2009 08:21:05 -0500 X-ASG-Debug-ID: 1237296023-244402e00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FED91C4B6D2 for ; Tue, 17 Mar 2009 06:20:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id Ga1wd2PFjp1r7u6m for ; Tue, 17 Mar 2009 06:20:23 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2HDFDuv019915; Tue, 17 Mar 2009 09:15:13 -0400 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2HDFEs8031453; Tue, 17 Mar 2009 09:15:14 -0400 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n2HDFDSY004745; Tue, 17 Mar 2009 09:15:13 -0400 Received: from localhost (mpatocka@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n2HDFDDT004739; Tue, 17 Mar 2009 09:15:13 -0400 X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs Date: Tue, 17 Mar 2009 09:15:13 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Christoph Hellwig cc: Dave Chinner , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. Subject: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly. In-Reply-To: <20090316091331.GC2636@infradead.org> Message-ID: References: <1237116707-25793-1-git-send-email-david@fromorbit.com> <1237116707-25793-4-git-send-email-david@fromorbit.com> <20090316091331.GC2636@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237296024 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.20587 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, 16 Mar 2009, Christoph Hellwig wrote: > On Sun, Mar 15, 2009 at 10:31:45PM +1100, Dave Chinner wrote: > > xfs_flush_inodes() currently uses a magic timeout to wait for > > some inodes to be flushed before returning. This isn't > > really reliable but used to be the best that could be done > > due to deadlock potential of waiting for the entire flush. > > > > Now the inode flush is safe to execute while we hold page > > and inode locks, we can wait for all the inodes to flush > > synchronously. Convert the wait mechanism to a completion > > to do this efficiently. This should remove all remaining > > spurious ENOSPC errors from the delayed allocation reservation > > path. > > Why do we queue it up to a different thread if we synchronously wait > for it anyway? The good thing is that it saves a bit of stack space. ... And the bad thing of that it avoids lockdep warnings, because the lockdep engine cannot track dependence of processes via completions. (I tried to call it directly and there are none warnings, though for long-term development it would be better to allow the warnings so that deadlocks could be fixed before they hurt someone). Mikulas From felixb@sgi.com Tue Mar 17 10:48:00 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=unavailable 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 n2HFldC0166645; Tue, 17 Mar 2009 10:48:00 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id A5CC58F80B7; Tue, 17 Mar 2009 08:47:19 -0700 (PDT) Received: from eagdhcp-233-164.americas.sgi.com (eagdhcp-233-164.americas.sgi.com [128.162.233.164]) by estes.americas.sgi.com (Postfix) with ESMTP id 15E557000103; Tue, 17 Mar 2009 10:19:59 -0500 (CDT) Cc: Hisashi Hifumi , xfs-masters@oss.sgi.com, xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090317064230.GA26111@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: [PATCH] XFS: Pagecache usage optimization on XFS Date: Tue, 17 Mar 2009 10:19:58 -0500 References: <6.0.0.20.2.20090304114824.06985898@172.19.0.2> <20090316091606.GA1720@infradead.org> <6.0.0.20.2.20090317102134.06e60b30@172.19.0.2> <20090317064230.GA26111@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 Mar 17, 2009, at 1:42 AM, Christoph Hellwig wrote: > On Tue, Mar 17, 2009 at 01:03:08PM +0900, Hisashi Hifumi wrote: >> >> At 18:16 09/03/16, Christoph Hellwig wrote: >>> This looks like it should work. did you run XFSQA on a small >>> blocksize >>> filesystem with this applied? >> >> Hi. >> I did XFSQA test on XFS partition with this patch applied. >> >> arch:ia64 >> pagesize:16K >> blocksize:2K > > Thanks a lot. In that case the patch is fine with me. > > > Reviewed-by: Christoph Hellwig > > (as in reviewing the generic function to make sense with XFS :)) Make sense to me too. Reviewed-by: Felix Blyakher From ESC1102503113224_1101197854682_10034@in.constantcontact.com Tue Mar 17 11:28:40 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_FONT_SIZE_LARGE,HTML_MESSAGE 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 n2HGSJIf168536 for ; Tue, 17 Mar 2009 11:28:39 -0500 X-ASG-Debug-ID: 1237307278-3a19011b0000-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 DA86F1C4C4C0 for ; Tue, 17 Mar 2009 09:27:58 -0700 (PDT) Received: from ccm29.constantcontact.com (ccm29.constantcontact.com [208.75.123.225]) by cuda.sgi.com with ESMTP id 840331L0bpZuaHPU for ; Tue, 17 Mar 2009 09:27:58 -0700 (PDT) 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 09C3A2800108 for ; Tue, 17 Mar 2009 11:34:54 -0400 (EDT) Message-ID: <1102503113224.1101197854682.10034.5.291225FF@scheduler> Date: Tue, 17 Mar 2009 12:27:58 -0400 (EDT) From: Emergency Film Group Reply-To: info@efilmgroup.com To: xfs@oss.sgi.com X-ASG-Orig-Subj: NIMS training - Get certified Subject: NIMS training - Get certified Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16512019_1819372657.1237307278059" X-Mailer: Roving Constant Contact 0 (http://www.constantcontact.com) List-Unsubscribe: http://visitor.constantcontact.com/d.jsp?p=un&v=001LJMCW0I5jW0byL63YTets51TF4pTTIL4rabG1gjo9ps8_TujECcemFDxdva2RRNh X-Return-Path-Hint: ESC1102503113224_1101197854682_10034@in.roving.com X-Roving-ID: 1101197854682.10034 X-Lumos-SenderID: 1101197854682 X-Roving-CampaignId: 1102503113224 X-Roving-StreamId: 0 X-Barracuda-Connect: ccm29.constantcontact.com[208.75.123.225] X-Barracuda-Start-Time: 1237307278 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_16512019_1819372657.1237307278059 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The exciting way to NIMS compliance Teaches what you need to pass IS-100 certification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NIMS: Introduction to the National Incident Management System [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOy7OHUSp6N6LsrJ4I2vIF8czzGKcW2cppBaz_8yFKo_it9hXJ4WGz5iJ-NaCEk2igYsD4RUHUu1rmIvCF8hVesqhvGsjqC9nRRhutdsCThy4LgE1pYLXHjfhM18uGis4Ekr3W93f6Y4ZANYQRyWHiXpcOA6dgGDhmd66lSVn-zhWlQruLpX60YI85zOe5Mym9Irzr9SgHvGMAfvQ7nqQ38gzZRKNjcu-TnoV2-odfNKHQ==] Using footage of actual incidents and realistic training scenarios, this program shows how various responding agencies work together using standardized terminology, structure, communications and processes. Topics covered: * The structure of the Incident Command System * Expanding and contracting ICS to suit the complexity of the incident * How to establish and transfer Command * Unified Command * The roles of Command, the Command Staff and Section Leaders * Managing incident-related intelligence * The Procedures Guide includes a detailed description of the NIMS process, including the roles of all key players in ICS, checklists, job action sheets, test quizzes (no answers) for IS-100, and a copy of the script for reference. After watching this DVD, students can log on to the FEMA web site to go directly to the Final Exam for IS-100 [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOxh79C389oT7oZezMw-qRPWq6IQ07fPpYef78d37mvlZA3eHx1NOLt-Ct2nlG3dA8QxFeGIkaDPVR2RCuRKe2_5FwTyJ4cy-uAPg7Sh8Yas2A9iO5a6gv7db7l_vSKuvk2Ws8pPT392xQ==]. Upon successful completion of the test, students will be certified in NIMS awareness. Only $450 Order Here [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOy7OHUSp6N6LsrJ4I2vIF8czzGKcW2cppBaz_8yFKo_it9hXJ4WGz5iJ-NaCEk2igYsD4RUHUu1rmIvCF8hVesqhvGsjqC9nRRhutdsCThy4LgE1pYLXHjfhM18uGis4Ekr3W93f6Y4ZANYQRyWHiXpcOA6dgGDhmd66lSVn-zhWlQruLpX60YI85zOe5Mym9Irzr9SgHvGMAfvQ7nqQ38gzZRKNjcu-TnoV2-odfNKHQ==] or call (800-842-0999 ***** Questions? Call 800.842.0999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The solution for organizations that need effective NIMS training Homeland Security Presidential Directive 5 (HSPD-5) calls for development of the National Incident Management System (NIMS)...a consistent yet flexible nation-wide framework for managing all types of domestic incidents at the local, state, and federal levels of government. Emergency organizations are required to adopt NIMS in order to receive federal preparedness grants. NIMS: Introduction to the National Incident Management System [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOy7OHUSp6N6LsrJ4I2vIF8czzGKcW2cppBaz_8yFKo_it9hXJ4WGz5iJ-NaCEk2igYsD4RUHUu1rmIvCF8hVesqhvGsjqC9nRRhutdsCThy4LgE1pYLXHjfhM18uGis4Ekr3W93f6Y4ZANYQRyWHiXpcOA6dgGDhmd66lSVn-zhWlQruLpX60YI85zOe5Mym9Irzr9SgHvGMAfvQ7nqQ38gzZRKNjcu-TnoV2-odfNKHQ==]is a program designed to train personnel in law enforcement, fire departments, emergency management, and other emergency response organizations to comply with the law. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NIMS: Introduction to the National Incident Management System [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOy7OHUSp6N6LsrJ4I2vIF8czzGKcW2cppBaz_8yFKo_it9hXJ4WGz5iJ-NaCEk2igYsD4RUHUu1rmIvCF8hVesqhvGsjqC9nRRhutdsCThy4LgE1pYLXHjfhM18uGis4Ekr3W93f6Y4ZANYQRyWHiXpcOA6dgGDhmd66lSVn-zhWlQruLpX60YI85zOe5Mym9Irzr9SgHvGMAfvQ7nqQ38gzZRKNjcu-TnoV2-odfNKHQ==]includes a 27-minute DVD plus Procedures Guide which outlines the roles and responsibilities for key players in the Incident Command system. After viewing this DVD, students can log on to the FEMA web site to to go directly to the Final Exam for IS-100 [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOxh79C389oT7oZezMw-qRPWq6IQ07fPpYef78d37mvlZA3eHx1NOLt-Ct2nlG3dA8QxFeGIkaDPVR2RCuRKe2_5FwTyJ4cy-uAPg7Sh8Yas2A9iO5a6gv7db7l_vSKuvk2Ws8pPT392xQ==]. Upon successful completion of the test, students will receive a certification of competency in NIMS awareness. ORDER HERE [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOy7OHUSp6N6LsrJ4I2vIF8czzGKcW2cppBaz_8yFKo_it9hXJ4WGz5iJ-NaCEk2igYsD4RUHUu1rmIvCF8hVesqhvGsjqC9nRRhutdsCThy4LgE1pYLXHjfhM18uGis4Ekr3W93f6Y4ZANYQRyWHiXpcOA6dgGDhmd66lSVn-zhWlQruLpX60YI85zOe5Mym9Irzr9SgHvGMAfvQ7nqQ38gzZRKNjcu-TnoV2-odfNKHQ==] or call (800) 842-0999 Technical committee members who served as advisors for this program include the following authorities in NIMS training: John Buckman [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOzJGh40F1f7l_YqVJuhERgI751KQAVf_XSWc48K6MvKb28BYx98YUCQCuDNsCLqpi1AbG-k9U-q0XZ4A6f17oy0A2Ar_hdCIBCWOdgc_OjaMotaHMtc08jMmf16jeU19d7qnv4HHbPXBM2QfK1xWI8u6UbMxkft_09dLq6J8GTodLwxFW6GWTDd], former president of the International Association of Fire Chiefs; Kenneth Honig [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOzaHVDYb98HuUwBn0ADiAn3LuGRg-lgYtia9Ph_EXinKq5m24RVCs-Z_yCyflhuSgx82OVj9SvRFnQ9N3D7Rg3FJI6Uy8p6v8TucZ-1-k7TYpJ7hLjjU-Ms2IHF_bYEmDghHexr59zNxOZ7sULgkYU4Q5wgZM5Uv2X8lo-XcRk0Fg==], Senior Program Coordinator for the training/consulting firm Critical Incident Management and Training, Inc. During 9/11, Kenn served as the Emergency Operations Center Manager for the Port Authority; Zachary Goldfarb [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOzsuM8jZ8Rsw4WY5krNfFcnNw1PEHUvUuPdfcuKA4cGNcVQbeM0u1HO6szsUtsJWVqWDnit9xh_UViZM5DCCyYy0EuIsq1vogbBClkekt-OT_qf91hZ2EcuOWreHaZ_DnupJaSbRjXAxdbjciQeDDgplvh1Tn0PWpAVzr3o54kzxg==], Deputy Chief, FDNY (ret.), Principal of Incident Management Solutions, Inc. During both the 1993 bombing and the 2001 terrorist attack on the World Trade Center, he served as an EMS commander at the scene.; Kevin Neary [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOznaKFZxKQF29c4Nq1z85ThYjUoMD12Waxe6iIHt9jSmAkHPkbhO9CUikGI2cy_w5zoTr4qjozUuooXxZyL6JMxIpwD1yysZGRwIqYzRqtZ5hR1MQk44vLkNUZfgGws9ALLfXOIgQuvdMPeuOJCzaIEXTzN0-uyhpMk3d_7YxyFsw==], former Chief of Operations at New York State Emergency ManagementOffice and a veteran of many disasters including 9/11; and Greg Noll [http://rs6.net/tn.jsp?et=1102503113224&e=001xelYHXAvNOwLwQsDZvB6sOyHxZXpKnMZDtBZpQnhUxEEcZK-N5O-OCx0DdTHhBPf268Ykf3z7f_i5v6QO1JgbmcQfJpwZJPlQzfFynYB3MI7CgNJBfCo0TujesS9FpYcqJ_gI2qw6veG9EzrprG_akLRqIMktUxIFXaoLGRrALQ=], senior partner in Hildebrand Noll Associates, a consulting firm specializing in emergency planning, response and incident management issues. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email http://ui.constantcontact.com/sa/fwtf.jsp?m=1101197854682&ea=xfs@oss.sgi.com&a=1102503113224 This email was sent to xfs@oss.sgi.com by info@efilmgroup.com. Update Profile/Email Address http://visitor.constantcontact.com/d.jsp?v=001LJMCW0I5jW0byL63YTets51TF4pTTIL4rabG1gjo9ps8_TujECcemFl-aD1EbtGqcZ9YXptEVRhsnSNEbpMVxQ%3D%3D&p=oo Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/d.jsp?v=001LJMCW0I5jW0byL63YTets51TF4pTTIL4rabG1gjo9ps8_TujECcemFl-aD1EbtGqcZ9YXptEVRhsnSNEbpMVxQ%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_16512019_1819372657.1237307278059 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=09
3D"Emergency
=09
The exciting way to NIMS compliance
Teaches = what you need to pass IS-100 certification
=09
 
 
 3D"NIMS
  

Us= ing footage of actual incidents and realistic training scenarios, this prog= ram shows how various responding agencies work together using standardized = terminology, structure, communications and processes. Topics covered:<= /font>
  • The structure of the Incident Command System=20
  • Expanding and contracting ICS to suit the complexity of the incident=20
  • How to establish and transfer Command=20
  • Unified Command=20
  • The roles of Command, the Command Staff and Section Leaders=20
  • Managing incident-related intelligence=20
  • The Procedures Guide includes a detailed description of the NIMS proces= s, including the roles of all key players in ICS, checklists,&nbs= p;job action sheets, test quizzes (no answers) for IS-100, an= d a copy of the script for reference.  
    • <= /li>


 

A= fter watching this DVD, students can log on to the FEMA web site to go dire= ctly to the Final Exam for IS-100<= /a>. Upon successful completion of the test, students will be certified in = NIMS awareness. 

 

Only $450
or call (800-842-0999
  
 
 
 
*****
 
Questions?=20
Call 800.842.0999

 =09
=09=09 =09=09
The solution for organizations that need effective NIMS training
=
 
Homeland Security= Presidential Directive 5 (HSPD-5) calls for development of the National In= cident Management System (NIMS)...a consistent yet flexible nation-wide fra= mework for managing all types of domestic incidents at the local, state, an= d federal levels of government. Emergency organizations are required to ado= pt NIMS in order to receive federal preparedness grants. NIMS: Introduction to the N= ational Incident Management System is a program designed = ;to train personnel in law enforcement, fire departments, emergency ma= nagement, and other emergency response organizations to comply with the law= .  
 
=09=09 =09=09=09 =09=09 =09=09
=09=09
&n= bsp;      3D"NIMS  
NI= MS: Introduction to the National Incident Management System includes a 27-minute = DVD plus Procedures Guide which outlines the roles and responsibil= ities for key players in the Incident Command system. 
 
   = ;
3D"NIMS
  
After viewing this DVD, stud= ents can log on to the FEMA web site to to go directly to the Final Exam for IS-100. Upon successful comp= letion of the test, students will receive a certification of competency&nbs= p;in NIMS awareness.
 
ORDER HERE
or call (800) 842-0999 
 

Technical committee members who served as advisors for this program=  include the following authorities in NIMS training: John Buckman, former p= resident of the International Association of Fire Chiefs; Kenneth Honig, <= font color=3D"#4c3f36" face=3D"Arial,Helvetica,sans-serif">Senior Program C= oordinator for the training/consulting firm Critical Incident Management an= d Training, Inc. During 9/11, Kenn served as the Emergency Operations Center = Manager for the Port Authority; Zachary Goldfarb, Deputy Chief, FDNY (ret= .), Principal of Incident Management Solutions, Inc. During both the 1993 bombing a= nd the 2001 terrorist attack on the World Trade Center, he served as an EMS= commander at the scene.; Kevin Neary, former Chief of Operations at New York St= ate Emergency ManagementOffice and a veteran of many disasters including 9/= 11; and Greg No= ll, senior partner in Hildebrand Noll Associates, a consulting firm spe= cializing in emergency planning, response and incident management issues. <= br />


=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
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_16512019_1819372657.1237307278059-- From Webinars@knowledgewave.com Tue Mar 17 11:58:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,WHOIS_NETSOLPR 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 n2HGwK95169970 for ; Tue, 17 Mar 2009 11:58:40 -0500 X-ASG-Debug-ID: 1237309079-036300870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from SHAREPOINT.knowledgewave.local (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 871C91C4C7D8 for ; Tue, 17 Mar 2009 09:57:59 -0700 (PDT) Received: from SHAREPOINT.knowledgewave.local (rr-64-25-209-169.teljet.com [64.25.209.169]) by cuda.sgi.com with ESMTP id htF3rvPbm9VqHXgt for ; Tue, 17 Mar 2009 09:57:59 -0700 (PDT) Received: from SHAREPOINT ([127.0.0.1]) by SHAREPOINT.knowledgewave.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:40:20 -0400 MIME-Version: 1.0 From: Webinars@knowledgewave.com To: xfs@oss.sgi.com Date: 17 Mar 2009 12:40:20 -0400 X-ASG-Orig-Subj: Learn to Love Microsoft Vista: No Fee Webinar Subject: Learn to Love Microsoft Vista: No Fee Webinar Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Message-ID: X-OriginalArrivalTime: 17 Mar 2009 16:40:20.0191 (UTC) FILETIME=[0F74D6F0:01C9A71F] X-Barracuda-Connect: rr-64-25-209-169.teljet.com[64.25.209.169] X-Barracuda-Start-Time: 1237309079 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.85 X-Barracuda-Spam-Status: No, SCORE=0.85 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, MIME_HTML_ONLY, NO_REAL_NAME, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20601 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 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 DQo8aHRtbCB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8y MDA0LzEyL29tbWwiIHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4 bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiPg0KDQo8 aGVhZD4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQouc3R5bGUxIHsNCglmb250LXNpemU6 IHgtc21hbGw7DQoJZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 DQp9DQouc3R5bGUzIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCi5zdHlsZTQgew0K CWZvbnQtc2l6ZTogeC1zbWFsbDsNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQoNCjx0aXRsZT5X ZWJpbmFyOiBObyBGZWUgRXZlbnQ6IE91dGxvb2sgMjAwNyBOZXcgRmVhdHVyZXM8L3RpdGxl Pg0KDQo8c3BhbiBjbGFzcz0ic3R5bGUzIj48c3BhbiBjbGFzcz0ic3R5bGU0Ij5EYXZpZA0K DQo8YnI+DQo8YnI+DQpKb2luIHVzIGF0IG5vIGNoYXJnZSENCkJhc2VkIG9uIGEgdHJlbWVu ZG91cyByZXNwb25zZSBLbm93bGVkZ2VXYXZlIGlzIGhvc3RpbmcgYW5vdGhlciBubyBmZWUg d2ViaW5hciB0aXRsZWQgDQo8c3Ryb25nPlRpcHMgYW5kIFRyaWNrcyBmb3IgV2luZG93cyBW aXN0YTwvc3Ryb25nPi4gPGJyPg0KPGJyPg0KPHN0cm9uZz48ZW0+PHNwYW4gY2xhc3M9InN0 eWxlNCI+V2hhdCB3aWxsIHlvdSBsZWFybj88L3NwYW4+PC9lbT48L3N0cm9uZz48c3BhbiBj bGFzcz0ic3R5bGU0Ij48YnI+DQpFeHBsb3JlIHRoZSBwb3dlcmZ1bCBuZXcgZmVhdHVyZXMg aW4gdGhlIFdpbmRvd3MgVmlzdGEgb3BlcmF0aW5nIHN5c3RlbSwgaW5jbHVkaW5nLCB0aGUg bmV3IHVzZXIgaW50ZXJmYWNlLCBzZWFyY2gsIGFuZCBvcmdhbml6YXRpb25hbCB0b29scy4g V2UgYWxzbyBwcm92aWRlIHVzZWZ1bCB0aXBzIG9uIHVzaW5nIFdpbmRvd3MgSW50ZXJuZXQg RXhwbG9yZXIgNyBhbmQgaWxsdXN0cmF0ZSBwcmFjdGljYWwgZGVza3RvcCB0ZWNobmlxdWVz IHRoYXQgaGVscCB5b3UgdG8gYmUgbW9yZSBwcm9kdWN0aXZlIHJpZ2h0IGF3YXkuIEpvaW4g dXMgZm9yIHRoaXMgaW5mb3JtYXRpdmUgc2Vzc2lvbiB0byBzZWUgaG93IFdpbmRvd3MgVmlz dGEgcmVwcmVzZW50cyBhIGJyZWFrdGhyb3VnaCBpbiB1c2VyIGV4cGVyaWVuY2UuPGJyPg0K PGJyPg0KDQpLbm93bGVkZ2VXYXZlIHByb3ZpZGVzIG92ZXIgODArIHdlYmluYXIgdGl0bGVz IGluIGJvdGggb3BlbiBlbnJvbGxtZW50IGFuZCBjbG9zZWQgY29ycG9yYXRlIGZvcm1hdC4g VGhpcyBldmVudCBpcyBvcGVuIHRvIHRoZSBnZW5lcmFsIHB1YmxpYyBhbmQgdGhlcmUgaXMg DQo8c3Ryb25nPm5vIGZlZTwvc3Ryb25nPi4gRW5yb2xsIHRvZGF5IGFuZCBsZWFybiBmcm9t IHRoZSBleHBlcnRzLjxicj4NCjxicj4NCjwvc3Bhbj4NCjxzdHJvbmc+PHNwYW4gY2xhc3M9 InN0eWxlNCI+UHJvZHVjdChzKTogTWljcm9zb2Z0IFdpbmRvd3MgVmlzdGEuICBBdWRpZW5j ZShzKTogQnVzaW5lc3MgUHJvZmVzc2lvbmFsLiBEdXJhdGlvbjogNjAgTWludXRlcywgU3Rh cnQgRGF0ZToNCjxzcGFuIGNsYXNzPSJ0ZXh0Ij48c3BhbiBjbGFzcz0ic3R5bGU5Ij5NYXJj aCAyMCwgMTA6MDBBTSBFU1Q8L3NwYW4+PC9zcGFuPi48L3NwYW4+PC9zdHJvbmc+PHNwYW4g Y2xhc3M9InN0eWxlNCI+PGJyPg0KPC9zcGFuPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmdv dG9tZWV0aW5nLmNvbS9yZWdpc3Rlci81MzIwNDk3ODYiPjxzcGFuIGNsYXNzPSJzdHlsZTQi PlJlZ2lzdGVyIFRvZGF5PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ic3R5bGU0Ij46IENsaWNr IHRoZSBsaW5rLg0KPGJyPg0KPGJyPg0KPC9zcGFuPg0KV2ViaW5hcnMgYXJlDQo8L3NwYW4+ IDxzdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+ZmFzdDwvc3Bhbj48L3N0cm9uZz48c3Bh biBjbGFzcz0ic3R5bGU0Ij4sIA0KPC9zcGFuPiA8c3Ryb25nPjxzcGFuIGNsYXNzPSJzdHls ZTQiPmNvbnZlbmllbnQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+IGFu ZCANCjwvc3Bhbj4gPHN0cm9uZz4NCjxzcGFuIGNsYXNzPSJzdHlsZTQiPmFmZm9yZGFibGU8 L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+LiBUaGVyZSBpcyBubyB3YXN0 ZWQgdGltZS4gR2V0IHJpZ2h0IHRvIHRoZSBvYmplY3RpdmUgb2YgdGhlIA0KMS1ob3VyIHNl c3Npb24uIFdlYmluYXJzIGFyZSBkZXNpZ25lZCB0byBmaXQgZWFzaWx5IGludG8geW91ciBi dXN5IHNjaGVkdWxlLiBZb3UgDQpoYXZlIG5vIHRyYXZlbCBhbmQgbm8gdGltZSBvdXQgb2Yg dGhlIG9mZmljZSEgT3VyIHdlYmluYXJzIGFyZSBmcmVlIG9yIHByaWNlZCBhdCANCmxlc3Mg dGhhbiAkOTAhIFRoYXQmIzM5O3MgYSBmcmFjdGlvbiBvZiB0aGUgY29zdCBvZiB0cmF2ZWwg YW5kIGF0dGVuZGFuY2UgZmVlcyBmb3IgDQpvdGhlciBoaWdoLXByaWNlZCBjbGFzc2VzLCBj b25mZXJlbmNlcywgc2VtaW5hcnMgb3Igb3RoZXIgb25saW5lIHdlYmluYXJzLiZuYnNwOw0K PGJyPg0KPGJyPg0KPC9zcGFuPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmdvdG9tZWV0aW5n LmNvbS9yZWdpc3Rlci81MzIwNDk3ODYiPjxzcGFuIGNsYXNzPSJzdHlsZTQiPlJlZ2lzdGVy IFRvZGF5PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ic3R5bGU0Ij46IENsaWNrIHRoZSBsaW5r Lg0KPGJyPg0KPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyB3ZWJpbmFyIGFu ZCBvdXIgb3RoZXIgd2ViaW5hciBldmVudHMsIHBsZWFzZSBnbyB0byBvdXIgd2Vic2l0ZToN Cjwvc3Bhbj4gDQo8YSBocmVmPSJodHRwOi8vd3d3Lmtub3dsZWRnZXdhdmUuY29tL3dlYmlu YXJzLnBocCI+PHNwYW4gY2xhc3M9InN0eWxlNCI+aHR0cDovL3d3dy5rbm93bGVkZ2V3YXZl LmNvbS93ZWJpbmFycy5waHA8L3NwYW4+PC9hPjwvc3Bhbj4NCjxzcGFuIGNsYXNzPSJzdHls ZTMiPjxzcGFuIGNsYXNzPSJzdHlsZTQiPjxicj4NCjxicj4NClRoYW5rcywgYW5kIGhhdmUg YSBncmVhdCBkYXkuDQoNCjxicj4NCjxicj4NCjwvc3Bhbj4NCjxzdHJvbmc+PHNwYW4gY2xh c3M9InN0eWxlNCI+S25vd2xlZGdlV2F2ZSBXZWJpbmFyIFN0YWZmIDwvc3Bhbj4NCg0KIA0K DQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCjwv c3Ryb25nPjxicj4NCjxicj4NCjxpbWcgYWx0PSJLbm93bGVkZ2VXYXZlIFdlYmluYXJzIiBz cmM9Imh0dHA6Ly93d3cua25vd2xlZGdld2F2ZS5jb20vaW1hZ2VzL2xvZ28tY29sb3Itd2Vi LmpwZyIgd2lkdGg9IjI2MCIgaGVpZ2h0PSI1MSI+PGJyPg0KPGJyPg0KPGltZyBhbHQ9Ik1p Y3Jvc29mdCBHb2xkIFBhcnRuZXIiIHNyYz0iaHR0cDovL3d3dy5rbm93bGVkZ2V3YXZlLmNv bS9pbWFnZXMvbWljcm9zb2Z0R29sZENlcnRpZmllZC5naWYiIHdpZHRoPSIyNjMiIGhlaWdo dD0iNTIiPjxicj4NCjxicj4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzp3ZWJpbmFyc0Brbm93 bGVkZ2V3YXZlLmNvbSI+d2ViaW5hcnNAa25vd2xlZGdld2F2ZS5jb208L2E+PC9zcGFuPg0K PHNwYW4gY2xhc3M9InN0eWxlMyI+PGJyPg0KS25vd2xlZGdld2F2ZSBpcyBWZXJtb250J3Mg b25seSBDZXJ0aWZpZWQgTWljcm9zb2Z0IEdvbGQgUGFydG5lciBmb3IgTGVhcm5pbmcgU29s dXRpb25zLg0KIDxicj4NCsKpIDIwMDggS25vd2xlZGdlV2F2ZS4gDQo8YnI+DQozMCBDb21t dW5pdHkgRHJpdmUsIFN0ZSA1LCBTb3V0aCBCdXJsaW5ndG9uLCBWVCAwNTQwMyANCjxicj4N CkNhbGw6IDEtODAwLTgzMS04NDQ5DQogDQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gY2xh c3M9InN0eWxlMSI+VGhlIGVtYWlsIHdhcyBzZW50IHRvIHhmc0Bvc3Muc2dpLmNvbS4gSWYg eW91IHByZWZlciBub3QgdG8gcmVjZWl2ZSB0aGVzZSBlbWFpbHMsIHBsZWFzZSByZXBseSB0 byB0aGlzIG1lc3NhZ2Ugd2l0aCBSRU1PVkUgaW4gdGhlIHN1YmplY3QgbGluZSBhbmQgd2Ug d2lsbCByZW1vdmUgeW91ciBlbWFpbCBhZGRyZXNzIGZyb20gZnV0dXJlIEtub3dsZWRnZVdh dmUgZGlzdHJpYnV0aW9ucy4NCjwvc3Bhbj4= From Steffen.Knauf@liga01.de Tue Mar 17 12:26: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=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 n2HHQGng171391 for ; Tue, 17 Mar 2009 12:26:38 -0500 X-ASG-Debug-ID: 1237310755-310d004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p00-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7BE251C4CA23 for ; Tue, 17 Mar 2009 10:25:55 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by cuda.sgi.com with ESMTP id Bcs5t66aNNXfzoVX for ; Tue, 17 Mar 2009 10:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237310755; l=454; s=domk; d=liga01.de; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version: Reply-To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=yUfqBKz99F+3DR1+iZRk9pWC5CoF+eS3bGBhSX41XBw=; b=uB1uepaq1hg6tJpLYQhO07J8zMLSMNGpRXxMZxJ5PzNYils0oDCuQgvdgaG38AQhS0t RzxWBWaXyh9Kc1digkJVXJyTaamsgLGHQmCxB2RG8sYwii7Z47DF7qCG8LLOh2LTSVGyI R9pGBm7uEA7IS4yeV67Pk6dImwuCPKFKnt4= X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (fruni mo7) (RZmta 18.26) with ESMTP id 6032cdl2HHD5KL for ; Tue, 17 Mar 2009 18:24:03 +0100 (MET) Message-ID: <49BFDC6E.6050607@liga01.de> Date: Tue, 17 Mar 2009 18:22:54 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Lost files + indentical Foldernames on XFS Partition Subject: Lost files + indentical Foldernames on XFS Partition Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p00-ob.rzone.de[81.169.146.161] X-Barracuda-Start-Time: 1237310756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 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=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20602 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello, today i have a strange behavior. I have a a directory which contains lots of indentical Folders with the same Name and Inode. I don't create Hardlinks or something else. On the other side some files are suddenly vanished. A "ls -al" result in the following error: "Access to bla not possible: File or Directory not found." I don't find some Errormessages in the logfile. I don't know whether a xfs_check make sense. greets Steffen From Steffen.Knauf@renderforce.de Tue Mar 17 12:29: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 n2HHT0nq171581 for ; Tue, 17 Mar 2009 12:29:19 -0500 X-ASG-Debug-ID: 1237310918-64f003c30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p05-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF72A1A33DB for ; Tue, 17 Mar 2009 10:28:39 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by cuda.sgi.com with ESMTP id BjSHOU5RR2CgUgGd for ; Tue, 17 Mar 2009 10:28:39 -0700 (PDT) X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo05 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (fruni mo42) (RZmta 18.26) with ESMTP id J022b4l2HHLxaK for ; Tue, 17 Mar 2009 18:28:37 +0100 (MET) Message-ID: <49BFDD80.1060401@renderforce.de> Date: Tue, 17 Mar 2009 18:27:28 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Lost files + indentical Foldernames on XFS Partition Subject: Lost files + indentical Foldernames on XFS Partition Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p05-ob.rzone.de[81.169.146.181] X-Barracuda-Start-Time: 1237310919 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4983 1.0000 0.0000 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=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20602 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello, today i have a strange behavior. I have a a directory which contains lots of indentical Folders with the same Name and Inode. I don't create Hardlinks or something else. On the other side some files are suddenly vanished. A "ls -al" result in the following error: "Access to bla not possible: File or Directory not found." I don't find some Errormessages in the logfile. I don't know whether a xfs_check make sense. greets Steffen From sandeen@sandeen.net Tue Mar 17 12:29: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2HHT658171583 for ; Tue, 17 Mar 2009 12:29:26 -0500 X-ASG-Debug-ID: 1237310925-50ac01230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AA2F81A33E2 for ; Tue, 17 Mar 2009 10:28:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id dWcyJaRvEVqv9GIA for ; Tue, 17 Mar 2009 10:28:45 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2HHSd4r020901; Tue, 17 Mar 2009 13:28:40 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2HHSdCB030518; Tue, 17 Mar 2009 13:28:40 -0400 Message-ID: <49BFDDC5.9060500@sandeen.net> Date: Tue, 17 Mar 2009 12:28:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Steffen.Knauf@liga01.de CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> In-Reply-To: <49BFDC6E.6050607@liga01.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237310925 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0205 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20602 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Steffen Knauf wrote: > Hello, > > today i have a strange behavior. I have a a directory which contains > lots of indentical Folders with the same Name and Inode. What kernel? Can you cut and paste what you see? > I don't create Hardlinks or something else. On the other side some files > are suddenly vanished. A "ls -al" result in the following error: > "Access to bla not possible: File or Directory not found." > I don't find some Errormessages in the logfile. I don't know whether a > xfs_check make sense. xfs_repair -n will check the filesystem without actually modifying anything. -Eric From johannes@sipsolutions.net Tue Mar 17 16:27: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=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 n2HLRY9O183650 for ; Tue, 17 Mar 2009 16:27:55 -0500 X-ASG-Debug-ID: 1237325212-24ae01b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sipsolutions.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 49CCF1A4539; Tue, 17 Mar 2009 14:26:52 -0700 (PDT) Received: from sipsolutions.net (xc.sipsolutions.net [83.246.72.84]) by cuda.sgi.com with ESMTP id ahOgTeyMN2KGwQng; Tue, 17 Mar 2009 14:26:52 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LjgnE-0003kV-D9; Tue, 17 Mar 2009 22:25:48 +0100 X-ASG-Orig-Subj: lockdep report with 2.6.29-rc8-wl-18593-gef1cb6f-dirty Subject: lockdep report with 2.6.29-rc8-wl-18593-gef1cb6f-dirty From: Johannes Berg To: xfs-masters@oss.sgi.com Cc: xfs@oss.sgi.com, Christoph Hellwig Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-59nMbdlnTLjLok6jFJY5" Date: Tue, 17 Mar 2009 19:45:20 +0100 Message-Id: <1237315521.31814.17.camel@johannes.local> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 X-Barracuda-Connect: xc.sipsolutions.net[83.246.72.84] X-Barracuda-Start-Time: 1237325234 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: -0.82 X-Barracuda-Spam-Status: No, SCORE=-0.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_RULE_7582B, PR0N_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20618 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 0.20 PR0N_SUBJECT Subject has letters around special characters (pr0n) 0.50 BSF_RULE_7582B Custom Rule 7582B X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --=-59nMbdlnTLjLok6jFJY5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (ignore the -wl-... stuff, it's a wireless tree, but everything but wireless is plain -rc8) This happened about 20 minutes into a long rsync session where I was writing a lot of data to the XFS filesystem: [ 2182.810987] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ 2182.811372] [ INFO: possible circular locking dependency detected ] [ 2182.811669] 2.6.29-rc8-wl-18593-gef1cb6f-dirty #30 [ 2182.811894] ------------------------------------------------------- [ 2182.812189] rsync/4528 is trying to acquire lock: [ 2182.812408] (iprune_mutex){--..}, at: [] .prune_icach= e+0x58/0x2c4 [ 2182.812802]=20 [ 2182.812803] but task is already holding lock: [ 2182.813073] (&(&ip->i_iolock)->mr_lock){----}, at: []= .xfs_ilock+0x30/0x9c [ 2182.813499]=20 [ 2182.813501] which lock already depends on the new lock. [ 2182.813503]=20 [ 2182.813876]=20 [ 2182.813877] the existing dependency chain (in reverse order) is: [ 2182.814223]=20 [ 2182.814225] -> #1 (&(&ip->i_iolock)->mr_lock){----}: [ 2182.814544] [] .validate_chain+0x740/0x928 [ 2182.814846] [] .__lock_acquire+0x828/0x908 [ 2182.815148] [] .lock_acquire+0xa4/0xec [ 2182.815433] [] .down_write_nested+0x70/0x110 [ 2182.815744] [] .xfs_ilock+0x30/0x9c [ 2182.816016] [] .xfs_ireclaim+0xc0/0x1f0 [ 2182.828398] [] .xfs_reclaim_inode+0x16c/0x198 [ 2182.840760] [] .xfs_reclaim+0xc0/0xf0 [ 2182.853054] [] .xfs_fs_destroy_inode+0x4c/0x84 [ 2182.865273] [] .destroy_inode+0x58/0x8c [ 2182.877335] [] .dispose_list+0x108/0x17c [ 2182.889251] [] .prune_icache+0x288/0x2c4 [ 2182.901023] [] .shrink_icache_memory+0x2c/0x64 [ 2182.912715] [] .shrink_slab+0x168/0x27c [ 2182.924301] [] .balance_pgdat+0x3f8/0x614 [ 2182.935746] [] .kswapd+0x154/0x158 [ 2182.947235] [] .kthread+0x78/0xc4 [ 2182.958620] [] .kernel_thread+0x54/0x70 [ 2182.969955]=20 [ 2182.969956] -> #0 (iprune_mutex){--..}: [ 2182.992430] [] .__lock_acquire+0x828/0x908 [ 2183.003723] [] .lock_acquire+0xa4/0xec [ 2183.014986] [] .mutex_lock_nested+0x194/0x4c8 [ 2183.026210] [] .prune_icache+0x58/0x2c4 [ 2183.037321] [] .shrink_icache_memory+0x2c/0x64 [ 2183.048365] [] .shrink_slab+0x168/0x27c [ 2183.059271] [] .do_try_to_free_pages+0x2bc/0x43= 8 [ 2183.070142] [] .try_to_free_pages+0xa0/0xcc [ 2183.080867] [] .__alloc_pages_internal+0x32c/0x= 55c [ 2183.091593] [] .grab_cache_page_write_begin+0x8= 0/0xf0 [ 2183.102345] [] .block_write_begin+0x60/0x13c [ 2183.113136] [] .xfs_vm_write_begin+0x24/0x3c [ 2183.123933] [] .generic_perform_write+0x100/0x2= 94 [ 2183.134731] [] .generic_file_buffered_write+0x8= 8/0x15c [ 2183.145447] [] .xfs_write+0x4ac/0x70c [ 2183.156132] [] .xfs_file_aio_write+0x78/0x8c [ 2183.166837] [] .do_sync_write+0xcc/0x130 [ 2183.177399] [] .vfs_write+0xd0/0x1bc [ 2183.188041] [] .SyS_write+0x58/0xa0 [ 2183.198645] [] syscall_exit+0x0/0x40 [ 2183.209296]=20 [ 2183.209297] other info that might help us debug this: [ 2183.209299]=20 [ 2183.240399] 3 locks held by rsync/4528: [ 2183.250633] #0: (&sb->s_type->i_mutex_key#5){--..}, at: [] .xfs_write+0x1c8/0x70c [ 2183.261377] #1: (&(&ip->i_iolock)->mr_lock){----}, at: [] .xfs_ilock+0x30/0x9c [ 2183.272194] #2: (shrinker_rwsem){----}, at: [] .shri= nk_slab+0x60/0x27c [ 2183.283115]=20 [ 2183.283116] stack backtrace: [ 2183.304318] Call Trace: [ 2183.314712] [c0000001b096ab60] [c00000000000fef8] .show_stack+0x6c/0x174= (unreliable) [ 2183.325448] [c0000001b096ac10] [c000000000089528] .print_circular_bug_ta= il+0xd8/0xfc [ 2183.336117] [c0000001b096ace0] [c00000000008a7c0] .validate_chain+0x740/= 0x928 [ 2183.346633] [c0000001b096ada0] [c00000000008b1d0] .__lock_acquire+0x828/= 0x908 [ 2183.356978] [c0000001b096aea0] [c00000000008b354] .lock_acquire+0xa4/0xe= c [ 2183.367329] [c0000001b096af60] [c000000000428ce8] .mutex_lock_nested+0x1= 94/0x4c8 [ 2183.377555] [c0000001b096b070] [c000000000124160] .prune_icache+0x58/0x2= c4 [ 2183.387589] [c0000001b096b130] [c0000000001243f8] .shrink_icache_memory+= 0x2c/0x64 [ 2183.397649] [c0000001b096b1b0] [c0000000000de4f8] .shrink_slab+0x168/0x2= 7c [ 2183.407654] [c0000001b096b280] [c0000000000df37c] .do_try_to_free_pages+= 0x2bc/0x438 [ 2183.417842] [c0000001b096b380] [c0000000000df598] .try_to_free_pages+0xa= 0/0xcc [ 2183.427975] [c0000001b096b470] [c0000000000d60f4] .__alloc_pages_interna= l+0x32c/0x55c [ 2183.438101] [c0000001b096b5a0] [c0000000000ce8c8] .grab_cache_page_write= _begin+0x80/0xf0 [ 2183.448275] [c0000001b096b650] [c000000000139798] .block_write_begin+0x6= 0/0x13c [ 2183.458381] [c0000001b096b710] [c000000000223eb8] .xfs_vm_write_begin+0x= 24/0x3c [ 2183.468545] [c0000001b096b790] [c0000000000cd3f8] .generic_perform_write= +0x100/0x294 [ 2183.478770] [c0000001b096b8a0] [c0000000000cfb88] .generic_file_buffered= _write+0x88/0x15c [ 2183.489036] [c0000001b096b980] [c00000000022c0d0] .xfs_write+0x4ac/0x70c [ 2183.499291] [c0000001b096bad0] [c000000000227c30] .xfs_file_aio_write+0x= 78/0x8c [ 2183.509609] [c0000001b096bb40] [c00000000010a8b4] .do_sync_write+0xcc/0x= 130 [ 2183.519935] [c0000001b096bce0] [c00000000010b4c0] .vfs_write+0xd0/0x1bc --=-59nMbdlnTLjLok6jFJY5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Comment: Johannes Berg (powerbook) iQIcBAABAgAGBQJJv+++AAoJEKVg1VMiehFYxIAP/Ay6Rfkfqo9fdoEOO8dlXdzI J02xVr/YDHrPUPONH8872W4whgxVSlxYoZuOdzPGw723bw21lU8cDc3fDjHojClX bXGEYBmGBJMP78koZuT2TzrV1eEXtVOU1i1Vb2ekk2cHvzJlg2OuvI5LcIvLOA6C PNc1gCOzCEq9M0iMtltpYYBzCmpCbxWpB7WVEIDefqzfEGxDIy/IlpMgiR4nsBXX yh3cXr7/Xm78/leCEyOEvkSpFAakkdUHttT7hLU0sTRNCr5El+37j6TtzeWuJfF6 Lpbm32wBwXsEmH9xMY3RE7GJN1eaAf9QHNQWHJmp4snICmEWcRwsaSGFNoSZqGXO YEMojOJ9McoFHrVoeoZhrNeDuwTQVfZj+nixDhRXEMG+YEVHO3cisCcmP2gZeQVo SOiOnssIWBo5zPKwlBp18uR84dGf9Sr+1IUnl4yl/5RXPyAt5pHnn4bkUgGE4Q85 1giGspYGiv9xlhwDR2CcVI1QbKwRL2eeoQsGlYxPAVrFS4rKszjgrazXdX5AhwOe I5wwCSmOf04cHN8HniOLOujIyM2fPZtprruPAwP1Qd6Sq+nqllBLeoE3qcNu/m8d G5nAM5qspnqn1P93j4jnUjynbGuVotlvvyf8cBINKz3qkZHxn2CVIGMbnwrl3A1u BoXR6Wdf4maT2ixtZ4RW =Nhvg -----END PGP SIGNATURE----- --=-59nMbdlnTLjLok6jFJY5-- From Steffen.Knauf@liga01.de Tue Mar 17 17:54:44 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 n2HMsN7G187396 for ; Tue, 17 Mar 2009 17:54:44 -0500 X-ASG-Debug-ID: 1237330421-128b01af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p00-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 933A41C4DED8 for ; Tue, 17 Mar 2009 15:53:42 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by cuda.sgi.com with ESMTP id crG1BKgvzZZ1eg3Y for ; Tue, 17 Mar 2009 15:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237330421; l=1373; s=domk; d=liga01.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:Reply-To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=Wv+xrEOuWL6SWerjJFTKTz3a/9+A4wtICKR7/qMbhss=; b=Zc4G5pkuVgzjXO/YDSOJq2MvOx1XZQD4FfXHm+bM67dVJFasXt+uajNPylHSziDug8/ /IBH2g+f10KHKrtrAmbh8kvoBfTN5CvH4RJjr6xZ4/uVzU8w+bij9E+7D32ZXmkNYtY3Z xoYzcJTHR8acN/acIwfbEpLN8q+8kG/IA4o= X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (klopstock mo34) (RZmta 18.27) with ESMTP id j03727l2HKNcYs ; Tue, 17 Mar 2009 23:53:40 +0100 (MET) Message-ID: <49C029AF.5070205@liga01.de> Date: Tue, 17 Mar 2009 23:52:31 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de 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: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> In-Reply-To: <49BFDDC5.9060500@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p00-ob.rzone.de[81.169.146.162] X-Barracuda-Start-Time: 1237330443 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4313 1.0000 0.0000 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=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > Steffen Knauf wrote: > >> Hello, >> >> today i have a strange behavior. I have a a directory which contains >> lots of indentical Folders with the same Name and Inode. >> > > What kernel? > > Linux version 2.6.16.60-0.21-smp (geeko@buildhost) (gcc version 4.1.2 20070115 (SUSE Linux)) > Can you cut and paste what you see? > > Really strange is that if execute only a 'ls' command the files are shown twice: combine_sbn.0051.tga combine_sbn.0051.tga But if i execute 'ls -il' the output looks like this: combine_sbn.0051.tga: Datei oder Verzeichnis nicht gefunden combine_sbn.0057.tga: Datei oder Verzeichnis nicht gefunden combine_sbn.0058.tga: Datei oder Verzeichnis nicht gefunden Here a directory example: 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33 S14-01_Fische_beauty_Main 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33 S14-01_Fische_beauty_Main >> I don't create Hardlinks or something else. On the other side some files >> are suddenly vanished. A "ls -al" result in the following error: >> "Access to bla not possible: File or Directory not found." >> I don't find some Errormessages in the logfile. I don't know whether a >> xfs_check make sense. >> > > xfs_repair -n will check the filesystem without actually modifying anything. > > I'll try it.... > -Eric > > Steffen * * From sandeen@sandeen.net Tue Mar 17 21:13: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=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 n2I2D89u197144 for ; Tue, 17 Mar 2009 21:13:29 -0500 X-ASG-Debug-ID: 1237342346-0e2200e50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ADC751C4DF91 for ; Tue, 17 Mar 2009 19:12:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id gVsuCNUdq7EJx2y1 for ; Tue, 17 Mar 2009 19:12:26 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2I2CO4t006118; Tue, 17 Mar 2009 22:12:24 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2I2CPJH002591; Tue, 17 Mar 2009 22:12:25 -0400 Message-ID: <49C05887.10207@sandeen.net> Date: Tue, 17 Mar 2009 21:12:23 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Steffen.Knauf@liga01.de CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> In-Reply-To: <49C029AF.5070205@liga01.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237342368 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.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20636 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Steffen Knauf wrote: >> Steffen Knauf wrote: >> >>> Hello, >>> >>> today i have a strange behavior. I have a a directory which contains >>> lots of indentical Folders with the same Name and Inode. >>> >> What kernel? > > Linux version 2.6.16.60-0.21-smp (geeko@buildhost) (gcc version 4.1.2 > 20070115 (SUSE Linux)) Would probably be good to try an upstream kernel to see if it persists, if you can; otherwise for an older distro kernel like this, a report to SuSE would be in order. >> Can you cut and paste what you see? > > Really strange is that if execute only a 'ls' command the files are > shown twice: > > combine_sbn.0051.tga > combine_sbn.0051.tga > > But if i execute 'ls -il' the output looks like this: > > combine_sbn.0051.tga: Datei oder Verzeichnis nicht gefunden > combine_sbn.0057.tga: Datei oder Verzeichnis nicht gefunden > combine_sbn.0058.tga: Datei oder Verzeichnis nicht gefunden so the filename is in the directory but doesn't point to a valid file I guess. > Here a directory example: > > 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33 > S14-01_Fische_beauty_Main > 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33 > S14-01_Fische_beauty_Main > >>> I don't create Hardlinks or something else. On the other side some files >>> are suddenly vanished. A "ls -al" result in the following error: >>> "Access to bla not possible: File or Directory not found." >>> I don't find some Errormessages in the logfile. I don't know whether a >>> xfs_check make sense. >>> >> xfs_repair -n will check the filesystem without actually modifying anything. >> > I'll try it.... You could also create an xfs_metadump to save for later investigation. -Eric >> -Eric >> > Steffen From webinars@knowledgewave.com Tue Mar 17 22:55:25 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,WHOIS_NETSOLPR 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 n2I3t41O202323 for ; Tue, 17 Mar 2009 22:55:25 -0500 X-ASG-Debug-ID: 1237348483-1c80031e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from SHAREPOINT.knowledgewave.local (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1496E1A5661 for ; Tue, 17 Mar 2009 20:54:43 -0700 (PDT) Received: from SHAREPOINT.knowledgewave.local (rr-64-25-209-169.teljet.com [64.25.209.169]) by cuda.sgi.com with ESMTP id av1xfPByLktqMmrW for ; Tue, 17 Mar 2009 20:54:43 -0700 (PDT) Received: from SHAREPOINT ([127.0.0.1]) by SHAREPOINT.knowledgewave.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 23:54:43 -0400 MIME-Version: 1.0 From: webinars@knowledgewave.com To: xfs@oss.sgi.com Date: 17 Mar 2009 23:54:43 -0400 X-ASG-Orig-Subj: Learn to Love Microsoft Vista: No Fee Webinar Subject: Learn to Love Microsoft Vista: No Fee Webinar Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Message-ID: X-OriginalArrivalTime: 18 Mar 2009 03:54:43.0314 (UTC) FILETIME=[455B6D20:01C9A77D] X-Barracuda-Connect: rr-64-25-209-169.teljet.com[64.25.209.169] X-Barracuda-Start-Time: 1237348484 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.85 X-Barracuda-Spam-Status: No, SCORE=0.85 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, MIME_HTML_ONLY, NO_REAL_NAME, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20644 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 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 DQo8aHRtbCB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8y MDA0LzEyL29tbWwiIHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4 bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiPg0KDQo8 aGVhZD4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQouc3R5bGUxIHsNCglmb250LXNpemU6 IHgtc21hbGw7DQoJZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 DQp9DQouc3R5bGUzIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCi5zdHlsZTQgew0K CWZvbnQtc2l6ZTogeC1zbWFsbDsNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQoNCjx0aXRsZT5X ZWJpbmFyOiBObyBGZWUgRXZlbnQ6IE91dGxvb2sgMjAwNyBOZXcgRmVhdHVyZXM8L3RpdGxl Pg0KDQo8c3BhbiBjbGFzcz0ic3R5bGUzIj48c3BhbiBjbGFzcz0ic3R5bGU0Ij5EYXZpZA0K DQo8YnI+DQo8YnI+DQpKb2luIHVzIGF0IG5vIGNoYXJnZSENCkJhc2VkIG9uIGEgdHJlbWVu ZG91cyByZXNwb25zZSBLbm93bGVkZ2VXYXZlIGlzIGhvc3RpbmcgYW5vdGhlciBubyBmZWUg d2ViaW5hciB0aXRsZWQgDQo8c3Ryb25nPlRpcHMgYW5kIFRyaWNrcyBmb3IgV2luZG93cyBW aXN0YTwvc3Ryb25nPi4gPGJyPg0KPGJyPg0KPHN0cm9uZz48ZW0+PHNwYW4gY2xhc3M9InN0 eWxlNCI+V2hhdCB3aWxsIHlvdSBsZWFybj88L3NwYW4+PC9lbT48L3N0cm9uZz48c3BhbiBj bGFzcz0ic3R5bGU0Ij48YnI+DQpFeHBsb3JlIHRoZSBwb3dlcmZ1bCBuZXcgZmVhdHVyZXMg aW4gdGhlIFdpbmRvd3MgVmlzdGEgb3BlcmF0aW5nIHN5c3RlbSwgaW5jbHVkaW5nLCB0aGUg bmV3IHVzZXIgaW50ZXJmYWNlLCBzZWFyY2gsIGFuZCBvcmdhbml6YXRpb25hbCB0b29scy4g V2UgYWxzbyBwcm92aWRlIHVzZWZ1bCB0aXBzIG9uIHVzaW5nIFdpbmRvd3MgSW50ZXJuZXQg RXhwbG9yZXIgNyBhbmQgaWxsdXN0cmF0ZSBwcmFjdGljYWwgZGVza3RvcCB0ZWNobmlxdWVz IHRoYXQgaGVscCB5b3UgdG8gYmUgbW9yZSBwcm9kdWN0aXZlIHJpZ2h0IGF3YXkuIEpvaW4g dXMgZm9yIHRoaXMgaW5mb3JtYXRpdmUgc2Vzc2lvbiB0byBzZWUgaG93IFdpbmRvd3MgVmlz dGEgcmVwcmVzZW50cyBhIGJyZWFrdGhyb3VnaCBpbiB1c2VyIGV4cGVyaWVuY2UuPGJyPg0K PGJyPg0KDQpLbm93bGVkZ2VXYXZlIHByb3ZpZGVzIG92ZXIgODArIHdlYmluYXIgdGl0bGVz IGluIGJvdGggb3BlbiBlbnJvbGxtZW50IGFuZCBjbG9zZWQgY29ycG9yYXRlIGZvcm1hdC4g VGhpcyBldmVudCBpcyBvcGVuIHRvIHRoZSBnZW5lcmFsIHB1YmxpYyBhbmQgdGhlcmUgaXMg DQo8c3Ryb25nPm5vIGZlZTwvc3Ryb25nPi4gRW5yb2xsIHRvZGF5IGFuZCBsZWFybiBmcm9t IHRoZSBleHBlcnRzLjxicj4NCjxicj4NCjwvc3Bhbj4NCjxzdHJvbmc+PHNwYW4gY2xhc3M9 InN0eWxlNCI+UHJvZHVjdChzKTogTWljcm9zb2Z0IFdpbmRvd3MgVmlzdGEuICBBdWRpZW5j ZShzKTogQnVzaW5lc3MgUHJvZmVzc2lvbmFsLiBEdXJhdGlvbjogNjAgTWludXRlcywgU3Rh cnQgRGF0ZToNCjxzcGFuIGNsYXNzPSJ0ZXh0Ij48c3BhbiBjbGFzcz0ic3R5bGU5Ij5NYXJj aCAyMCwgMTA6MDBBTSBFU1Q8L3NwYW4+PC9zcGFuPi48L3NwYW4+PC9zdHJvbmc+PHNwYW4g Y2xhc3M9InN0eWxlNCI+PGJyPg0KPC9zcGFuPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmdv dG9tZWV0aW5nLmNvbS9yZWdpc3Rlci81MzIwNDk3ODYiPjxzcGFuIGNsYXNzPSJzdHlsZTQi PlJlZ2lzdGVyIFRvZGF5PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ic3R5bGU0Ij46IENsaWNr IHRoZSBsaW5rLg0KPGJyPg0KPGJyPg0KPC9zcGFuPg0KV2ViaW5hcnMgYXJlDQo8L3NwYW4+ IDxzdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+ZmFzdDwvc3Bhbj48L3N0cm9uZz48c3Bh biBjbGFzcz0ic3R5bGU0Ij4sIA0KPC9zcGFuPiA8c3Ryb25nPjxzcGFuIGNsYXNzPSJzdHls ZTQiPmNvbnZlbmllbnQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+IGFu ZCANCjwvc3Bhbj4gPHN0cm9uZz4NCjxzcGFuIGNsYXNzPSJzdHlsZTQiPmFmZm9yZGFibGU8 L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InN0eWxlNCI+LiBUaGVyZSBpcyBubyB3YXN0 ZWQgdGltZS4gR2V0IHJpZ2h0IHRvIHRoZSBvYmplY3RpdmUgb2YgdGhlIA0KMS1ob3VyIHNl c3Npb24uIFdlYmluYXJzIGFyZSBkZXNpZ25lZCB0byBmaXQgZWFzaWx5IGludG8geW91ciBi dXN5IHNjaGVkdWxlLiBZb3UgDQpoYXZlIG5vIHRyYXZlbCBhbmQgbm8gdGltZSBvdXQgb2Yg dGhlIG9mZmljZSEgT3VyIHdlYmluYXJzIGFyZSBmcmVlIG9yIHByaWNlZCBhdCANCmxlc3Mg dGhhbiAkOTAhIFRoYXQmIzM5O3MgYSBmcmFjdGlvbiBvZiB0aGUgY29zdCBvZiB0cmF2ZWwg YW5kIGF0dGVuZGFuY2UgZmVlcyBmb3IgDQpvdGhlciBoaWdoLXByaWNlZCBjbGFzc2VzLCBj b25mZXJlbmNlcywgc2VtaW5hcnMgb3Igb3RoZXIgb25saW5lIHdlYmluYXJzLiZuYnNwOw0K PGJyPg0KPGJyPg0KPC9zcGFuPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmdvdG9tZWV0aW5n LmNvbS9yZWdpc3Rlci81MzIwNDk3ODYiPjxzcGFuIGNsYXNzPSJzdHlsZTQiPlJlZ2lzdGVy IFRvZGF5PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ic3R5bGU0Ij46IENsaWNrIHRoZSBsaW5r Lg0KPGJyPg0KPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyB3ZWJpbmFyIGFu ZCBvdXIgb3RoZXIgd2ViaW5hciBldmVudHMsIHBsZWFzZSBnbyB0byBvdXIgd2Vic2l0ZToN Cjwvc3Bhbj4gDQo8YSBocmVmPSJodHRwOi8vd3d3Lmtub3dsZWRnZXdhdmUuY29tL3dlYmlu YXJzLnBocCI+PHNwYW4gY2xhc3M9InN0eWxlNCI+aHR0cDovL3d3dy5rbm93bGVkZ2V3YXZl LmNvbS93ZWJpbmFycy5waHA8L3NwYW4+PC9hPjwvc3Bhbj4NCjxzcGFuIGNsYXNzPSJzdHls ZTMiPjxzcGFuIGNsYXNzPSJzdHlsZTQiPjxicj4NCjxicj4NClRoYW5rcywgYW5kIGhhdmUg YSBncmVhdCBkYXkuDQoNCjxicj4NCjxicj4NCjwvc3Bhbj4NCjxzdHJvbmc+PHNwYW4gY2xh c3M9InN0eWxlNCI+S25vd2xlZGdlV2F2ZSBXZWJpbmFyIFN0YWZmIDwvc3Bhbj4NCg0KIA0K DQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCjwv c3Ryb25nPjxicj4NCjxicj4NCjxpbWcgYWx0PSJLbm93bGVkZ2VXYXZlIFdlYmluYXJzIiBz cmM9Imh0dHA6Ly93d3cua25vd2xlZGdld2F2ZS5jb20vaW1hZ2VzL2xvZ28tY29sb3Itd2Vi LmpwZyIgd2lkdGg9IjI2MCIgaGVpZ2h0PSI1MSI+PGJyPg0KPGJyPg0KPGltZyBhbHQ9Ik1p Y3Jvc29mdCBHb2xkIFBhcnRuZXIiIHNyYz0iaHR0cDovL3d3dy5rbm93bGVkZ2V3YXZlLmNv bS9pbWFnZXMvbWljcm9zb2Z0R29sZENlcnRpZmllZC5naWYiIHdpZHRoPSIyNjMiIGhlaWdo dD0iNTIiPjxicj4NCjxicj4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzp3ZWJpbmFyc0Brbm93 bGVkZ2V3YXZlLmNvbSI+d2ViaW5hcnNAa25vd2xlZGdld2F2ZS5jb208L2E+PC9zcGFuPg0K PHNwYW4gY2xhc3M9InN0eWxlMyI+PGJyPg0KS25vd2xlZGdld2F2ZSBpcyBWZXJtb250J3Mg b25seSBDZXJ0aWZpZWQgTWljcm9zb2Z0IEdvbGQgUGFydG5lciBmb3IgTGVhcm5pbmcgU29s dXRpb25zLg0KIDxicj4NCsKpIDIwMDggS25vd2xlZGdlV2F2ZS4gDQo8YnI+DQozMCBDb21t dW5pdHkgRHJpdmUsIFN0ZSA1LCBTb3V0aCBCdXJsaW5ndG9uLCBWVCAwNTQwMyANCjxicj4N CkNhbGw6IDEtODAwLTgzMS04NDQ5DQogDQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gY2xh c3M9InN0eWxlMSI+VGhlIGVtYWlsIHdhcyBzZW50IHRvIHhmc0Bvc3Muc2dpLmNvbS4gSWYg eW91IHByZWZlciBub3QgdG8gcmVjZWl2ZSB0aGVzZSBlbWFpbHMsIHBsZWFzZSByZXBseSB0 byB0aGlzIG1lc3NhZ2Ugd2l0aCBSRU1PVkUgaW4gdGhlIHN1YmplY3QgbGluZSBhbmQgd2Ug d2lsbCByZW1vdmUgeW91ciBlbWFpbCBhZGRyZXNzIGZyb20gZnV0dXJlIEtub3dsZWRnZVdh dmUgZGlzdHJpYnV0aW9ucy4NCjwvc3Bhbj4= From david@fromorbit.com Tue Mar 17 23:38: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 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 n2I4c4II204426 for ; Tue, 17 Mar 2009 23:38:24 -0500 X-ASG-Debug-ID: 1237351038-73d3015c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 246581C4E93C for ; Tue, 17 Mar 2009 21:37:20 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id PCP0l36zhY2hP43E for ; Tue, 17 Mar 2009 21:37:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALoQwEl5LAJ7/2dsb2JhbADTJYN8Bg X-IronPort-AV: E=Sophos;i="4.38,382,1233495000"; d="scan'208";a="341252283" Received: from ppp121-44-2-123.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.2.123]) by ipmail05.adl2.internode.on.net with ESMTP; 18 Mar 2009 14:47:55 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LjnE1-0004Pj-0n; Wed, 18 Mar 2009 15:17:53 +1100 Date: Wed, 18 Mar 2009 15:17:52 +1100 From: Dave Chinner To: Mikulas Patocka Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Message-ID: <20090318041752.GN26138@disturbed> Mail-Followup-To: Mikulas Patocka , Christoph Hellwig , xfs@oss.sgi.com References: <1237114679-18808-1-git-send-email-david@fromorbit.com> <1237114679-18808-2-git-send-email-david@fromorbit.com> 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-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145] X-Barracuda-Start-Time: 1237351064 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0511 1.0000 -1.6929 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.69 X-Barracuda-Spam-Status: No, SCORE=-1.69 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.20646 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 Tue, Mar 17, 2009 at 09:08:36AM -0400, Mikulas Patocka wrote: > On Sun, 15 Mar 2009, Dave Chinner wrote: > > > From: Dave Chinner > > > > Currently xfs_device_flush calls sync_blockdev() which is > > a no-op for XFS as all it's metadata is held in a different > > address to the one sync_blockdev() works on. > > > > Call xfs_sync_inodes() instead to flush all the delayed > > allocation blocks out. To do this as efficiently as possible, > > do it via two passes - one to do an async flush of all the > > dirty blocks and a second to wait for all the IO to complete. > > This requires some modification to the xfs-sync_inodes_ag() > > flush code to do efficiently. ..... > I tested the code and it works fine. > > But I'm not somehow convinced that that TRYLOCK is right ... that it will > avoid that pagelock-deadlock that I found before. Care to expand on why? > What is the ordering of pagelock, ILOCK and IOLOCK? iolock, pagelock, and ilock is always the innermost of the three. > If you keep the > ordering right, you don't need trylock. In this case, we are doing: iolock exclusive pagelock Clearly we can't take the iolock during (nor any other several other places in XFS that might try to take the iolock), so trylock-and-fail is the usual method used in XFS for avoiding a deadlock in this scenario. > And if the ordering is wrong, > trylock will only lower the probability of a deadlock, not avoid it > completely. Details of why you think this? XFS uses trylocks extensively to avoid deadlocks in these sorts of situations, so I'm curious to know why you think this technique provide an absolute guarantee in this case.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 01:35: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.6 required=5.0 tests=AWL,BAYES_00, LOCALPART_IN_SUBJECT 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 n2I6Ykjw213496 for ; Wed, 18 Mar 2009 01:35:07 -0500 X-ASG-Debug-ID: 1237358066-035000ab0000-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 8FC3D1C4EFFB for ; Tue, 17 Mar 2009 23:34:26 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id BLqQADhnHCG8Sbet for ; Tue, 17 Mar 2009 23:34:26 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjpM9-0004nh-Kd; Wed, 18 Mar 2009 06:34:25 +0000 Date: Wed, 18 Mar 2009 02:34:25 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com Cc: Dave Chinner , Nick Piggin , linux-fsdevel@vger.kernel.org X-ASG-Orig-Subj: xfs: properly truncate blocks outsize i_size on write_begin failure Subject: xfs: properly truncate blocks outsize i_size on write_begin failure Message-ID: <20090318063425.GA18386@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: 1237358066 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 As pointed out by Dave in the thread starting at http://oss.sgi.com/archives/xfs/2008-04/msg00542.html the current use of vmtruncate in block_write_begin is incorrect for filesystem not using ->truncate for doing the actual on-disk truncatation. Doing it in ->truncate for a filesystem like XFS means it would be split over multiple transactions leading to violations of the atomicy guarantee. Historically (and still documented in Documentation/filesystems/Locking) ->truncate is not a method but only a helper for setattr implementations so this is correct. The correct fix would be to use ->setattr but that needs a new ATTR_NOLOCK flag and an audit of all filesystems. I'm still hoping to do that later but for now I really want XFS fixed. So just duplicate block_write_begin in XFS to do the proper truncation, note that I need to export __block_prepare_write to no duplicate even more code than nessecary. GFS2 and UFS and possibly others wants the same kind of fix, too. And I need to get rid of ->truncate one day to prevent people from using it in stupid ways. Signed-off-by: Christoph Hellwig Index: xfs/fs/buffer.c =================================================================== --- xfs.orig/fs/buffer.c 2009-03-01 04:22:47.091430206 +0100 +++ xfs/fs/buffer.c 2009-03-01 04:22:59.913336991 +0100 @@ -1910,7 +1910,7 @@ void page_zero_new_buffers(struct page * } EXPORT_SYMBOL(page_zero_new_buffers); -static int __block_prepare_write(struct inode *inode, struct page *page, +int __block_prepare_write(struct inode *inode, struct page *page, unsigned from, unsigned to, get_block_t *get_block) { unsigned block_start, block_end; @@ -1989,6 +1989,7 @@ static int __block_prepare_write(struct page_zero_new_buffers(page, from, to); return err; } +EXPORT_SYMBOL(__block_prepare_write); static int __block_commit_write(struct inode *inode, struct page *page, unsigned from, unsigned to) Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2009-03-01 04:16:12.003305119 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2009-03-01 04:21:55.618306704 +0100 @@ -1598,6 +1598,71 @@ xfs_vm_direct_IO( return ret; } +/* + * This is a copy of fs/buffer.c:block_write_begin except for doing + * the correct setattr call in the error case instead of the wrong + * vmtruncate. + */ +static int +xfs_block_write_begin(struct file *file, struct address_space *mapping, + loff_t pos, unsigned len, unsigned flags, + struct page **pagep, void **fsdata, + get_block_t *get_block) +{ + struct inode *inode = mapping->host; + int status = 0; + struct page *page; + pgoff_t index; + unsigned start, end; + int ownpage = 0; + + index = pos >> PAGE_CACHE_SHIFT; + start = pos & (PAGE_CACHE_SIZE - 1); + end = start + len; + + page = *pagep; + if (page == NULL) { + ownpage = 1; + page = grab_cache_page_write_begin(mapping, index, flags); + if (!page) { + status = -ENOMEM; + goto out; + } + *pagep = page; + } else + BUG_ON(!PageLocked(page)); + + status = __block_prepare_write(inode, page, start, end, get_block); + if (unlikely(status)) { + ClearPageUptodate(page); + + if (ownpage) { + unlock_page(page); + page_cache_release(page); + *pagep = NULL; + + /* + * prepare_write() may have instantiated a few blocks + * outside i_size. Trim these off again. Don't need + * i_size_read because we hold i_mutex. + */ + if (pos + len > inode->i_size) { + struct iattr newattrs; + int error; + + newattrs.ia_size = inode->i_size; + newattrs.ia_valid = ATTR_SIZE | ATTR_FORCE; + error = xfs_setattr(XFS_I(inode), &newattrs, + XFS_ATTR_NOLOCK); + WARN_ON(error); /* not much we can do.. */ + } + } + } + +out: + return status; +} + STATIC int xfs_vm_write_begin( struct file *file, Index: xfs/include/linux/buffer_head.h =================================================================== --- xfs.orig/include/linux/buffer_head.h 2009-03-01 04:23:14.364305635 +0100 +++ xfs/include/linux/buffer_head.h 2009-03-01 04:23:19.081305583 +0100 @@ -218,6 +218,8 @@ int generic_write_end(struct file *, str struct page *, void *); void page_zero_new_buffers(struct page *page, unsigned from, unsigned to); int block_prepare_write(struct page*, unsigned, unsigned, get_block_t*); +int __block_prepare_write(struct inode *inode, struct page *page, + unsigned from, unsigned to, get_block_t *get_block); int cont_write_begin(struct file *, struct address_space *, loff_t, unsigned, unsigned, struct page **, void **, get_block_t *, loff_t *); From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 02:14:45 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 n2I7EOEK216005 for ; Wed, 18 Mar 2009 02:14:45 -0500 X-ASG-Debug-ID: 1237360424-034901460000-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 09B5A1C4F1A7 for ; Wed, 18 Mar 2009 00:13:44 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id S5aBQizUR5qlImc9 for ; Wed, 18 Mar 2009 00:13:44 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Ljpxh-0001GD-EN; Wed, 18 Mar 2009 07:13:13 +0000 Date: Wed, 18 Mar 2009 03:13:13 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com, linux-mm@kvack.org X-ASG-Orig-Subj: fput under mmap_sem Subject: fput under mmap_sem Message-ID: <20090318071313.GA30011@infradead.org> References: <200903151459.01320.denys@visp.net.lb> <20090315221921.GY26138@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090315221921.GY26138@disturbed> 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: 1237360445 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, Mar 16, 2009 at 09:19:21AM +1100, Dave Chinner wrote: > This is a VM problem where it calls fput() with the mmap_sem() held > in remove_vma(). It makes the incorrect assumption that filesystems > will never use the same lock in the IO path and the inode release path. > > This can deadlock if you are really unlucky. I really wonder why other filesystems haven't hit this yet. Any chance we can get the fput moved out of mmap_sem to get rid of this class of problems? From sbrings@silexmedia.com Wed Mar 18 03:35: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 n2I8Yvd2221175 for ; Wed, 18 Mar 2009 03:35:17 -0500 X-ASG-Debug-ID: 1237365276-034302a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from relay.ihostexchange.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2CD3A1C4F3C4 for ; Wed, 18 Mar 2009 01:34:36 -0700 (PDT) Received: from relay.ihostexchange.net (relay.ihostexchange.net [66.46.182.51]) by cuda.sgi.com with ESMTP id nGH2vqoB5PNjhO6L for ; Wed, 18 Mar 2009 01:34:36 -0700 (PDT) Received: from VMBX103.ihostexchange.net ([192.168.3.5]) by HUB101.ihostexchange.net ([66.46.182.51]) with mapi; Wed, 18 Mar 2009 04:34:04 -0400 From: Sebastian Brings To: "Steffen.Knauf@liga01.de" , Eric Sandeen CC: "xfs@oss.sgi.com" Date: Wed, 18 Mar 2009 04:33:47 -0400 X-ASG-Orig-Subj: RE: Lost files + indentical Foldernames on XFS Partition Subject: RE: Lost files + indentical Foldernames on XFS Partition Thread-Topic: Lost files + indentical Foldernames on XFS Partition Thread-Index: AcmnU4kyx8YJ6po9RbqRIyw/c+ZfQgAUHZfg Message-ID: <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> In-Reply-To: <49C029AF.5070205@liga01.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: relay.ihostexchange.net[66.46.182.51] X-Barracuda-Start-Time: 1237365277 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0207 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20651 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > -----Original Message----- > From: xfs-bounces@oss.sgi.com=20 > [mailto:xfs-bounces@oss.sgi.com] On Behalf Of Steffen Knauf > Sent: Dienstag, 17. M=E4rz 2009 23:53 > To: Eric Sandeen > Cc: xfs@oss.sgi.com > Subject: Re: Lost files + indentical Foldernames on XFS Partition >=20 >=20 > > Steffen Knauf wrote: > > =20 > >> Hello, > >> > >> today i have a strange behavior. I have a a directory=20 > which contains=20 > >> lots of indentical Folders with the same Name and Inode. > >> =20 Does this happen on the filesystem you mounted in parallel on two machines? I remember your question from early this week, so I ask=20 Sebastian > > > > What kernel? > > > > =20 >=20 > Linux version 2.6.16.60-0.21-smp (geeko@buildhost) (gcc version 4.1.2=20 > 20070115 (SUSE Linux)) > > Can you cut and paste what you see? > > > > =20 >=20 >=20 > Really strange is that if execute only a 'ls' command the files are=20 > shown twice: >=20 > combine_sbn.0051.tga > combine_sbn.0051.tga >=20 > But if i execute 'ls -il' the output looks like this: >=20 > combine_sbn.0051.tga: Datei oder Verzeichnis nicht gefunden > combine_sbn.0057.tga: Datei oder Verzeichnis nicht gefunden > combine_sbn.0058.tga: Datei oder Verzeichnis nicht gefunden >=20 > Here a directory example: >=20 > 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33=20 > S14-01_Fische_beauty_Main > 2147642598 drwxrwxrwx 2 500 500 4096 2009-03-17 12:33=20 > S14-01_Fische_beauty_Main >=20 > >> I don't create Hardlinks or something else. On the other=20 > side some files=20 > >> are suddenly vanished. A "ls -al" result in the following error:=20 > >> "Access to bla not possible: File or Directory not found." > >> I don't find some Errormessages in the logfile. I don't=20 > know whether a=20 > >> xfs_check make sense. > >> =20 > > > > xfs_repair -n will check the filesystem without actually=20 > modifying anything. > > > > =20 > I'll try it.... > > -Eric > > > > =20 > Steffen >=20 > * > * >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > = From Steffen.Knauf@liga01.de Wed Mar 18 03:46: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.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 n2I8jphr221715 for ; Wed, 18 Mar 2009 03:46:16 -0500 X-ASG-Debug-ID: 1237365929-4dd901630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p00-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 691EE1C4F3D1 for ; Wed, 18 Mar 2009 01:45:29 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by cuda.sgi.com with ESMTP id cxJVzQPwR9IjwXg9 for ; Wed, 18 Mar 2009 01:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237365928; l=345; s=domk; d=liga01.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:Reply-To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=cqfA0qEoPyAAe4/WrvBe5pRlquXdsCOLunewtIMm/7Y=; b=JJ4h30tGmhe463ukEdKqNP1cprbHgTx18jKV98EJW8JDsuvpGar8yI965N83k1PiSpW f4ydRI+9UywQbjT/MddTpsQosx5EfuTlqYyZ4J5p3ZRmbLnKTXy5VdvLa3hzkINQ/7cp2 v6OB2eQnC3aCTZ8CnyYucdtlnVlzm/rPJJk= X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (klopstock mo27) (RZmta 18.27) with ESMTP id k03297l2I8ZQ8d ; Wed, 18 Mar 2009 09:44:17 +0100 (MET) Message-ID: <49C0B41C.2060506@liga01.de> Date: Wed, 18 Mar 2009 09:43:08 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sebastian Brings CC: Eric Sandeen , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> In-Reply-To: <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p00-ob.rzone.de[81.169.146.160] X-Barracuda-Start-Time: 1237365931 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1434 1.0000 -1.1386 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.73 X-Barracuda-Spam-Status: No, SCORE=-0.73 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20651 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > > > Does this happen on the filesystem you mounted in parallel on two machines? > I remember your question from early this week, so I ask > > Sebastian > Yes, but i mounted the partition only a short time parallel (we only read from this partition). At the moment, the mounted Filesystem is only mounted on one machine. Steffen From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42:13 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_61, J_CHICKENPOX_64 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 n2I9fp21224791 for ; Wed, 18 Mar 2009 04:42:13 -0500 X-ASG-Debug-ID: 1237369291-22a501ef0000-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 36FCE1A6298 for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AHW7wsey2CmTl06u for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHD-0007dR-S7 for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:31 +0000 Message-Id: <20090318094131.771403000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:20 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/5] xfs: cleanup uuid handling Subject: [PATCH 1/5] xfs: cleanup uuid handling References: <20090318094119.561416000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-uuid-cleanup 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: 1237369292 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 uuid table handling should not be part of a semi-generic uuid library but in the XFS code using it, so move those bits to xfs_mount.c and refactor the whole glob to give a proper abstraction. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/support/uuid.c =================================================================== --- xfs.orig/fs/xfs/support/uuid.c 2009-02-15 19:40:08.564944522 +0100 +++ xfs/fs/xfs/support/uuid.c 2009-02-24 21:50:49.051029140 +0100 @@ -17,10 +17,6 @@ */ #include -static DEFINE_MUTEX(uuid_monitor); -static int uuid_table_size; -static uuid_t *uuid_table; - /* IRIX interpretation of an uuid_t */ typedef struct { __be32 uu_timelow; @@ -46,12 +42,6 @@ uuid_getnodeuniq(uuid_t *uuid, int fsid fsid[1] = be32_to_cpu(uup->uu_timelow); } -void -uuid_create_nil(uuid_t *uuid) -{ - memset(uuid, 0, sizeof(*uuid)); -} - int uuid_is_nil(uuid_t *uuid) { @@ -71,64 +61,3 @@ uuid_equal(uuid_t *uuid1, uuid_t *uuid2) { return memcmp(uuid1, uuid2, sizeof(uuid_t)) ? 0 : 1; } - -/* - * Given a 128-bit uuid, return a 64-bit value by adding the top and bottom - * 64-bit words. NOTE: This function can not be changed EVER. Although - * brain-dead, some applications depend on this 64-bit value remaining - * persistent. Specifically, DMI vendors store the value as a persistent - * filehandle. - */ -__uint64_t -uuid_hash64(uuid_t *uuid) -{ - __uint64_t *sp = (__uint64_t *)uuid; - - return sp[0] + sp[1]; -} - -int -uuid_table_insert(uuid_t *uuid) -{ - int i, hole; - - mutex_lock(&uuid_monitor); - for (i = 0, hole = -1; i < uuid_table_size; i++) { - if (uuid_is_nil(&uuid_table[i])) { - hole = i; - continue; - } - if (uuid_equal(uuid, &uuid_table[i])) { - mutex_unlock(&uuid_monitor); - return 0; - } - } - if (hole < 0) { - uuid_table = kmem_realloc(uuid_table, - (uuid_table_size + 1) * sizeof(*uuid_table), - uuid_table_size * sizeof(*uuid_table), - KM_SLEEP); - hole = uuid_table_size++; - } - uuid_table[hole] = *uuid; - mutex_unlock(&uuid_monitor); - return 1; -} - -void -uuid_table_remove(uuid_t *uuid) -{ - int i; - - mutex_lock(&uuid_monitor); - for (i = 0; i < uuid_table_size; i++) { - if (uuid_is_nil(&uuid_table[i])) - continue; - if (!uuid_equal(uuid, &uuid_table[i])) - continue; - uuid_create_nil(&uuid_table[i]); - break; - } - ASSERT(i < uuid_table_size); - mutex_unlock(&uuid_monitor); -} Index: xfs/fs/xfs/support/uuid.h =================================================================== --- xfs.orig/fs/xfs/support/uuid.h 2009-02-15 19:40:08.569944670 +0100 +++ xfs/fs/xfs/support/uuid.h 2009-02-24 21:50:37.206029255 +0100 @@ -22,12 +22,8 @@ typedef struct { unsigned char __u_bits[16]; } uuid_t; -extern void uuid_create_nil(uuid_t *uuid); extern int uuid_is_nil(uuid_t *uuid); extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2); extern void uuid_getnodeuniq(uuid_t *uuid, int fsid [2]); -extern __uint64_t uuid_hash64(uuid_t *uuid); -extern int uuid_table_insert(uuid_t *uuid); -extern void uuid_table_remove(uuid_t *uuid); #endif /* __XFS_SUPPORT_UUID_H__ */ Index: xfs/fs/xfs/xfs_mount.c =================================================================== --- xfs.orig/fs/xfs/xfs_mount.c 2009-02-24 15:32:35.871518446 +0100 +++ xfs/fs/xfs/xfs_mount.c 2009-02-24 21:51:03.558027729 +0100 @@ -45,7 +45,6 @@ #include "xfs_fsops.h" #include "xfs_utils.h" -STATIC int xfs_uuid_mount(xfs_mount_t *); STATIC void xfs_unmountfs_wait(xfs_mount_t *); @@ -121,6 +120,84 @@ static const struct { { sizeof(xfs_sb_t), 0 } }; +static DEFINE_MUTEX(xfs_uuid_table_mutex); +static int xfs_uuid_table_size; +static uuid_t *xfs_uuid_table; + +/* + * See if the UUID is unique among mounted XFS filesystems. + * Mount fails if UUID is nil or a FS with the same UUID is already mounted. + */ +STATIC int +xfs_uuid_mount( + struct xfs_mount *mp) +{ + uuid_t *uuid = &mp->m_sb.sb_uuid; + int hole, i; + + if (mp->m_flags & XFS_MOUNT_NOUUID) + return 0; + + if (uuid_is_nil(uuid)) { + cmn_err(CE_WARN, + "XFS: Filesystem %s has nil UUID - can't mount", + mp->m_fsname); + return XFS_ERROR(EINVAL); + } + + mutex_lock(&xfs_uuid_table_mutex); + for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) { + if (uuid_is_nil(&xfs_uuid_table[i])) { + hole = i; + continue; + } + if (uuid_equal(uuid, &xfs_uuid_table[i])) + goto out_duplicate; + } + + if (hole < 0) { + xfs_uuid_table = kmem_realloc(xfs_uuid_table, + (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), + xfs_uuid_table_size * sizeof(*xfs_uuid_table), + KM_SLEEP); + hole = xfs_uuid_table_size++; + } + xfs_uuid_table[hole] = *uuid; + mutex_unlock(&xfs_uuid_table_mutex); + + return 0; + + out_duplicate: + mutex_unlock(&xfs_uuid_table_mutex); + cmn_err(CE_WARN, "XFS: Filesystem %s has duplicate UUID - can't mount", + mp->m_fsname); + return XFS_ERROR(EINVAL); +} + +STATIC void +xfs_uuid_unmount( + struct xfs_mount *mp) +{ + uuid_t *uuid = &mp->m_sb.sb_uuid; + int i; + + if (mp->m_flags & XFS_MOUNT_NOUUID) + return; + + mutex_lock(&xfs_uuid_table_mutex); + for (i = 0; i < xfs_uuid_table_size; i++) { + if (uuid_is_nil(&xfs_uuid_table[i])) + continue; + if (!uuid_equal(uuid, &xfs_uuid_table[i])) + continue; + memset(&xfs_uuid_table[i], 0, sizeof(uuid_t)); + break; + } + ASSERT(i < xfs_uuid_table_size); + mutex_unlock(&xfs_uuid_table_mutex); +} + + /* * Free up the resources associated with a mount structure. Assume that * the structure was initially zeroed, so we can tell which fields got @@ -1016,18 +1093,9 @@ xfs_mountfs( mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); - /* - * XFS uses the uuid from the superblock as the unique - * identifier for fsid. We can not use the uuid from the volume - * since a single partition filesystem is identical to a single - * partition volume/filesystem. - */ - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) { - if (xfs_uuid_mount(mp)) { - error = XFS_ERROR(EINVAL); - goto out; - } - } + error = xfs_uuid_mount(mp); + if (error) + goto out; /* * Set the minimum read and write sizes @@ -1275,8 +1343,7 @@ xfs_mountfs( out_free_perag: xfs_free_perag(mp); out_remove_uuid: - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) - uuid_table_remove(&mp->m_sb.sb_uuid); + xfs_uuid_unmount(mp); out: return error; } @@ -1351,9 +1418,7 @@ xfs_unmountfs( xfs_unmountfs_wait(mp); /* wait for async bufs */ xfs_log_unmount_write(mp); xfs_log_unmount(mp); - - if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) - uuid_table_remove(&mp->m_sb.sb_uuid); + xfs_uuid_unmount(mp); #if defined(DEBUG) xfs_errortag_clearall(mp, 0); @@ -1855,29 +1920,6 @@ xfs_freesb( } /* - * See if the UUID is unique among mounted XFS filesystems. - * Mount fails if UUID is nil or a FS with the same UUID is already mounted. - */ -STATIC int -xfs_uuid_mount( - xfs_mount_t *mp) -{ - if (uuid_is_nil(&mp->m_sb.sb_uuid)) { - cmn_err(CE_WARN, - "XFS: Filesystem %s has nil UUID - can't mount", - mp->m_fsname); - return -1; - } - if (!uuid_table_insert(&mp->m_sb.sb_uuid)) { - cmn_err(CE_WARN, - "XFS: Filesystem %s has duplicate UUID - can't mount", - mp->m_fsname); - return -1; - } - return 0; -} - -/* * Used to log changes to the superblock unit and width fields which could * be altered by the mount options, as well as any potential sb_features2 * fixup. Only the first superblock is updated. From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_48, 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 n2I9fqxC224792 for ; Wed, 18 Mar 2009 04:42:13 -0500 X-ASG-Debug-ID: 1237369292-22a301e50000-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 5B5371A629A for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id WDRFsVTji0jkhjhF for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHE-0007dx-0f for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:32 +0000 Message-Id: <20090318094131.924623000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:21 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/5] xfs: kill mutex_t typedef Subject: [PATCH 2/5] xfs: kill mutex_t typedef References: <20090318094119.561416000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-mutex_t 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: 1237369292 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 People continue to complain about this for weird reasons, but there's really no point in keeping this typedef for a couple of users anyway. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/linux-2.6/mutex.h =================================================================== --- xfs.orig/fs/xfs/linux-2.6/mutex.h 2009-02-24 21:01:18.877182725 +0100 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,25 +0,0 @@ -/* - * Copyright (c) 2000-2003,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 - */ -#ifndef __XFS_SUPPORT_MUTEX_H__ -#define __XFS_SUPPORT_MUTEX_H__ - -#include - -typedef struct mutex mutex_t; - -#endif /* __XFS_SUPPORT_MUTEX_H__ */ Index: xfs/fs/xfs/linux-2.6/xfs_linux.h =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_linux.h 2009-02-24 21:01:34.596153088 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_linux.h 2009-02-24 21:01:47.951030927 +0100 @@ -38,7 +38,6 @@ #include #include #include -#include #include #include @@ -51,6 +50,7 @@ #include #include #include +#include #include #include #include Index: xfs/fs/xfs/quota/xfs_dquot.h =================================================================== --- xfs.orig/fs/xfs/quota/xfs_dquot.h 2009-02-24 20:59:24.413152831 +0100 +++ xfs/fs/xfs/quota/xfs_dquot.h 2009-02-24 20:59:39.642153943 +0100 @@ -34,7 +34,7 @@ */ typedef struct xfs_dqhash { struct xfs_dquot *qh_next; - mutex_t qh_lock; + struct mutex qh_lock; uint qh_version; /* ever increasing version */ uint qh_nelems; /* number of dquots on the list */ } xfs_dqhash_t; @@ -81,7 +81,7 @@ typedef struct xfs_dquot { xfs_qcnt_t q_res_bcount; /* total regular nblks used+reserved */ xfs_qcnt_t q_res_icount; /* total inos allocd+reserved */ xfs_qcnt_t q_res_rtbcount;/* total realtime blks used+reserved */ - mutex_t q_qlock; /* quota lock */ + struct mutex q_qlock; /* quota lock */ struct completion q_flush; /* flush completion queue */ atomic_t q_pincount; /* dquot pin count */ wait_queue_head_t q_pinwait; /* dquot pinning wait queue */ Index: xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm.c 2009-02-24 21:00:11.195028215 +0100 +++ xfs/fs/xfs/quota/xfs_qm.c 2009-02-24 21:00:30.583030096 +0100 @@ -55,7 +55,7 @@ * quota functionality, including maintaining the freelist and hash * tables of dquots. */ -mutex_t xfs_Gqm_lock; +struct mutex xfs_Gqm_lock; struct xfs_qm *xfs_Gqm; uint ndquot; @@ -80,7 +80,7 @@ static struct shrinker xfs_qm_shaker = { }; #ifdef DEBUG -extern mutex_t qcheck_lock; +extern struct mutex qcheck_lock; #endif #ifdef QUOTADEBUG Index: xfs/fs/xfs/quota/xfs_qm.h =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm.h 2009-02-24 21:00:11.207028206 +0100 +++ xfs/fs/xfs/quota/xfs_qm.h 2009-02-24 21:00:52.676027690 +0100 @@ -27,7 +27,7 @@ struct xfs_qm; struct xfs_inode; extern uint ndquot; -extern mutex_t xfs_Gqm_lock; +extern struct mutex xfs_Gqm_lock; extern struct xfs_qm *xfs_Gqm; extern kmem_zone_t *qm_dqzone; extern kmem_zone_t *qm_dqtrxzone; @@ -79,7 +79,7 @@ typedef xfs_dqhash_t xfs_dqlist_t; typedef struct xfs_frlist { struct xfs_dquot *qh_next; struct xfs_dquot *qh_prev; - mutex_t qh_lock; + struct mutex qh_lock; uint qh_version; uint qh_nelems; } xfs_frlist_t; @@ -115,7 +115,7 @@ typedef struct xfs_quotainfo { xfs_qwarncnt_t qi_bwarnlimit; /* limit for blks warnings */ xfs_qwarncnt_t qi_iwarnlimit; /* limit for inodes warnings */ xfs_qwarncnt_t qi_rtbwarnlimit;/* limit for rt blks warnings */ - mutex_t qi_quotaofflock;/* to serialize quotaoff */ + struct mutex qi_quotaofflock;/* to serialize quotaoff */ xfs_filblks_t qi_dqchunklen; /* # BBs in a chunk of dqs */ uint qi_dqperchunk; /* # ondisk dqs in above chunk */ xfs_qcnt_t qi_bhardlimit; /* default data blk hard limit */ Index: xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-24 21:01:03.015027884 +0100 +++ xfs/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-24 21:01:11.159155659 +0100 @@ -960,7 +960,7 @@ xfs_dqhash_t *qmtest_udqtab; xfs_dqhash_t *qmtest_gdqtab; int qmtest_hashmask; int qmtest_nfails; -mutex_t qcheck_lock; +struct mutex qcheck_lock; #define DQTEST_HASHVAL(mp, id) (((__psunsigned_t)(mp) + \ (__psunsigned_t)(id)) & \ From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,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 n2I9fqPs224793 for ; Wed, 18 Mar 2009 04:42:13 -0500 X-ASG-Debug-ID: 1237369292-22a701f70000-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 806381A629D for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id bplHiFjCfNhGSQCP for ; Wed, 18 Mar 2009 02:41:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHE-0007eT-5V for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:32 +0000 Message-Id: <20090318094132.076764000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:22 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/5] xfs: kill ino64 mount option Subject: [PATCH 3/5] xfs: kill ino64 mount option References: <20090318094119.561416000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-ino64 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: 1237369292 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 ino64 mount option adds a fixed offset to 32bit inode numbers to bring them into the 64bit range. There's no need for this kind of debug tool given that it's easy to produce real 64bit inode numbers for testing. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2009-03-17 19:46:13.246882523 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_iops.c 2009-03-17 19:58:00.491978754 +0100 @@ -541,9 +541,6 @@ xfs_vn_getattr( stat->uid = ip->i_d.di_uid; stat->gid = ip->i_d.di_gid; stat->ino = ip->i_ino; -#if XFS_BIG_INUMS - stat->ino += mp->m_inoadd; -#endif stat->atime = inode->i_atime; stat->mtime.tv_sec = ip->i_d.di_mtime.t_sec; stat->mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; Index: xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2009-03-17 19:50:03.421854113 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-03-17 19:58:00.492978881 +0100 @@ -78,7 +78,6 @@ mempool_t *xfs_ioend_pool; #define MNTOPT_RTDEV "rtdev" /* realtime I/O device */ #define MNTOPT_BIOSIZE "biosize" /* log2 of preferred buffered io size */ #define MNTOPT_WSYNC "wsync" /* safe-mode nfs compatible mount */ -#define MNTOPT_INO64 "ino64" /* force inodes into 64-bit range */ #define MNTOPT_NOALIGN "noalign" /* turn off stripe alignment */ #define MNTOPT_SWALLOC "swalloc" /* turn on stripe width allocation */ #define MNTOPT_SUNIT "sunit" /* data volume stripe unit */ @@ -290,16 +289,6 @@ xfs_parseargs( mp->m_flags |= XFS_MOUNT_OSYNCISOSYNC; } else if (!strcmp(this_char, MNTOPT_NORECOVERY)) { mp->m_flags |= XFS_MOUNT_NORECOVERY; - } else if (!strcmp(this_char, MNTOPT_INO64)) { -#if XFS_BIG_INUMS - mp->m_flags |= XFS_MOUNT_INO64; - mp->m_inoadd = XFS_INO64_OFFSET; -#else - cmn_err(CE_WARN, - "XFS: %s option not allowed on this system", - this_char); - return EINVAL; -#endif } else if (!strcmp(this_char, MNTOPT_NOALIGN)) { mp->m_flags |= XFS_MOUNT_NOALIGN; } else if (!strcmp(this_char, MNTOPT_SWALLOC)) { @@ -536,7 +525,6 @@ xfs_showargs( /* the few simple ones we can get from the mount struct */ { XFS_MOUNT_IKEEP, "," MNTOPT_IKEEP }, { XFS_MOUNT_WSYNC, "," MNTOPT_WSYNC }, - { XFS_MOUNT_INO64, "," MNTOPT_INO64 }, { XFS_MOUNT_NOALIGN, "," MNTOPT_NOALIGN }, { XFS_MOUNT_SWALLOC, "," MNTOPT_SWALLOC }, { XFS_MOUNT_NOUUID, "," MNTOPT_NOUUID }, @@ -1207,18 +1195,12 @@ xfs_fs_statfs( statp->f_bfree = statp->f_bavail = sbp->sb_fdblocks - XFS_ALLOC_SET_ASIDE(mp); fakeinos = statp->f_bfree << sbp->sb_inopblog; -#if XFS_BIG_INUMS - fakeinos += mp->m_inoadd; -#endif statp->f_files = MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); if (mp->m_maxicount) -#if XFS_BIG_INUMS - if (!mp->m_inoadd) -#endif - statp->f_files = min_t(typeof(statp->f_files), - statp->f_files, - mp->m_maxicount); + statp->f_files = min_t(typeof(statp->f_files), + statp->f_files, + mp->m_maxicount); statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); spin_unlock(&mp->m_sb_lock); Index: xfs/fs/xfs/xfs_dir2_block.c =================================================================== --- xfs.orig/fs/xfs/xfs_dir2_block.c 2009-02-11 20:49:46.773069530 +0100 +++ xfs/fs/xfs/xfs_dir2_block.c 2009-03-17 19:58:53.672855925 +0100 @@ -448,7 +448,6 @@ xfs_dir2_block_getdents( xfs_mount_t *mp; /* filesystem mount point */ char *ptr; /* current data entry */ int wantoff; /* starting block offset */ - xfs_ino_t ino; xfs_off_t cook; mp = dp->i_mount; @@ -509,16 +508,12 @@ xfs_dir2_block_getdents( cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (char *)dep - (char *)block); - ino = be64_to_cpu(dep->inumber); -#if XFS_BIG_INUMS - ino += mp->m_inoadd; -#endif /* * If it didn't fit, set the final offset to here & return. */ if (filldir(dirent, dep->name, dep->namelen, cook & 0x7fffffff, - ino, DT_UNKNOWN)) { + be64_to_cpu(dep->inumber), DT_UNKNOWN)) { *offset = cook & 0x7fffffff; xfs_da_brelse(NULL, bp); return 0; Index: xfs/fs/xfs/xfs_dir2_leaf.c =================================================================== --- xfs.orig/fs/xfs/xfs_dir2_leaf.c 2009-03-15 15:52:46.814978815 +0100 +++ xfs/fs/xfs/xfs_dir2_leaf.c 2009-03-17 19:59:39.331981439 +0100 @@ -780,7 +780,6 @@ xfs_dir2_leaf_getdents( int ra_index; /* *map index for read-ahead */ int ra_offset; /* map entry offset for ra */ int ra_want; /* readahead count wanted */ - xfs_ino_t ino; /* * If the offset is at or past the largest allowed value, @@ -1076,24 +1075,12 @@ xfs_dir2_leaf_getdents( continue; } - /* - * Copy the entry into the putargs, and try formatting it. - */ dep = (xfs_dir2_data_entry_t *)ptr; - length = xfs_dir2_data_entsize(dep->namelen); - ino = be64_to_cpu(dep->inumber); -#if XFS_BIG_INUMS - ino += mp->m_inoadd; -#endif - - /* - * Won't fit. Return to caller. - */ if (filldir(dirent, dep->name, dep->namelen, xfs_dir2_byte_to_dataptr(mp, curoff) & 0x7fffffff, - ino, DT_UNKNOWN)) + be64_to_cpu(dep->inumber), DT_UNKNOWN)) break; /* Index: xfs/fs/xfs/xfs_dir2_sf.c =================================================================== --- xfs.orig/fs/xfs/xfs_dir2_sf.c 2009-02-11 20:49:46.759069355 +0100 +++ xfs/fs/xfs/xfs_dir2_sf.c 2009-03-17 20:00:44.438859792 +0100 @@ -748,11 +748,7 @@ xfs_dir2_sf_getdents( * Put . entry unless we're starting past it. */ if (*offset <= dot_offset) { - ino = dp->i_ino; -#if XFS_BIG_INUMS - ino += mp->m_inoadd; -#endif - if (filldir(dirent, ".", 1, dot_offset & 0x7fffffff, ino, DT_DIR)) { + if (filldir(dirent, ".", 1, dot_offset & 0x7fffffff, dp->i_ino, DT_DIR)) { *offset = dot_offset & 0x7fffffff; return 0; } @@ -763,9 +759,6 @@ xfs_dir2_sf_getdents( */ if (*offset <= dotdot_offset) { ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); -#if XFS_BIG_INUMS - ino += mp->m_inoadd; -#endif if (filldir(dirent, "..", 2, dotdot_offset & 0x7fffffff, ino, DT_DIR)) { *offset = dotdot_offset & 0x7fffffff; return 0; @@ -786,10 +779,6 @@ xfs_dir2_sf_getdents( } ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); -#if XFS_BIG_INUMS - ino += mp->m_inoadd; -#endif - if (filldir(dirent, sfep->name, sfep->namelen, off & 0x7fffffff, ino, DT_UNKNOWN)) { *offset = off & 0x7fffffff; Index: xfs/fs/xfs/xfs_mount.h =================================================================== --- xfs.orig/fs/xfs/xfs_mount.h 2009-03-17 19:50:03.418853801 +0100 +++ xfs/fs/xfs/xfs_mount.h 2009-03-17 19:58:00.501978351 +0100 @@ -211,9 +211,6 @@ typedef struct xfs_mount { __uint64_t m_maxioffset; /* maximum inode offset */ __uint64_t m_resblks; /* total reserved blocks */ __uint64_t m_resblks_avail;/* available reserved blocks */ -#if XFS_BIG_INUMS - xfs_ino_t m_inoadd; /* add value for ino64_offset */ -#endif int m_dalign; /* stripe unit */ int m_swidth; /* stripe width */ int m_sinoalign; /* stripe unit inode alignment */ @@ -255,7 +252,6 @@ typedef struct xfs_mount { #define XFS_MOUNT_WSYNC (1ULL << 0) /* for nfs - all metadata ops must be synchronous except for space allocations */ -#define XFS_MOUNT_INO64 (1ULL << 1) #define XFS_MOUNT_DMAPI (1ULL << 2) /* dmapi is enabled */ #define XFS_MOUNT_WAS_CLEAN (1ULL << 3) #define XFS_MOUNT_FS_SHUTDOWN (1ULL << 4) /* atomic stop of all filesystem From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42: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 n2I9gMtb224833 for ; Wed, 18 Mar 2009 04:42:42 -0500 X-ASG-Debug-ID: 1237369322-22a201f70000-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 7A7C11A62BF for ; Wed, 18 Mar 2009 02:42:02 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id VtJcCTU7Oxotjv0q for ; Wed, 18 Mar 2009 02:42:02 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHD-0007cr-KZ for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:31 +0000 Message-Id: <20090318094119.561416000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:19 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/5] A couple more patches for 2.6.30 Subject: [PATCH 0/5] A couple more patches for 2.6.30 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: 1237369322 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 From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42:44 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_66 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 n2I9gM7E224834 for ; Wed, 18 Mar 2009 04:42:43 -0500 X-ASG-Debug-ID: 1237369322-034903bf0000-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 2DD461C4F729 for ; Wed, 18 Mar 2009 02:42:03 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id rdWGWf5frDSOFFPJ for ; Wed, 18 Mar 2009 02:42:03 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHE-0007ez-AX for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:32 +0000 Message-Id: <20090318094132.224487000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:23 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 4/5] xfs: remove m_litino Subject: [PATCH 4/5] xfs: remove m_litino References: <20090318094119.561416000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-m_litino 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: 1237369323 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 With the upcoming v3 inodes the inode data/attr area size needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_dinode.h =================================================================== --- xfs.orig/fs/xfs/xfs_dinode.h 2009-02-19 20:44:20.755069389 +0100 +++ xfs/fs/xfs/xfs_dinode.h 2009-03-18 07:37:16.652977839 +0100 @@ -103,7 +103,9 @@ typedef enum xfs_dinode_fmt { /* * Inode size for given fs. */ -#define XFS_LITINO(mp) ((mp)->m_litino) +#define XFS_LITINO(mp) \ + ((int)(((mp)->m_sb.sb_inodesize) - sizeof(struct xfs_dinode))) + #define XFS_BROOT_SIZE_ADJ \ (XFS_BTREE_LBLOCK_LEN - sizeof(xfs_bmdr_block_t)) Index: xfs/fs/xfs/xfs_mount.c =================================================================== --- xfs.orig/fs/xfs/xfs_mount.c 2009-03-18 07:37:15.633978066 +0100 +++ xfs/fs/xfs/xfs_mount.c 2009-03-18 07:37:20.566978952 +0100 @@ -651,7 +651,6 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb mp->m_sectbb_log = sbp->sb_sectlog - BBSHIFT; mp->m_agno_log = xfs_highbit32(sbp->sb_agcount - 1) + 1; mp->m_agino_log = sbp->sb_inopblog + sbp->sb_agblklog; - mp->m_litino = sbp->sb_inodesize - sizeof(struct xfs_dinode); mp->m_blockmask = sbp->sb_blocksize - 1; mp->m_blockwsize = sbp->sb_blocksize >> XFS_WORDLOG; mp->m_blockwmask = mp->m_blockwsize - 1; Index: xfs/fs/xfs/xfs_mount.h =================================================================== --- xfs.orig/fs/xfs/xfs_mount.h 2009-03-18 07:37:16.077856262 +0100 +++ xfs/fs/xfs/xfs_mount.h 2009-03-18 07:37:20.585978718 +0100 @@ -203,7 +203,6 @@ typedef struct xfs_mount { uint m_attr_node_ents; /* #entries in attr danode */ int m_ialloc_inos; /* inodes in inode allocation */ int m_ialloc_blks; /* blocks in inode allocation */ - int m_litino; /* size of inode union area */ int m_inoalign_mask;/* mask sb_inoalignmt if used */ uint m_qflags; /* quota status flags */ xfs_trans_reservations_t m_reservations;/* precomputed res values */ From SRS0+d437c05eed502ad2c4eb+2033+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 18 04:42:44 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_66 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 n2I9gNNE224836 for ; Wed, 18 Mar 2009 04:42:43 -0500 X-ASG-Debug-ID: 1237369323-034303b80000-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 542631C4F72A for ; Wed, 18 Mar 2009 02:42:03 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id YOdFpD7E2msGUIbZ for ; Wed, 18 Mar 2009 02:42:03 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LjsHE-0007fV-Gp for xfs@oss.sgi.com; Wed, 18 Mar 2009 09:41:32 +0000 Message-Id: <20090318094132.430583000@bombadil.infradead.org> User-Agent: quilt/0.47-1 Date: Wed, 18 Mar 2009 05:41:24 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 5/5] xfs: remove m_attroffset Subject: [PATCH 5/5] xfs: remove m_attroffset References: <20090318094119.561416000@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-xfs_default_attroffset 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: 1237369323 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 With the upcoming v3 inodes the default attroffset needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Also replace the assert for wrong inode sizes with a proper error check also included in non-debug builds. Note that the ENOSYS retourn for that might seem odd, but that error is returned by xfs_mount_validate_sb for all theoretically valid but not supported filesystem geometries. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_mount.c =================================================================== --- xfs.orig/fs/xfs/xfs_mount.c 2009-03-18 07:37:20.566978952 +0100 +++ xfs/fs/xfs/xfs_mount.c 2009-03-18 07:47:49.573979000 +0100 @@ -333,6 +333,22 @@ xfs_mount_validate_sb( return XFS_ERROR(ENOSYS); } + /* + * Currently only very few inode sizes are supported. + */ + switch (sbp->sb_inodesize) { + case 256: + case 512: + case 1024: + case 2048: + break; + default: + xfs_fs_mount_cmn_err(flags, + "inode size of %d bytes not supported", + sbp->sb_inodesize); + return XFS_ERROR(ENOSYS); + } + if (xfs_sb_validate_fsb_count(sbp, sbp->sb_dblocks) || xfs_sb_validate_fsb_count(sbp, sbp->sb_rblocks)) { xfs_fs_mount_cmn_err(flags, @@ -655,27 +671,6 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb mp->m_blockwsize = sbp->sb_blocksize >> XFS_WORDLOG; mp->m_blockwmask = mp->m_blockwsize - 1; - /* - * Setup for attributes, in case they get created. - * This value is for inodes getting attributes for the first time, - * the per-inode value is for old attribute values. - */ - ASSERT(sbp->sb_inodesize >= 256 && sbp->sb_inodesize <= 2048); - switch (sbp->sb_inodesize) { - case 256: - mp->m_attroffset = XFS_LITINO(mp) - - XFS_BMDR_SPACE_CALC(MINABTPTRS); - break; - case 512: - case 1024: - case 2048: - mp->m_attroffset = XFS_BMDR_SPACE_CALC(6 * MINABTPTRS); - break; - default: - ASSERT(0); - } - ASSERT(mp->m_attroffset < XFS_LITINO(mp)); - mp->m_alloc_mxr[0] = xfs_allocbt_maxrecs(mp, sbp->sb_blocksize, 1); mp->m_alloc_mxr[1] = xfs_allocbt_maxrecs(mp, sbp->sb_blocksize, 0); mp->m_alloc_mnr[0] = mp->m_alloc_mxr[0] / 2; Index: xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- xfs.orig/fs/xfs/xfs_attr_leaf.c 2009-03-18 07:37:20.570978763 +0100 +++ xfs/fs/xfs/xfs_attr_leaf.c 2009-03-18 07:37:23.768978423 +0100 @@ -155,7 +155,8 @@ xfs_attr_shortform_bytesfit(xfs_inode_t * minimum offset only needs to be the space required for * the btree root. */ - if (!dp->i_d.di_forkoff && dp->i_df.if_bytes > mp->m_attroffset) + if (!dp->i_d.di_forkoff && dp->i_df.if_bytes > + xfs_default_attroffset(dp)) dsize = XFS_BMDR_SPACE_CALC(MINDBTPTRS); break; Index: xfs/fs/xfs/xfs_bmap.c =================================================================== --- xfs.orig/fs/xfs/xfs_bmap.c 2009-03-18 07:37:20.575978772 +0100 +++ xfs/fs/xfs/xfs_bmap.c 2009-03-18 07:37:23.770978468 +0100 @@ -3569,6 +3569,27 @@ xfs_bmap_extents_to_btree( } /* + * Calculate the default attribute fork offset for newly created inodes. + */ +uint +xfs_default_attroffset( + struct xfs_inode *ip) +{ + struct xfs_mount *mp = ip->i_mount; + uint offset; + + if (mp->m_sb.sb_inodesize == 256) { + offset = XFS_LITINO(mp) - + XFS_BMDR_SPACE_CALC(MINABTPTRS); + } else { + offset = XFS_BMDR_SPACE_CALC(6 * MINABTPTRS); + } + + ASSERT(offset < XFS_LITINO(mp)); + return offset; +} + +/* * Helper routine to reset inode di_forkoff field when switching * attribute fork from local to extent format - we reset it where * possible to make space available for inline data fork extents. @@ -3580,15 +3601,18 @@ xfs_bmap_forkoff_reset( int whichfork) { if (whichfork == XFS_ATTR_FORK && - (ip->i_d.di_format != XFS_DINODE_FMT_DEV) && - (ip->i_d.di_format != XFS_DINODE_FMT_UUID) && - (ip->i_d.di_format != XFS_DINODE_FMT_BTREE) && - ((mp->m_attroffset >> 3) > ip->i_d.di_forkoff)) { - ip->i_d.di_forkoff = mp->m_attroffset >> 3; - ip->i_df.if_ext_max = XFS_IFORK_DSIZE(ip) / - (uint)sizeof(xfs_bmbt_rec_t); - ip->i_afp->if_ext_max = XFS_IFORK_ASIZE(ip) / - (uint)sizeof(xfs_bmbt_rec_t); + ip->i_d.di_format != XFS_DINODE_FMT_DEV && + ip->i_d.di_format != XFS_DINODE_FMT_UUID && + ip->i_d.di_format != XFS_DINODE_FMT_BTREE) { + uint dfl_forkoff = xfs_default_attroffset(ip) >> 3; + + if (dfl_forkoff > ip->i_d.di_forkoff) { + ip->i_d.di_forkoff = dfl_forkoff; + ip->i_df.if_ext_max = + XFS_IFORK_DSIZE(ip) / sizeof(xfs_bmbt_rec_t); + ip->i_afp->if_ext_max = + XFS_IFORK_ASIZE(ip) / sizeof(xfs_bmbt_rec_t); + } } } @@ -4057,7 +4081,7 @@ xfs_bmap_add_attrfork( case XFS_DINODE_FMT_BTREE: ip->i_d.di_forkoff = xfs_attr_shortform_bytesfit(ip, size); if (!ip->i_d.di_forkoff) - ip->i_d.di_forkoff = mp->m_attroffset >> 3; + ip->i_d.di_forkoff = xfs_default_attroffset(ip) >> 3; else if (mp->m_flags & XFS_MOUNT_ATTR2) version = 2; break; @@ -4204,12 +4228,12 @@ xfs_bmap_compute_maxlevels( * (a signed 16-bit number, xfs_aextnum_t). * * Note that we can no longer assume that if we are in ATTR1 that - * the fork offset of all the inodes will be (m_attroffset >> 3) - * because we could have mounted with ATTR2 and then mounted back - * with ATTR1, keeping the di_forkoff's fixed but probably at - * various positions. Therefore, for both ATTR1 and ATTR2 - * we have to assume the worst case scenario of a minimum size - * available. + * the fork offset of all the inodes will be + * (xfs_default_attroffset(ip) >> 3) because we could have mounted + * with ATTR2 and then mounted back with ATTR1, keeping the + * di_forkoff's fixed but probably at various positions. Therefore, + * for both ATTR1 and ATTR2 we have to assume the worst case scenario + * of a minimum size available. */ if (whichfork == XFS_DATA_FORK) { maxleafents = MAXEXTNUM; Index: xfs/fs/xfs/xfs_bmap.h =================================================================== --- xfs.orig/fs/xfs/xfs_bmap.h 2009-03-18 07:37:20.579979142 +0100 +++ xfs/fs/xfs/xfs_bmap.h 2009-03-18 07:37:23.772979002 +0100 @@ -338,6 +338,10 @@ xfs_check_nostate_extents( xfs_extnum_t idx, xfs_extnum_t num); +uint +xfs_default_attroffset( + struct xfs_inode *ip); + #ifdef __KERNEL__ /* Index: xfs/fs/xfs/xfs_mount.h =================================================================== --- xfs.orig/fs/xfs/xfs_mount.h 2009-03-18 07:37:20.585978718 +0100 +++ xfs/fs/xfs/xfs_mount.h 2009-03-18 07:37:23.772979002 +0100 @@ -198,7 +198,6 @@ typedef struct xfs_mount { int m_fixedfsid[2]; /* unchanged for life of FS */ uint m_dmevmask; /* DMI events for this FS */ __uint64_t m_flags; /* global mount flags */ - uint m_attroffset; /* inode attribute offset */ uint m_dir_node_ents; /* #entries in a dir danode */ uint m_attr_node_ents; /* #entries in attr danode */ int m_ialloc_inos; /* inodes in inode allocation */ From nickpiggin@yahoo.com.au Wed Mar 18 07:38:58 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 n2ICcb5i237296 for ; Wed, 18 Mar 2009 07:38:58 -0500 X-ASG-Debug-ID: 1237379876-5bd500870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp120.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 9821D1C4EEE1 for ; Wed, 18 Mar 2009 05:37:56 -0700 (PDT) Received: from smtp120.mail.mud.yahoo.com (smtp120.mail.mud.yahoo.com [209.191.84.77]) by cuda.sgi.com with SMTP id e5PEJnA0WgIp5L3n for ; Wed, 18 Mar 2009 05:37:56 -0700 (PDT) Received: (qmail 71511 invoked from network); 18 Mar 2009 12:37:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Disposition:Message-Id:Content-Type:Content-Transfer-Encoding; b=BZZ8nDfnEZzkfqncXeJi9NFd4wmml8coDbB4fHLOaTbf1RCtopB7+bh8vIoOhuGfSZEPBsbN7/5mz4dqldZtMLEf6R4mQS0F7oWGzpb6ncC3xqXsAfLMNH+i48957HIfithHHnDMw85YcH8JOEIapq7SNnuo+dsmLsrYNCrdLKk= ; Received: from unknown (HELO nick.localnet) (nickpiggin@59.167.60.25 with plain) by smtp120.mail.mud.yahoo.com with SMTP; 18 Mar 2009 12:37:54 -0000 X-YMail-OSG: MM4moxkVM1l3XLQnZviYy4Yp1nPZP2jSPYJRyGPfhDjJnimiIMz56awYTT0fciTPlgf5VZnrbsA4NtUUa2ypKomt9be834bBAnE6484yN0X76e9iitjOf4W9zXYaA7lGTGFBaYSK3hJqSPoOB8xKLKKRjVppG6QwWEHEwaXMCL_mjAtaeJ3JcLREL4Yivg-- X-Yahoo-Newman-Property: ymail-3 From: Nick Piggin To: Christoph Hellwig X-ASG-Orig-Subj: Re: fput under mmap_sem Subject: Re: fput under mmap_sem Date: Wed, 18 Mar 2009 23:37:48 +1100 User-Agent: KMail/1.9.51 (KDE/4.0.4; ; ) Cc: xfs@oss.sgi.com, linux-mm@kvack.org References: <200903151459.01320.denys@visp.net.lb> <20090315221921.GY26138@disturbed> <20090318071313.GA30011@infradead.org> In-Reply-To: <20090318071313.GA30011@infradead.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200903182337.48789.nickpiggin@yahoo.com.au> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp120.mail.mud.yahoo.com[209.191.84.77] X-Barracuda-Start-Time: 1237379897 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 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.20651 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 Wednesday 18 March 2009 18:13:13 Christoph Hellwig wrote: > On Mon, Mar 16, 2009 at 09:19:21AM +1100, Dave Chinner wrote: > > This is a VM problem where it calls fput() with the mmap_sem() held > > in remove_vma(). It makes the incorrect assumption that filesystems > > will never use the same lock in the IO path and the inode release path. > > > > This can deadlock if you are really unlucky. > > I really wonder why other filesystems haven't hit this yet. Any chance > we can get the fput moved out of mmap_sem to get rid of this class of > problems? Yes I don't think there is any reason against holding the file refcount a little longer, but it can be pretty nasty to do in practice because of deep call chains and sometimes multiple fputs within a given lock section. Possibly the easiest and quickest way will be to move aio's deferred __fput into a usable API and try that. If there are any performance problems, then we can try to move those fputs out from the mmap_sem one at a time (eg. I don't expect fput for vma replacement/merging to often cause the refcount to reach 0, and this is one of the harder places; wheras fput for a simple munmap might be more often causing refcount to reach 0 but it should be simpler to move out of mmap_sem if it is a problem). From sandeen@sandeen.net Wed Mar 18 09:00:53 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 n2IE0WI4242613 for ; Wed, 18 Mar 2009 09:00:52 -0500 X-ASG-Debug-ID: 1237384809-605801aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C6CCB1A7048 for ; Wed, 18 Mar 2009 07:00:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id IUOwDu1iJezxbYzP for ; Wed, 18 Mar 2009 07:00:09 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2IE07tP027545; Wed, 18 Mar 2009 10:00:07 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2IE06kv030449; Wed, 18 Mar 2009 10:00:07 -0400 Message-ID: <49C0FE64.3040203@sandeen.net> Date: Wed, 18 Mar 2009 09:00:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Steffen.Knauf@liga01.de CC: Sebastian Brings , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> <49C0B41C.2060506@liga01.de> In-Reply-To: <49C0B41C.2060506@liga01.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237384810 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.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20653 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Steffen Knauf wrote: >> >> Does this happen on the filesystem you mounted in parallel on two machines? >> I remember your question from early this week, so I ask >> >> Sebastian >> > Yes, but i mounted the partition only a short time parallel (we only > read from this partition). At the moment, the mounted Filesystem is only > mounted on one machine. > > Steffen > oh... well in that case, do an xfs_repair before anything else. -Eric From Steffen.Knauf@liga01.de Wed Mar 18 09:37: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 n2IEbLTi244525 for ; Wed, 18 Mar 2009 09:37:42 -0500 X-ASG-Debug-ID: 1237387020-5379029b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p00-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E0CBC1A734D for ; Wed, 18 Mar 2009 07:37:01 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by cuda.sgi.com with ESMTP id 8b5DHnGyOEz6s6eJ for ; Wed, 18 Mar 2009 07:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237387020; l=642; s=domk; d=liga01.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:Reply-To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=TiSCwWTqpeblt1pJagJSexr9OZE8a+pfpp0mX25A5FQ=; b=pm2gO54wiQVYKsBHNlqp6R3ZNB+yHzncvBmoFfFBRCjgAYTclvd0YMja4xVlasBTTlC XXDtG+zZFMB/P8oY2R8oy2UQez0tbTU7W32tQdIbxQorHRGZWLoh+HEOlBT4ZBOLhC1Ln dtKSz156hNlNwul+SQsJIUy2eUMi6f2iKVM= X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (klopstock mo41) (RZmta 18.27) with ESMTP id i03b74l2IDqDo6 ; Wed, 18 Mar 2009 15:35:09 +0100 (MET) Message-ID: <49C10658.5010000@liga01.de> Date: Wed, 18 Mar 2009 15:34:00 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Sandeen CC: Sebastian Brings , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> <49C0B41C.2060506@liga01.de> <49C0FE64.3040203@sandeen.net> In-Reply-To: <49C0FE64.3040203@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-p00-ob.rzone.de[81.169.146.162] X-Barracuda-Start-Time: 1237387021 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2643 1.0000 -0.5074 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.10 X-Barracuda-Spam-Status: No, SCORE=-0.10 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20654 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > Steffen Knauf wrote: > >>> Does this happen on the filesystem you mounted in parallel on two machines? >>> I remember your question from early this week, so I ask >>> >>> Sebastian >>> >>> >> Yes, but i mounted the partition only a short time parallel (we only >> read from this partition). At the moment, the mounted Filesystem is only >> mounted on one machine. >> >> Steffen >> >> > > oh... well in that case, do an xfs_repair before anything else. > > -Eric > > Yes, i'll do this in next days, but the Partitions are very huge ( 5 TB). I think that will take a while. Till then, greets and thanks! Steffen From mpatocka@redhat.com Wed Mar 18 11:16: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 (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2IGGKDq251778 for ; Wed, 18 Mar 2009 11:16:41 -0500 X-ASG-Debug-ID: 1237392938-407400760000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 554B91C51078 for ; Wed, 18 Mar 2009 09:15:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id BnqFhTTGFbpEWC0A for ; Wed, 18 Mar 2009 09:15:38 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2IGEpeJ015449; Wed, 18 Mar 2009 12:14:51 -0400 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2IGEr3Q028007; Wed, 18 Mar 2009 12:14:53 -0400 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n2IGEp8r020019; Wed, 18 Mar 2009 12:14:51 -0400 Received: from localhost (mpatocka@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n2IGEpdH020013; Wed, 18 Mar 2009 12:14:51 -0400 X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs Date: Wed, 18 Mar 2009 12:14:51 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing In-Reply-To: <20090318041752.GN26138@disturbed> Message-ID: References: <1237114679-18808-1-git-send-email-david@fromorbit.com> <1237114679-18808-2-git-send-email-david@fromorbit.com> <20090318041752.GN26138@disturbed> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237392960 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0260 1.0000 -1.8524 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.85 X-Barracuda-Spam-Status: No, SCORE=-1.85 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.20655 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 Wed, 18 Mar 2009, Dave Chinner wrote: > On Tue, Mar 17, 2009 at 09:08:36AM -0400, Mikulas Patocka wrote: > > On Sun, 15 Mar 2009, Dave Chinner wrote: > > > > > From: Dave Chinner > > > > > > Currently xfs_device_flush calls sync_blockdev() which is > > > a no-op for XFS as all it's metadata is held in a different > > > address to the one sync_blockdev() works on. > > > > > > Call xfs_sync_inodes() instead to flush all the delayed > > > allocation blocks out. To do this as efficiently as possible, > > > do it via two passes - one to do an async flush of all the > > > dirty blocks and a second to wait for all the IO to complete. > > > This requires some modification to the xfs-sync_inodes_ag() > > > flush code to do efficiently. > > ..... > > > I tested the code and it works fine. > > > > But I'm not somehow convinced that that TRYLOCK is right ... that it will > > avoid that pagelock-deadlock that I found before. > > Care to expand on why? > > > What is the ordering of pagelock, ILOCK and IOLOCK? > > iolock, pagelock, and ilock is always the innermost of the three. > > > If you keep the > > ordering right, you don't need trylock. > > In this case, we are doing: > > iolock exclusive > pagelock > > > Clearly we can't take the iolock during (nor any other > several other places in XFS that might try to take the iolock), so > trylock-and-fail is the usual method used in XFS for avoiding a > deadlock in this scenario. > > > And if the ordering is wrong, > > trylock will only lower the probability of a deadlock, not avoid it > > completely. > > Details of why you think this? XFS uses trylocks extensively to > avoid deadlocks in these sorts of situations, so I'm curious to > know why you think this technique provide an absolute guarantee in > this case.... > > Cheers, > > Dave. What I find scary is those two recursive pagelocks being held without trylock. The sequence is like: lock iolock 1 lock pagelock 1 --- submit request to xfssyncd, that does trylock iolock 2 lock pagelock 2 ... now suppose that this is racing with another process that takes pagelock without taking iolock first (memory manager trying to flush files mmaped for write or so). It can do lock pagelock 2 ... and submit flush request to a thread that is actually waiting to get pagelock 2. --- I don't know --- is there a possibility to reserve filesystem space for write-mapped files at the time of the first page fault? (so that the space won't be allocated at the time of a flush?). Mikulas From Martin@lichtvoll.de Wed Mar 18 13:53: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=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 n2IIr46x260557 for ; Wed, 18 Mar 2009 13:53:24 -0500 X-ASG-Debug-ID: 1237402341-68e100480000-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 65AC11C51BC3 for ; Wed, 18 Mar 2009 11:52:22 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id PKPOM7donoJhlSKY for ; Wed, 18 Mar 2009 11:52:22 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.228.6.ip-pool.NEFkom.net [212.114.228.6]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 198E45AE8D for ; Wed, 18 Mar 2009 19:52:18 +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: Wed, 18 Mar 2009 19:52:51 +0100 User-Agent: KMail/1.9.9 References: <200903121239.35442@zmi.at> <200903142043.11638.Martin@lichtvoll.de> <200903161717.19362@zmi.at> (sfid-20090316_194351_435811_EA2FEFA0) In-Reply-To: <200903161717.19362@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903181952.51901.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1237402363 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.20662 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 Montag 16 M=E4rz 2009 schrieb Michael Monnerie: > On Samstag 14 M=E4rz 2009 Martin Steigerwald wrote: > > Am Donnerstag 12 M=E4rz 2009 schrieb Michael Monnerie: > > > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/ > > > > BTW I think you gave away a subcriber only link. The article is not > > officially available yet: > > http://lwn.net/Articles/322823/ > > LWN might not be too happy with this. > > Nope. I am a subscriber, and can generate such Links in order to > provider an article to others. If you read that, they offer a "Free > trial subscription" for 3 months, and encourage you to pay then. I can > recommend lwn.net a lot, so maybe some people subscribe there because > of my posting :-) Okay, nice to hear. I like LWN a lot and consider subscribing to it. =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From info@mailhelp-desk.org Wed Mar 18 23:12:26 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_05 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 n2J4C5uj032975 for ; Wed, 18 Mar 2009 23:12:26 -0500 X-ASG-Debug-ID: 1237435905-703f00a10000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from webmail.moerstaal.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1153B1C53570 for ; Wed, 18 Mar 2009 21:11:45 -0700 (PDT) Received: from webmail.moerstaal.nl (webmail.moerstaal.nl [81.171.113.64]) by cuda.sgi.com with ESMTP id PHC6vIkQjAZ00Crj for ; Wed, 18 Mar 2009 21:11:45 -0700 (PDT) Received: by webmail.moerstaal.nl (Postfix, from userid 33) id 586A426C7E9; Thu, 19 Mar 2009 05:08:15 +0100 (CET) Received: from 82.128.15.140 (SquirrelMail authenticated user pop_355465) by webmail.moerstaal.nl with HTTP; Thu, 19 Mar 2009 05:08:15 +0100 (CET) Message-ID: <4702.82.128.15.140.1237435695.squirrel@webmail.moerstaal.nl> Date: Thu, 19 Mar 2009 05:08:15 +0100 (CET) X-ASG-Orig-Subj: Important: Email Account Verification Update ! ! ! Subject: Important: Email Account Verification Update ! ! ! From: "Web Help Desk." Reply-To: webmailupgrade@mailhelp-desk.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; X-moerstaal.nl-MailScanner: Found to be clean X-moerstaal.nl-MailScanner-From: info@mailhelp-desk.org X-Barracuda-Connect: webmail.moerstaal.nl[81.171.113.64] X-Barracuda-Start-Time: 1237435906 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5351 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.20693 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 The Helpdesk Program that periodically checks the size of your e-mail space is sending you this information. The program runs weekly to ensure your inbox does not grow too large, thus preventing you from receiving or sending new e-mail. As this message is being sent, you have 18 megabytes (MB) or more stored in your inbox. To help us reset your space in our database, please enter your current user name (_________________) password (_______________) You will receive a periodic alert if your inbox size is between 18 and 20 MB. If your inbox size is 20 MB, a program on your Webmail will move your oldest e-mails to a folder in your home directory to ensure you can continue receiving incoming e-mail. You will be notified this has taken place. If your inbox grows to 25 MB, you will be unable to receive new e-mail and it will be returned to sender. All this is programmed to ensure your e-mail continues to function well. Thank you for your cooperation. Help Desk. From Steffen.Knauf@liga01.de Thu Mar 19 04:27: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.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 n2J9R6wL054905 for ; Thu, 19 Mar 2009 04:27:26 -0500 X-ASG-Debug-ID: 1237454805-0bfb03750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mo-p00-ob.rzone.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E39861C54009 for ; Thu, 19 Mar 2009 02:26:45 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by cuda.sgi.com with ESMTP id RPm1FoJoZF6yiOT3 for ; Thu, 19 Mar 2009 02:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237454804; l=1763; s=domk; d=liga01.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:Reply-To:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=SovEQAyXLLN720rl9asesb7sQWNYx40/l2CXo6MjhWo=; b=xs57Zu4GdEefbHKoEr3sfBFo29Y/bAZPHhqQwxJsljW7mWrOF0DHg9OJXW5lVR27SrK wyvfxFjlBCmaEfbB5RjW/Q2cIDgKsxZupfyWKX/CqUe5TXe+n1i+T1pqwQ5Feg6alV5K/ kAujy5lqtF9/He8b3FX65hJS6jkMF6qGfLA= X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q== X-RZG-CLASS-ID: mo00 Received: from [10.1.1.65] ([213.39.240.61]) by post.strato.de (klopstock mo35) (RZmta 18.28) with ESMTP id a0096cl2J8TcJx ; Thu, 19 Mar 2009 10:26:43 +0100 (MET) Message-ID: <49C20F8E.3000504@liga01.de> Date: Thu, 19 Mar 2009 10:25:34 +0100 From: Steffen Knauf Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Sandeen CC: Sebastian Brings , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: Lost files + indentical Foldernames on XFS Partition Subject: Re: Lost files + indentical Foldernames on XFS Partition References: <49BFDC6E.6050607@liga01.de> <49BFDDC5.9060500@sandeen.net> <49C029AF.5070205@liga01.de> <5948362D99F6F145B37A7D45B5DDA4481042DDA609@VMBX103.ihostexchange.net> <49C0B41C.2060506@liga01.de> <49C0FE64.3040203@sandeen.net> In-Reply-To: <49C0FE64.3040203@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mo-p00-ob.rzone.de[81.169.146.161] X-Barracuda-Start-Time: 1237454805 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1949 1.0000 -0.8547 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.44 X-Barracuda-Spam-Status: No, SCORE=-0.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >> Yes, but i mounted the partition only a short time parallel (we only >> read from this partition). At the moment, the mounted Filesystem is only >> mounted on one machine. >> >> Steffen >> >> > > oh... well in that case, do an xfs_repair before anything else. > > -Eric > > I unmount the partition, but if i try to use xfs_repair, i get the following error: xfs_repair: /dev/sdc3 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library greets Steffen -- Steffen Knauf System Management fon: +49 (0)89 - 51 555 878 fax: +49 (0)89 51 555 877 *LIGA_01 | MÜNCHEN *LIGA_01 COMPUTERFILM GmbH *| *Landwehrstrasse 60-62 *| *80336 Munich, Germany fon: +49 (0)89 51 555 888 *|* fax: +49 (0)89 51 555 877 *| *www.liga01.com Geschäftsführer: Pablo Bach, Justus Engel, Sebastian Faber *|* Amtsgericht München HRB 143251 *| *USt-IdNr. DE223186904 *LIGA_01 | HAMBURG *LIGA_01 COMPUTERFILM HAMBURG GmbH *| *Grosse Theaterstrasse 1 *| *20354 Hamburg, Germany fon: +49 (0)40 226 226 00 *| *fax: +49 (0) 40 226 226 026 *| *www.liga01.com Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen diese Nachricht. Das unerlaubte Kopieren und die unbefugte Weiterleitung dieser Nachricht sind nicht gestattet. This message may contain confidential and/or privileged information. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete this message. Any unauthorised copying, disclosure or distribution of this message is strictly forbidden. From david@fromorbit.com Thu Mar 19 23:49:31 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 n2K4nA4k126474 for ; Thu, 19 Mar 2009 23:49:31 -0500 X-ASG-Debug-ID: 1237524530-6e6b01ab0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 16B571AF60F for ; Thu, 19 Mar 2009 21:48:50 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id LaKh09BPcz0qXCdq for ; Thu, 19 Mar 2009 21:48:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAO3wkl5LJAJ/2dsb2JhbADTYoN8Bg X-IronPort-AV: E=Sophos;i="4.38,393,1233495000"; d="scan'208";a="332741254" Received: from ppp121-44-144-9.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.144.9]) by ipmail04.adl2.internode.on.net with ESMTP; 20 Mar 2009 15:00:28 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LkWNH-0007Ls-CG; Fri, 20 Mar 2009 15:30:27 +1100 Date: Fri, 20 Mar 2009 15:30:27 +1100 From: Dave Chinner To: Mikulas Patocka Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Message-ID: <20090320043027.GO26138@disturbed> Mail-Followup-To: Mikulas Patocka , Christoph Hellwig , xfs@oss.sgi.com References: <1237114679-18808-1-git-send-email-david@fromorbit.com> <1237114679-18808-2-git-send-email-david@fromorbit.com> <20090318041752.GN26138@disturbed> 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-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1237524532 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0153 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.20789 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 Wed, Mar 18, 2009 at 12:14:51PM -0400, Mikulas Patocka wrote: > On Wed, 18 Mar 2009, Dave Chinner wrote: > > On Tue, Mar 17, 2009 at 09:08:36AM -0400, Mikulas Patocka wrote: > > > On Sun, 15 Mar 2009, Dave Chinner wrote: > What I find scary is those two recursive pagelocks being held without > trylock. The sequence is like: > > lock iolock 1 > lock pagelock 1 > --- submit request to xfssyncd, that does > trylock iolock 2 > lock pagelock 2 Those two pages will be on different inodes, so locking through all paths to pagelock 2 except for page writeback will be protected by the iolocks... > ... now suppose that this is racing with another process that takes > pagelock without taking iolock first (memory manager trying to flush files > mmaped for write or so). It can do > > lock pagelock 2 > ... and submit flush request to a thread that is actually waiting to get > pagelock 2. Which, AFAIK, is never done in XFS. Once we have a page locked in the writeback path we either dispatch it in an IO or unlock it directly before continuing. There should not be a case like you describe occurring (it is a bug if that does happen). > --- I don't know --- is there a possibility to reserve filesystem space > for write-mapped files at the time of the first page fault? (so that the > space won't be allocated at the time of a flush?). ->page_mkwrite Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+0625fbca3dd0f4700a64+2035+infradead.org+hch@bombadil.srs.infradead.org Fri Mar 20 02:27: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 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 n2K7RSbq148324 for ; Fri, 20 Mar 2009 02:27:49 -0500 X-ASG-Debug-ID: 1237534009-53e201010000-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 D82A51C58AAE for ; Fri, 20 Mar 2009 00:26:49 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id DmI6LJfQs00pNu5u for ; Fri, 20 Mar 2009 00:26:49 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LkZ7S-0001Xp-Gz; Fri, 20 Mar 2009 07:26:18 +0000 Date: Fri, 20 Mar 2009 03:26:18 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com, moosh009@gmail.com X-ASG-Orig-Subj: [PATCH] xfs_io: fix extent array reallocation Subject: [PATCH] xfs_io: fix extent array reallocation Message-ID: <20090320072618.GA26571@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: 1237534029 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 From: Tomasz Majkowski The XFS_IOC_FSGETXATTRA ioctl only returns the number of allocated extents, so when we reallocate the extent array in the bmap command we have to account for the worst case where there is a whole between each two allocated extents. Also add some slack to that case to allow for a file growing while we are racing with it. Index: xfsprogs-dev/io/bmap.c =================================================================== --- xfsprogs-dev.orig/io/bmap.c 2009-03-20 06:28:33.000000000 +0000 +++ xfsprogs-dev/io/bmap.c 2009-03-20 06:29:52.000000000 +0000 @@ -217,8 +217,8 @@ exitcode = 1; return 0; } - if (fsx.fsx_nextents >= map_size-1) { - map_size = 2*(fsx.fsx_nextents+1); + if (2 * fsx.fsx_nextents > map_size) { + map_size = 2 * fsx.fsx_nextents + 1; map = realloc(map, map_size*sizeof(*map)); if (map == NULL) { fprintf(stderr, From SRS0+0625fbca3dd0f4700a64+2035+infradead.org+hch@bombadil.srs.infradead.org Fri Mar 20 02:30:08 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 n2K7Tl7L148657 for ; Fri, 20 Mar 2009 02:30:08 -0500 X-ASG-Debug-ID: 1237534168-378c02de0000-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 C29561C58AD9 for ; Fri, 20 Mar 2009 00:29:28 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id xR1BzTOqaSeCWvzc for ; Fri, 20 Mar 2009 00:29:28 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LkZA1-0004lM-Vr; Fri, 20 Mar 2009 07:28:57 +0000 Date: Fri, 20 Mar 2009 03:28:57 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com, Tomasz Majkowski X-ASG-Orig-Subj: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Subject: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Message-ID: <20090320072857.GB26571@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: 1237534168 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 Test that we can get all extent/hole information for files with more than 16 extents and 15 holes which require a reallocation based on XFS_IOC_FSGETXATTR. Based on a testcase from Tomasz Majkowski . Signed-off-by: Christoph Hellwig Index: xfstests-dev/203 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfstests-dev/203 2009-03-20 07:28:06.000000000 +0000 @@ -0,0 +1,71 @@ +#! /bin/sh +# FS QA Test No. 203 +# +# Test out reallocation of the extent array in xfs_io. +# Based on a testcase from Tomasz Majkowski . +# +#----------------------------------------------------------------------- +# Copyright (c) 2009 Christoph Hellwig. +#----------------------------------------------------------------------- +# +# creator +owner=hch@lst.de + +seq=`basename $0` +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! + +_write_holes() +{ + file=$1 + holes=$2 + let writes=$holes+1 + + offset=0 + for i in `seq 0 $writes`; do + xfs_io -f $file -c "pwrite -q $offset 1" + let offset=$offset+0x100000 + done +} + +# 0: [0..7]: 104..111 +# 1: [8..2047]: hole +_filter_bmap() +{ + awk '$3 ~ /hole/ { print $1, $2, $3; next } + {print $1, $2; next}' +} + +_cleanup() +{ + rm -f $TEST_DIR/hole_file* + rm -f $TEST_DIR/r?? +} +trap "_cleanup; exit \$status" 0 1 2 3 15 + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +# real QA test starts here +_supported_fs xfs +_supported_os Linux + + +for i in 10 14 15 16 17 28 29 30 31; do + rm -f $TEST_DIR/hole_file + _write_holes $TEST_DIR/hole_file${i} ${i} +done + +for i in 10 14 15 16 17 28 29 30 31; do + xfs_bmap $TEST_DIR/hole_file${i} | _filter_bmap + echo +done + +# success, all done +echo "*** done" +rm -f $seq.full +status=0 Index: xfstests-dev/203.out =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfstests-dev/203.out 2009-03-20 07:09:51.000000000 +0000 @@ -0,0 +1,427 @@ +QA output created by 203 +/mnt/test/hole_file10: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: + +/mnt/test/hole_file14: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: + +/mnt/test/hole_file15: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: + +/mnt/test/hole_file16: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: + +/mnt/test/hole_file17: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: +35: [34824..36863]: hole +36: [36864..36871]: + +/mnt/test/hole_file28: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: +35: [34824..36863]: hole +36: [36864..36871]: +37: [36872..38911]: hole +38: [38912..38919]: +39: [38920..40959]: hole +40: [40960..40967]: +41: [40968..43007]: hole +42: [43008..43015]: +43: [43016..45055]: hole +44: [45056..45063]: +45: [45064..47103]: hole +46: [47104..47111]: +47: [47112..49151]: hole +48: [49152..49159]: +49: [49160..51199]: hole +50: [51200..51207]: +51: [51208..53247]: hole +52: [53248..53255]: +53: [53256..55295]: hole +54: [55296..55303]: +55: [55304..57343]: hole +56: [57344..57351]: +57: [57352..59391]: hole +58: [59392..59399]: + +/mnt/test/hole_file29: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: +35: [34824..36863]: hole +36: [36864..36871]: +37: [36872..38911]: hole +38: [38912..38919]: +39: [38920..40959]: hole +40: [40960..40967]: +41: [40968..43007]: hole +42: [43008..43015]: +43: [43016..45055]: hole +44: [45056..45063]: +45: [45064..47103]: hole +46: [47104..47111]: +47: [47112..49151]: hole +48: [49152..49159]: +49: [49160..51199]: hole +50: [51200..51207]: +51: [51208..53247]: hole +52: [53248..53255]: +53: [53256..55295]: hole +54: [55296..55303]: +55: [55304..57343]: hole +56: [57344..57351]: +57: [57352..59391]: hole +58: [59392..59399]: +59: [59400..61439]: hole +60: [61440..61447]: + +/mnt/test/hole_file30: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: +35: [34824..36863]: hole +36: [36864..36871]: +37: [36872..38911]: hole +38: [38912..38919]: +39: [38920..40959]: hole +40: [40960..40967]: +41: [40968..43007]: hole +42: [43008..43015]: +43: [43016..45055]: hole +44: [45056..45063]: +45: [45064..47103]: hole +46: [47104..47111]: +47: [47112..49151]: hole +48: [49152..49159]: +49: [49160..51199]: hole +50: [51200..51207]: +51: [51208..53247]: hole +52: [53248..53255]: +53: [53256..55295]: hole +54: [55296..55303]: +55: [55304..57343]: hole +56: [57344..57351]: +57: [57352..59391]: hole +58: [59392..59399]: +59: [59400..61439]: hole +60: [61440..61447]: +61: [61448..63487]: hole +62: [63488..63495]: + +/mnt/test/hole_file31: +0: [0..7]: +1: [8..2047]: hole +2: [2048..2055]: +3: [2056..4095]: hole +4: [4096..4103]: +5: [4104..6143]: hole +6: [6144..6151]: +7: [6152..8191]: hole +8: [8192..8199]: +9: [8200..10239]: hole +10: [10240..10247]: +11: [10248..12287]: hole +12: [12288..12295]: +13: [12296..14335]: hole +14: [14336..14343]: +15: [14344..16383]: hole +16: [16384..16391]: +17: [16392..18431]: hole +18: [18432..18439]: +19: [18440..20479]: hole +20: [20480..20487]: +21: [20488..22527]: hole +22: [22528..22535]: +23: [22536..24575]: hole +24: [24576..24583]: +25: [24584..26623]: hole +26: [26624..26631]: +27: [26632..28671]: hole +28: [28672..28679]: +29: [28680..30719]: hole +30: [30720..30727]: +31: [30728..32767]: hole +32: [32768..32775]: +33: [32776..34815]: hole +34: [34816..34823]: +35: [34824..36863]: hole +36: [36864..36871]: +37: [36872..38911]: hole +38: [38912..38919]: +39: [38920..40959]: hole +40: [40960..40967]: +41: [40968..43007]: hole +42: [43008..43015]: +43: [43016..45055]: hole +44: [45056..45063]: +45: [45064..47103]: hole +46: [47104..47111]: +47: [47112..49151]: hole +48: [49152..49159]: +49: [49160..51199]: hole +50: [51200..51207]: +51: [51208..53247]: hole +52: [53248..53255]: +53: [53256..55295]: hole +54: [55296..55303]: +55: [55304..57343]: hole +56: [57344..57351]: +57: [57352..59391]: hole +58: [59392..59399]: +59: [59400..61439]: hole +60: [61440..61447]: +61: [61448..63487]: hole +62: [63488..63495]: +63: [63496..65535]: hole +64: [65536..65543]: + +*** done Index: xfstests-dev/group =================================================================== --- xfstests-dev.orig/group 2009-03-20 06:56:23.000000000 +0000 +++ xfstests-dev/group 2009-03-20 06:57:06.000000000 +0000 @@ -307,3 +307,4 @@ 200 mount auto quick 201 metadata auto quick 202 repair auto quick +203 ioctl auto From SEMA-CR-1-418A69@ptcmarketing.com Fri Mar 20 04:57:48 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_8BIT_HEADER 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 n2K9vRZg160025 for ; Fri, 20 Mar 2009 04:57:48 -0500 X-ASG-Debug-ID: 1237543007-013801c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 001A61C5918E for ; Fri, 20 Mar 2009 02:56:47 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id aOFE3LzBG1nulhXF for ; Fri, 20 Mar 2009 02:56:47 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,394,1233550800"; d="scan'208,217";a="292938108" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 20 Mar 2009 03:41:22 -0400 Date: Fri, 20 Mar 2009 03:37:55 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: Stay ahead of the pack =?utf-8?q?=E2=80=93?= attend PTC/USER World Event 2009 Subject: Stay ahead of the pack =?utf-8?q?=E2=80=93?= attend PTC/USER World Event 2009 Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1237532132160_1727601034 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1237543029 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 --BF_1237532132160_1727601034 Content-Type: text/plain; charset=UTF-8 Join us in Orlando and celebrate the 20th Anniversary of the PTC/USER World Event. If you've attended this event in the past, you know what to expect - new skills, new solutions, renewed energy and the chance to extend your network of peers. In a tough economy, the companies that survive are those who stay ahead of the pack - those who streamline their processes, implement solutions before their competitors do, and keep their customers satisfied. This conference will give you the tools you need to help your company do just that. Here are a few highlights from this year's event: * 3 days of in-depth education with more than 300 technical presentations. * Increased PTC University training (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fprecision.html) opportunities with 160 hours of free instructor led hands on training and if you arrive early you can take advantage of new Sunday sessions helping you to avoid schedule conflicts during the main event. And back by popular demand - post event 1-day courses (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fposttraining.html) discounted 40% for event attendees only. Sign up for all training is in advance and on a first come first serve basis so make sure to register for the event early! * Multiple networking activities including topic table breakfasts, lunches and evening receptions giving you plenty of opportunities to connect with your peers and extend your network. * Extensive exhibit hall featuring the latest in products and services from more than 100 PTC and Partner exhibits. * 1-day Management Forum on Monday. This year's theme, "Energizing Product Development in a Challenging Global Economy" (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fforum.html) , focuses on practical advice that will help you and your company move forward through the troubled waters of today's marketplace. * New tools for justifying your attendance. We know that current economic difficulties might make it hard to get approval to attend so make sure to read our new top 10 reasons (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fwhy.html) why you should come to Orlando and check out these strategies to get funding (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fjustify.html) for your conference attendance. We also have a new letter to your boss (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009%2Fbossltr.html) that you can e-mail today. * You can create a personalized curriculum to suit your needs with our new agenda builder tool allowing you to select relevant and timely sessions that address your needs. Print out your personalized agenda and show your boss why this is an event you can't afford to miss! Visit the PTC/USER World Event 2009 website at (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3P40S4&o=1-40A1FT&w=2354034&t=http%3A%2F%2Fwww.ptcuser.org%2F2009) to learn more and register. Make sure to register before the early bird deadline to save! We look forward to seeing you in Orlando! =============================================================================== contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-40A1FT&campd=1-3P40S4&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-40A1FT&campd=1-3P40S4&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com edit profile http://www.ptc.com/read?&w=2354034&t=/common/account/index.htm ------------------------------------------------------------------------------- This email was sent to: xfs@oss.sgi.com PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com. --BF_1237532132160_1727601034 Content-Type: text/html; charset=UTF-8 SMB Register Now Email FY09Q3 PTCUSER World Event

Join us in Orlando and celebrate the 20th Anniversary of the PTC/USER World Event.  If you've attended this event in the past, you know what to expect – new skills, new solutions, renewed energy and the chance to extend your network of peers.

In a tough economy, the companies that survive are those who stay ahead of the pack – those who streamline their processes, implement solutions before their competitors do, and keep their customers satisfied. This conference will give you the tools you need to help your company do just that.  

Here are a few highlights from this year's event:

·   3 days of in-depth education with more than 300 technical presentations.

·   Increased PTC University training opportunities with 160 hours of free instructor led hands on training and if you arrive early you can take advantage of new Sunday sessions helping you to avoid schedule conflicts during the main event. And back by popular demand - post event 1-day courses discounted 40% for event attendees only. Sign up for all training is in advance and on a first come first serve basis so make sure to register for the event early!

·   Multiple networking activities including topic table breakfasts, lunches and evening receptions giving you plenty of opportunities to connect with your peers and extend your network.

·   Extensive exhibit hall featuring the latest in products and services from more than 100 PTC and Partner exhibits.

·   1-day Management Forum on Monday . This year's theme, "Energizing Product Development in a Challenging Global Economy", focuses on practical advice that will help you and your company move forward through the troubled waters of today's marketplace.

·   New tools for justifying your attendance. We know that current economic difficulties might make it hard to get approval to attend so make sure to read our new top 10 reasons why you should come to Orlando and check out these strategies to get funding for your conference attendance. We also have a new letter to your boss that you can e-mail today.

·   You can create a personalized curriculum to suit your needs with our new agenda builder tool allowing you to select relevant and timely sessions that address your needs. Print out your personalized agenda and show your boss why this is an event you can't afford to miss!

Visit the PTC/USER World Event 2009 website at www.ptcuser.org/2009 to learn more and register. Make sure to register before the early bird deadline to save!

We look forward to seeing you in Orlando!

contact PTC | privacy policy | unsubscribe | change preferences | edit profile
This email was sent to: xfs@oss.sgi.com     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com.
--BF_1237532132160_1727601034-- From felixb@sgi.com Fri Mar 20 09:41: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 autolearn=no 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 n2KEfSbD175293 for ; Fri, 20 Mar 2009 09:41:48 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id EF3B38F80D0 for ; Fri, 20 Mar 2009 07:41:09 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id 707C6700016A; Fri, 20 Mar 2009 09:33:29 -0500 (CDT) Cc: xfs@oss.sgi.com, moosh009@gmail.com Message-Id: <88A46616-5E3A-49D4-BAD5-9CEA426725D2@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090320072618.GA26571@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH] xfs_io: fix extent array reallocation Date: Fri, 20 Mar 2009 09:33:29 -0500 References: <20090320072618.GA26571@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 Mar 20, 2009, at 2:26 AM, Christoph Hellwig wrote: > From: Tomasz Majkowski > > The XFS_IOC_FSGETXATTRA ioctl only returns the number of allocated > extents, so when we reallocate the extent array in the bmap command > we have to account for the worst case where there is a whole between > each two allocated extents. Also add some slack to that case to > allow for a file growing while we are racing with it. Reviewed-by: Felix Blyakher > > > > Index: xfsprogs-dev/io/bmap.c > =================================================================== > --- xfsprogs-dev.orig/io/bmap.c 2009-03-20 06:28:33.000000000 +0000 > +++ xfsprogs-dev/io/bmap.c 2009-03-20 06:29:52.000000000 +0000 > @@ -217,8 +217,8 @@ > exitcode = 1; > return 0; > } > - if (fsx.fsx_nextents >= map_size-1) { > - map_size = 2*(fsx.fsx_nextents+1); > + if (2 * fsx.fsx_nextents > map_size) { > + map_size = 2 * fsx.fsx_nextents + 1; > map = realloc(map, map_size*sizeof(*map)); > if (map == NULL) { > fprintf(stderr, > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Fri Mar 20 22:52:37 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 n2L3qGPJ216086 for ; Fri, 20 Mar 2009 22:52:37 -0500 X-ASG-Debug-ID: 1237607496-06fd01190000-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 428C51B35CB for ; Fri, 20 Mar 2009 20:51:37 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id E9TEjCzZIONFAzTW for ; Fri, 20 Mar 2009 20:51:37 -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 n2L3pS3g016039; Fri, 20 Mar 2009 23:51:28 -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 n2L3pPZ7026479; Fri, 20 Mar 2009 23:51:26 -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 n2L3pSZH025904; Fri, 20 Mar 2009 23:51:28 -0400 Message-ID: <49C4643F.9090702@sandeen.net> Date: Fri, 20 Mar 2009 22:51:27 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/5] xfs: kill mutex_t typedef Subject: Re: [PATCH 2/5] xfs: kill mutex_t typedef References: <20090318094119.561416000@bombadil.infradead.org> <20090318094131.924623000@bombadil.infradead.org> In-Reply-To: <20090318094131.924623000@bombadil.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: 1237607518 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.20875 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: (argh quilt sending attachments) Anyway Reviewed-by: Eric Sandeen From sandeen@sandeen.net Fri Mar 20 22:55: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.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 n2L3teLP216328 for ; Fri, 20 Mar 2009 22:55:56 -0500 X-ASG-Debug-ID: 1237607701-46e900f60000-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 1AE6A1C5C8F1 for ; Fri, 20 Mar 2009 20:55:01 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id vdyabBRXUPvuE6WO for ; Fri, 20 Mar 2009 20:55:01 -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 n2L3srCV016214; Fri, 20 Mar 2009 23:54:53 -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 n2L3soId027250; Fri, 20 Mar 2009 23:54:50 -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 n2L3sqXH025982; Fri, 20 Mar 2009 23:54:53 -0400 Message-ID: <49C4650B.4040509@sandeen.net> Date: Fri, 20 Mar 2009 22:54:51 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/5] xfs: kill ino64 mount option Subject: Re: [PATCH 3/5] xfs: kill ino64 mount option References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> In-Reply-To: <20090318094132.076764000@bombadil.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: 1237607722 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.20875 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: > The ino64 mount option adds a fixed offset to 32bit inode numbers > to bring them into the 64bit range. There's no need for this kind > of debug tool given that it's easy to produce real 64bit inode numbers > for testing. hm, easy how? Change seems fien though. Reviewed-by: Eric Sandeen From sandeen@sandeen.net Fri Mar 20 22:58: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 n2L3w6wE216548 for ; Fri, 20 Mar 2009 22:58:26 -0500 X-ASG-Debug-ID: 1237607866-77ab03a60000-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 1975A1C5C90A for ; Fri, 20 Mar 2009 20:57:46 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id B2iTWq5p0ep1SXTs for ; Fri, 20 Mar 2009 20:57:46 -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 n2L3vYdY016756; Fri, 20 Mar 2009 23:57: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 n2L3vVXR027814; Fri, 20 Mar 2009 23:57:31 -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 n2L3vXab027700; Fri, 20 Mar 2009 23:57:34 -0400 Message-ID: <49C465AC.3010809@sandeen.net> Date: Fri, 20 Mar 2009 22:57:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/5] xfs: remove m_litino Subject: Re: [PATCH 4/5] xfs: remove m_litino References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.224487000@bombadil.infradead.org> In-Reply-To: <20090318094132.224487000@bombadil.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: 1237607867 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.20875 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: > With the upcoming v3 inodes the inode data/attr area size needs to be > calculated for each specific inode, so we can't cache it in the superblock > anymore. hm, ok, but why do this now? -Eric From sandeen@sandeen.net Fri Mar 20 23:12: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=AWL,BAYES_00,J_CHICKENPOX_61, J_CHICKENPOX_71,J_CHICKENPOX_72 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 n2L4CJGj217213 for ; Fri, 20 Mar 2009 23:12:39 -0500 X-ASG-Debug-ID: 1237608719-046c01860000-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 028D31B3AA2 for ; Fri, 20 Mar 2009 21:11:59 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id l2YT6raZXgEIuF4p for ; Fri, 20 Mar 2009 21:11:59 -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 n2L4BqNS019265; Sat, 21 Mar 2009 00:11:52 -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 n2L4BmjJ029934; Sat, 21 Mar 2009 00:11:49 -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 n2L4Bptt030848; Sat, 21 Mar 2009 00:11:51 -0400 Message-ID: <49C46905.9050207@sandeen.net> Date: Fri, 20 Mar 2009 23:11:49 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: a couple of fixes for external logs Subject: Re: [PATCH] xfstests: a couple of fixes for external logs References: <20090224131847.GB1579@infradead.org> In-Reply-To: <20090224131847.GB1579@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: 1237608720 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.20875 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: > Fix a couple of issues when running xfsqa with external logs: > > - update the 096 golden output for the external log case > - add a new _scratch_xfs_check similar to _scratch_xfs_logprint and > _scratch_xfs_repair that take the log device into account and use it > in test 134 > - use _scratch_xfs_repair in test 202 to fix it for external log > devices > > Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen > Index: xfstests-dev/017 > =================================================================== > --- xfstests-dev.orig/017 2009-02-23 21:05:07.000000000 +0000 > +++ xfstests-dev/017 2009-02-23 21:08:46.000000000 +0000 > @@ -67,7 +67,7 @@ > echo "" >>$seq.full > echo "*** XFS_CHECK ***" >>$seq.full > echo "" >>$seq.full > - xfs_check $checkopts $SCRATCH_DEV >>$seq.full 2>&1 \ > + _scratch_xfs_check $checkopts >>$seq.full 2>&1 \ > || _fail "xfs_check $checkopts failed" > _scratch_mount -o remount,rw \ > || _fail "remount rw failed" > Index: xfstests-dev/common.rc > =================================================================== > --- xfstests-dev.orig/common.rc 2009-02-23 21:05:07.000000000 +0000 > +++ xfstests-dev/common.rc 2009-02-24 00:09:39.000000000 +0000 > @@ -268,6 +268,14 @@ > $XFS_LOGPRINT_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV > } > > +_scratch_xfs_check() > +{ > + SCRATCH_OPTIONS="" > + [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \ > + SCRATCH_OPTIONS="-l $SCRATCH_LOGDEV" > + $XFS_CHECK_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV > +} > + > _scratch_xfs_repair() > { > SCRATCH_OPTIONS="" > Index: xfstests-dev/202 > =================================================================== > --- xfstests-dev.orig/202 2009-02-23 21:15:56.000000000 +0000 > +++ xfstests-dev/202 2009-02-23 21:20:12.000000000 +0000 > @@ -20,6 +20,7 @@ > # get standard environment, filters and checks > . ./common.rc > . ./common.filter > +. ./common.repair > > # real QA test starts here > _supported_fs xfs > @@ -31,10 +32,10 @@ > _scratch_mkfs_xfs -d agcount=1 >/dev/null 2>&1 > > echo "== Trying to repair it (should fail) ==" > -xfs_repair $SCRATCH_DEV > +_scratch_xfs_repair > > echo "== Trying to repair it with -o force_geometry ==" > -xfs_repair -o force_geometry $SCRATCH_DEV > +_scratch_xfs_repair -o force_geometry 2>&1 | _filter_repair > > # success, all done > echo "*** done" > Index: xfstests-dev/202.out > =================================================================== > --- xfstests-dev.orig/202.out 2009-02-23 21:18:49.000000000 +0000 > +++ xfstests-dev/202.out 2009-02-23 21:20:46.000000000 +0000 > @@ -6,19 +6,17 @@ > Use the -o force_geometry option to proceed. > == Trying to repair it with -o force_geometry == > Phase 1 - find and verify superblock... > -Phase 2 - using internal log > +Phase 2 - using log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - - agno = 0 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - - agno = 0 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > Index: xfstests-dev/096.external > =================================================================== > --- xfstests-dev.orig/096.external 2009-02-23 21:23:19.000000000 +0000 > +++ xfstests-dev/096.external 2009-02-23 21:24:38.000000000 +0000 > @@ -30,7 +30,7 @@ > > > # test out data stripe > ---- mkfs=-d su=266240,sw=1 --- > +--- mkfs=-l version=1 -d su=266240,sw=1 --- > meta-data=DEV isize=256 agcount=N, agsize=N blks > data = bsize=4096 blocks=N, imaxpct=25 > = sunit=65 swidth=65 blks, unwritten=1 > @@ -41,7 +41,7 @@ > > > # test out data stripe the same but using sunit & swidth > ---- mkfs=-d sunit=520,swidth=520 --- > +--- mkfs=-l version=1 -d sunit=520,swidth=520 --- > meta-data=DEV isize=256 agcount=N, agsize=N blks > data = bsize=4096 blocks=N, imaxpct=25 > = sunit=65 swidth=65 blks, unwritten=1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Fri Mar 20 23:17: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.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 n2L4GnqA217716 for ; Fri, 20 Mar 2009 23:17:10 -0500 X-ASG-Debug-ID: 1237608990-46dd01600000-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 1383E1C5CAA7 for ; Fri, 20 Mar 2009 21:16:30 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id uxzrCtcQoDbzqdI2 for ; Fri, 20 Mar 2009 21:16:30 -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 n2L4GNfF019993; Sat, 21 Mar 2009 00:16:23 -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 n2L4GJD8030499; Sat, 21 Mar 2009 00:16:20 -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 n2L4GMIg031273; Sat, 21 Mar 2009 00:16:22 -0400 Message-ID: <49C46A14.8000602@sandeen.net> Date: Fri, 20 Mar 2009 23:16:20 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: 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 References: <20090224132737.GA8161@infradead.org> <20090304173224.GB32471@infradead.org> In-Reply-To: <20090304173224.GB32471@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: 1237608991 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: 0.58 X-Barracuda-Spam-Status: No, SCORE=0.58 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJ_PAREN_NUMS X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20875 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 2.60 SUBJ_PAREN_NUMS Subject has several parenthesized numbers 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 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: Looks fine. Reviewed-by: Eric Sandeen > 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). > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Fri Mar 20 23:17:12 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 n2L4GplD217720 for ; Fri, 20 Mar 2009 23:17:12 -0500 X-ASG-Debug-ID: 1237608991-04a201aa0002-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 C202D1B3AD1 for ; Fri, 20 Mar 2009 21:16:32 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id 4W0T0MMBBg8oFLzS for ; Fri, 20 Mar 2009 21:16:32 -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 n2L3kxIu015336; Fri, 20 Mar 2009 23:47:01 -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 n2L3ku8A025839; Fri, 20 Mar 2009 23:46:56 -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 n2L3ktqj025445; Fri, 20 Mar 2009 23:46:57 -0400 Message-ID: <49C4632D.2050901@sandeen.net> Date: Fri, 20 Mar 2009 22:46:53 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com, Tomasz Majkowski X-ASG-Orig-Subj: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Subject: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation References: <20090320072857.GB26571@infradead.org> In-Reply-To: <20090320072857.GB26571@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: 1237608992 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=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20875 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 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: > Test that we can get all extent/hole information for files with more > than 16 extents and 15 holes which require a reallocation based on > XFS_IOC_FSGETXATTR. > > Based on a testcase from Tomasz Majkowski . > > > Signed-off-by: Christoph Hellwig Looks fine to me (do we need a GPL header on the c file? license on all of xfsqa is hard to sort out, I guess...) -Eric > Index: xfstests-dev/203 > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfstests-dev/203 2009-03-20 07:28:06.000000000 +0000 > @@ -0,0 +1,71 @@ > +#! /bin/sh > +# FS QA Test No. 203 > +# > +# Test out reallocation of the extent array in xfs_io. > +# Based on a testcase from Tomasz Majkowski . > +# > +#----------------------------------------------------------------------- > +# Copyright (c) 2009 Christoph Hellwig. > +#----------------------------------------------------------------------- > +# > +# creator > +owner=hch@lst.de > + > +seq=`basename $0` > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=/tmp/$$ > +status=1 # failure is the default! > + > +_write_holes() > +{ > + file=$1 > + holes=$2 > + let writes=$holes+1 > + > + offset=0 > + for i in `seq 0 $writes`; do > + xfs_io -f $file -c "pwrite -q $offset 1" > + let offset=$offset+0x100000 > + done > +} > + > +# 0: [0..7]: 104..111 > +# 1: [8..2047]: hole > +_filter_bmap() > +{ > + awk '$3 ~ /hole/ { print $1, $2, $3; next } > + {print $1, $2; next}' > +} > + > +_cleanup() > +{ > + rm -f $TEST_DIR/hole_file* > + rm -f $TEST_DIR/r?? > +} > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +# get standard environment, filters and checks > +. ./common.rc > +. ./common.filter > + > +# real QA test starts here > +_supported_fs xfs > +_supported_os Linux > + > + > +for i in 10 14 15 16 17 28 29 30 31; do > + rm -f $TEST_DIR/hole_file > + _write_holes $TEST_DIR/hole_file${i} ${i} > +done > + > +for i in 10 14 15 16 17 28 29 30 31; do > + xfs_bmap $TEST_DIR/hole_file${i} | _filter_bmap > + echo > +done > + > +# success, all done > +echo "*** done" > +rm -f $seq.full > +status=0 > Index: xfstests-dev/203.out > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfstests-dev/203.out 2009-03-20 07:09:51.000000000 +0000 > @@ -0,0 +1,427 @@ > +QA output created by 203 > +/mnt/test/hole_file10: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > + > +/mnt/test/hole_file14: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > + > +/mnt/test/hole_file15: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > + > +/mnt/test/hole_file16: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > + > +/mnt/test/hole_file17: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > +35: [34824..36863]: hole > +36: [36864..36871]: > + > +/mnt/test/hole_file28: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > +35: [34824..36863]: hole > +36: [36864..36871]: > +37: [36872..38911]: hole > +38: [38912..38919]: > +39: [38920..40959]: hole > +40: [40960..40967]: > +41: [40968..43007]: hole > +42: [43008..43015]: > +43: [43016..45055]: hole > +44: [45056..45063]: > +45: [45064..47103]: hole > +46: [47104..47111]: > +47: [47112..49151]: hole > +48: [49152..49159]: > +49: [49160..51199]: hole > +50: [51200..51207]: > +51: [51208..53247]: hole > +52: [53248..53255]: > +53: [53256..55295]: hole > +54: [55296..55303]: > +55: [55304..57343]: hole > +56: [57344..57351]: > +57: [57352..59391]: hole > +58: [59392..59399]: > + > +/mnt/test/hole_file29: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > +35: [34824..36863]: hole > +36: [36864..36871]: > +37: [36872..38911]: hole > +38: [38912..38919]: > +39: [38920..40959]: hole > +40: [40960..40967]: > +41: [40968..43007]: hole > +42: [43008..43015]: > +43: [43016..45055]: hole > +44: [45056..45063]: > +45: [45064..47103]: hole > +46: [47104..47111]: > +47: [47112..49151]: hole > +48: [49152..49159]: > +49: [49160..51199]: hole > +50: [51200..51207]: > +51: [51208..53247]: hole > +52: [53248..53255]: > +53: [53256..55295]: hole > +54: [55296..55303]: > +55: [55304..57343]: hole > +56: [57344..57351]: > +57: [57352..59391]: hole > +58: [59392..59399]: > +59: [59400..61439]: hole > +60: [61440..61447]: > + > +/mnt/test/hole_file30: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > +35: [34824..36863]: hole > +36: [36864..36871]: > +37: [36872..38911]: hole > +38: [38912..38919]: > +39: [38920..40959]: hole > +40: [40960..40967]: > +41: [40968..43007]: hole > +42: [43008..43015]: > +43: [43016..45055]: hole > +44: [45056..45063]: > +45: [45064..47103]: hole > +46: [47104..47111]: > +47: [47112..49151]: hole > +48: [49152..49159]: > +49: [49160..51199]: hole > +50: [51200..51207]: > +51: [51208..53247]: hole > +52: [53248..53255]: > +53: [53256..55295]: hole > +54: [55296..55303]: > +55: [55304..57343]: hole > +56: [57344..57351]: > +57: [57352..59391]: hole > +58: [59392..59399]: > +59: [59400..61439]: hole > +60: [61440..61447]: > +61: [61448..63487]: hole > +62: [63488..63495]: > + > +/mnt/test/hole_file31: > +0: [0..7]: > +1: [8..2047]: hole > +2: [2048..2055]: > +3: [2056..4095]: hole > +4: [4096..4103]: > +5: [4104..6143]: hole > +6: [6144..6151]: > +7: [6152..8191]: hole > +8: [8192..8199]: > +9: [8200..10239]: hole > +10: [10240..10247]: > +11: [10248..12287]: hole > +12: [12288..12295]: > +13: [12296..14335]: hole > +14: [14336..14343]: > +15: [14344..16383]: hole > +16: [16384..16391]: > +17: [16392..18431]: hole > +18: [18432..18439]: > +19: [18440..20479]: hole > +20: [20480..20487]: > +21: [20488..22527]: hole > +22: [22528..22535]: > +23: [22536..24575]: hole > +24: [24576..24583]: > +25: [24584..26623]: hole > +26: [26624..26631]: > +27: [26632..28671]: hole > +28: [28672..28679]: > +29: [28680..30719]: hole > +30: [30720..30727]: > +31: [30728..32767]: hole > +32: [32768..32775]: > +33: [32776..34815]: hole > +34: [34816..34823]: > +35: [34824..36863]: hole > +36: [36864..36871]: > +37: [36872..38911]: hole > +38: [38912..38919]: > +39: [38920..40959]: hole > +40: [40960..40967]: > +41: [40968..43007]: hole > +42: [43008..43015]: > +43: [43016..45055]: hole > +44: [45056..45063]: > +45: [45064..47103]: hole > +46: [47104..47111]: > +47: [47112..49151]: hole > +48: [49152..49159]: > +49: [49160..51199]: hole > +50: [51200..51207]: > +51: [51208..53247]: hole > +52: [53248..53255]: > +53: [53256..55295]: hole > +54: [55296..55303]: > +55: [55304..57343]: hole > +56: [57344..57351]: > +57: [57352..59391]: hole > +58: [59392..59399]: > +59: [59400..61439]: hole > +60: [61440..61447]: > +61: [61448..63487]: hole > +62: [63488..63495]: > +63: [63496..65535]: hole > +64: [65536..65543]: > + > +*** done > Index: xfstests-dev/group > =================================================================== > --- xfstests-dev.orig/group 2009-03-20 06:56:23.000000000 +0000 > +++ xfstests-dev/group 2009-03-20 06:57:06.000000000 +0000 > @@ -307,3 +307,4 @@ > 200 mount auto quick > 201 metadata auto quick > 202 repair auto quick > +203 ioctl auto > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Fri Mar 20 23:17:11 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_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 n2L4Gpfe217719 for ; Fri, 20 Mar 2009 23:17:11 -0500 X-ASG-Debug-ID: 1237608991-04a201aa0000-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 2C4C51B3ACB for ; Fri, 20 Mar 2009 21:16:31 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id vyL2hiKdkUWmozzE for ; Fri, 20 Mar 2009 21:16:31 -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 n2L42OLD017567; Sat, 21 Mar 2009 00:02:24 -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 n2L42LxL028615; Sat, 21 Mar 2009 00:02:21 -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 n2L42N2A029981; Sat, 21 Mar 2009 00:02:24 -0400 Message-ID: <49C466CE.3000609@sandeen.net> Date: Fri, 20 Mar 2009 23:02:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfsdump: make sure Makpekgs is complete Subject: Re: [PATCH] xfsdump: make sure Makpekgs is complete References: <20090224183819.GA25706@infradead.org> In-Reply-To: <20090224183819.GA25706@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: 1237608992 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.20875 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: > Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen > Index: xfsdump-dev/doc/Makefile > =================================================================== > --- xfsdump-dev.orig/doc/Makefile 2009-02-24 19:31:07.048152638 +0100 > +++ xfsdump-dev/doc/Makefile 2009-02-24 19:31:34.859030054 +0100 > @@ -7,13 +7,8 @@ include $(TOPDIR)/include/builddefs > > README = README.xfsdump > LSRCFILES = INSTALL PORTING CHANGES COPYING $(README) \ > - directories.gif directories.obj \ > - files.gif files.obj \ > - global_hdr.gif global_hdr.obj \ > - inode_map.gif inode_map.obj \ > - media_files.gif media_files.obj \ > - split_algorithm.gif split_algorithm.obj \ > - xfsdump.html xfsdump_ts.txt > + xfsdump.html xfsdump_ts.txt \ > + *.obj *.gif > > LDIRT = *.gz > > Index: xfsdump-dev/include/Makefile > =================================================================== > --- xfsdump-dev.orig/include/Makefile 2009-02-24 19:31:49.244027259 +0100 > +++ xfsdump-dev/include/Makefile 2009-02-24 19:37:18.132152625 +0100 > @@ -5,7 +5,7 @@ > TOPDIR = .. > include $(TOPDIR)/include/builddefs > > -HFILES = swap.h > +HFILES = swab.h swap.h > LSRCFILES = builddefs.in buildmacros buildrules config.h.in > > default install install-dev : > Index: xfsdump-dev/inventory/Makefile > =================================================================== > --- xfsdump-dev.orig/inventory/Makefile 2009-02-24 19:32:17.497028005 +0100 > +++ xfsdump-dev/inventory/Makefile 2009-02-24 19:34:01.969057100 +0100 > @@ -7,7 +7,7 @@ include $(TOPDIR)/include/builddefs > > LSRCFILES = inv_api.c inv_core.c inv_fstab.c inv_idx.c inv_mgr.c \ > inv_oref.c inv_oref.h inv_priv.h inv_stobj.c inv_files.c \ > - inventory.h > + inventory.h getopt.h testmain.c > > default install install-dev: > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From SRS0+003e39f7270a0557756a+2036+infradead.org+hch@bombadil.srs.infradead.org Sat Mar 21 15:03:50 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 n2LK3STH011232 for ; Sat, 21 Mar 2009 15:03:50 -0500 X-ASG-Debug-ID: 1237665771-4718021a0000-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 4C16E1B4F7E for ; Sat, 21 Mar 2009 13:02:51 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id EjfnhKeBkBH1susF for ; Sat, 21 Mar 2009 13:02:51 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Ll7OZ-0003EF-JY; Sat, 21 Mar 2009 20:02:15 +0000 Date: Sat, 21 Mar 2009 16:02:15 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , Tomasz Majkowski , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Subject: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Message-ID: <20090321200215.GA8568@infradead.org> References: <20090320072857.GB26571@infradead.org> <49C4632D.2050901@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C4632D.2050901@sandeen.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: 1237665790 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, Mar 20, 2009 at 10:46:53PM -0500, Eric Sandeen wrote: > Christoph Hellwig wrote: > > Test that we can get all extent/hole information for files with more > > than 16 extents and 15 holes which require a reallocation based on > > XFS_IOC_FSGETXATTR. > > > > Based on a testcase from Tomasz Majkowski . > > > > > > Signed-off-by: Christoph Hellwig > > Looks fine to me (do we need a GPL header on the c file? license on all > of xfsqa is hard to sort out, I guess...) There's no c file. From SRS0+003e39f7270a0557756a+2036+infradead.org+hch@bombadil.srs.infradead.org Sat Mar 21 15:08:45 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 n2LK8OxY011514 for ; Sat, 21 Mar 2009 15:08:45 -0500 X-ASG-Debug-ID: 1237666086-5a1a011d0000-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 ED6631B4AD2 for ; Sat, 21 Mar 2009 13:08:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id P4QdTcW8d99wscD7 for ; Sat, 21 Mar 2009 13:08:06 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Ll7UE-0005tN-Fj; Sat, 21 Mar 2009 20:08:06 +0000 Date: Sat, 21 Mar 2009 16:08:06 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/5] xfs: kill ino64 mount option Subject: Re: [PATCH 3/5] xfs: kill ino64 mount option Message-ID: <20090321200806.GA15245@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> <49C4650B.4040509@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C4650B.4040509@sandeen.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: 1237666086 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, Mar 20, 2009 at 10:54:51PM -0500, Eric Sandeen wrote: > Christoph Hellwig wrote: > > > The ino64 mount option adds a fixed offset to 32bit inode numbers > > to bring them into the 64bit range. There's no need for this kind > > of debug tool given that it's easy to produce real 64bit inode numbers > > for testing. > > hm, easy how? Actually test with a large enough device and let them spread evenly over the AGs. From SRS0+003e39f7270a0557756a+2036+infradead.org+hch@bombadil.srs.infradead.org Sat Mar 21 15:09:53 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 n2LK9WQF011615 for ; Sat, 21 Mar 2009 15:09:53 -0500 X-ASG-Debug-ID: 1237666154-4459028e0000-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 CE9A11B4F88 for ; Sat, 21 Mar 2009 13:09:14 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id YCO1ybRfPC73aNBY for ; Sat, 21 Mar 2009 13:09:14 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Ll7VK-0001Qw-FZ; Sat, 21 Mar 2009 20:09:14 +0000 Date: Sat, 21 Mar 2009 16:09:14 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/5] xfs: remove m_litino Subject: Re: [PATCH 4/5] xfs: remove m_litino Message-ID: <20090321200914.GB15245@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.224487000@bombadil.infradead.org> <49C465AC.3010809@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C465AC.3010809@sandeen.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: 1237666154 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, Mar 20, 2009 at 10:57:32PM -0500, Eric Sandeen wrote: > Christoph Hellwig wrote: > > > With the upcoming v3 inodes the inode data/attr area size needs to be > > calculated for each specific inode, so we can't cache it in the superblock > > anymore. > > hm, ok, but why do this now? It could be considered a cleanup as there's no point in caching a constant expression in the superblock. More importantly I want to get as many of the CRC preparation patches upstream so that I don't have to keep rebasing them. From sandeen@sandeen.net Sat Mar 21 17:13: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2LMD5iA018599 for ; Sat, 21 Mar 2009 17:13:25 -0500 X-ASG-Debug-ID: 1237673545-2ec700f70000-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 276701B50EC for ; Sat, 21 Mar 2009 15:12:25 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id PTaAfXFge1vrdKQq for ; Sat, 21 Mar 2009 15:12:25 -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 n2LMCFvP011413; Sat, 21 Mar 2009 18:12:15 -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 n2LMCBmu007530; Sat, 21 Mar 2009 18:12:11 -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 n2LMCBVf000892; Sat, 21 Mar 2009 18:12:14 -0400 Message-ID: <49C5663A.7010403@sandeen.net> Date: Sat, 21 Mar 2009 17:12:10 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: Tomasz Majkowski , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation Subject: Re: [PATCH] xfstests: add test 203, xfs_io bmap reallocation References: <20090320072857.GB26571@infradead.org> <49C4632D.2050901@sandeen.net> <20090321200215.GA8568@infradead.org> In-Reply-To: <20090321200215.GA8568@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: 1237673567 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=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.20947 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 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, Mar 20, 2009 at 10:46:53PM -0500, Eric Sandeen wrote: >> Christoph Hellwig wrote: >>> Test that we can get all extent/hole information for files with more >>> than 16 extents and 15 holes which require a reallocation based on >>> XFS_IOC_FSGETXATTR. >>> >>> Based on a testcase from Tomasz Majkowski . >>> >>> >>> Signed-off-by: Christoph Hellwig >> Looks fine to me (do we need a GPL header on the c file? license on all >> of xfsqa is hard to sort out, I guess...) > > There's no c file. Oh, heh. I had Tomasz's original testcase in mind, sorry! :) -Eric From sandeen@sandeen.net Sat Mar 21 17:13: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=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 n2LMDLXR018616 for ; Sat, 21 Mar 2009 17:13:38 -0500 X-ASG-Debug-ID: 1237673562-13c0038e0000-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 B9F3D1C5E751 for ; Sat, 21 Mar 2009 15:12:42 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id HlHQebxiUSLAirWn for ; Sat, 21 Mar 2009 15:12: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 n2LMCYaJ011457; Sat, 21 Mar 2009 18:12: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 n2LMCVgH007543; Sat, 21 Mar 2009 18:12:31 -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 n2LMCXhQ000905; Sat, 21 Mar 2009 18:12:34 -0400 Message-ID: <49C56650.10008@sandeen.net> Date: Sat, 21 Mar 2009 17:12:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/5] xfs: kill ino64 mount option Subject: Re: [PATCH 3/5] xfs: kill ino64 mount option References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> <49C4650B.4040509@sandeen.net> <20090321200806.GA15245@infradead.org> In-Reply-To: <20090321200806.GA15245@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: 1237673583 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.20947 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, Mar 20, 2009 at 10:54:51PM -0500, Eric Sandeen wrote: >> Christoph Hellwig wrote: >> >>> The ino64 mount option adds a fixed offset to 32bit inode numbers >>> to bring them into the 64bit range. There's no need for this kind >>> of debug tool given that it's easy to produce real 64bit inode numbers >>> for testing. >> hm, easy how? > > Actually test with a large enough device and let them spread evenly > over the AGs. It's the large-enough device which sometimes is at odds with "easy" -Eric From richardjuliano14@comcast.net Sun Mar 22 09:50:56 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50,FROM_EXCESS_BASE64 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 n2MEoan4073322 for ; Sun, 22 Mar 2009 09:50:56 -0500 X-ASG-Debug-ID: 1237733417-648903930000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from QMTA02.westchester.pa.mail.comcast.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 370F71B5F70 for ; Sun, 22 Mar 2009 07:50:17 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by cuda.sgi.com with ESMTP id kvQH60cazcySG0ru for ; Sun, 22 Mar 2009 07:50:17 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id WBt31b00117dt5G52EqJXo; Sun, 22 Mar 2009 14:50:18 +0000 Received: from vinny-c7d289ca1 ([76.28.53.209]) by OMTA13.westchester.pa.mail.comcast.net with comcast id WEqJ1b00B4WpdSc3ZEqJgR; Sun, 22 Mar 2009 14:50:18 +0000 From: "=?utf-8?B?dmlubnk=?=" To: xfs@oss.sgi.com X-ASG-Orig-Subj: =?utf-8?B?UGFydG5lcnNoaXAgPGNvbXB1dGVycGNyZQ==?= =?utf-8?B?cGFpci5jb20g?= Subject: =?utf-8?B?UGFydG5lcnNoaXAgPGNvbXB1dGVycGNyZQ==?= =?utf-8?B?cGFpci5jb20g?= Sender: "=?utf-8?B?dmlubnk=?=" Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 22 Mar 2009 10:50:44 -0400 Message-ID: <20090322145044703.052F41A151F84D40@vinny-c7d289ca1> X-Mailer: Web CEO 8.0.0.3785 X-Barracuda-Connect: qmta02.westchester.pa.mail.comcast.net[76.96.62.24] X-Barracuda-Start-Time: 1237733418 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4796 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.06 X-Barracuda-Spam-Status: No, SCORE=1.06 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=FROM_EXCESS_BASE64, FROM_EXCESS_BASE64_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21015 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily 1.05 FROM_EXCESS_BASE64_2 From: base64 encoded unnecessarily X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean SSBhbSBpbnRlcmVzdGVkIGluIGhlbHBpbmcgb3RoZXIgdGhhdCBjYW4gaGVscCBtaHR0cDovL3d3 dy5jb21wdXRlcnBjcmVwYWlyLmNvbS9lIGkgZG8gd2ViIGhvc3Rpbmcgd2ViIGRlc2lnbiBuZXR3 b3JraW5nIGN1c3RvbWJ1aWx0IG1pY3Jvc29mdCBhY2Nlc3MgZGF0YS5odHRwOi8vd3d3LmNvbXB1 dGVycGNyZXBhaXIuY29tLyANCg== From sandeen@sandeen.net Sun Mar 22 15:47:32 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 (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2MKlBK6093753 for ; Sun, 22 Mar 2009 15:47:32 -0500 X-ASG-Debug-ID: 1237754793-757f004c0000-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 A08EA13BC411 for ; Sun, 22 Mar 2009 13:46:33 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id 1P6DD3ncvMyFDAbr for ; Sun, 22 Mar 2009 13:46:33 -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 n2MJMCXl022660; Sun, 22 Mar 2009 15:22:12 -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 n2MJM6VJ006630; Sun, 22 Mar 2009 15:22:07 -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 n2MJM9eh006620; Sun, 22 Mar 2009 15:22:10 -0400 Message-ID: <49C68FE0.4030501@sandeen.net> Date: Sun, 22 Mar 2009 14:22:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: tarballs generated by Makepkgs Subject: Re: tarballs generated by Makepkgs References: <20090215202125.GA18218@infradead.org> <20090224184252.GA28007@infradead.org> In-Reply-To: <20090224184252.GA28007@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: 1237754814 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.21038 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 Sun, Feb 15, 2009 at 03:21:25PM -0500, Christoph Hellwig wrote: >> currently Makepkgs generats the source tarball as >> package-version.src.tar.gz, which is not what we used for recent >> releases and not what most other open source packages do. I'd like to >> change it to package-version.tar.gz, but that currently collides with >> the binary tar packages. >> >> Does anyone still need those binary tar packages? If yes we should >> rename them, too or otherwise just remove them. > > This would be the easiest way, renaming the binary packages to > xfsprogs-$ver.bin.tar.gz and the source to the expected > xfsprogs-$ver.tar.gz. Same patch would also go into xfsdump and dmapi. > Yes, this looks good. it always bugged me the way it was ;) Missed this for review based on no [PATCH] ;) Reviewed-by: Eric Sandeen (same for the other packages as well) > Index: xfsprogs-dev/build/Makefile > =================================================================== > --- xfsprogs-dev.orig/build/Makefile 2009-02-24 19:39:37.259153164 +0100 > +++ xfsprogs-dev/build/Makefile 2009-02-24 19:39:58.817035065 +0100 > @@ -6,7 +6,7 @@ TOPDIR = .. > include $(TOPDIR)/include/builddefs > > MANIFEST=src-manifest > -SRCTAR=$(PKG_NAME)-$(PKG_VERSION).src.tar.gz > +SRCTAR=$(PKG_NAME)-$(PKG_VERSION).tar.gz > > LDIRT = *-manifest *.gz $(TOPDIR)/$(PKG_NAME)-* > > Index: xfsprogs-dev/build/tar/Makefile > =================================================================== > --- xfsprogs-dev.orig/build/tar/Makefile 2009-02-24 19:40:08.459152818 +0100 > +++ xfsprogs-dev/build/tar/Makefile 2009-02-24 19:40:13.721029934 +0100 > @@ -5,7 +5,7 @@ > TOPDIR = ../.. > include $(TOPDIR)/include/builddefs > > -BINTAR=$(PKG_NAME)-$(PKG_VERSION).tar.gz > +BINTAR=$(PKG_NAME)-$(PKG_VERSION).bin.tar.gz > LDIRT = *.gz > > default install install-dev install-lib: > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From SEMA-CR-1-41LOAG@ptcmarketing.com Mon Mar 23 02:41:35 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_50,HTML_MESSAGE, MIME_8BIT_HEADER 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 n2N7fE5i134039 for ; Mon, 23 Mar 2009 02:41:35 -0500 X-ASG-Debug-ID: 1237794056-48ab002d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 762001B7956 for ; Mon, 23 Mar 2009 00:40:57 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id HTp9VAQBpzGAF4sT for ; Mon, 23 Mar 2009 00:40:57 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,407,1233550800"; d="scan'208,217";a="293204388" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 23 Mar 2009 03:23:12 -0400 Date: Mon, 23 Mar 2009 03:18:20 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: New Enhancements in Pro/ENGINEER Wildfire =?utf-8?q?4.0=E2=80=94Attend?= Live Webcast to Learn More Subject: New Enhancements in Pro/ENGINEER Wildfire =?utf-8?q?4.0=E2=80=94Attend?= Live Webcast to Learn More Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1237790990820_277459220 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1237794057 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 --BF_1237790990820_277459220 Content-Type: text/plain; charset=UTF-8 PRODUCT ANNOUNCEMENT Pro/ENGINEER Wildfire 4.0 dramatically reduces hours, hurdles and processing time - see for yourself. What is it about the latest release of Pro/ENGINEER that makes it worthwhile to upgrade? Here is how one of our customers improved their productivity with Pro/ENGINEER Wildfire 4.0. "Importing a complex design that used to take over 3 hours to complete now only takes 13 minutes in Pro/ENGINEER Wildfire4.0!"- Daktronics The breadth of productivity improvements is enough to entice many current customers like you to upgrade. Factor in the inclusion of CAE Lite, CAM Lite, and Manikin Lite at no extra charge, and the reasons not to upgrade quickly fall by the wayside. Pro/ENGINEER Wildfire 4.0 Highlights * 20 times faster design with Auto Round * Clean up models in just 10% of the time with Remove Surface Feature * Reduce retrieval times by up to 50% and memory usage reduction of up to 60% with on-demand loading of full model data Attend the "What's New in Pro/ENGINEER" live webcast and Q&A session led by Mike Campbell, Senior Vice President Pro/ENGINEER Product Management. When: Wednesday, March 25th, 2009 Time: 2:00 - 3:00 p.m. ET How to register: http://www.ptc.com/go/proengineer/webcast (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDO&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) The productivity enhancements added to Pro/ENGINEER Wildfire 4.0 are best explained by example. Experience them first-hand in our "What's New in Pro/ENGINEER" webcast. (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDO&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) Simply click here to register. (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XLSDO&o=1-3ZCY9R&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fgo%2Fproengineer%2Fwebcast) ------------------------------------------------------------------------------- "Not an active Maintenance Support customer? Please contact us so you can access the preproduction release and take advantage of all or the Maintenance Support benefits." (http://www.ptc.com/read?&u=&c=&o=&w=&t=http%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D35338) =========================================================================== contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3ZCY9R&campd=1-3XLSDO&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3ZCY9R&campd=1-3XLSDO&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com edit profile http://www.ptc.com/read?&w=2354034&t=/common/account/index.htm ------------------------------------------------------------------------------- This email was sent to: xfs@oss.sgi.com PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com. --BF_1237790990820_277459220 Content-Type: text/html; charset=UTF-8 Receive CAE/CAM/Manikin Lite with Pro/ENGINEER Wildfire 4.0 M070
PTC.com

Product Announcement

Pro/ENGINEER Wildfire 4.0 dramatically reduces hours, hurdles and processing time - see for yourself.

What is it about the latest release of Pro/ENGINEER that makes it worthwhile to upgrade? Here is how one of our customers improved their productivity with Pro/ENGINEER Wildfire 4.0.

 "Importing a complex design that used to take over 3 hours to complete now only takes 13 minutes in Pro/ENGINEER Wildfire 4.0!" - Daktronics

The breadth of productivity improvements is enough to entice many current customers like you to upgrade. Factor in the inclusion of CAE Lite, CAM Lite, and Manikin Lite at no extra charge, and the reasons not to upgrade quickly fall by the wayside.

Pro/ENGINEER Wildfire 4.0 Highlights

  • 20 times faster design with Auto Round
  • Clean up models in just 10% of the time with Remove Surface Feature
  • Reduce retrieval times by up to 50% and memory usage reduction of up to 60% with on-demand loading of full model data

Attend the "What's New in Pro/ENGINEER" live webcast and Q&A session led by Mike Campbell, Senior Vice President Pro/ENGINEER Product Management.

When:   Wednesday, March 25th, 2009
Time:   2:00 - 3:00 p.m. ET
How to register:   http://www.ptc.com/go/proengineer/webcast

The productivity enhancements added to Pro/ENGINEER Wildfire 4.0 are best explained by example. Experience them first-hand in our "What's New in Pro/ENGINEER" webcast.

Simply click here to register.

"Not an active Maintenance Support customer?  Please contact us so you can access the preproduction release and take advantage of all or the Maintenance Support benefits."

contact PTC | privacy policy | unsubscribe | change preferences | edit profile
This email was sent to: xfs@oss.sgi.com     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com.
--BF_1237790990820_277459220-- From SEMA-CR-1-41NSPG@ptcmarketing.com Mon Mar 23 03:01:48 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2N81RtM135134 for ; Mon, 23 Mar 2009 03:01:47 -0500 X-ASG-Debug-ID: 1237795251-337501330000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8489613BD4DC for ; Mon, 23 Mar 2009 01:00:51 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id Ucz9U9QTHePZkV4R for ; Mon, 23 Mar 2009 01:00:51 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,407,1233550800"; d="scan'208,217";a="293240743" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 23 Mar 2009 03:37:09 -0400 Date: Mon, 23 Mar 2009 03:33:44 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: Tolerance Analysis: Preparing Your Model for the Real World Subject: Tolerance Analysis: Preparing Your Model for the Real World Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1237791571769_387872467 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1237795273 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 --BF_1237791571769_387872467 Content-Type: text/plain; charset=UTF-8 See instantly how multiple tolerances can affect your manufactured product. View Tolerance Analysis Feature Article Now (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3TC54M&o=1-3YNBE1&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D88588) In the imaginative world of 3D design, you can create flawless models that represent the ideal version of the product your customer wants to build. But in the real world of Manufacturing, plastics will shrink, cutters will lose their edge, and parts won't fit perfectly. It's called manufacturing process variation-or variational behavior-and it's sometimes very difficult to predict. That's where tolerance analysis software comes in. With today's powerful tolerance analysis tools-now fully integrated with your 3D CAD software-you can see graphically, and in near real-time, how changes in tolerances will affect the manufactured product. The result: you can perform multiple what-if scenarios, and predict how the model will be affected by manufacturing variations, so you can set the tolerances accordingly-and get better products out the door faster. Read Feature Article on Tolerance Analysis (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3TC54M&o=1-3YNBE1&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D88588) Learn why tolerance analysis software is now being adopted by organizations of all sizes, and how it can benefit multiple areas of your organization, from concept modeling, to functional assembly modeling, to detailed part modeling and beyond. =========================================================================== contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3YNBE1&campd=1-3TC54M&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-3YNBE1&campd=1-3TC54M&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com edit profile http://www.ptc.com/read?&w=2354034&t=/common/account/index.htm ------------------------------------------------------------------------------- This email was sent to: xfs@oss.sgi.com PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com. --BF_1237791571769_387872467 Content-Type: text/html; charset=UTF-8 Email ProE Module Tolerence Analysis WP NA FY09
PTC.com
FREE DOWNLOAD

See instantly how multiple tolerances can affect your manufactured product. View Tolerance Analysis Feature Article Now

In the imaginative world of 3D design, you can create flawless models that represent the ideal version of the product your customer wants to build.

But in the real world of Manufacturing, plastics will shrink, cutters will lose their edge, and parts won't fit perfectly. It's called manufacturing process variation-or variational behavior-and it's sometimes very difficult to predict.

That's where tolerance analysis software comes in.

With today's powerful tolerance analysis tools-now fully integrated with your 3D CAD software-you can see graphically, and in near real-time, how changes in tolerances will affect the manufactured product. The result: you can perform multiple what-if scenarios, and predict how the model will be affected by manufacturing variations, so you can set the tolerances accordingly-and get better products out the door faster.

Read Feature Article on Tolerance Analysis

Learn why tolerance analysis software is now being adopted by organizations of all sizes, and how it can benefit multiple areas of your organization, from concept modeling, to functional assembly modeling, to detailed part modeling and beyond.

contact PTC | privacy policy | unsubscribe | change preferences | edit profile
This email was sent to: xfs@oss.sgi.com     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com.
--BF_1237791571769_387872467-- From raziebe@gmail.com Mon Mar 23 09:00:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, SUSPICIOUS_RECIPS 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 n2NE0RxA159505 for ; Mon, 23 Mar 2009 09:00:47 -0500 X-ASG-Debug-ID: 1237816788-556f02340000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f226.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 04AE71B87AB for ; Mon, 23 Mar 2009 06:59:48 -0700 (PDT) Received: from mail-bw0-f226.google.com (mail-bw0-f226.google.com [209.85.218.226]) by cuda.sgi.com with ESMTP id 5aZZ6QbWonKkSFrp for ; Mon, 23 Mar 2009 06:59:48 -0700 (PDT) Received: by bwz26 with SMTP id 26so1776595bwz.20 for ; Mon, 23 Mar 2009 06:59:47 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=K4TrkfAIOCfZNb7ZGognzrRPydmsChmMM7uczkEwDqk=; b=i5seRfLQHxvzft+liVEQkKTmbPdCRtu9ucZ+Bf/EIi64rc+wav1xwtZF/suJAJGSu4 nINChx/qpa++053aOjN7DA41NBJG5neLsWk9es28HhKvIHl+0x19kgZ31UANgXOqOhC1 yyS+nSIjOlaP3ASIlri8wBx0+efreaJnevN+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=eO5Tx10tkfVf+qHXZV0UMxJJi6qZi49xtcY9vIu0BG18TNA0kJ7b8DhHohJc2sVc4k OIZp+jCDjqkjjtqJ4/BeXMwNawTnaPwIwXCTjP/yM2cirgzMT7k96J9RYpu57MlIui/y uN6ovYSh5mq4i6jtVCnG8ocCtaOjNQSW507Tw= MIME-Version: 1.0 Received: by 10.103.198.20 with SMTP id a20mr3091269muq.29.1237816787331; Mon, 23 Mar 2009 06:59:47 -0700 (PDT) Date: Mon, 23 Mar 2009 15:59:47 +0200 Message-ID: <5d96567b0903230659t734677a3pb4fd77cccb54008b@mail.gmail.com> X-ASG-Orig-Subj: How to configure 36 disks ? Subject: How to configure 36 disks ? From: Raz To: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-bw0-f226.google.com[209.85.218.226] X-Barracuda-Start-Time: 1237816810 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0005 1.0000 -2.0177 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.18 X-Barracuda-Spam-Status: No, SCORE=1.18 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e, SUSPICIOUS_RECIPS X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21106 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 3.20 SUSPICIOUS_RECIPS Similar addresses in recipient list 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello I need to configure 3xDAS'es, each with 12 disks. All three DAS'es are connected to a single machine. I have the following requirements (in this order of importance) from the storage: 1. redundancy. having two disks failing in one raid5 breaks the entire raid. when you have 30TB storage it is a disaster. 2. performance. My code eliminates Linux raid5/6 write penalty. I managed to do by manipulating xfs and patching linux raid5 a bit. 3. modularity ( a "grow" and it will be nice to have "shrink" ) file system and volume must be able to grow. shrinking is possible by unifying multiple file systems under unionfs or aufs. 4. Utilize storage size. I assume each disk is 1TB. Solution #1 raid0 DAS1: raid5: D,D,D,D,D,D | raid5: D,D,D,D,D,D | | DAS2: raid5: D,D,D,D,D,D | xfs raid5: D,D,D,D,D,D | | DAS3: raid5: D,D,D,D,D,D | raid5: D,D,D,D,D,D | 1. redundancy. no. if a single raid fails, 30 TB fails. 2. performance. good. 3. modularity. no. raid0 does not grow. 4. Size. 30TB. Solution #2 raid0 DAS1: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | | DAS2: raid6: D,D,D,D,D,D | xfs. raid6: D,D,D,D,D,D | | DAS3: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | 1. redundancy. fair. less likely three disks will break in a single raid. 2. performance. good. 3. modularity. no. raid0 does not grow. 4. size. 24 TB Solution #3 unionfs/aufs DAS1: raid5: D,D,D,D,D,D xfs | raid5: D,D,D,D,D,D xfs | | DAS2: raid5: D,D,D,D,D,D xfs | raid5: D,D,D,D,D,D xfs | | DAS3: raid5: D,D,D,D,D,D xfs | raid5: D,D,D,D,D,D xfs | 1. redundancy. fair. if a single raid fails, only this raid fails. 2. performance. fair. unionfs is not mainline and does not support write balancing. aufs is not mature enough. 3. modularity. yes. grow and shrinks. 4. Size. 30TB. Solution #4 xfs over Linux LVM DAS1: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | | DAS2: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | | DAS3: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | 1. redundancy. fair. less likely three disks will break in a single raid 2. performance. bad. 3. modularity. yes. grows 4. Size 24TB Any other ideas ? From eflorac@intellique.com Mon Mar 23 09:13:43 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=AWL,BAYES_00,RCVD_IN_BRBL, SUSPICIOUS_RECIPS autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2NEDLGU160157 for ; Mon, 23 Mar 2009 09:13:42 -0500 X-ASG-Debug-ID: 1237817586-6cf801c00000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB50313A6BD2 for ; Mon, 23 Mar 2009 07:13:07 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by cuda.sgi.com with ESMTP id pxYhZTupRDWNp5n2 for ; Mon, 23 Mar 2009 07:13:07 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id A3A3D94012F; Mon, 23 Mar 2009 15:12:56 +0100 (CET) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5AF0794015E; Mon, 23 Mar 2009 15:12:53 +0100 (CET) Date: Mon, 23 Mar 2009 15:12:57 +0100 From: Emmanuel Florac To: Raz Cc: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? Message-ID: <20090323151257.1c7c0a8e@harpe.intellique.com> In-Reply-To: <5d96567b0903230659t734677a3pb4fd77cccb54008b@mail.gmail.com> References: <5d96567b0903230659t734677a3pb4fd77cccb54008b@mail.gmail.com> Organization: Intellique X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp1-g21.free.fr[212.27.42.1] X-Barracuda-Start-Time: 1237817589 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.18 X-Barracuda-Spam-Status: No, SCORE=1.18 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e, SUSPICIOUS_RECIPS X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21108 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 3.20 SUSPICIOUS_RECIPS Similar addresses in recipient list 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Mon, 23 Mar 2009 15:59:47 +0200 Raz =E9crivait: > 1. redundancy. fair. less likely three disks will break in a single > raid 2. performance. bad. > 3. modularity. yes. grows > 4. Size 24TB I don't understand why you'd have a bad performance here. I usually notice a very slight difference between LVM and linux-raid raid0 in all practical benchmarks. Did you use LVM striping capability? You may have to adjust readahead (using blockdev --setra) on each device /dev/dm-X and /dev/md-X) to achieve optimal performance. --=20 ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From davidsen@tmr.com Mon Mar 23 10:36:22 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=AWL,BAYES_00,J_CHICKENPOX_32, SUSPICIOUS_RECIPS autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2NFa1vo166268 for ; Mon, 23 Mar 2009 10:36:22 -0500 X-ASG-Debug-ID: 1237822527-6af300e90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from partygirl.tmr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 991CE13BEEAD for ; Mon, 23 Mar 2009 08:35:27 -0700 (PDT) Received: from partygirl.tmr.com (mail.tmr.com [64.65.253.246]) by cuda.sgi.com with ESMTP id ohkuR7nCDbmT4D2G for ; Mon, 23 Mar 2009 08:35:27 -0700 (PDT) Received: from partygirl.tmr.com (partygirl.tmr.com [127.0.0.1]) by partygirl.tmr.com (8.14.2/8.14.2) with ESMTP id n2NFZ8jC024723; Mon, 23 Mar 2009 11:35:08 -0400 Message-ID: <49C7AC2C.9090307@tmr.com> Date: Mon, 23 Mar 2009 11:35:08 -0400 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081217 Fedora/1.1.14-1.fc9 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Raz CC: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? References: <5d96567b0903230659t734677a3pb4fd77cccb54008b@mail.gmail.com> In-Reply-To: <5d96567b0903230659t734677a3pb4fd77cccb54008b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.tmr.com[64.65.253.246] X-Barracuda-Start-Time: 1237822549 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0152 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.18 X-Barracuda-Spam-Status: No, SCORE=1.18 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUSPICIOUS_RECIPS X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21114 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 3.20 SUSPICIOUS_RECIPS Similar addresses in recipient list X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Raz wrote: > Hello > I need to configure 3xDAS'es, each with 12 disks. > All three DAS'es are connected to a single machine. > I have the following requirements (in this order of importance) > from the storage: > > 1. redundancy. > having two disks failing in one raid5 breaks the entire raid. when > you have 30TB storage > it is a disaster. > > 2. performance. > My code eliminates Linux raid5/6 write penalty. I managed to do by > manipulating xfs and patching linux raid5 a bit. > > 3. modularity ( a "grow" and it will be nice to have "shrink" ) > file system and volume must be able to grow. shrinking is possible > by unifying multiple file systems > under unionfs or aufs. > > 4. Utilize storage size. > > I assume each disk is 1TB. > > ___ snip ___ > Any other ideas ? Yes, you have the whole solution rotated 90 degrees. Consider your original solution #2 below... You have no redundancy if one whole DAS box fails, which is certainly a possible failure mode. If you put the RAID0 horizontally, two arrays size six in each DAS, then RAID6 vertically, if one DAS fails completely you still have a functioning system, and the failure results for individual drives remains about the same, while the rebuild time will be longer. Solution #2 raid0 DAS1: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | | DAS2: raid6: D,D,D,D,D,D | xfs. raid6: D,D,D,D,D,D | | DAS3: raid6: D,D,D,D,D,D | raid6: D,D,D,D,D,D | In addition, you can expand this configuration by adding more DAS units. This addresses several of your goals. In practice, just to get faster rebuild as the array gets larger, I suspect you would find it was worth making the horizontal arrays RAID5 instead of RAID0, just to minimize time to full performance. -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout. From BATV+2d54ac848ded8d4dbde5+2038+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 23 10:59: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.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 n2NFxED1167895 for ; Mon, 23 Mar 2009 10:59:35 -0500 X-ASG-Debug-ID: 1237823937-329302570000-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 621091C62D5C for ; Mon, 23 Mar 2009 08:58:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id iSqnXf58QFzDK9w3 for ; Mon, 23 Mar 2009 08:58:57 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LlmYC-000381-Ar; Mon, 23 Mar 2009 15:58:56 +0000 Date: Mon, 23 Mar 2009 11:58:56 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: tarballs generated by Makepkgs Subject: Re: tarballs generated by Makepkgs Message-ID: <20090323155856.GA6421@infradead.org> References: <20090215202125.GA18218@infradead.org> <20090224184252.GA28007@infradead.org> <49C68FE0.4030501@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C68FE0.4030501@sandeen.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: 1237823937 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 22, 2009 at 02:22:08PM -0500, Eric Sandeen wrote: > Yes, this looks good. it always bugged me the way it was ;) > > Missed this for review based on no [PATCH] ;) > > Reviewed-by: Eric Sandeen > > (same for the other packages as well) Thanks, I've pushed this and the equivalent changes for xfsdump and dmapi out to the kernel.org trees. Now the only outstanding userspace patches for the 3.0.1 releases is the whole autoconf/libtool magic from Andreas. Although we might consider this reviewed enough given that it comes from the acl/attr build system. From jd_hardcastle@yahoo.com Mon Mar 23 11:02: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=BAYES_00,J_CHICKENPOX_32 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2NG2Ytn168261 for ; Mon, 23 Mar 2009 11:02:54 -0500 X-ASG-Debug-ID: 1237824141-6cf103560000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web51309.mail.re2.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 04CA313BF496 for ; Mon, 23 Mar 2009 09:02:21 -0700 (PDT) Received: from web51309.mail.re2.yahoo.com (web51309.mail.re2.yahoo.com [206.190.38.175]) by cuda.sgi.com with SMTP id QXbwc3H28jenuxHF for ; Mon, 23 Mar 2009 09:02:21 -0700 (PDT) Received: (qmail 25023 invoked by uid 60001); 23 Mar 2009 16:02:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237824135; bh=+q71vj39cs2Pugq9i+x8fyy3lE/RntaIth9PmB3h5N0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pJAXC9qYytHJMA9Yl4LApOR0Cxr6ELqvh/GX6eOENG1TvFoXGgw2aGgrScEXdfsh3Ha9ZhqHCNUnrwv9lgQIpfNrKCX2RhKJyoESxYP2uba/WvUWUiqy/tidDn1OiTY/u5rNci32rPE7gHJ7CIEptsny+wlqj6r3sN6DOf0yc7o= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cogw1DhGbIql09bR3/CMm7R8Ao9goMbvtRE7VAvrba1KPLRtmSWCAm4GFjiVeFkcyspDzP4cQ2mzhJPxI8Za5FZvml1AikmHYbZqT4RdcThXQGJjMQZ9pr1a8LrQXXvsBR/rTozjPTpivM6iVzVl9YYoQtQZLxpPKYXz5DcY1qU=; Message-ID: <174852.24274.qm@web51309.mail.re2.yahoo.com> X-YMail-OSG: _wnpLJoVM1kcRPjlRVem8U0_i4gcc6ShUBzsUApl6P._AFh8v0fGKSRl8vjgf.8psMnQ6aQZV5Z88A8nLp6bdcgEhMRuHOKzQqxa7UaEfUdox4jsBsrftZQYAseTYCQY7Sk1Sf7iMK16GA28bC6XjmY04InihLW44BAzmjDsYuN1K5NhJjpKEWlTnN6Zmz6BZVWOBGOID5Nr6PYmwf7FdJM_iKLLLxUJ5UWf3XdB Received: from [193.114.208.194] by web51309.mail.re2.yahoo.com via HTTP; Mon, 23 Mar 2009 09:02:14 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Mon, 23 Mar 2009 09:02:14 -0700 (PDT) From: Jon Hardcastle Reply-To: Jon@eHardcastle.com X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? To: Raz , Bill Davidsen Cc: linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" In-Reply-To: <49C7AC2C.9090307@tmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: web51309.mail.re2.yahoo.com[206.190.38.175] X-Barracuda-Start-Time: 1237824142 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.21114 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'd like to understand how you even go attaching that many devices to a sys= tem.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not en= terprise.. and i have slammed into case/power/sat slot issues already. What= sort of hardware must one use to grow to a 36 array system! ----------------------- N: Jon Hardcastle E: Jon@eHardcastle.com '..Be fearful when others are greedy, and be greedy when others are fearful= .' ----------------------- --- On Mon, 23/3/09, Bill Davidsen wrote: > From: Bill Davidsen > Subject: Re: How to configure 36 disks ? > To: "Raz" > Cc: linux-fsdevel@vger.kernel.org, "Linux RAID Mailing List" , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vg= er.kernel.org" > Date: Monday, 23 March, 2009, 3:35 PM > Raz wrote: > > Hello > > I need to configure 3xDAS'es, each with 12 disks. > > All three DAS'es are connected to a single > machine. > > I have the following requirements (in this order of > importance) > > from the storage: > >=20 > > 1. redundancy. > > having two disks failing in one raid5 breaks the > entire raid. when > > you have 30TB storage > > it is a disaster. > >=20 > > 2. performance. > > My code eliminates Linux raid5/6 write penalty. I > managed to do by > > manipulating xfs and patching linux raid5 a bit. > >=20 > > 3. modularity ( a "grow" and it will be nice > to have "shrink" ) > > file system and volume must be able to grow. > shrinking is possible > > by unifying multiple file systems > > under unionfs or aufs. > >=20 > > 4. Utilize storage size. > >=20 > > I assume each disk is 1TB. > >=20 > > =20 > ___ snip ___ >=20 > > Any other ideas ? >=20 > Yes, you have the whole solution rotated 90 degrees. > Consider your original solution #2 below... You have no > redundancy if one whole DAS box fails, which is certainly a > possible failure mode. If you put the RAID0 horizontally, > two arrays size six in each DAS, then RAID6 vertically, if > one DAS fails completely you still have a functioning > system, and the failure results for individual drives > remains about the same, while the rebuild time will be > longer. >=20 > Solution #2 > =09=09=09 raid0 > DAS1: raid6: D,D,D,D,D,D | > raid6: D,D,D,D,D,D | > =09=09=09 | > DAS2: raid6: D,D,D,D,D,D | xfs. > raid6: D,D,D,D,D,D | > | > DAS3: raid6: D,D,D,D,D,D | > raid6: D,D,D,D,D,D | >=20 >=20 > In addition, you can expand this configuration by adding > more DAS units. This addresses several of your goals. >=20 > In practice, just to get faster rebuild as the array gets > larger, I suspect you would find it was worth making the > horizontal arrays RAID5 instead of RAID0, just to minimize > time to full performance. >=20 > -- bill davidsen > CTO TMR Associates, Inc >=20 > "You are disgraced professional losers. And by the > way, give us our money back." > - Representative Earl Pomeroy, Democrat of North Dakota > on the A.I.G. executives who were paid bonuses after a > federal bailout. >=20 >=20 > -- > To unsubscribe from this list: send the line > "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at=20 > http://vger.kernel.org/majordomo-info.html From liml@rtr.ca Mon Mar 23 11:23: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.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 n2NGMnmR169500 for ; Mon, 23 Mar 2009 11:23:10 -0500 X-ASG-Debug-ID: 1237825330-11c001470000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.rtr.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 075C41C62FAE for ; Mon, 23 Mar 2009 09:22:10 -0700 (PDT) Received: from mail.rtr.ca (rtr.ca [76.10.145.34]) by cuda.sgi.com with ESMTP id fwAZb287VIkYkLdW for ; Mon, 23 Mar 2009 09:22:10 -0700 (PDT) Received: by mail.rtr.ca (Postfix, from userid 1002) id 09EE0E3E05C; Mon, 23 Mar 2009 12:22:09 -0400 (EDT) Received: from [10.0.0.6] (corey.localnet [10.0.0.6]) by mail.rtr.ca (Postfix) with ESMTP id D08859460DF; Mon, 23 Mar 2009 12:22:08 -0400 (EDT) Message-ID: <49C7B730.7030506@rtr.ca> Date: Mon, 23 Mar 2009 12:22:08 -0400 From: Mark Lord Organization: Real-Time Remedies Inc. User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Jon@eHardcastle.com Cc: Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? References: <174852.24274.qm@web51309.mail.re2.yahoo.com> In-Reply-To: <174852.24274.qm@web51309.mail.re2.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rtr.ca[76.10.145.34] X-Barracuda-Start-Time: 1237825352 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.21117 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 Jon Hardcastle wrote: > I'd like to understand how you even go attaching that many devices to a system.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not enterprise.. and i have slammed into case/power/sat slot issues already. What sort of hardware must one use to grow to a 36 array system! .. Here's one way: -- four onboard SATA ports -- plus four add-in PCI/PCIX/PCIe 8-port Marvell SATA cards. -- and a honkin' huge PSU! :) From x@xman.org Mon Mar 23 11:23: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.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 n2NGNgGv169559 for ; Mon, 23 Mar 2009 11:23:58 -0500 X-ASG-Debug-ID: 1237825404-329802d90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postman.lauml.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 363881C62FCA for ; Mon, 23 Mar 2009 09:23:24 -0700 (PDT) Received: from postman.lauml.com (postman.lauml.com [205.134.240.66]) by cuda.sgi.com with ESMTP id aRWSXwGswmKXQgDq for ; Mon, 23 Mar 2009 09:23:24 -0700 (PDT) Received: from [192.168.1.130] (adsl-99-165-23-73.dsl.lsan03.sbcglobal.net [99.165.23.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cbsmith@xman.org) by postman.lauml.com (Postfix) with ESMTPSA id 5604D1858001; Mon, 23 Mar 2009 09:23:22 -0700 (PDT) Message-ID: <49C7B778.7000604@xman.org> Date: Mon, 23 Mar 2009 09:23:20 -0700 From: Christopher Smith User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Jon@eHardcastle.com CC: Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? References: <174852.24274.qm@web51309.mail.re2.yahoo.com> In-Reply-To: <174852.24274.qm@web51309.mail.re2.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: postman.lauml.com[205.134.240.66] X-Barracuda-Start-Time: 1237825405 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.21117 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 Jon Hardcastle wrote: > I'd like to understand how you even go attaching that many devices to a system.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not enterprise.. and i have slammed into case/power/sat slot issues already. What sort of hardware must one use to grow to a 36 array system! You can always use this approach: http://www.youtube.com/watch?v=96dWOEa4Djs --Chris P.S.: Sorry, couldn't resist. From raziebe@gmail.com Mon Mar 23 11:28:48 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2NGSRhh169970 for ; Mon, 23 Mar 2009 11:28:47 -0500 X-ASG-Debug-ID: 1237825694-0ce500f30000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f226.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AC39213BF72A for ; Mon, 23 Mar 2009 09:28:14 -0700 (PDT) Received: from mail-bw0-f226.google.com (mail-bw0-f226.google.com [209.85.218.226]) by cuda.sgi.com with ESMTP id bs03lWLoVoEY6zMI for ; Mon, 23 Mar 2009 09:28:14 -0700 (PDT) Received: by bwz26 with SMTP id 26so1842719bwz.20 for ; Mon, 23 Mar 2009 09:28:08 -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=/436JaNSpYJ/kSAUO+YI9ur5e4C8SbrxJqM1UsMZ6nQ=; b=Lhd2lbT8xutBNue8d93SyndIn9s9RZ1yeu3AR5+PteEg2aV9/Mcho2YD46PvxzucUK IjkE/02Ij+PW4z5RZ8P3h8UhdTUTPXtLyaO8WhK9/xmzlJjBTic5KnytAe5X8F2SIAp6 nNv6TBy6YJ5x7EdzoSk0bHVtoDQFstcTFpdnM= 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=dqqtJ4c9VcDBdV7DvO4QMsSucnY9FNTCXp5D3ygDfgdUNozpjqaYzzBYDUwAAgtOnT bE+vRBq7exsb8q6SIq1+aw+CnP1kychQjje1PG0He8BF/AOXeAqF7kz2fjrTRDoMwwPo /hzzkMP3HRATSXGQRm0+mB+FFC1u2SsCr2ys0= MIME-Version: 1.0 Received: by 10.103.227.13 with SMTP id e13mr3162626mur.20.1237825688062; Mon, 23 Mar 2009 09:28:08 -0700 (PDT) In-Reply-To: <49C7B778.7000604@xman.org> References: <174852.24274.qm@web51309.mail.re2.yahoo.com> <49C7B778.7000604@xman.org> Date: Mon, 23 Mar 2009 18:28:07 +0200 Message-ID: <5d96567b0903230928p794e4140y9263f4095beb5b52@mail.gmail.com> X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? From: Raz To: Christopher Smith Cc: Jon@ehardcastle.com, Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-bw0-f226.google.com[209.85.218.226] X-Barracuda-Start-Time: 1237825695 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.21116 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, Mar 23, 2009 at 6:23 PM, Christopher Smith wrote: > Jon Hardcastle wrote: >> >> I'd like to understand how you even go attaching that many devices to a >> system.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not >> enterprise.. and i have slammed into case/power/sat slot issues already. >> What sort of hardware must one use to grow to a 36 array system! > > You can always use this approach: > > http://www.youtube.com/watch?v=96dWOEa4Djs > > --Chris > > P.S.: Sorry, couldn't resist. > > me too. http://blogs.sun.com/observatory/entry/don_t_shout_at_your From greg.freemyer@gmail.com Mon Mar 23 11:46:02 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 n2NGjfqU170969 for ; Mon, 23 Mar 2009 11:46:02 -0500 X-ASG-Debug-ID: 1237826723-7d1700140000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from qw-out-1920.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1C78D1C63466 for ; Mon, 23 Mar 2009 09:45:23 -0700 (PDT) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by cuda.sgi.com with ESMTP id yl1lVcxBCkgRYSH1 for ; Mon, 23 Mar 2009 09:45:23 -0700 (PDT) Received: by qw-out-1920.google.com with SMTP id 9so1119514qwj.32 for ; Mon, 23 Mar 2009 09:45:23 -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=dk5oyG/SDECqp/aZD6IuO+1SGcIDar4ksHyiiDw9YgU=; b=ajuppUzWAJToc+uGORe3g1AgfrbXz7ufAUv5Nhl070XsH7hzHvSQLeBNrSKqa/Iu2T SBofeYMBxEXCkVj3gZrmg8/e9MBmuLZmDrkzHetvjJ4666yBTvdydsFKdepIexB1mG+N 5XssoPfLws/LnH7tTNVy6axnG7S8cmsHdVDuE= 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=Ncu5nHdH2GNLB/0UIZ7kdSr8yy19cL4l9sDGIPASNj93frP1d1NmAsYDVhmx6/iu93 1PP+5rXaW1embDvmnF8oTc7bt0UblOYtLsCjbc7TnBGvF8TL2eOQwd9N9gZJ3UoUdQmV +AwFR9eKVie+uf1KyZ4TTD4cEyz/zCpQNtOSk= MIME-Version: 1.0 Received: by 10.224.45.66 with SMTP id d2mr7922250qaf.158.1237826723131; Mon, 23 Mar 2009 09:45:23 -0700 (PDT) In-Reply-To: <174852.24274.qm@web51309.mail.re2.yahoo.com> References: <49C7AC2C.9090307@tmr.com> <174852.24274.qm@web51309.mail.re2.yahoo.com> Date: Mon, 23 Mar 2009 12:45:23 -0400 Message-ID: <87f94c370903230945k66a804a0iefbb76dd9c93fc16@mail.gmail.com> X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? From: Greg Freemyer To: Jon@ehardcastle.com Cc: Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: qw-out-1920.google.com[74.125.92.146] X-Barracuda-Start-Time: 1237826724 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.21117 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, Mar 23, 2009 at 12:02 PM, Jon Hardcastle wrote: > > I'd like to understand how you even go attaching that many devices to a s= ystem.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not = enterprise.. and i have slammed into case/power/sat slot issues already. Wh= at sort of hardware must one use to grow to a 36 array system! For the drives you could get a few big enclosures: http://www.pc-pitstop.com/sata_enclosures/sat122urd.asp http://www.pc-pitstop.com/sata_enclosures/scsas16rm.asp I don't think these offer PMP (port multiplexer) support. I would look for ones that did if you're serious about doing something like this. If you used PMP with 4x drives per sata port, you would only need 9 sata ports in the PC to control the 36 drives. Not sure what the limits of PMP is, but 4x seems reasonable to me. Greg --=20 Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com From swmike@swm.pp.se Mon Mar 23 13:33:31 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,DRUGS_PAIN autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2NIX9K3177619 for ; Mon, 23 Mar 2009 13:33:31 -0500 X-ASG-Debug-ID: 1237833156-3dd9008d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from uplift.swm.pp.se (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E7B8D13C02E1 for ; Mon, 23 Mar 2009 11:32:36 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by cuda.sgi.com with ESMTP id NKoFNBXdxeYuyU61 for ; Mon, 23 Mar 2009 11:32:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D3B729C; Mon, 23 Mar 2009 19:32:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D1B5C9A; Mon, 23 Mar 2009 19:32:28 +0100 (CET) Date: Mon, 23 Mar 2009 19:32:28 +0100 (CET) From: Mikael Abrahamsson To: Greg Freemyer cc: Jon@ehardcastle.com, Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? In-Reply-To: <87f94c370903230945k66a804a0iefbb76dd9c93fc16@mail.gmail.com> Message-ID: References: <49C7AC2C.9090307@tmr.com> <174852.24274.qm@web51309.mail.re2.yahoo.com> <87f94c370903230945k66a804a0iefbb76dd9c93fc16@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: swm.pp.se[212.247.200.143] X-Barracuda-Start-Time: 1237833177 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=DRUGS_PAIN X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21124 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DRUGS_PAIN Refers to a pain relief drug X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 23 Mar 2009, Greg Freemyer wrote: > http://www.pc-pitstop.com/sata_enclosures/sat122urd.asp > http://www.pc-pitstop.com/sata_enclosures/scsas16rm.asp I would like to add this if you're on a budget: > sata ports in the PC to control the 36 drives. Not sure what the limits > of PMP is, but 4x seems reasonable to me. The PMPs I've seen take 5 drives each: -- Mikael Abrahamsson email: swmike@swm.pp.se From felixb@oss.sgi.com Tue Mar 24 14:50:04 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,AWL,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 n2OJnxwB037685 for ; Tue, 24 Mar 2009 14:50:04 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2OJnxtj037621; Tue, 24 Mar 2009 14:49:59 -0500 Date: Tue, 24 Mar 2009 14:49:59 -0500 Message-Id: <200903241949.n2OJnxtj037621@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-14198-g8e0ee43 X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 5bee17f18b595937e6beafeee5197868a3f74a06 X-Git-Newrev: 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 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 5bee17f18b595937e6beafeee5197868a3f74a06 (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 Tue Mar 24 14:50:14 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,AWL,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 n2OJo9Pp037754 for ; Tue, 24 Mar 2009 14:50:14 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2OJo9oE037703; Tue, 24 Mar 2009 14:50:09 -0500 Date: Tue, 24 Mar 2009 14:50:09 -0500 Message-Id: <200903241950.n2OJo9oE037703@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-14271-g61454f3 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 4740cd8b4f27d6ac11e76c432d5d03fb780b2596 X-Git-Newrev: 61454f33389ecfac68846e07d29c8d18af342c43 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 4740cd8b4f27d6ac11e76c432d5d03fb780b2596 (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 Tue Mar 24 14:50:39 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,AWL,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 n2OJoYYb037862 for ; Tue, 24 Mar 2009 14:50:39 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2OJoYcI037770; Tue, 24 Mar 2009 14:50:34 -0500 Date: Tue, 24 Mar 2009 14:50:34 -0500 Message-Id: <200903241950.n2OJoYcI037770@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, xfs-dev, updated. v2.6.28-rc3-12036-gc3c45fe X-Git-Refname: refs/heads/xfs-dev X-Git-Reftype: branch X-Git-Oldrev: 48f392c1d468f93d79c735f76dd2a124d7022778 X-Git-Newrev: c3c45fe196e80ad2571cfe3ee72ff37eb7f18b69 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, xfs-dev has been updated from 48f392c1d468f93d79c735f76dd2a124d7022778 (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 BATV+3a69bfa7eea57bac796f+2039+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 24 16:24: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.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 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 n2OLOXnS046619 for ; Tue, 24 Mar 2009 16:24:48 -0500 X-ASG-Debug-ID: 1237929847-2a9200fb0000-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 4D91B1C009C for ; Tue, 24 Mar 2009 14:24:07 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id y74Mzq8V34guhcAp for ; Tue, 24 Mar 2009 14:24:07 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lm6Qz-0001vP-DX; Tue, 24 Mar 2009 13:12:49 +0000 Date: Tue, 24 Mar 2009 09:12:49 -0400 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , Eric Sandeen , Mike Frysinger , 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: <20090324131249.GA6964@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <20090316070550.GA628@infradead.org> <200903160331.53142.vapier@gentoo.org> <200903161053.32745.agruen@suse.de> <20090316210249.GA2641@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316210249.GA2641@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: 1237929847 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 > + ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \ > + m4/ltversion.m4 m4/lt~obsolete.m4 \ Btw, where do these m4 files come from? Is this another libtool version dependency? I can't find them anywhere for either acl/attr or the patched xfsprogs From goswin-v-b@web.de Tue Mar 24 16:50:30 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 n2OLoAlO047868 for ; Tue, 24 Mar 2009 16:50:20 -0500 X-ASG-Debug-ID: 1237931360-434900180000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fmmailgate02.web.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 81CF21C69A6F for ; Tue, 24 Mar 2009 14:49:20 -0700 (PDT) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by cuda.sgi.com with ESMTP id iRJf3NESOmraa8wW for ; Tue, 24 Mar 2009 14:49:20 -0700 (PDT) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate02.web.de (Postfix) with ESMTP id 49B1EFBE8E1C; Tue, 24 Mar 2009 20:38:36 +0100 (CET) Received: from [78.43.226.218] (helo=frosties.localdomain) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LmCSK-0007Yt-00; Tue, 24 Mar 2009 20:38:36 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.69) (envelope-from ) id 1LmCSJ-00006T-Jr; Tue, 24 Mar 2009 20:38:35 +0100 From: Goswin von Brederlow To: Jon@eHardcastle.com Cc: Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? References: <174852.24274.qm@web51309.mail.re2.yahoo.com> Date: Tue, 24 Mar 2009 20:38:35 +0100 In-Reply-To: <174852.24274.qm@web51309.mail.re2.yahoo.com> (Jon Hardcastle's message of "Mon, 23 Mar 2009 09:02:14 -0700 (PDT)") Message-ID: <87hc1iemo4.fsf@frosties.localdomain> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1+lKg9MRzMIR/DyB/vEswbmJYmvBvzebm9tOuK9 BDh2izdVlU1fskdY96JBK1A7fQz76qsXBhe3eUEcqLp1ZRZ2OT Ho8j5qnj4= X-Barracuda-Connect: fmmailgate02.web.de[217.72.192.227] X-Barracuda-Start-Time: 1237931381 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.21235 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 Jon Hardcastle writes: > I'd like to understand how you even go attaching that many devices to a system.. I am 'comparatively' new to this.. and have a 6 raid5 system.. not enterprise.. and i have slammed into case/power/sat slot issues already. What sort of hardware must one use to grow to a 36 array system! Well, lets see. Put 3 dual channel SAS controler in the box giving you 6 external SAS connectors. Buy 6 48x disk enclosures and connect them. Configure them all as JBOD and you get your 288 disks. MfG Goswin From agruen@suse.de Tue Mar 24 16:55:47 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 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 n2OLtRdY048214 for ; Tue, 24 Mar 2009 16:55:37 -0500 X-ASG-Debug-ID: 1237931679-430500340000-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 503681C69D1E for ; Tue, 24 Mar 2009 14:54:39 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id ikNECLJNU0Vm5W2K for ; Tue, 24 Mar 2009 14:54:39 -0700 (PDT) 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 mx2.suse.de (Postfix) with ESMTP id 533F685654; Tue, 24 Mar 2009 19:18:47 +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, 24 Mar 2009 19:18:39 +0100 User-Agent: KMail/1.9.9 Cc: Eric Sandeen , Mike Frysinger , "xfs-oss" References: <200902240010.25434.vapier@gentoo.org> <20090316210249.GA2641@infradead.org> <20090324131249.GA6964@infradead.org> In-Reply-To: <20090324131249.GA6964@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903241918.39649.agruen@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1237931700 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.21235 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 Tuesday, 24 March 2009 14:12:49 Christoph Hellwig wrote: > > + ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 \ > > + m4/ltversion.m4 m4/lt~obsolete.m4 \ > > Btw, where do these m4 files come from? =46rom libtool via libtoolize. The AC_PROG_LIBTOOL macro pulls them in AFAI= CT. > Is this another libtool version dependency? It would seem so but the build system simply ignores files in the file list= =20 that don't exist. This is all rather ugly, but at least the result works... Andreas=20 From sandeen@sandeen.net Tue Mar 24 17:11: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.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 n2OMAxEU049056 for ; Tue, 24 Mar 2009 17:11:09 -0500 X-ASG-Debug-ID: 1237932630-2a9402240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B78311C03A9 for ; Tue, 24 Mar 2009 15:10:30 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id qpyRd1Id4ePnAbUk for ; Tue, 24 Mar 2009 15:10:30 -0700 (PDT) Received: from [10.0.0.65] (ipod.sandeen.net [10.0.0.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 43716AC08CB; Tue, 24 Mar 2009 08:11:55 -0500 (CDT) References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> <49C4650B.4040509@sandeen.net> <20090321200806.GA15245@infradead.org> <49C56650.10008@sandeen.net> <20090324083037.GP26138@disturbed> Message-Id: <612C6156-D3B9-43BF-880A-DE54EB4F56A9@sandeen.net> From: Eric Sandeen To: Dave Chinner In-Reply-To: <20090324083037.GP26138@disturbed> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (5H11) Mime-Version: 1.0 (iPod Mail 5H11) X-ASG-Orig-Subj: Re: [PATCH 3/5] xfs: kill ino64 mount option Subject: Re: [PATCH 3/5] xfs: kill ino64 mount option Date: Tue, 24 Mar 2009 08:11:36 -0500 Cc: Christoph Hellwig , "xfs@oss.sgi.com" X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1237932632 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.21235 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 Mar 24, 2009, at 3:30 AM, Dave Chinner wrote: > On Sat, Mar 21, 2009 at 05:12:32PM -0500, Eric Sandeen wrote: >> Christoph Hellwig wrote: >>> On Fri, Mar 20, 2009 at 10:54:51PM -0500, Eric Sandeen wrote: >>>> Christoph Hellwig wrote: >>>> >>>>> The ino64 mount option adds a fixed offset to 32bit inode numbers >>>>> to bring them into the 64bit range. There's no need for this kind >>>>> of debug tool given that it's easy to produce real 64bit inode >>>>> numbers >>>>> for testing. >>>> hm, easy how? >>> >>> Actually test with a large enough device and let them spread evenly >>> over the AGs. >> >> It's the large-enough device which sometimes is at odds with "easy" > > Sparse loopback image OK I'm sold... Eric > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > From david@fromorbit.com Tue Mar 24 18:25:30 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 (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2ONP9Xa053437 for ; Tue, 24 Mar 2009 18:25:20 -0500 X-ASG-Debug-ID: 1237937073-026e02360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BC37F13C6843 for ; Tue, 24 Mar 2009 16:24:34 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id mOmDXAcu5g8rEYav for ; Tue, 24 Mar 2009 16:24:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEQ1yEl5LJex/2dsb2JhbADSLoN2Bg X-IronPort-AV: E=Sophos;i="4.38,411,1233495000"; d="scan'208";a="317530046" Received: from ppp121-44-151-177.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.151.177]) by ipmail01.adl6.internode.on.net with ESMTP; 24 Mar 2009 19:00:39 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1Lm21u-0008TJ-FX; Tue, 24 Mar 2009 19:30:38 +1100 Date: Tue, 24 Mar 2009 19:30:37 +1100 From: Dave Chinner To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/5] xfs: kill ino64 mount option Subject: Re: [PATCH 3/5] xfs: kill ino64 mount option Message-ID: <20090324083037.GP26138@disturbed> Mail-Followup-To: Eric Sandeen , Christoph Hellwig , xfs@oss.sgi.com References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> <49C4650B.4040509@sandeen.net> <20090321200806.GA15245@infradead.org> <49C56650.10008@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C56650.10008@sandeen.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1237937095 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.21240 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 Sat, Mar 21, 2009 at 05:12:32PM -0500, Eric Sandeen wrote: > Christoph Hellwig wrote: > > On Fri, Mar 20, 2009 at 10:54:51PM -0500, Eric Sandeen wrote: > >> Christoph Hellwig wrote: > >> > >>> The ino64 mount option adds a fixed offset to 32bit inode numbers > >>> to bring them into the 64bit range. There's no need for this kind > >>> of debug tool given that it's easy to produce real 64bit inode numbers > >>> for testing. > >> hm, easy how? > > > > Actually test with a large enough device and let them spread evenly > > over the AGs. > > It's the large-enough device which sometimes is at odds with "easy" Sparse loopback image. Cheers, Dave. -- Dave Chinner david@fromorbit.com From drew.kay@gmail.com Wed Mar 25 07:15: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.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 n2PCFTX4091756 for ; Wed, 25 Mar 2009 07:15:39 -0500 X-ASG-Debug-ID: 1237983282-653200860000-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 DC9D01C6CB06 for ; Wed, 25 Mar 2009 05:14:42 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by cuda.sgi.com with ESMTP id irtvrkeZuYWgFJgH for ; Wed, 25 Mar 2009 05:14:42 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id b2so904ana.5 for ; Wed, 25 Mar 2009 05:14:42 -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=GS5nu+/QLSk7vEVJPxKfmqv1wfKYtEUIHpakLzto50M=; b=JI1nYB3eoffcWv3eJjrIbhC9USD5AG8AM6L1u24Mzb+Z6U0QGMpal4YfyTk+Nj+DYT EZvhAQtUUCBR+BzaFZlsL5GQ1qgMgPGkw+s2KydUBd2LeeSsIauIAvqZgkIludUQeAnt d7kS828YQF9kOKRQe9kSOTnvqXuF2VHKRvcRY= 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=hB2+VQT0uue36F1dyLRtviq26P9sZpW7ieEg3xhZxKvbubL0p24tZWeLlEf4ageUtv g7Cu4hu1Fs9KqVtEGzJnVjUpx48J0NgmYDtKiSlGH+sBarmEIlc9QlETIGuSzSvL+iJw NsT2ERsSiblf6jY4DMsYmXhbyJc1G+QbxCeJU= MIME-Version: 1.0 Received: by 10.100.32.6 with SMTP id f6mr4364175anf.32.1237983282232; Wed, 25 Mar 2009 05:14:42 -0700 (PDT) In-Reply-To: <87hc1iemo4.fsf@frosties.localdomain> References: <174852.24274.qm@web51309.mail.re2.yahoo.com> <87hc1iemo4.fsf@frosties.localdomain> Date: Wed, 25 Mar 2009 05:14:42 -0700 Message-ID: X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? From: Drew To: Goswin von Brederlow Cc: Jon@ehardcastle.com, Raz , Bill Davidsen , linux-fsdevel@vger.kernel.org, Linux RAID Mailing List , linux-xfs@oss.sgi.com, linux-aio@kvack.org, "linux-ide@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: an-out-0708.google.com[209.85.132.251] X-Barracuda-Start-Time: 1237983302 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0339 1.0000 -1.8019 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.80 X-Barracuda-Spam-Status: No, SCORE=-1.80 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.21291 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'd like to understand how you even go attaching that many devices to a system.. I am 'comparatively' >> new to this.. and have a 6 raid5 system.. not enterprise.. and i have slammed into case/power/sat slot >> issues already. What sort of hardware must one use to grow to a 36 array system! > > Well, lets see. > > Put 3 dual channel SAS controler in the box giving you 6 external SAS > connectors. Buy 6 48x disk enclosures and connect them. Configure them > all as JBOD and you get your 288 disks. And after you've mortgaged your house, your future, and your first born ... :-P -- Drew "Nothing in life is to be feared. It is only to be understood." --Marie Curie From mpatocka@redhat.com Wed Mar 25 10:21:02 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 n2PFKgxW101373 for ; Wed, 25 Mar 2009 10:20:52 -0500 X-ASG-Debug-ID: 1237994415-61e2037c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A0E681C6D70C for ; Wed, 25 Mar 2009 08:20:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id pC7yiYmVSHf4yYi6 for ; Wed, 25 Mar 2009 08:20:15 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2PFJkAu016633; Wed, 25 Mar 2009 11:19:46 -0400 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2PFJpnH013604; Wed, 25 Mar 2009 11:19:51 -0400 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n2PFJlhS005152; Wed, 25 Mar 2009 11:19:47 -0400 Received: from localhost (mpatocka@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n2PFJlRi005146; Wed, 25 Mar 2009 11:19:47 -0400 X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs Date: Wed, 25 Mar 2009 11:19:47 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing In-Reply-To: <20090320043027.GO26138@disturbed> Message-ID: References: <1237114679-18808-1-git-send-email-david@fromorbit.com> <1237114679-18808-2-git-send-email-david@fromorbit.com> <20090318041752.GN26138@disturbed> <20090320043027.GO26138@disturbed> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1237994415 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.21305 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 Fri, 20 Mar 2009, Dave Chinner wrote: > On Wed, Mar 18, 2009 at 12:14:51PM -0400, Mikulas Patocka wrote: > > On Wed, 18 Mar 2009, Dave Chinner wrote: > > > On Tue, Mar 17, 2009 at 09:08:36AM -0400, Mikulas Patocka wrote: > > > > On Sun, 15 Mar 2009, Dave Chinner wrote: > > What I find scary is those two recursive pagelocks being held without > > trylock. The sequence is like: > > > > lock iolock 1 > > lock pagelock 1 > > --- submit request to xfssyncd, that does > > trylock iolock 2 > > lock pagelock 2 > > Those two pages will be on different inodes, so locking through all > paths to pagelock 2 except for page writeback will be protected by the iolocks... > > > ... now suppose that this is racing with another process that takes > > pagelock without taking iolock first (memory manager trying to flush files > > mmaped for write or so). It can do > > > > lock pagelock 2 > > ... and submit flush request to a thread that is actually waiting to get > > pagelock 2. > > Which, AFAIK, is never done in XFS. Once we have a page locked in > the writeback path we either dispatch it in an IO or unlock it > directly before continuing. There should not be a case like you > describe occurring (it is a bug if that does happen). > > > --- I don't know --- is there a possibility to reserve filesystem space > > for write-mapped files at the time of the first page fault? (so that the > > space won't be allocated at the time of a flush?). > > ->page_mkwrite This is called without page lock so it is ok. So I think there is no deadlock possibility. But I still say that it is scary to take two pagelocks recursively and there is risk that someone will forget about these specific requirements after few years and make a bug. Mikulas From BATV+168f106fd9f7e44a027c+2040+infradead.org+hch@bombadil.srs.infradead.org Wed Mar 25 14:04: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 n2PJ4QKN111795 for ; Wed, 25 Mar 2009 14:04:41 -0500 X-ASG-Debug-ID: 1238007819-362e00120000-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 38E381C6EBA2 for ; Wed, 25 Mar 2009 12:03:40 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jRSdHWtiYzinrTX5 for ; Wed, 25 Mar 2009 12:03:40 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LmYNy-0005xD-CT; Wed, 25 Mar 2009 19:03:34 +0000 Date: Wed, 25 Mar 2009 15:03:34 -0400 From: Christoph Hellwig To: Andreas Gruenbacher Cc: 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: <20090325190334.GA18742@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <20090316210249.GA2641@infradead.org> <20090324131249.GA6964@infradead.org> <200903241918.39649.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903241918.39649.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: 1238007840 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 24, 2009 at 07:18:39PM +0100, Andreas Gruenbacher wrote: > It would seem so but the build system simply ignores files in the file list > that don't exist. This is all rather ugly, but at least the result works... Oh well. I've now pushed these patches to xfsprogs, xfsdump and dmapi as authored by you and reviewed by me as they were straight-forward ports. From chris@cjx.com Thu Mar 26 10:42:13 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=BAYES_20,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 n2QFfl5a174588 for ; Thu, 26 Mar 2009 10:41:58 -0500 X-ASG-Debug-ID: 1238082081-6739002e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nuka.cjx.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5201E1C8B2C for ; Thu, 26 Mar 2009 08:41:21 -0700 (PDT) Received: from nuka.cjx.com (37.233.187.81.in-addr.arpa [81.187.233.37]) by cuda.sgi.com with ESMTP id CjIf9Km8pHNpVyya for ; Thu, 26 Mar 2009 08:41:21 -0700 (PDT) Received: from chris-allens-imac-g5.local (mac.cjx.com [10.0.1.8]) by nuka.cjx.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2QFfJov012566 for ; Thu, 26 Mar 2009 15:41:19 GMT Message-ID: <49CBA221.2090701@cjx.com> Date: Thu, 26 Mar 2009 15:41:21 +0000 From: Chris Allen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: accidentally deleted very large file (3.5TB) but still available through loop device Subject: accidentally deleted very large file (3.5TB) but still available through loop device Content-Type: multipart/alternative; boundary="------------040103060906030107000105" X-Barracuda-Connect: 37.233.187.81.in-addr.arpa[81.187.233.37] X-Barracuda-Start-Time: 1238082082 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0018 1.0000 -2.0094 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=HTML_MESSAGE, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21399 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 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 This is a multi-part message in MIME format. --------------040103060906030107000105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, In a nutshell, I did the following: 1. dd if=some_filesystem_dump of=some_file (where some_file resides on an XFS filesystem and is 3.5TB large) 2. losetup /dev/loop0 some_file 3. mount /dev/loop0 /recovered [.... i can now access my recovered filesystem through /recovered ...] 4. rm some_file (remotely via an nfs export) (oops!) So, I just removed my 3.5TB file even though it is attached to the loop device and mounted (XFS did this almost instantly). Now it *appears* that the filesystem as attached to /dev/loop0 and mounted on /recovered is still OK. I can cd around it and copy files off. So I have these questions: 1. Is there any way I can get back the 1 file that I accidentally deleted (nothing else has been written to that partition since) 2. Am I safe in accessing my filesystem through /dev/loop0 and /recovered even though the underlying file has been zapped? If so I can quickly copy everything off onto another partition. 3. Will this command: dd if=/dev/loop0 of=saved_file get my file back? Many thanks for any advice! --------------040103060906030107000105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

In a nutshell, I did the following:

1. dd if=some_filesystem_dump of=some_file (where some_file resides on an XFS filesystem and is 3.5TB large)

2. losetup /dev/loop0 some_file

3. mount /dev/loop0 /recovered

[.... i can now access my recovered filesystem through /recovered ...]

4. rm some_file (remotely via an nfs export) (oops!)

So, I just removed my 3.5TB file even though it is attached to the loop device and mounted (XFS did this almost instantly).


Now it *appears* that the filesystem as attached to /dev/loop0 and mounted on /recovered is still OK. I
can cd around it and copy files off.

So I have these questions:


1. Is there any way I can get back the 1 file that I accidentally deleted (nothing else has been written to that partition since)

2. Am I safe in accessing my filesystem through /dev/loop0 and /recovered even though the underlying file has been zapped? If so
I can quickly copy everything off onto another partition.

3. Will this command: dd if=/dev/loop0 of=saved_file get my file back?


Many thanks for any advice!


 --------------040103060906030107000105-- From sandeen@sandeen.net Thu Mar 26 11:07: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2QG76Vh175665 for ; Thu, 26 Mar 2009 11:07:16 -0500 X-ASG-Debug-ID: 1238083600-3ae9011a0000-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 24C311C8DE5 for ; Thu, 26 Mar 2009 09:06:40 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id ArCDRScAU0XzDZBq for ; Thu, 26 Mar 2009 09:06:40 -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 n2QG6bZl004153; Thu, 26 Mar 2009 12:06:37 -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 n2QG6UNl002699; Thu, 26 Mar 2009 12:06:30 -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 n2QG6aOP019225; Thu, 26 Mar 2009 12:06:36 -0400 Message-ID: <49CBA80A.8010500@sandeen.net> Date: Thu, 26 Mar 2009 11:06:34 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Chris Allen CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: accidentally deleted very large file (3.5TB) but still available through loop device Subject: Re: accidentally deleted very large file (3.5TB) but still available through loop device References: <49CBA221.2090701@cjx.com> In-Reply-To: <49CBA221.2090701@cjx.com> 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: 1238083601 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.21401 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 Chris Allen wrote: > Hi, > > In a nutshell, I did the following: > > 1. dd if=some_filesystem_dump of=some_file (where some_file resides on > an XFS filesystem and is 3.5TB large) > > 2. losetup /dev/loop0 some_file > > 3. mount /dev/loop0 /recovered > > [.... i can now access my recovered filesystem through /recovered ...] > > 4. rm some_file (remotely via an nfs export) (oops!) > > So, I just removed my 3.5TB file even though it is attached to the loop > device and mounted (XFS did this almost instantly). > > > Now it *appears* that the filesystem as attached to /dev/loop0 and > mounted on /recovered is still OK. I > can cd around it and copy files off. > > So I have these questions: > > > 1. Is there any way I can get back the 1 file that I accidentally > deleted (nothing else has been written to that partition since) I thought that maybe an open fd could be found in /proc, but it seems not. > 2. Am I safe in accessing my filesystem through /dev/loop0 and > /recovered even though the underlying file has been zapped? If so > I can quickly copy everything off onto another partition. The file is still held open by the loop device, so yes, it should be just fine. It doesn't really go away until you unmount & unhook the loopback device. > 3. Will this command: dd if=/dev/loop0 of=saved_file get my file back? I'd suggest: # xfs_freeze -f /recovered # dd if=/dev/loop0 of=saved_file # xfs_freeze -u /recovered to be sure you get a consistent view of the fs. -Eric From Martin@lichtvoll.de Thu Mar 26 11:36: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.4 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 n2QGabmv176818 for ; Thu, 26 Mar 2009 11:36:47 -0500 X-ASG-Debug-ID: 1238085370-223602480000-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 8E8431C7BFB for ; Thu, 26 Mar 2009 09:36:10 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 6HYxZC4P5RtBoGPY for ; Thu, 26 Mar 2009 09:36:10 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.230.144.ip-pool.NEFkom.net [212.114.230.144]) by mail.lichtvoll.de (Postfix) with ESMTPSA id CC0815ADB7 for ; Thu, 26 Mar 2009 17:36:09 +0100 (CET) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: accidentally deleted very large file (3.5TB) but still available through loop device Subject: Re: accidentally deleted very large file (3.5TB) but still available through loop device Date: Thu, 26 Mar 2009 17:36:52 +0100 User-Agent: KMail/1.9.9 References: <49CBA221.2090701@cjx.com> (sfid-20090326_172934_176693_DA0712EB) (sfid-20090326_172934_176693_DA0712EB) (sfid-20090326_172934_176693_DA0712EB) In-Reply-To: <49CBA221.2090701@cjx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903261736.53093.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1238085371 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.21403 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 26 M=E4rz 2009 schrieb Chris Allen: > Hi, Hi Chris, > In a nutshell, I did the following: > > 1. dd if=3Dsome_filesystem_dump of=3Dsome_file (where some_file resides on > an XFS filesystem and is 3.5TB large) > > 2. losetup /dev/loop0 some_file > > 3. mount /dev/loop0 /recovered > > [.... i can now access my recovered filesystem through /recovered ...] > > 4. rm some_file (remotely via an nfs export) (oops!) > > So, I just removed my 3.5TB file even though it is attached to the loop > device and mounted (XFS did this almost instantly). > > > Now it *appears* that the filesystem as attached to /dev/loop0 and > mounted on /recovered is still OK. I > can cd around it and copy files off. > > So I have these questions: > > > 1. Is there any way I can get back the 1 file that I accidentally > deleted (nothing else has been written to that partition since) dd if=3D/dev/loop0 of=3Dsomefile-restore should work IMHO. > 2. Am I safe in accessing my filesystem through /dev/loop0 and > /recovered even though the underlying file has been zapped? If so > I can quickly copy everything off onto another partition. Yes. XFS as other linux filesystems perform the real delete - i.e. freeing= =20 the blocks the file occupies - only after the last user of it has closed=20 it. Before just the directory entry of the file is removed. > 3. Will this command: dd if=3D/dev/loop0 of=3Dsaved_file get my file back? I think it will. Just try it. Ciao, =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From chris@cjx.com Thu Mar 26 11:44:44 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=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2QGiOmP177143 for ; Thu, 26 Mar 2009 11:44:34 -0500 X-ASG-Debug-ID: 1238085838-4c97001f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nuka.cjx.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AD55C13CF292 for ; Thu, 26 Mar 2009 09:43:59 -0700 (PDT) Received: from nuka.cjx.com (37.233.187.81.in-addr.arpa [81.187.233.37]) by cuda.sgi.com with ESMTP id n2W2TeVTsM3Cwl2f for ; Thu, 26 Mar 2009 09:43:59 -0700 (PDT) Received: from chris-allens-imac-g5.local (mac.cjx.com [10.0.1.8]) by nuka.cjx.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2QGhUPf012956 for ; Thu, 26 Mar 2009 16:43:31 GMT Message-ID: <49CBB0B5.7040107@cjx.com> Date: Thu, 26 Mar 2009 16:43:33 +0000 From: Chris Allen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: accidentally deleted very large file (3.5TB) but still available through loop device Subject: Re: accidentally deleted very large file (3.5TB) but still available through loop device References: <49CBA221.2090701@cjx.com> <49CBA80A.8010500@sandeen.net> In-Reply-To: <49CBA80A.8010500@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 37.233.187.81.in-addr.arpa[81.187.233.37] X-Barracuda-Start-Time: 1238085860 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0016 1.0000 -2.0105 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=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21404 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 Eric Sandeen wrote: > Chris Allen wrote: > >> Hi, >> >> In a nutshell, I did the following: >> >> 1. dd if=some_filesystem_dump of=some_file (where some_file resides on >> an XFS filesystem and is 3.5TB large) >> >> 2. losetup /dev/loop0 some_file >> >> 3. mount /dev/loop0 /recovered >> >> [.... i can now access my recovered filesystem through /recovered ...] >> >> 4. rm some_file (remotely via an nfs export) (oops!) >> >> So, I just removed my 3.5TB file even though it is attached to the loop >> device and mounted (XFS did this almost instantly). >> >> > I'd suggest: > > # xfs_freeze -f /recovered > # dd if=/dev/loop0 of=saved_file > # xfs_freeze -u /recovered > > to be sure you get a consistent view of the fs. > > -Eric > Many thanks to those who have replied. This solution does indeed work perfectly and I have recovered my lost file. Chris. From jeffpc@josefsipek.net Thu Mar 26 14:43:14 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 n2QJgsJ2185088 for ; Thu, 26 Mar 2009 14:43:04 -0500 X-ASG-Debug-ID: 1238096527-6abb037b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from josefsipek.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E8B8E1C9E74 for ; Thu, 26 Mar 2009 12:42:07 -0700 (PDT) Received: from josefsipek.net (josefsipek.net [141.211.133.196]) by cuda.sgi.com with ESMTP id Ja3KxeWuKo3fAgrh for ; Thu, 26 Mar 2009 12:42:07 -0700 (PDT) Received: by josefsipek.net (Postfix, from userid 1000) id A42CA1C00DC4; Thu, 26 Mar 2009 15:42:06 -0400 (EDT) Date: Thu, 26 Mar 2009 15:42:06 -0400 From: "Josef 'Jeff' Sipek" To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: remove m_attroffset Subject: Re: [PATCH 5/5] xfs: remove m_attroffset Message-ID: <20090326194206.GV27222@josefsipek.net> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.430583000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090318094132.430583000@bombadil.infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: josefsipek.net[141.211.133.196] X-Barracuda-Start-Time: 1238096548 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.21415 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 Wed, Mar 18, 2009 at 05:41:24AM -0400, Christoph Hellwig wrote: > With the upcoming v3 inodes the default attroffset needs to be calculated > for each specific inode, so we can't cache it in the superblock anymore. > > Also replace the assert for wrong inode sizes with a proper error check > also included in non-debug builds. Note that the ENOSYS retourn for ^^^^^^^ Typo. Otherwise it makes sense. Josef 'Jeff' Sipek. P.S. feel free to consider this an acked-by -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw From ms@citd.de Thu Mar 26 15:25: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 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 n2QKPTd8187456 for ; Thu, 26 Mar 2009 15:25:39 -0500 X-ASG-Debug-ID: 1238099083-3236001d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from enyo.dsw2k3.info (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 538861C73CA0 for ; Thu, 26 Mar 2009 13:24:43 -0700 (PDT) Received: from enyo.dsw2k3.info (enyo.dsw2k3.info [195.71.86.239]) by cuda.sgi.com with ESMTP id 4e10GNgfVDH0MEP3 for ; Thu, 26 Mar 2009 13:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by enyo.dsw2k3.info (Postfix) with ESMTP id B1AAF2BC5B; Thu, 26 Mar 2009 21:24:42 +0100 (CET) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at enyo.dsw2k3.info Received: from enyo.dsw2k3.info ([127.0.0.1]) by localhost (enyo.dsw2k3.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vbD4y8T0asUy; Thu, 26 Mar 2009 21:24:33 +0100 (CET) Received: from citd.de (p4FC4EEC9.dip.t-dialin.net [79.196.238.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by enyo.dsw2k3.info (Postfix) with ESMTP id 83CFE2BC51; Thu, 26 Mar 2009 21:24:32 +0100 (CET) Date: Thu, 26 Mar 2009 21:24:29 +0100 From: Matthias Schniedermeyer To: Chris Allen Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: accidentally deleted very large file (3.5TB) but still available through loop device Subject: Re: accidentally deleted very large file (3.5TB) but still available through loop device Message-ID: <20090326202429.GA27234@citd.de> References: <49CBA221.2090701@cjx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CBA221.2090701@cjx.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: enyo.dsw2k3.info[195.71.86.239] X-Barracuda-Start-Time: 1238099104 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Whitelist: HEADER (^X-Barracuda-Connect: [^ ]+\.dsw2k3\.info\[) X-Virus-Status: Clean On 26.03.2009 15:41, Chris Allen wrote: > Hi, > > In a nutshell, I did the following: > > 1. dd if=some_filesystem_dump of=some_file (where some_file resides on > an XFS filesystem and is 3.5TB large) > > 2. losetup /dev/loop0 some_file > > 3. mount /dev/loop0 /recovered > > [.... i can now access my recovered filesystem through /recovered ...] > > 4. rm some_file (remotely via an nfs export) (oops!) > > So, I just removed my 3.5TB file even though it is attached to the loop > device and mounted (XFS did this almost instantly). > > > Now it *appears* that the filesystem as attached to /dev/loop0 and > mounted on /recovered is still OK. I > can cd around it and copy files off. > > So I have these questions: > > > 1. Is there any way I can get back the 1 file that I accidentally > deleted (nothing else has been written to that partition since) Unfortunatly not directly. You can't create a directory entry for an inode. It was discussed a few years back, but rejected for security reasons. (I speak for the kernel in general, i don't know if there is a XFS specific thing to create a directory entry for an inode.) > 2. Am I safe in accessing my filesystem through /dev/loop0 and > /recovered even though the underlying file has been zapped? If so Yes. You are saved by the standard unix semantics of "only delete a file if it's reference count is 0". A directory entry counts and having a file open also counts. > I can quickly copy everything off onto another partition. As long as you don't reboot/umount the partition you are in no hurry. Only Murphy can really ruin your day now. ;-) > 3. Will this command: dd if=/dev/loop0 of=saved_file get my file back? Yes, but: - You should drop the caches before starting the copy: echo 3 > /proc/sys/vm/drop_caches - You should not touch the filesystem while copying. Especially you shouldn't write anything. The "view" of the upper- and underside (Filesystem vs. backing-store) are NOT kept in sync by the kernel. So it is best not to touch the filesystem. You can also: xfs_freeze the filesystem (see man xfs_freeze) or umount the filesystem if the entry in "/etc/mtab" does NOT mention "loop=/dev/loop" or if you delete if before umounting. Because umount will only free the loop-device if there is a "loop=" or with the parameter "-d" (see man umount) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. From felixb@sgi.com Thu Mar 26 17:38:03 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 n2QMbhjR194043 for ; Thu, 26 Mar 2009 17:37:53 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 11D843040E7 for ; Thu, 26 Mar 2009 15:37:18 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id C9A1570001C8; Thu, 26 Mar 2009 17:37:11 -0500 (CDT) Cc: Dave Chinner , Christoph Hellwig , "xfs@oss.sgi.com" Message-Id: From: Felix Blyakher To: Eric Sandeen In-Reply-To: <612C6156-D3B9-43BF-880A-DE54EB4F56A9@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: [PATCH 3/5] xfs: kill ino64 mount option Date: Thu, 26 Mar 2009 17:37:11 -0500 References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.076764000@bombadil.infradead.org> <49C4650B.4040509@sandeen.net> <20090321200806.GA15245@infradead.org> <49C56650.10008@sandeen.net> <20090324083037.GP26138@disturbed> <612C6156-D3B9-43BF-880A-DE54EB4F56A9@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 24, 2009, at 8:11 AM, Eric Sandeen wrote: > > > On Mar 24, 2009, at 3:30 AM, Dave Chinner wrote: > >> On Sat, Mar 21, 2009 at 05:12:32PM -0500, Eric Sandeen wrote: >>> Christoph Hellwig wrote: >>>> On Fri, Mar 20, 2009 at 10:54:51PM -0500, Eric Sandeen wrote: >>>>> Christoph Hellwig wrote: >>>>> >>>>>> The ino64 mount option adds a fixed offset to 32bit inode numbers >>>>>> to bring them into the 64bit range. There's no need for this >>>>>> kind >>>>>> of debug tool given that it's easy to produce real 64bit inode >>>>>> numbers >>>>>> for testing. >>>>> hm, easy how? >>>> >>>> Actually test with a large enough device and let them spread evenly >>>> over the AGs. >>> >>> It's the large-enough device which sometimes is at odds with "easy" >> >> Sparse loopback image > > OK I'm sold... That addressed my concern too. Reviewed-by: Felix Blyakher > > > Eric > >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> david@fromorbit.com >> > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From felixb@sgi.com Thu Mar 26 17:38: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_48 autolearn=no 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 n2QMc9GI194048 for ; Thu, 26 Mar 2009 17:38:19 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2C10A3040E9 for ; Thu, 26 Mar 2009 15:37:44 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id 43D06700016A; Thu, 26 Mar 2009 17:31:10 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090318094131.924623000@bombadil.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: [PATCH 2/5] xfs: kill mutex_t typedef Date: Thu, 26 Mar 2009 17:31:10 -0500 References: <20090318094119.561416000@bombadil.infradead.org> <20090318094131.924623000@bombadil.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 Mar 18, 2009, at 4:41 AM, Christoph Hellwig wrote: > People continue to complain about this for weird reasons, but there's > really no point in keeping this typedef for a couple of users anyway. Yeah, linux community seems to shy away from type_t's in favor of 'struct type'. Reviewed-by: Felix Blyakher > Signed-off-by: Christoph Hellwig > > > Index: xfs/fs/xfs/linux-2.6/mutex.h > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/mutex.h 2009-02-24 21:01:18.877182725 > +0100 > +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 > @@ -1,25 +0,0 @@ > -/* > - * Copyright (c) 2000-2003,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 > - */ > -#ifndef __XFS_SUPPORT_MUTEX_H__ > -#define __XFS_SUPPORT_MUTEX_H__ > - > -#include > - > -typedef struct mutex mutex_t; > - > -#endif /* __XFS_SUPPORT_MUTEX_H__ */ > Index: xfs/fs/xfs/linux-2.6/xfs_linux.h > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_linux.h 2009-02-24 > 21:01:34.596153088 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_linux.h 2009-02-24 21:01:47.951030927 > +0100 > @@ -38,7 +38,6 @@ > #include > #include > #include > -#include > #include > > #include > @@ -51,6 +50,7 @@ > #include > #include > #include > +#include > #include > #include > #include > Index: xfs/fs/xfs/quota/xfs_dquot.h > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_dquot.h 2009-02-24 20:59:24.413152831 > +0100 > +++ xfs/fs/xfs/quota/xfs_dquot.h 2009-02-24 20:59:39.642153943 +0100 > @@ -34,7 +34,7 @@ > */ > typedef struct xfs_dqhash { > struct xfs_dquot *qh_next; > - mutex_t qh_lock; > + struct mutex qh_lock; > uint qh_version; /* ever increasing version */ > uint qh_nelems; /* number of dquots on the list */ > } xfs_dqhash_t; > @@ -81,7 +81,7 @@ typedef struct xfs_dquot { > xfs_qcnt_t q_res_bcount; /* total regular nblks used+reserved */ > xfs_qcnt_t q_res_icount; /* total inos allocd+reserved */ > xfs_qcnt_t q_res_rtbcount;/* total realtime blks used+reserved */ > - mutex_t q_qlock; /* quota lock */ > + struct mutex q_qlock; /* quota lock */ > struct completion q_flush; /* flush completion queue */ > atomic_t q_pincount; /* dquot pin count */ > wait_queue_head_t q_pinwait; /* dquot pinning wait queue */ > Index: xfs/fs/xfs/quota/xfs_qm.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm.c 2009-02-24 21:00:11.195028215 +0100 > +++ xfs/fs/xfs/quota/xfs_qm.c 2009-02-24 21:00:30.583030096 +0100 > @@ -55,7 +55,7 @@ > * quota functionality, including maintaining the freelist and hash > * tables of dquots. > */ > -mutex_t xfs_Gqm_lock; > +struct mutex xfs_Gqm_lock; > struct xfs_qm *xfs_Gqm; > uint ndquot; > > @@ -80,7 +80,7 @@ static struct shrinker xfs_qm_shaker = { > }; > > #ifdef DEBUG > -extern mutex_t qcheck_lock; > +extern struct mutex qcheck_lock; > #endif > > #ifdef QUOTADEBUG > Index: xfs/fs/xfs/quota/xfs_qm.h > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm.h 2009-02-24 21:00:11.207028206 +0100 > +++ xfs/fs/xfs/quota/xfs_qm.h 2009-02-24 21:00:52.676027690 +0100 > @@ -27,7 +27,7 @@ struct xfs_qm; > struct xfs_inode; > > extern uint ndquot; > -extern mutex_t xfs_Gqm_lock; > +extern struct mutex xfs_Gqm_lock; > extern struct xfs_qm *xfs_Gqm; > extern kmem_zone_t *qm_dqzone; > extern kmem_zone_t *qm_dqtrxzone; > @@ -79,7 +79,7 @@ typedef xfs_dqhash_t xfs_dqlist_t; > typedef struct xfs_frlist { > struct xfs_dquot *qh_next; > struct xfs_dquot *qh_prev; > - mutex_t qh_lock; > + struct mutex qh_lock; > uint qh_version; > uint qh_nelems; > } xfs_frlist_t; > @@ -115,7 +115,7 @@ typedef struct xfs_quotainfo { > xfs_qwarncnt_t qi_bwarnlimit; /* limit for blks warnings */ > xfs_qwarncnt_t qi_iwarnlimit; /* limit for inodes warnings */ > xfs_qwarncnt_t qi_rtbwarnlimit;/* limit for rt blks warnings */ > - mutex_t qi_quotaofflock;/* to serialize quotaoff */ > + struct mutex qi_quotaofflock;/* to serialize quotaoff */ > xfs_filblks_t qi_dqchunklen; /* # BBs in a chunk of dqs */ > uint qi_dqperchunk; /* # ondisk dqs in above chunk */ > xfs_qcnt_t qi_bhardlimit; /* default data blk hard limit */ > Index: xfs/fs/xfs/quota/xfs_qm_syscalls.c > =================================================================== > --- xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-24 > 21:01:03.015027884 +0100 > +++ xfs/fs/xfs/quota/xfs_qm_syscalls.c 2009-02-24 21:01:11.159155659 > +0100 > @@ -960,7 +960,7 @@ xfs_dqhash_t *qmtest_udqtab; > xfs_dqhash_t *qmtest_gdqtab; > int qmtest_hashmask; > int qmtest_nfails; > -mutex_t qcheck_lock; > +struct mutex qcheck_lock; > > #define DQTEST_HASHVAL(mp, id) (((__psunsigned_t)(mp) + \ > (__psunsigned_t)(id)) & \ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From felixb@sgi.com Thu Mar 26 17:42:03 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_66 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2QMfgmM194189 for ; Thu, 26 Mar 2009 17:41:52 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 5AC20AC00E for ; Thu, 26 Mar 2009 15:41:17 -0700 (PDT) Received: from eagdhcp-232-172.americas.sgi.com (eagdhcp-232-172.americas.sgi.com [128.162.232.172]) by estes.americas.sgi.com (Postfix) with ESMTP id EB3DE700016A; Thu, 26 Mar 2009 17:41:16 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <3D659CF1-738E-4580-B390-9E7B65C4BE2F@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090318094132.224487000@bombadil.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: [PATCH 4/5] xfs: remove m_litino Date: Thu, 26 Mar 2009 17:41:16 -0500 References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.224487000@bombadil.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 Mar 18, 2009, at 4:41 AM, Christoph Hellwig wrote: > With the upcoming v3 inodes the inode data/attr area size needs to be > calculated for each specific inode, so we can't cache it in the > superblock > anymore. The change looks fine. But what is "v3 inodes"? I'm sure it's been mentioned on the list, I'm just missing the history. Reviewed-by: Felix Blyakher > > > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/xfs_dinode.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_dinode.h 2009-02-19 20:44:20.755069389 +0100 > +++ xfs/fs/xfs/xfs_dinode.h 2009-03-18 07:37:16.652977839 +0100 > @@ -103,7 +103,9 @@ typedef enum xfs_dinode_fmt { > /* > * Inode size for given fs. > */ > -#define XFS_LITINO(mp) ((mp)->m_litino) > +#define XFS_LITINO(mp) \ > + ((int)(((mp)->m_sb.sb_inodesize) - sizeof(struct xfs_dinode))) > + > #define XFS_BROOT_SIZE_ADJ \ > (XFS_BTREE_LBLOCK_LEN - sizeof(xfs_bmdr_block_t)) > > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2009-03-18 07:37:15.633978066 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2009-03-18 07:37:20.566978952 +0100 > @@ -651,7 +651,6 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb > mp->m_sectbb_log = sbp->sb_sectlog - BBSHIFT; > mp->m_agno_log = xfs_highbit32(sbp->sb_agcount - 1) + 1; > mp->m_agino_log = sbp->sb_inopblog + sbp->sb_agblklog; > - mp->m_litino = sbp->sb_inodesize - sizeof(struct xfs_dinode); > mp->m_blockmask = sbp->sb_blocksize - 1; > mp->m_blockwsize = sbp->sb_blocksize >> XFS_WORDLOG; > mp->m_blockwmask = mp->m_blockwsize - 1; > Index: xfs/fs/xfs/xfs_mount.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.h 2009-03-18 07:37:16.077856262 +0100 > +++ xfs/fs/xfs/xfs_mount.h 2009-03-18 07:37:20.585978718 +0100 > @@ -203,7 +203,6 @@ typedef struct xfs_mount { > uint m_attr_node_ents; /* #entries in attr danode */ > int m_ialloc_inos; /* inodes in inode allocation */ > int m_ialloc_blks; /* blocks in inode allocation */ > - int m_litino; /* size of inode union area */ > int m_inoalign_mask;/* mask sb_inoalignmt if used */ > uint m_qflags; /* quota status flags */ > xfs_trans_reservations_t m_reservations;/* precomputed res values */ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From SEMA-CR-1-43KR63@ptcmarketing.com Fri Mar 27 03:04:14 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.4 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_QP_LONG_LINE 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 n2R83mAK223242 for ; Fri, 27 Mar 2009 03:04:03 -0500 X-ASG-Debug-ID: 1238140983-552600820000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 860AA1C75B21 for ; Fri, 27 Mar 2009 01:03:03 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id YLALLKI1VJeZ31xa for ; Fri, 27 Mar 2009 01:03:03 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.38,431,1233550800"; d="scan'208,217";a="294227677" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 27 Mar 2009 03:58:31 -0400 Date: Fri, 27 Mar 2009 03:51:52 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: Save Time and Effort by Leveraging Your 3D CAD Data with Arbortext IsoDraw Subject: Save Time and Effort by Leveraging Your 3D CAD Data with Arbortext IsoDraw Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1238140356000_1735257016 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1238141003 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 --BF_1238140356000_1735257016 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable Arbortext IsoDraw: A Demonstration of PTC's Technical Illustration Tools (http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3XZ5PG= &o=3D= 1-3ZD09F= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D89246) There's a revolution going on in the world of technical documentation today.= Forward-thinking companies are now reusing their rich 3D CAD model data by = converting them into high-quality technical illustrations. The savings in il= lustration time, cost and effort are simply revolutionary! * Do your engineers spend valuable design time to prepare data for technic= al illustrations for your company=E2=80=99s parts catalogs and manuals? * Is your product delivery often delayed because documentation was not rea= dy? * Do revisions cause major effort because the technical illustrations have= no connection with the original CAD data? * Do your illustrators invest a lot of time with cleaning up the files the= y receive out of the CAD system? This demonstration will provide an overview of PTC=E2=80=99s technical illus= tration solutions and a short product demonstration of how Arbortext IsoDraw= allows you to leverage your 3D CAD data and easily convert them to high-qua= lity technical illustrations. As an engineer, technical illustrator, or technical writer, you certainly kn= ow the challenges in the field of technical publications. Get up-to-speed on= the revolution now happening in technical documentation. View the Arbortext= IsoDraw demonstration now and see why smart companies are leveraging their = 3D CAD data for their documentation process. (http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3XZ5PG= &o=3D= 1-3ZD09F= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D89246) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-3ZD09F= &campd=3D= 1-3XZ5PG= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-3ZD09F= &campd=3D= 1-3XZ5PG= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= edit profile http://www.ptc.com/read?&w=3D= 2354034= &t=3D/common/account/index.htm ----------------------------------------------------------------------------= --- This email was sent to: = xfs@oss.sgi.com= PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to= unsubscribe@ptc.com. --BF_1238140356000_1735257016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable IsoDraw Tech Illustration Demo NA FY09
3D"PTC.com"
3D"
 
Arbortext IsoDr= aw: A Demonstration of PTC's Technical Illustration Tools=20

There's a revolution going on in the world of technical documentation tod= ay. Forward-thinking companies are now reusing their rich 3D CAD model data = by converting them into high-quality technical illustrations. The savings in= illustration time, cost and effort are simply revolutionary!

  • Do your engineers spend valuable design time to prepare data for techni= cal illustrations for your company's parts catalogs and manuals?
  • Is your product delivery often delayed because documentation was not re= ady?
  • Do revisions cause major effort because the technical illustrations hav= e no connection with the original CAD data?
  • Do your illustrators invest a lot of time with cleaning up the files th= ey receive out of the CAD system?

This demonstration will provide an overview of PTC's technical illustrati= on solutions and a short product demonstration of how Arbortext IsoDraw allo= ws you to leverage your 3D CAD data and easily convert them to high-quality = technical illustrations.

As an engineer, technical illustrator, or technical writer, you certainly= know the challenges in the field of technical publications. Get up-to-speed= on the revolution now happening in technical documentation. View the Arbortext IsoDr= aw demonstration now and see why smart companies are leveraging= their 3D CAD data for their documentation process.

3D""
contact PTC | privacy policy | edit profile
This email was sent to: = xfs@oss.sgi.com=     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank ema= il to unsubscribe@ptc.com.
--BF_1238140356000_1735257016-- From michael.monnerie@is.it-management.at Fri Mar 27 03:31: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.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, URIBL_SBL 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 n2R8VYnu224613 for ; Fri, 27 Mar 2009 03:31:49 -0500 X-ASG-Debug-ID: 1238142665-560c01890000-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 7943B1C752DF for ; Fri, 27 Mar 2009 01:31:06 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id ml1SleM1SjyHsQxE for ; Fri, 27 Mar 2009 01:31:06 -0700 (PDT) Received: from mailsrv2.i.zmi.at (unknown [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 9AF944C29 for ; Fri, 27 Mar 2009 09:31:04 +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 9491640DC04 for ; Fri, 27 Mar 2009 09:31:04 +0100 (CET) To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: How to configure 36 disks ? Subject: Re: How to configure 36 disks ? Content-Disposition: inline From: Michael Monnerie Organization: it-management http://it-management.at Date: Fri, 27 Mar 2009 09:31:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200903270931.03964@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1238142666 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.21467 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 sent this mail on Tue 23:40 CET, but it seems it didn't arrive on the=20 list. At least I didn't receive it. So I send again) On Montag 23 M=E4rz 2009 Raz wrote: > 1. redundancy. > 2. performance. =46irst, you should have bought enclosures with included RAID controllers,= =20 then you'd be finished already. But then, I guess you wanted to save the money, but at least go get some=20 real hardware RAID controller. Look at Areca ( http://www.areca.com.tw )=20 if you use Linux or Windows, the 1680 series SAS controllers can cope=20 with SAS/SATA drives, up to 128 drives per controller. You can put a=20 cache up to 4GB on the controller, and a battery backup module that=20 protects your data in case of power outages. Those controllers are=20 blazing fast, have good admin tools, send you an e-mail in case of=20 problems, and they used it in the video that Chris mentioned: http://blogs.sun.com/observatory/entry/don_t_shout_at_your In the end you see they used an Areca 16port, plus an Adaptec 8port (I=20 guess because they only had the Areca in 16port available). Then configure a RAID-60 or whatever you like. 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 BATV+2466005718b056c2c0c5+2042+infradead.org+hch@bombadil.srs.infradead.org Fri Mar 27 11:03: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.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34 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 n2RG2s9Q251551 for ; Fri, 27 Mar 2009 11:03:10 -0500 X-ASG-Debug-ID: 1238169729-455203690000-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 B64841C76775 for ; Fri, 27 Mar 2009 09:02:09 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id SNQpHR0VgEvYNpz1 for ; Fri, 27 Mar 2009 09:02:09 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnEVQ-000393-Ll; Fri, 27 Mar 2009 16:02:04 +0000 Date: Fri, 27 Mar 2009 12:02:04 -0400 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , Eric Sandeen , Mike Frysinger , xfs-oss , nathans@debian.org 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: <20090327160204.GA9306@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200902271835.30912.agruen@suse.de> <20090304172727.GA21463@infradead.org> <200903081409.28808.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903081409.28808.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: 1238169749 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 I did some make dist and build the tarball tests with acl,attr,xfsprogs & co. We still run libtoolize, aclocal and autoconf when building a clean tree. I wonder if we should just get rid of the whole configure target and require a manual ./configure like most tools? Nathan, any comments on that from the Debian perspective? From vapier@gentoo.org Fri Mar 27 11:32:08 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_34 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 n2RGVm8x253349 for ; Fri, 27 Mar 2009 11:31:58 -0500 X-ASG-Debug-ID: 1238171462-7b0e03360000-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 56EDA1CCFBA for ; Fri, 27 Mar 2009 09:31:02 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by cuda.sgi.com with ESMTP id NoZ9vg5lwpHpCso5 for ; Fri, 27 Mar 2009 09:31:02 -0700 (PDT) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DA25D64F80; Fri, 27 Mar 2009 16:31:01 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org 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: Fri, 27 Mar 2009 12:30:59 -0400 User-Agent: KMail/1.11.1 (Linux/2.6.28; KDE/4.2.1; x86_64; ; ) Cc: Andreas Gruenbacher , Eric Sandeen , "xfs-oss" , nathans@debian.org References: <200902240010.25434.vapier@gentoo.org> <200903081409.28808.agruen@suse.de> <20090327160204.GA9306@infradead.org> In-Reply-To: <20090327160204.GA9306@infradead.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2531250.rhzhurNsDd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903271231.01055.vapier@gentoo.org> X-Barracuda-Connect: smtp.gentoo.org[140.211.166.183] X-Barracuda-Start-Time: 1238171483 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.21499 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 --nextPart2531250.rhzhurNsDd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 27 March 2009 12:02:04 Christoph Hellwig wrote: > I did some make dist and build the tarball tests with > acl,attr,xfsprogs & co. > > We still run libtoolize, aclocal and autoconf when building a clean > tree. I wonder if we should just get rid of the whole configure target > and require a manual ./configure like most tools? `make dist` should produce a tarball that, when unpacked, people can run: ./configure && make && make install -mike --nextPart2531250.rhzhurNsDd 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) iQIcBAABAgAGBQJJzP9EAAoJEEFjO5/oN/WBPsYP/3U7Jxx00499xHd1+EHXCfPn 0FHGvSxuDbf5ibVaYORgozEkJT0cnhXjl8dFjes5ZSvx6xHIe4/8LU2WbCZIVitW cpGIRuDQjylzuJ+SzcmZ3PutsOH/RqA7XoXmVfnCDpuXiUa4o3h/nvMt5o6B3ZfJ zLaP4QONuAWvTBdtilFjT/RaEOqT/8kwNSVuyc2X2OAVkgFqe9evcnKdv4dModj1 MmbL7w2qotP4fBFVuHfyQJ8MjJYj6vRCAvQtq1d5c1M0wD8ZJAgNLAR14mTFaLCs hzRBDKoId/onYhA/YtQDYE54zNRaLMC5rTAB7m+roRoqDLWw/lyC74rFeN+w1l25 WVEC32OlQneLrbt59lMXoD3u2jmDttb28DEE9ZkS+TYwGy5Ruo1zdTLgmUlHNw2k PnyKMJGbqboan+Eo27W+9tWvRhXVjHXfCnmGyLPgbHE3fqpOitbMO8Hob0obaZ5B 91s0ss3+yEa5LzhsfHRUP7atFaD9dUt4tgenFlqMpYBeg7+OpXt5bNckBdiEWXi3 5mbdmjrahlnjQn3WoHHWmQlXHG7VVq6gpVkbSDJZFodCexn9KpRvGqsNA+BSM+Pv Tj/tPiSEY/y2Vkr5nc/BP7rIGMSEwz5IRqEQbtpPreni8P92O1Jluhsr/OGlIlB+ +0MpVfT7MGh8T5nZT0aC =QfBO -----END PGP SIGNATURE----- --nextPart2531250.rhzhurNsDd-- From anniesimanski@worldwidehealthdirectory.com Fri Mar 27 12:03: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.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 n2RH3Apk255059 for ; Fri, 27 Mar 2009 12:03:20 -0500 X-ASG-Debug-ID: 1238173364-348f009b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from unixserver8.unixsrv8.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D40991CD8FC for ; Fri, 27 Mar 2009 10:02:44 -0700 (PDT) Received: from unixserver8.unixsrv8.com (unixserver8.unixsrv8.com [66.45.226.2]) by cuda.sgi.com with ESMTP id zQ97rsQVs8Oxfshz for ; Fri, 27 Mar 2009 10:02:44 -0700 (PDT) Received: from [69.209.193.249] (helo=SG-20) by unixserver8.unixsrv8.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmFVk-0005dP-13 for xfs@oss.sgi.com; Tue, 24 Mar 2009 18:54:20 -0400 Reply-To: "Annie Simanski" From: "Annie Simanski" To: X-ASG-Orig-Subj: Link Exchange with oss.sgi.com Subject: Link Exchange with oss.sgi.com Date: Tue, 24 Mar 2009 17:53:47 -0500 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 X-AntiAbuse: Message Originator UID: RI {1a52a-92599} X-AntiAbuse: Since we wish to continue to provide abuse tracking! X-AntiAbuse: Please do not use this header to filter out email X-AntiAbuse: Report abuse incidents to mach 5 enterprises X-AntiAbuse: This header is intended to track abuse. Include with any abuse report X-Mailer: Mach 5 Mailer version 4 RI{1a52a-92599} Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - unixserver8.unixsrv8.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - worldwidehealthdirectory.com X-Source: X-Source-Args: X-Source-Dir: X-Barracuda-Connect: unixserver8.unixsrv8.com[66.45.226.2] X-Barracuda-Start-Time: 1238173364 Message-Id: <20090327170244.D40991CD8FC@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: 1.25 X-Barracuda-Spam-Status: No, SCORE=1.25 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b, NO_OBLIGATION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21501 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.30 NO_OBLIGATION BODY: There is no obligation 0.20 BSF_SC0_SA074b Custom Rule SA074b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, I visited your site oss.sgi.com and I'm interested in swapping links with you. I can add your link to a category specific page on our site worldwidehealthdirectory.com, in exchange for a link back from the home or internal page of your site. If you're interested, please reply to this email with your link details and the URL of your links page below: Anchor Text (example: Atlanta employment agency): URL: Description: Links Page: Once I hear back from you with the following information, I'll send you a reply regarding our link details. Remember, we need all of the information above in order to post your link. I look forward to hearing from you. Best regards, Annie Simanski Account Manager worldwidehealthdirectory.com Ref: 3-24 PLEASE NOTE: This email is not spam, it was manually sent by us, our sole purpose being to introduce ourselves to you with no obligation on your part. Your email address was found to be publicly available on your website and it has not been added to any list. We consider this to be a polite way to contact you and apologize sincerely if you have been inconvenienced in any way. We are legally obliged to offer you an 'OPT-OUT' from future mailings from us; should you wish to exercise this right, please reply with "OPT-OUT" in the subject field and give us your email address and URL of your site. From BATV+2466005718b056c2c0c5+2042+infradead.org+hch@bombadil.srs.infradead.org Fri Mar 27 13:33:14 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_34 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 n2RIWmlT260879 for ; Fri, 27 Mar 2009 13:33:04 -0500 X-ASG-Debug-ID: 1238178723-349002eb0000-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 CEC0F1CDE8F for ; Fri, 27 Mar 2009 11:32:03 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id K8HytACGxGoGOWBp for ; Fri, 27 Mar 2009 11:32:03 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnGqS-0006YX-JR; Fri, 27 Mar 2009 18:31:56 +0000 Date: Fri, 27 Mar 2009 14:31:56 -0400 From: Christoph Hellwig To: Mike Frysinger Cc: Christoph Hellwig , Andreas Gruenbacher , Eric Sandeen , xfs-oss , nathans@debian.org 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: <20090327183156.GA20588@infradead.org> References: <200902240010.25434.vapier@gentoo.org> <200903081409.28808.agruen@suse.de> <20090327160204.GA9306@infradead.org> <200903271231.01055.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903271231.01055.vapier@gentoo.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: 1238178743 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, Mar 27, 2009 at 12:30:59PM -0400, Mike Frysinger wrote: > On Friday 27 March 2009 12:02:04 Christoph Hellwig wrote: > > I did some make dist and build the tarball tests with > > acl,attr,xfsprogs & co. > > > > We still run libtoolize, aclocal and autoconf when building a clean > > tree. I wonder if we should just get rid of the whole configure target > > and require a manual ./configure like most tools? > > `make dist` should produce a tarball that, when unpacked, people can run: > ./configure && make && make install Yes. The added complication is that the various xfs-cmds derived tools also run ./configure from a default target make which complicates the build system. From fhines@blackopscode.com Fri Mar 27 14:55:37 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 n2RJtGxF004151 for ; Fri, 27 Mar 2009 14:55:27 -0500 X-ASG-Debug-ID: 1238183670-7900035b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sensor2.syn-recon.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8E4501C78102 for ; Fri, 27 Mar 2009 12:54:30 -0700 (PDT) Received: from sensor2.syn-recon.net (sensor2.syn-recon.net [209.61.158.40]) by cuda.sgi.com with ESMTP id ABDD8pGQAC85wIWa for ; Fri, 27 Mar 2009 12:54:30 -0700 (PDT) Received: by sensor2.syn-recon.net (Postfix, from userid 99) id 7A8323F43DA; Fri, 27 Mar 2009 14:54:30 -0500 (CDT) Received: from localhost.localdomain (unknown [64.39.1.185]) by sensor2.syn-recon.net (Postfix) with ESMTP id 1AC023F4329 for ; Fri, 27 Mar 2009 14:54:25 -0500 (CDT) Message-ID: <49CD2EF0.9060009@blackopscode.com> Date: Fri, 27 Mar 2009 14:54:24 -0500 From: Florian Hines User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Corruption of in-memory data Subject: Corruption of in-memory data Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sensor2.syn-recon.net[209.61.158.40] X-Barracuda-Start-Time: 1238183691 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.21513 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 Hey everybody, Over the last few day's I've been getting a rash (8 so far) of disk's throwing the error "Filesystem "sdxX": Corruption of in-memory data detected. Shutting down filesystem: sdxX". xfs_check never seem's to find anything and just unmounting and remounting solves the issue at least for awhile. Is this usually caused by bad ram ? It's happened on 6 systems so far (all using Debian Etch AMD64 with the stock 2.6.18 kernel, each system as a 5 sata drives, not raided). Can anyone shed some light on what this error actually indicates for me ? --Full error from dmesg below-- Filesystem "sda3": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xffffffff8818ead5 Call Trace: [] :xfs:xfs_trans_cancel+0x5b/0xfe [] :xfs:xfs_rename+0xa13/0xa9a [] :xfs:xfs_vn_rename+0x2c/0x6f [] __up_read+0x13/0x8a [] :xfs:xfs_iunlock+0x57/0x79 [] __up_read+0x13/0x8a [] :xfs:xfs_iunlock+0x57/0x79 [] :xfs:xfs_access+0x3d/0x46 [] vfs_rename+0x2d5/0x426 [] sys_renameat+0x180/0x1f9 [] sys_newstat+0x28/0x31 [] system_call+0x7e/0x83 xfs_force_shutdown(sda3,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8818fdee Filesystem "sda3": Corruption of in-memory data detected. Shutting down filesystem: sda3 Please umount the filesystem, and rectify the problem(s) -- flo From sandeen@sandeen.net Fri Mar 27 15:23: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.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 n2RKNcx7006134 for ; Fri, 27 Mar 2009 15:23:48 -0500 X-ASG-Debug-ID: 1238185391-680c00380000-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 AF4ED1CE30E for ; Fri, 27 Mar 2009 13:23:11 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id igsZg37crIjshEAJ for ; Fri, 27 Mar 2009 13:23: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 n2RKMvmM001058; Fri, 27 Mar 2009 16:22:58 -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 n2RKMn7E010471; Fri, 27 Mar 2009 16:22:49 -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 n2RKMuou031410; Fri, 27 Mar 2009 16:22:56 -0400 Message-ID: <49CD359E.905@sandeen.net> Date: Fri, 27 Mar 2009 15:22:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Florian Hines CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data Subject: Re: Corruption of in-memory data References: <49CD2EF0.9060009@blackopscode.com> In-Reply-To: <49CD2EF0.9060009@blackopscode.com> 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: 1238185392 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.21515 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 Florian Hines wrote: > Hey everybody, > > Over the last few day's I've been getting a rash (8 so far) of disk's > throwing the error "Filesystem "sdxX": Corruption of in-memory data > detected. Shutting down filesystem: sdxX". xfs_check never seem's to > find anything and just unmounting and remounting solves the issue at > least for awhile. try xfs_repair, with -n if you want a dry run. It's canceling a dirty transaction, I'm not sure why. The message is a little misleading. Want to try 2.6.29? :) -Eric > Is this usually caused by bad ram ? It's happened > on 6 systems so far (all using Debian Etch AMD64 with the stock 2.6.18 > kernel, each system as a 5 sata drives, not raided). > > Can anyone shed some light on what this error actually indicates for me ? > > --Full error from dmesg below-- > Filesystem "sda3": XFS internal error xfs_trans_cancel at line 1138 of > file fs/xfs/xfs_trans.c. Caller 0xffffffff8818ead5 > > Call Trace: > [] :xfs:xfs_trans_cancel+0x5b/0xfe > [] :xfs:xfs_rename+0xa13/0xa9a > [] :xfs:xfs_vn_rename+0x2c/0x6f > [] __up_read+0x13/0x8a > [] :xfs:xfs_iunlock+0x57/0x79 > [] __up_read+0x13/0x8a > [] :xfs:xfs_iunlock+0x57/0x79 > [] :xfs:xfs_access+0x3d/0x46 > [] vfs_rename+0x2d5/0x426 > [] sys_renameat+0x180/0x1f9 > [] sys_newstat+0x28/0x31 > [] system_call+0x7e/0x83 > > xfs_force_shutdown(sda3,0x8) called from line 1139 of file > fs/xfs/xfs_trans.c. Return address = 0xffffffff8818fdee > Filesystem "sda3": Corruption of in-memory data detected. Shutting down > filesystem: sda3 > Please umount the filesystem, and rectify the problem(s) > > > -- > flo > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From Curtis@GreenKey.net Fri Mar 27 20:12:14 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 (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2S1BmKK023836 for ; Fri, 27 Mar 2009 20:12:04 -0500 X-ASG-Debug-ID: 1238202691-51e001f90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from alopias.GreenKey.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEB8613D6241 for ; Fri, 27 Mar 2009 18:11:31 -0700 (PDT) Received: from alopias.GreenKey.net (alopias.GreenKey.net [209.209.60.60]) by cuda.sgi.com with ESMTP id QTSrw8AsFo17USC2 for ; Fri, 27 Mar 2009 18:11:31 -0700 (PDT) Received: from [10.1.1.124] (unknown [209.209.31.8]) (Authenticated sender: curtis) by alopias.GreenKey.net (Postfix) with ESMTP id 7242F6F05C for ; Fri, 27 Mar 2009 18:10:58 -0700 (PDT) Message-ID: <49CD7912.6080508@GreenKey.net> Date: Fri, 27 Mar 2009 18:10:42 -0700 From: Curtis Doty User-Agent: Thundahboyd (Windoze XP; en-US) MIME-Version: 1.0 To: XFS X-ASG-Orig-Subj: why xfs_write() race with O_DIRECT only? Subject: why xfs_write() race with O_DIRECT only? X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: alopias.GreenKey.net[209.209.60.60] X-Barracuda-Start-Time: 1238202712 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.21534 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'm guessing this is the race fixed in 2.6.29. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=25051158 But my app is running O_DIRECT and only calls pwrite(). Is there something I'm missing that explains the aio stuff etc.? ../C ------------[ cut here ]------------ WARNING: at fs/xfs/linux-2.6/xfs_lrw.c:724 xfs_write+0x364/0x694() Modules linked in: dm_mod sg usbhid usbkbd usbmouse qla2xxx firmware_class scsi_transport_fc bnx2 hpilo ipmi_si ipmi_msghandler container shpchp pci_hotplug rng_core iTCO_wdt iTCO_vendor_support thermal button processor rtc_cmos rtc_core rtc_lib ehci_hcd uhci_hcd usbcore Pid: 5789, comm: myServer Not tainted 2.6.28.9 #1 Call Trace: [] warn_on_slowpath+0x41/0x5b [] ? mempool_alloc+0x21/0xbc [] ? xfs_vm_direct_IO+0x90/0xb4 [] ? xfs_get_blocks_direct+0x0/0x14 [] ? xfs_end_io_direct+0x0/0x5c [] ? generic_file_direct_write+0x184/0x1dc [] ? xfs_trans_unlocked_item+0x28/0x3e [] xfs_write+0x364/0x694 [] ? read_tsc+0x9/0x26 [] ? getnstimeofday+0x54/0xe4 [] xfs_file_aio_write+0x50/0x58 [] do_sync_write+0xab/0xe6 [] ? autoremove_wake_function+0x0/0x33 [] ? schedule+0x737/0x785 [] ? read_tsc+0x9/0x26 [] ? do_sync_write+0x0/0xe6 [] vfs_write+0x8c/0x108 [] sys_pwrite64+0x45/0x60 [] sysenter_do_call+0x12/0x21 [] ? hpwdt_init_one+0x103/0x38d ---[ end trace 3985be2a3d46f5ef ]--- From sandeen@sandeen.net Sat Mar 28 09:55: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.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2SEt7pd066674 for ; Sat, 28 Mar 2009 09:55:17 -0500 X-ASG-Debug-ID: 1238252093-4c4f03280000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C47CC13D6E8E for ; Sat, 28 Mar 2009 07:54:53 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id gJ3GpVjJgM1WJ3qm for ; Sat, 28 Mar 2009 07:54:53 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id C3331AC627C for ; Sat, 28 Mar 2009 09:54:18 -0500 (CDT) Message-ID: <49CE3A1A.9020103@sandeen.net> Date: Sat, 28 Mar 2009 09:54:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: xfstests license clarification? Subject: xfstests license clarification? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1238252114 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.21586 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 Since most of the scripts themselves in xfstests make no mention of redistribution, and only say "copyright sgi, all rights reserved" etc: #----------------------------------------------------------------------- # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. #----------------------------------------------------------------------- do we need to do anything in terms of making this look more like Free Software (assuming that's the intent?) It might be a rats-nest, there are a several testcases in src/ gleaned from mailing lists & bugs with little or no attribution; OTOH maybe this stuff is trivial enough that it doesn't warrant copyright, I dunno. Is it worth trying to clarify the license on the collection, or is this just a can of worms? -Eric From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:39:31 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 n2T7ctqL117698 for ; Sun, 29 Mar 2009 02:39:21 -0500 X-ASG-Debug-ID: 1238312291-7cb0030a0000-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 8DCF51D1517 for ; Sun, 29 Mar 2009 00:38:11 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 3dBRHuwfjlfEIlIV for ; Sun, 29 Mar 2009 00:38:11 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnpar-0006Pm-PB; Sun, 29 Mar 2009 07:38:09 +0000 Date: Sun, 29 Mar 2009 03:38:09 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss X-ASG-Orig-Subj: Re: xfstests license clarification? Subject: Re: xfstests license clarification? Message-ID: <20090329073809.GA10444@infradead.org> References: <49CE3A1A.9020103@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CE3A1A.9020103@sandeen.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: 1238312311 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 Sat, Mar 28, 2009 at 09:54:18AM -0500, Eric Sandeen wrote: > Since most of the scripts themselves in xfstests make no mention of > redistribution, and only say "copyright sgi, all rights reserved" etc: > > #----------------------------------------------------------------------- > # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. > #----------------------------------------------------------------------- > > do we need to do anything in terms of making this look more like Free > Software (assuming that's the intent?) > > It might be a rats-nest, there are a several testcases in src/ gleaned > from mailing lists & bugs with little or no attribution; OTOH maybe this > stuff is trivial enough that it doesn't warrant copyright, I dunno. > > Is it worth trying to clarify the license on the collection, or is this > just a can of worms? While only a couple of files have the same, just with me as a copyright holder I'm willing to license it under whatever free license suits best. I suspect BSD might be best for test code like this. From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:43: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2T7hVUg118045 for ; Sun, 29 Mar 2009 02:43:46 -0500 X-ASG-Debug-ID: 1238312602-695e01ed0000-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 7124113D8320 for ; Sun, 29 Mar 2009 00:43:22 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id WxY0d2b4yzzboosP for ; Sun, 29 Mar 2009 00:43:22 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnpfK-0004H1-Bp for xfs@oss.sgi.com; Sun, 29 Mar 2009 07:42:46 +0000 Date: Sun, 29 Mar 2009 03:42:46 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: validate quota log items during log recovery Subject: Re: [PATCH] xfs: validate quota log items during log recovery Message-ID: <20090329074246.GA16402@infradead.org> References: <20090303175427.GA20582@infradead.org> <20090316075407.GB19858@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316075407.GB19858@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: 1238312623 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 ping^2? On Mon, Mar 16, 2009 at 03:54:07AM -0400, Christoph Hellwig wrote: > ping? > > On Tue, Mar 03, 2009 at 12:54:27PM -0500, Christoph Hellwig wrote: > > 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< > + > > + memcpy(xfs_buf_offset(bp, > > + (uint)bit << XFS_BLI_SHIFT), /* dest */ > > + item->ri_buf[i].i_addr, /* source */ > > + nbits< > + next: > > i++; > > bit += nbits; > > } > > @@ -2615,7 +2625,15 @@ xlog_recover_do_dquot_trans( > > return (0); > > > > recddq = (xfs_disk_dquot_t *)item->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. > > */ > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:45:00 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_42, J_CHICKENPOX_45,J_CHICKENPOX_63,J_CHICKENPOX_64 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2T7iYVn118097 for ; Sun, 29 Mar 2009 02:44:49 -0500 X-ASG-Debug-ID: 1238312685-696d01f40000-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 20F9F13D8322 for ; Sun, 29 Mar 2009 00:44:45 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id IqTDL7kRtB6hkzlV for ; Sun, 29 Mar 2009 00:44:45 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnpgf-0004LR-2S for xfs@oss.sgi.com; Sun, 29 Mar 2009 07:44:09 +0000 Date: Sun, 29 Mar 2009 03:44:09 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: kill xfs_qmops Subject: Re: [PATCH] xfs: kill xfs_qmops Message-ID: <20090329074408.GB16402@infradead.org> References: <20090224143736.GA16616@infradead.org> <20090316075529.GA22373@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316075529.GA22373@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: 1238312686 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 ping^2? On Mon, Mar 16, 2009 at 03:55:29AM -0400, Christoph Hellwig wrote: > ping? > > On Tue, Feb 24, 2009 at 09:37:36AM -0500, Christoph Hellwig wrote: > > > > Kill the quota ops function vector and replace it with direct calls or > > stubs in the CONFIG_XFS_QUOTA=n case. > > > > Make sure we check XFS_IS_QUOTA_RUNNING in the right spots. We can remove > > the number of those checks because the XFS_TRANS_DQ_DIRTY flag can't be set > > otherwise. > > > > This brings us back closer to the way this code worked in IRIX and earlier > > Linux versions, but we keep a lot of the more useful factoring of common > > code. > > > > Eventually we should also kill xfs_qm_bhv.c, but that's left for a later > > patch. > > > > Reduces the size of the source code by about 250 lines and the size of > > XFS module by about 1.5 kilobytes with quotas enabled: > > > > text data bss dec hex filename > > 615957 2960 3848 622765 980ad fs/xfs/xfs.o > > 617231 3152 3848 624231 98667 fs/xfs/xfs.o.old > > > > > > Fallout: > > > > - xfs_qm_dqattach is split into xfs_qm_dqattach_locked which expects > > the inode locked and xfs_qm_dqattach which does the locking around it, > > thus removing XFS_QMOPT_ILOCKED. > > > > Signed-off-by: Christoph Hellwig > > > > Index: xfs/fs/xfs/quota/xfs_trans_dquot.c > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2009-02-24 15:32:16.063369993 +0100 > > +++ xfs/fs/xfs/quota/xfs_trans_dquot.c 2009-02-24 15:32:35.845494182 +0100 > > @@ -111,7 +111,7 @@ xfs_trans_log_dquot( > > * Carry forward whatever is left of the quota blk reservation to > > * the spanky new transaction > > */ > > -STATIC void > > +void > > xfs_trans_dup_dqinfo( > > xfs_trans_t *otp, > > xfs_trans_t *ntp) > > @@ -167,19 +167,17 @@ xfs_trans_dup_dqinfo( > > /* > > * Wrap around mod_dquot to account for both user and group quotas. > > */ > > -STATIC void > > +void > > xfs_trans_mod_dquot_byino( > > xfs_trans_t *tp, > > xfs_inode_t *ip, > > uint field, > > long delta) > > { > > - xfs_mount_t *mp; > > + xfs_mount_t *mp = tp->t_mountp; > > > > - ASSERT(tp); > > - mp = tp->t_mountp; > > - > > - if (!XFS_IS_QUOTA_ON(mp) || > > + if (!XFS_IS_QUOTA_RUNNING(mp) || > > + !XFS_IS_QUOTA_ON(mp) || > > ip->i_ino == mp->m_sb.sb_uquotino || > > ip->i_ino == mp->m_sb.sb_gquotino) > > return; > > @@ -229,6 +227,7 @@ xfs_trans_mod_dquot( > > xfs_dqtrx_t *qtrx; > > > > ASSERT(tp); > > + ASSERT(XFS_IS_QUOTA_RUNNING(tp->t_mountp)); > > qtrx = NULL; > > > > if (tp->t_dqinfo == NULL) > > @@ -346,7 +345,7 @@ xfs_trans_dqlockedjoin( > > * Unreserve just the reservations done by this transaction. > > * dquot is still left locked at exit. > > */ > > -STATIC void > > +void > > xfs_trans_apply_dquot_deltas( > > xfs_trans_t *tp) > > { > > @@ -357,7 +356,7 @@ xfs_trans_apply_dquot_deltas( > > long totalbdelta; > > long totalrtbdelta; > > > > - if (! (tp->t_flags & XFS_TRANS_DQ_DIRTY)) > > + if (!(tp->t_flags & XFS_TRANS_DQ_DIRTY)) > > return; > > > > ASSERT(tp->t_dqinfo); > > @@ -531,7 +530,7 @@ xfs_trans_apply_dquot_deltas( > > * we simply throw those away, since that's the expected behavior > > * when a transaction is curtailed without a commit. > > */ > > -STATIC void > > +void > > xfs_trans_unreserve_and_mod_dquots( > > xfs_trans_t *tp) > > { > > @@ -768,6 +767,8 @@ xfs_trans_reserve_quota_bydquots( > > { > > int resvd = 0, error; > > > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > > + return 0; > > if (!XFS_IS_QUOTA_ON(mp)) > > return 0; > > > > @@ -811,17 +812,18 @@ xfs_trans_reserve_quota_bydquots( > > * This doesn't change the actual usage, just the reservation. > > * The inode sent in is locked. > > */ > > -STATIC int > > +int > > xfs_trans_reserve_quota_nblks( > > - xfs_trans_t *tp, > > - xfs_mount_t *mp, > > - xfs_inode_t *ip, > > - long nblks, > > - long ninos, > > - uint flags) > > + struct xfs_trans *tp, > > + struct xfs_inode *ip, > > + long nblks, > > + long ninos, > > + uint flags) > > { > > - int error; > > + struct xfs_mount *mp = ip->i_mount; > > > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > > + return 0; > > if (!XFS_IS_QUOTA_ON(mp)) > > return 0; > > if (XFS_IS_PQUOTA_ON(mp)) > > @@ -831,7 +833,6 @@ xfs_trans_reserve_quota_nblks( > > ASSERT(ip->i_ino != mp->m_sb.sb_gquotino); > > > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > - ASSERT(XFS_IS_QUOTA_RUNNING(ip->i_mount)); > > ASSERT((flags & ~(XFS_QMOPT_FORCE_RES | XFS_QMOPT_ENOSPC)) == > > XFS_TRANS_DQ_RES_RTBLKS || > > (flags & ~(XFS_QMOPT_FORCE_RES | XFS_QMOPT_ENOSPC)) == > > @@ -840,11 +841,9 @@ xfs_trans_reserve_quota_nblks( > > /* > > * Reserve nblks against these dquots, with trans as the mediator. > > */ > > - error = xfs_trans_reserve_quota_bydquots(tp, mp, > > - ip->i_udquot, ip->i_gdquot, > > - nblks, ninos, > > - flags); > > - return error; > > + return xfs_trans_reserve_quota_bydquots(tp, mp, > > + ip->i_udquot, ip->i_gdquot, > > + nblks, ninos, flags); > > } > > > > /* > > @@ -895,25 +894,15 @@ STATIC void > > xfs_trans_alloc_dqinfo( > > xfs_trans_t *tp) > > { > > - (tp)->t_dqinfo = kmem_zone_zalloc(xfs_Gqm->qm_dqtrxzone, KM_SLEEP); > > + tp->t_dqinfo = kmem_zone_zalloc(xfs_Gqm->qm_dqtrxzone, KM_SLEEP); > > } > > > > -STATIC void > > +void > > xfs_trans_free_dqinfo( > > xfs_trans_t *tp) > > { > > if (!tp->t_dqinfo) > > return; > > - kmem_zone_free(xfs_Gqm->qm_dqtrxzone, (tp)->t_dqinfo); > > - (tp)->t_dqinfo = NULL; > > + kmem_zone_free(xfs_Gqm->qm_dqtrxzone, tp->t_dqinfo); > > + tp->t_dqinfo = NULL; > > } > > - > > -xfs_dqtrxops_t xfs_trans_dquot_ops = { > > - .qo_dup_dqinfo = xfs_trans_dup_dqinfo, > > - .qo_free_dqinfo = xfs_trans_free_dqinfo, > > - .qo_mod_dquot_byino = xfs_trans_mod_dquot_byino, > > - .qo_apply_dquot_deltas = xfs_trans_apply_dquot_deltas, > > - .qo_reserve_quota_nblks = xfs_trans_reserve_quota_nblks, > > - .qo_reserve_quota_bydquots = xfs_trans_reserve_quota_bydquots, > > - .qo_unreserve_and_mod_dquots = xfs_trans_unreserve_and_mod_dquots, > > -}; > > Index: xfs/fs/xfs/xfs_quota.h > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_quota.h 2009-02-24 15:32:16.089369812 +0100 > > +++ xfs/fs/xfs/xfs_quota.h 2009-02-24 15:32:35.846494310 +0100 > > @@ -197,7 +197,6 @@ typedef struct xfs_qoff_logformat { > > #define XFS_QMOPT_UMOUNTING 0x0000100 /* filesys is being unmounted */ > > #define XFS_QMOPT_DOLOG 0x0000200 /* log buf changes (in quotacheck) */ > > #define XFS_QMOPT_DOWARN 0x0000400 /* increase warning cnt if needed */ > > -#define XFS_QMOPT_ILOCKED 0x0000800 /* inode is already locked (excl) */ > > #define XFS_QMOPT_DQREPAIR 0x0001000 /* repair dquot if damaged */ > > #define XFS_QMOPT_GQUOTA 0x0002000 /* group dquot requested */ > > #define XFS_QMOPT_ENOSPC 0x0004000 /* enospc instead of edquot (prj) */ > > @@ -302,69 +301,72 @@ typedef struct xfs_dqtrx { > > long qt_delrtb_delta; /* delayed RT blk count changes */ > > } xfs_dqtrx_t; > > > > -/* > > - * Dquot transaction functions, used if quota is enabled. > > - */ > > -typedef void (*qo_dup_dqinfo_t)(struct xfs_trans *, struct xfs_trans *); > > -typedef void (*qo_mod_dquot_byino_t)(struct xfs_trans *, > > - struct xfs_inode *, uint, long); > > -typedef void (*qo_free_dqinfo_t)(struct xfs_trans *); > > -typedef void (*qo_apply_dquot_deltas_t)(struct xfs_trans *); > > -typedef void (*qo_unreserve_and_mod_dquots_t)(struct xfs_trans *); > > -typedef int (*qo_reserve_quota_nblks_t)( > > - struct xfs_trans *, struct xfs_mount *, > > - struct xfs_inode *, long, long, uint); > > -typedef int (*qo_reserve_quota_bydquots_t)( > > - struct xfs_trans *, struct xfs_mount *, > > - struct xfs_dquot *, struct xfs_dquot *, > > - long, long, uint); > > -typedef struct xfs_dqtrxops { > > - qo_dup_dqinfo_t qo_dup_dqinfo; > > - qo_free_dqinfo_t qo_free_dqinfo; > > - qo_mod_dquot_byino_t qo_mod_dquot_byino; > > - qo_apply_dquot_deltas_t qo_apply_dquot_deltas; > > - qo_reserve_quota_nblks_t qo_reserve_quota_nblks; > > - qo_reserve_quota_bydquots_t qo_reserve_quota_bydquots; > > - qo_unreserve_and_mod_dquots_t qo_unreserve_and_mod_dquots; > > -} xfs_dqtrxops_t; > > - > > -#define XFS_DQTRXOP(mp, tp, op, args...) \ > > - ((mp)->m_qm_ops->xfs_dqtrxops ? \ > > - ((mp)->m_qm_ops->xfs_dqtrxops->op)(tp, ## args) : 0) > > - > > -#define XFS_DQTRXOP_VOID(mp, tp, op, args...) \ > > - ((mp)->m_qm_ops->xfs_dqtrxops ? \ > > - ((mp)->m_qm_ops->xfs_dqtrxops->op)(tp, ## args) : (void)0) > > - > > -#define XFS_TRANS_DUP_DQINFO(mp, otp, ntp) \ > > - XFS_DQTRXOP_VOID(mp, otp, qo_dup_dqinfo, ntp) > > -#define XFS_TRANS_FREE_DQINFO(mp, tp) \ > > - XFS_DQTRXOP_VOID(mp, tp, qo_free_dqinfo) > > -#define XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, field, delta) \ > > - XFS_DQTRXOP_VOID(mp, tp, qo_mod_dquot_byino, ip, field, delta) > > -#define XFS_TRANS_APPLY_DQUOT_DELTAS(mp, tp) \ > > - XFS_DQTRXOP_VOID(mp, tp, qo_apply_dquot_deltas) > > -#define XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, nblks, ninos, fl) \ > > - XFS_DQTRXOP(mp, tp, qo_reserve_quota_nblks, mp, ip, nblks, ninos, fl) > > -#define XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, nb, ni, fl) \ > > - XFS_DQTRXOP(mp, tp, qo_reserve_quota_bydquots, mp, ud, gd, nb, ni, fl) > > -#define XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp) \ > > - XFS_DQTRXOP_VOID(mp, tp, qo_unreserve_and_mod_dquots) > > - > > -#define XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, nblks, ninos, flags) \ > > - XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, -(nblks), -(ninos), flags) > > -#define XFS_TRANS_RESERVE_QUOTA(mp, tp, ud, gd, nb, ni, f) \ > > - XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, nb, ni, \ > > - f | XFS_QMOPT_RES_REGBLKS) > > -#define XFS_TRANS_UNRESERVE_QUOTA(mp, tp, ud, gd, nb, ni, f) \ > > - XFS_TRANS_RESERVE_QUOTA_BYDQUOTS(mp, tp, ud, gd, -(nb), -(ni), \ > > +#ifdef CONFIG_XFS_QUOTA > > +extern void xfs_trans_dup_dqinfo(struct xfs_trans *, struct xfs_trans *); > > +extern void xfs_trans_free_dqinfo(struct xfs_trans *); > > +extern void xfs_trans_mod_dquot_byino(struct xfs_trans *, struct xfs_inode *, > > + uint, long); > > +extern void xfs_trans_apply_dquot_deltas(struct xfs_trans *); > > +extern void xfs_trans_unreserve_and_mod_dquots(struct xfs_trans *); > > +extern int xfs_trans_reserve_quota_nblks(struct xfs_trans *, > > + struct xfs_inode *, long, long, uint); > > +extern int xfs_trans_reserve_quota_bydquots(struct xfs_trans *, > > + struct xfs_mount *, struct xfs_dquot *, > > + struct xfs_dquot *, long, long, uint); > > + > > +extern int xfs_qm_vop_dqalloc(struct xfs_inode *, uid_t, gid_t, prid_t, uint, > > + struct xfs_dquot **, struct xfs_dquot **); > > +extern void xfs_qm_vop_create_dqattach(struct xfs_trans *, struct xfs_inode *, > > + struct xfs_dquot *, struct xfs_dquot *); > > +extern int xfs_qm_vop_rename_dqattach(struct xfs_inode **); > > +extern struct xfs_dquot *xfs_qm_vop_chown(struct xfs_trans *, > > + struct xfs_inode *, struct xfs_dquot **, struct xfs_dquot *); > > +extern int xfs_qm_vop_chown_reserve(struct xfs_trans *, struct xfs_inode *, > > + struct xfs_dquot *, struct xfs_dquot *, uint); > > +extern int xfs_qm_dqattach(struct xfs_inode *, uint); > > +extern int xfs_qm_dqattach_locked(struct xfs_inode *, uint); > > +extern void xfs_qm_dqdetach(struct xfs_inode *); > > +extern void xfs_qm_dqrele(struct xfs_dquot *); > > +extern void xfs_qm_statvfs(struct xfs_inode *, struct kstatfs *); > > +extern int xfs_qm_sync(struct xfs_mount *, int); > > +extern int xfs_qm_newmount(struct xfs_mount *, uint *, uint *); > > +extern void xfs_qm_mount_quotas(struct xfs_mount *); > > +extern void xfs_qm_unmount(struct xfs_mount *); > > +extern void xfs_qm_unmount_quotas(struct xfs_mount *); > > + > > +#else > > +#define xfs_trans_dup_dqinfo(tp, tp2) > > +#define xfs_trans_free_dqinfo(tp) > > +#define xfs_trans_mod_dquot_byino(tp, ip, fields, delta) > > +#define xfs_trans_apply_dquot_deltas(tp) > > +#define xfs_trans_unreserve_and_mod_dquots(tp) > > +#define xfs_trans_reserve_quota_nblks(tp, ip, nblks, ninos, flags) (0) > > +#define xfs_trans_reserve_quota_bydquots(tp, mp, u, g, nb, ni, fl) (0) > > +#define xfs_qm_vop_dqalloc(ip, uid, gid, prid, fl, ou, og) (0) > > +#define xfs_qm_vop_create_dqattach(tp, ip, u, g) > > +#define xfs_qm_vop_rename_dqattach(it) (0) > > +#define xfs_qm_vop_chown(tp, ip, old, new) (NULL) > > +#define xfs_qm_vop_chown_reserve(tp, ip, u, g, fl) (0) > > +#define xfs_qm_dqattach(ip, fl) (0) > > +#define xfs_qm_dqattach_locked(ip, fl) (0) > > +#define xfs_qm_dqdetach(ip) > > +#define xfs_qm_dqrele(d) > > +#define xfs_qm_statvfs(ip, s) > > +#define xfs_qm_sync(mp, fl) (0) > > +#define xfs_qm_newmount(mp, a, b) (0) > > +#define xfs_qm_mount_quotas(mp) > > +#define xfs_qm_unmount(mp) > > +#define xfs_qm_unmount_quotas(mp) (0) > > +#endif /* CONFIG_XFS_QUOTA */ > > + > > +#define xfs_trans_unreserve_quota_nblks(tp, ip, nblks, ninos, flags) \ > > + xfs_trans_reserve_quota_nblks(tp, ip, -(nblks), -(ninos), flags) > > +#define xfs_trans_reserve_quota(tp, mp, ud, gd, nb, ni, f) \ > > + xfs_trans_reserve_quota_bydquots(tp, mp, ud, gd, nb, ni, \ > > f | XFS_QMOPT_RES_REGBLKS) > > > > extern int xfs_qm_dqcheck(xfs_disk_dquot_t *, xfs_dqid_t, uint, uint, char *); > > extern int xfs_mount_reset_sbqflags(struct xfs_mount *); > > > > -extern struct xfs_qmops xfs_qmcore_xfs; > > - > > #endif /* __KERNEL__ */ > > - > > #endif /* __XFS_QUOTA_H__ */ > > Index: xfs/fs/xfs/xfs_trans.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_trans.c 2009-02-24 15:32:16.093370321 +0100 > > +++ xfs/fs/xfs/xfs_trans.c 2009-02-24 15:32:35.847494368 +0100 > > @@ -297,7 +297,7 @@ xfs_trans_dup( > > tp->t_rtx_res = tp->t_rtx_res_used; > > ntp->t_pflags = tp->t_pflags; > > > > - XFS_TRANS_DUP_DQINFO(tp->t_mountp, tp, ntp); > > + xfs_trans_dup_dqinfo(tp, ntp); > > > > atomic_inc(&tp->t_mountp->m_active_trans); > > return ntp; > > @@ -831,7 +831,7 @@ shut_us_down: > > * means is that we have some (non-persistent) quota > > * reservations that need to be unreserved. > > */ > > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp); > > + xfs_trans_unreserve_and_mod_dquots(tp); > > if (tp->t_ticket) { > > commit_lsn = xfs_log_done(mp, tp->t_ticket, > > NULL, log_flags); > > @@ -850,10 +850,9 @@ shut_us_down: > > /* > > * If we need to update the superblock, then do it now. > > */ > > - if (tp->t_flags & XFS_TRANS_SB_DIRTY) { > > + if (tp->t_flags & XFS_TRANS_SB_DIRTY) > > xfs_trans_apply_sb_deltas(tp); > > - } > > - XFS_TRANS_APPLY_DQUOT_DELTAS(mp, tp); > > + xfs_trans_apply_dquot_deltas(tp); > > > > /* > > * Ask each log item how many log_vector entries it will > > @@ -1058,7 +1057,7 @@ xfs_trans_uncommit( > > } > > > > xfs_trans_unreserve_and_mod_sb(tp); > > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(tp->t_mountp, tp); > > + xfs_trans_unreserve_and_mod_dquots(tp); > > > > xfs_trans_free_items(tp, flags); > > xfs_trans_free_busy(tp); > > @@ -1183,7 +1182,7 @@ xfs_trans_cancel( > > } > > #endif > > xfs_trans_unreserve_and_mod_sb(tp); > > - XFS_TRANS_UNRESERVE_AND_MOD_DQUOTS(mp, tp); > > + xfs_trans_unreserve_and_mod_dquots(tp); > > > > if (tp->t_ticket) { > > if (flags & XFS_TRANS_RELEASE_LOG_RES) { > > @@ -1213,7 +1212,7 @@ xfs_trans_free( > > xfs_trans_t *tp) > > { > > atomic_dec(&tp->t_mountp->m_active_trans); > > - XFS_TRANS_FREE_DQINFO(tp->t_mountp, tp); > > + xfs_trans_free_dqinfo(tp); > > kmem_zone_free(xfs_trans_zone, tp); > > } > > > > Index: xfs/fs/xfs/xfs_utils.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_utils.c 2009-02-24 15:32:16.098369701 +0100 > > +++ xfs/fs/xfs/xfs_utils.c 2009-02-24 15:32:35.848494914 +0100 > > @@ -166,7 +166,7 @@ xfs_dir_ialloc( > > xfs_buf_relse(ialloc_context); > > if (dqinfo) { > > tp->t_dqinfo = dqinfo; > > - XFS_TRANS_FREE_DQINFO(tp->t_mountp, tp); > > + xfs_trans_free_dqinfo(tp); > > } > > *tpp = ntp; > > *ipp = NULL; > > Index: xfs/fs/xfs/xfs_bmap.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-24 15:32:16.102370140 +0100 > > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-24 15:32:35.853494922 +0100 > > @@ -2691,7 +2691,7 @@ xfs_bmap_rtalloc( > > * Adjust the disk quota also. This was reserved > > * earlier. > > */ > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, ap->tp, ap->ip, > > + xfs_trans_mod_dquot_byino(ap->tp, ap->ip, > > ap->wasdel ? XFS_TRANS_DQ_DELRTBCOUNT : > > XFS_TRANS_DQ_RTBCOUNT, (long) ralen); > > } else { > > @@ -2995,7 +2995,7 @@ xfs_bmap_btalloc( > > * Adjust the disk quota also. This was reserved > > * earlier. > > */ > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, ap->tp, ap->ip, > > + xfs_trans_mod_dquot_byino(ap->tp, ap->ip, > > ap->wasdel ? XFS_TRANS_DQ_DELBCOUNT : > > XFS_TRANS_DQ_BCOUNT, > > (long) args.len); > > @@ -3066,7 +3066,7 @@ xfs_bmap_btree_to_extents( > > return error; > > xfs_bmap_add_free(cbno, 1, cur->bc_private.b.flist, mp); > > ip->i_d.di_nblocks--; > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > > xfs_trans_binval(tp, cbp); > > if (cur->bc_bufs[0] == cbp) > > cur->bc_bufs[0] = NULL; > > @@ -3386,7 +3386,7 @@ xfs_bmap_del_extent( > > * Adjust quota data. > > */ > > if (qfield) > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, qfield, (long)-nblks); > > + xfs_trans_mod_dquot_byino(tp, ip, qfield, (long)-nblks); > > > > /* > > * Account for change in delayed indirect blocks. > > @@ -3523,7 +3523,7 @@ xfs_bmap_extents_to_btree( > > *firstblock = cur->bc_private.b.firstblock = args.fsbno; > > cur->bc_private.b.allocated++; > > ip->i_d.di_nblocks++; > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, 1L); > > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, 1L); > > abp = xfs_btree_get_bufl(mp, tp, args.fsbno, 0); > > /* > > * Fill in the child block. > > @@ -3666,7 +3666,7 @@ xfs_bmap_local_to_extents( > > XFS_BMAP_TRACE_POST_UPDATE("new", ip, 0, whichfork); > > XFS_IFORK_NEXT_SET(ip, whichfork, 1); > > ip->i_d.di_nblocks = 1; > > - XFS_TRANS_MOD_DQUOT_BYINO(args.mp, tp, ip, > > + xfs_trans_mod_dquot_byino(tp, ip, > > XFS_TRANS_DQ_BCOUNT, 1L); > > flags |= xfs_ilog_fext(whichfork); > > } else { > > @@ -4024,7 +4024,7 @@ xfs_bmap_add_attrfork( > > XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) > > goto error0; > > xfs_ilock(ip, XFS_ILOCK_EXCL); > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? > > + error = xfs_trans_reserve_quota_nblks(tp, ip, blks, 0, rsvd ? > > XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : > > XFS_QMOPT_RES_REGBLKS); > > if (error) { > > @@ -4959,10 +4959,11 @@ xfs_bmapi( > > * adjusted later. We return if we haven't > > * allocated blocks already inside this loop. > > */ > > - if ((error = XFS_TRANS_RESERVE_QUOTA_NBLKS( > > - mp, NULL, ip, (long)alen, 0, > > + error = xfs_trans_reserve_quota_nblks( > > + NULL, ip, (long)alen, 0, > > rt ? XFS_QMOPT_RES_RTBLKS : > > - XFS_QMOPT_RES_REGBLKS))) { > > + XFS_QMOPT_RES_REGBLKS); > > + if (error) { > > if (n == 0) { > > *nmap = 0; > > ASSERT(cur == NULL); > > @@ -5011,8 +5012,8 @@ xfs_bmapi( > > if (XFS_IS_QUOTA_ON(mp)) > > /* unreserve the blocks now */ > > (void) > > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS( > > - mp, NULL, ip, > > + xfs_trans_unreserve_quota_nblks( > > + NULL, ip, > > (long)alen, 0, rt ? > > XFS_QMOPT_RES_RTBLKS : > > XFS_QMOPT_RES_REGBLKS); > > @@ -5667,14 +5668,14 @@ xfs_bunmapi( > > do_div(rtexts, mp->m_sb.sb_rextsize); > > xfs_mod_incore_sb(mp, XFS_SBS_FREXTENTS, > > (int64_t)rtexts, rsvd); > > - (void)XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, > > - NULL, ip, -((long)del.br_blockcount), 0, > > + (void)xfs_trans_reserve_quota_nblks(NULL, > > + ip, -((long)del.br_blockcount), 0, > > XFS_QMOPT_RES_RTBLKS); > > } else { > > xfs_mod_incore_sb(mp, XFS_SBS_FDBLOCKS, > > (int64_t)del.br_blockcount, rsvd); > > - (void)XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, > > - NULL, ip, -((long)del.br_blockcount), 0, > > + (void)xfs_trans_reserve_quota_nblks(NULL, > > + ip, -((long)del.br_blockcount), 0, > > XFS_QMOPT_RES_REGBLKS); > > } > > ip->i_delayed_blks -= del.br_blockcount; > > Index: xfs/fs/xfs/xfs_bmap_btree.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_bmap_btree.c 2009-02-24 15:32:16.106369811 +0100 > > +++ xfs/fs/xfs/xfs_bmap_btree.c 2009-02-24 15:32:35.854494491 +0100 > > @@ -590,7 +590,7 @@ xfs_bmbt_alloc_block( > > cur->bc_private.b.allocated++; > > cur->bc_private.b.ip->i_d.di_nblocks++; > > xfs_trans_log_inode(args.tp, cur->bc_private.b.ip, XFS_ILOG_CORE); > > - XFS_TRANS_MOD_DQUOT_BYINO(args.mp, args.tp, cur->bc_private.b.ip, > > + xfs_trans_mod_dquot_byino(args.tp, cur->bc_private.b.ip, > > XFS_TRANS_DQ_BCOUNT, 1L); > > > > new->l = cpu_to_be64(args.fsbno); > > @@ -618,7 +618,7 @@ xfs_bmbt_free_block( > > ip->i_d.di_nblocks--; > > > > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_BCOUNT, -1L); > > xfs_trans_binval(tp, bp); > > return 0; > > } > > Index: xfs/fs/xfs/xfs_vnodeops.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_vnodeops.c 2009-02-24 15:32:16.111370238 +0100 > > +++ xfs/fs/xfs/xfs_vnodeops.c 2009-02-24 15:32:35.855495805 +0100 > > @@ -118,7 +118,7 @@ xfs_setattr( > > */ > > ASSERT(udqp == NULL); > > ASSERT(gdqp == NULL); > > - code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, ip->i_d.di_projid, > > + code = xfs_qm_vop_dqalloc(ip, uid, gid, ip->i_d.di_projid, > > qflags, &udqp, &gdqp); > > if (code) > > return code; > > @@ -183,7 +183,7 @@ xfs_setattr( > > if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) || > > (XFS_IS_GQUOTA_ON(mp) && igid != gid)) { > > ASSERT(tp); > > - code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > > + code = xfs_qm_vop_chown_reserve(tp, ip, udqp, gdqp, > > capable(CAP_FOWNER) ? > > XFS_QMOPT_FORCE_RES : 0); > > if (code) /* out of quota */ > > @@ -217,7 +217,7 @@ xfs_setattr( > > /* > > * Make sure that the dquots are attached to the inode. > > */ > > - code = XFS_QM_DQATTACH(mp, ip, XFS_QMOPT_ILOCKED); > > + code = xfs_qm_dqattach_locked(ip, 0); > > if (code) > > goto error_return; > > > > @@ -354,7 +354,7 @@ xfs_setattr( > > if (XFS_IS_UQUOTA_ON(mp)) { > > ASSERT(mask & ATTR_UID); > > ASSERT(udqp); > > - olddquot1 = XFS_QM_DQVOPCHOWN(mp, tp, ip, > > + olddquot1 = xfs_qm_vop_chown(tp, ip, > > &ip->i_udquot, udqp); > > } > > ip->i_d.di_uid = uid; > > @@ -365,7 +365,7 @@ xfs_setattr( > > ASSERT(!XFS_IS_PQUOTA_ON(mp)); > > ASSERT(mask & ATTR_GID); > > ASSERT(gdqp); > > - olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, > > + olddquot2 = xfs_qm_vop_chown(tp, ip, > > &ip->i_gdquot, gdqp); > > } > > ip->i_d.di_gid = gid; > > @@ -461,10 +461,10 @@ xfs_setattr( > > /* > > * Release any dquot(s) the inode had kept before chown. > > */ > > - XFS_QM_DQRELE(mp, olddquot1); > > - XFS_QM_DQRELE(mp, olddquot2); > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(olddquot1); > > + xfs_qm_dqrele(olddquot2); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > if (code) { > > return code; > > @@ -482,8 +482,8 @@ xfs_setattr( > > commit_flags |= XFS_TRANS_ABORT; > > /* FALLTHROUGH */ > > error_return: > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > if (tp) { > > xfs_trans_cancel(tp, commit_flags); > > } > > @@ -739,7 +739,8 @@ xfs_free_eofblocks( > > /* > > * Attach the dquots to the inode up front. > > */ > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > > + error = xfs_qm_dqattach(ip, 0); > > + if (error) > > return error; > > > > /* > > @@ -1181,7 +1182,8 @@ xfs_inactive( > > > > ASSERT(ip->i_d.di_nlink == 0); > > > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > > + error = xfs_qm_dqattach(ip, 0); > > + if (error) > > return VN_INACTIVE_CACHE; > > > > tp = xfs_trans_alloc(mp, XFS_TRANS_INACTIVE); > > @@ -1307,7 +1309,7 @@ xfs_inactive( > > /* > > * Credit the quota account(s). The inode is gone. > > */ > > - XFS_TRANS_MOD_DQUOT_BYINO(mp, tp, ip, XFS_TRANS_DQ_ICOUNT, -1); > > + xfs_trans_mod_dquot_byino(tp, ip, XFS_TRANS_DQ_ICOUNT, -1); > > > > /* > > * Just ignore errors at this point. There is nothing we can > > @@ -1323,11 +1325,11 @@ xfs_inactive( > > xfs_fs_cmn_err(CE_NOTE, mp, "xfs_inactive: " > > "xfs_trans_commit() returned error %d", error); > > } > > + > > /* > > * Release the dquots held by inode, if any. > > */ > > - XFS_QM_DQDETACH(mp, ip); > > - > > + xfs_qm_dqdetach(ip); > > xfs_iunlock(ip, XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL); > > > > out: > > @@ -1398,14 +1400,16 @@ xfs_create( > > uint cancel_flags; > > int committed; > > xfs_prid_t prid; > > - struct xfs_dquot *udqp = NULL; > > - struct xfs_dquot *gdqp = NULL; > > + struct xfs_dquot *udqp, *gdqp; > > uint resblks; > > uint log_res; > > uint log_count; > > > > xfs_itrace_entry(dp); > > > > + udqp = NULL; > > + gdqp = NULL; > > + > > if (XFS_FORCED_SHUTDOWN(mp)) > > return XFS_ERROR(EIO); > > > > @@ -1427,8 +1431,7 @@ xfs_create( > > /* > > * Make sure that we have allocated dquot(s) on disk. > > */ > > - error = XFS_QM_DQVOPALLOC(mp, dp, > > - current_fsuid(), current_fsgid(), prid, > > + error = xfs_qm_vop_dqalloc(dp, current_fsuid(), current_fsgid(), prid, > > XFS_QMOPT_QUOTALL | XFS_QMOPT_INHERIT, &udqp, &gdqp); > > if (error) > > goto std_return; > > @@ -1482,7 +1485,7 @@ xfs_create( > > /* > > * Reserve disk quota and the inode. > > */ > > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, udqp, gdqp, resblks, 1, 0); > > + error = xfs_trans_reserve_quota(tp, mp, udqp, gdqp, resblks, 1, 0); > > if (error) > > goto out_trans_cancel; > > > > @@ -1554,7 +1557,7 @@ xfs_create( > > * These ids of the inode couldn't have changed since the new > > * inode has been locked ever since it was created. > > */ > > - XFS_QM_DQVOPCREATE(mp, tp, ip, udqp, gdqp); > > + xfs_qm_vop_create_dqattach(tp, ip, udqp, gdqp); > > > > /* > > * xfs_trans_commit normally decrements the vnode ref count > > @@ -1573,8 +1576,8 @@ xfs_create( > > goto out_dqrele; > > } > > > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > *ipp = ip; > > > > @@ -1595,8 +1598,8 @@ xfs_create( > > out_trans_cancel: > > xfs_trans_cancel(tp, cancel_flags); > > out_dqrele: > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > if (unlock_dp_on_error) > > xfs_iunlock(dp, XFS_ILOCK_EXCL); > > @@ -1830,11 +1833,11 @@ xfs_remove( > > return error; > > } > > > > - error = XFS_QM_DQATTACH(mp, dp, 0); > > + error = xfs_qm_dqattach(dp, 0); > > if (error) > > goto std_return; > > > > - error = XFS_QM_DQATTACH(mp, ip, 0); > > + error = xfs_qm_dqattach(ip, 0); > > if (error) > > goto std_return; > > > > @@ -2021,11 +2024,11 @@ xfs_link( > > > > /* Return through std_return after this point. */ > > > > - error = XFS_QM_DQATTACH(mp, sip, 0); > > + error = xfs_qm_dqattach(sip, 0); > > if (error) > > goto std_return; > > > > - error = XFS_QM_DQATTACH(mp, tdp, 0); > > + error = xfs_qm_dqattach(tdp, 0); > > if (error) > > goto std_return; > > > > @@ -2198,8 +2201,7 @@ xfs_symlink( > > /* > > * Make sure that we have allocated dquot(s) on disk. > > */ > > - error = XFS_QM_DQVOPALLOC(mp, dp, > > - current_fsuid(), current_fsgid(), prid, > > + error = xfs_qm_vop_dqalloc(dp, current_fsuid(), current_fsgid(), prid, > > XFS_QMOPT_QUOTALL | XFS_QMOPT_INHERIT, &udqp, &gdqp); > > if (error) > > goto std_return; > > @@ -2241,7 +2243,7 @@ xfs_symlink( > > /* > > * Reserve disk quota : blocks and inode. > > */ > > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, udqp, gdqp, resblks, 1, 0); > > + error = xfs_trans_reserve_quota(tp, mp, udqp, gdqp, resblks, 1, 0); > > if (error) > > goto error_return; > > > > @@ -2281,7 +2283,7 @@ xfs_symlink( > > /* > > * Also attach the dquot(s) to it, if applicable. > > */ > > - XFS_QM_DQVOPCREATE(mp, tp, ip, udqp, gdqp); > > + xfs_qm_vop_create_dqattach(tp, ip, udqp, gdqp); > > > > if (resblks) > > resblks -= XFS_IALLOC_SPACE_RES(mp); > > @@ -2369,8 +2371,8 @@ xfs_symlink( > > goto error2; > > } > > error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > /* Fall through to std_return with error = 0 or errno from > > * xfs_trans_commit */ > > @@ -2394,8 +2396,8 @@ std_return: > > cancel_flags |= XFS_TRANS_ABORT; > > error_return: > > xfs_trans_cancel(tp, cancel_flags); > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > if (unlock_dp_on_error) > > xfs_iunlock(dp, XFS_ILOCK_EXCL); > > @@ -2534,7 +2536,8 @@ xfs_alloc_file_space( > > if (XFS_FORCED_SHUTDOWN(mp)) > > return XFS_ERROR(EIO); > > > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > > + error = xfs_qm_dqattach(ip, 0); > > + if (error) > > return error; > > > > if (len <= 0) > > @@ -2621,8 +2624,8 @@ retry: > > break; > > } > > xfs_ilock(ip, XFS_ILOCK_EXCL); > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, > > - qblocks, 0, quota_flag); > > + error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks, > > + 0, quota_flag); > > if (error) > > goto error1; > > > > @@ -2681,7 +2684,7 @@ dmapi_enospc_check: > > > > error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ > > xfs_bmap_cancel(&free_list); > > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, qblocks, 0, quota_flag); > > + xfs_trans_unreserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > > > > error1: /* Just cancel transaction */ > > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT); > > @@ -2820,7 +2823,8 @@ xfs_free_file_space( > > > > xfs_itrace_entry(ip); > > > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > > + error = xfs_qm_dqattach(ip, 0); > > + if (error) > > return error; > > > > error = 0; > > @@ -2946,9 +2950,9 @@ xfs_free_file_space( > > break; > > } > > xfs_ilock(ip, XFS_ILOCK_EXCL); > > - error = XFS_TRANS_RESERVE_QUOTA(mp, tp, > > - ip->i_udquot, ip->i_gdquot, resblks, 0, > > - XFS_QMOPT_RES_REGBLKS); > > + error = xfs_trans_reserve_quota(tp, mp, > > + ip->i_udquot, ip->i_gdquot, > > + resblks, 0, XFS_QMOPT_RES_REGBLKS); > > if (error) > > goto error1; > > > > Index: xfs/fs/xfs/quota/xfs_qm.h > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_qm.h 2009-02-24 15:32:16.067369944 +0100 > > +++ xfs/fs/xfs/quota/xfs_qm.h 2009-02-24 15:32:35.856495653 +0100 > > @@ -127,8 +127,6 @@ typedef struct xfs_quotainfo { > > } xfs_quotainfo_t; > > > > > > -extern xfs_dqtrxops_t xfs_trans_dquot_ops; > > - > > extern void xfs_trans_mod_dquot(xfs_trans_t *, xfs_dquot_t *, uint, long); > > extern int xfs_trans_reserve_quota_bydquots(xfs_trans_t *, xfs_mount_t *, > > xfs_dquot_t *, xfs_dquot_t *, long, long, uint); > > @@ -159,17 +157,11 @@ typedef struct xfs_dquot_acct { > > #define XFS_QM_RTBWARNLIMIT 5 > > > > extern void xfs_qm_destroy_quotainfo(xfs_mount_t *); > > -extern void xfs_qm_mount_quotas(xfs_mount_t *); > > extern int xfs_qm_quotacheck(xfs_mount_t *); > > -extern void xfs_qm_unmount_quotadestroy(xfs_mount_t *); > > -extern void xfs_qm_unmount_quotas(xfs_mount_t *); > > extern int xfs_qm_write_sb_changes(xfs_mount_t *, __int64_t); > > -extern int xfs_qm_sync(xfs_mount_t *, int); > > > > /* dquot stuff */ > > extern boolean_t xfs_qm_dqalloc_incore(xfs_dquot_t **); > > -extern int xfs_qm_dqattach(xfs_inode_t *, uint); > > -extern void xfs_qm_dqdetach(xfs_inode_t *); > > extern int xfs_qm_dqpurge_all(xfs_mount_t *, uint); > > extern void xfs_qm_dqrele_all_inodes(xfs_mount_t *, uint); > > > > @@ -183,19 +175,6 @@ extern int xfs_qm_scall_getqstat(xfs_mo > > extern int xfs_qm_scall_quotaon(xfs_mount_t *, uint); > > extern int xfs_qm_scall_quotaoff(xfs_mount_t *, uint); > > > > -/* vop stuff */ > > -extern int xfs_qm_vop_dqalloc(xfs_mount_t *, xfs_inode_t *, > > - uid_t, gid_t, prid_t, uint, > > - xfs_dquot_t **, xfs_dquot_t **); > > -extern void xfs_qm_vop_dqattach_and_dqmod_newinode( > > - xfs_trans_t *, xfs_inode_t *, > > - xfs_dquot_t *, xfs_dquot_t *); > > -extern int xfs_qm_vop_rename_dqattach(xfs_inode_t **); > > -extern xfs_dquot_t * xfs_qm_vop_chown(xfs_trans_t *, xfs_inode_t *, > > - xfs_dquot_t **, xfs_dquot_t *); > > -extern int xfs_qm_vop_chown_reserve(xfs_trans_t *, xfs_inode_t *, > > - xfs_dquot_t *, xfs_dquot_t *, uint); > > - > > /* list stuff */ > > extern void xfs_qm_freelist_append(xfs_frlist_t *, xfs_dquot_t *); > > extern void xfs_qm_freelist_unlink(xfs_dquot_t *); > > Index: xfs/fs/xfs/quota/xfs_qm_bhv.c > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2009-02-24 15:32:16.071370174 +0100 > > +++ xfs/fs/xfs/quota/xfs_qm_bhv.c 2009-02-24 15:32:35.856495653 +0100 > > @@ -84,7 +84,7 @@ xfs_fill_statvfs_from_dquot( > > * return a statvfs of the project, not the entire filesystem. > > * This makes such trees appear as if they are filesystems in themselves. > > */ > > -STATIC void > > +void > > xfs_qm_statvfs( > > xfs_inode_t *ip, > > struct kstatfs *statp) > > @@ -92,20 +92,13 @@ xfs_qm_statvfs( > > xfs_mount_t *mp = ip->i_mount; > > xfs_dquot_t *dqp; > > > > - if (!(ip->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) || > > - !((mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD))) == > > - (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD)) > > - return; > > - > > if (!xfs_qm_dqget(mp, NULL, ip->i_d.di_projid, XFS_DQ_PROJ, 0, &dqp)) { > > - xfs_disk_dquot_t *dp = &dqp->q_core; > > - > > - xfs_fill_statvfs_from_dquot(statp, dp); > > + xfs_fill_statvfs_from_dquot(statp, &dqp->q_core); > > xfs_qm_dqput(dqp); > > } > > } > > > > -STATIC int > > +int > > xfs_qm_newmount( > > xfs_mount_t *mp, > > uint *needquotamount, > > @@ -114,9 +107,6 @@ xfs_qm_newmount( > > uint quotaondisk; > > uint uquotaondisk = 0, gquotaondisk = 0, pquotaondisk = 0; > > > > - *quotaflags = 0; > > - *needquotamount = B_FALSE; > > - > > quotaondisk = xfs_sb_version_hasquota(&mp->m_sb) && > > (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT); > > > > @@ -179,66 +169,6 @@ xfs_qm_newmount( > > return 0; > > } > > > > -STATIC int > > -xfs_qm_endmount( > > - xfs_mount_t *mp, > > - uint needquotamount, > > - uint quotaflags) > > -{ > > - if (needquotamount) { > > - ASSERT(mp->m_qflags == 0); > > - mp->m_qflags = quotaflags; > > - xfs_qm_mount_quotas(mp); > > - } > > - > > -#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) > > - if (! (XFS_IS_QUOTA_ON(mp))) > > - xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas not turned on"); > > - else > > - xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas turned on"); > > -#endif > > - > > -#ifdef QUOTADEBUG > > - if (XFS_IS_QUOTA_ON(mp) && xfs_qm_internalqcheck(mp)) > > - cmn_err(CE_WARN, "XFS: mount internalqcheck failed"); > > -#endif > > - > > - return 0; > > -} > > - > > -STATIC void > > -xfs_qm_dqrele_null( > > - xfs_dquot_t *dq) > > -{ > > - /* > > - * Called from XFS, where we always check first for a NULL dquot. > > - */ > > - if (!dq) > > - return; > > - xfs_qm_dqrele(dq); > > -} > > - > > - > > -struct xfs_qmops xfs_qmcore_xfs = { > > - .xfs_qminit = xfs_qm_newmount, > > - .xfs_qmdone = xfs_qm_unmount_quotadestroy, > > - .xfs_qmmount = xfs_qm_endmount, > > - .xfs_qmunmount = xfs_qm_unmount_quotas, > > - .xfs_dqrele = xfs_qm_dqrele_null, > > - .xfs_dqattach = xfs_qm_dqattach, > > - .xfs_dqdetach = xfs_qm_dqdetach, > > - .xfs_dqpurgeall = xfs_qm_dqpurge_all, > > - .xfs_dqvopalloc = xfs_qm_vop_dqalloc, > > - .xfs_dqvopcreate = xfs_qm_vop_dqattach_and_dqmod_newinode, > > - .xfs_dqvoprename = xfs_qm_vop_rename_dqattach, > > - .xfs_dqvopchown = xfs_qm_vop_chown, > > - .xfs_dqvopchownresv = xfs_qm_vop_chown_reserve, > > - .xfs_dqstatvfs = xfs_qm_statvfs, > > - .xfs_dqsync = xfs_qm_sync, > > - .xfs_dqtrxops = &xfs_trans_dquot_ops, > > -}; > > -EXPORT_SYMBOL(xfs_qmcore_xfs); > > - > > void __init > > xfs_qm_init(void) > > { > > Index: xfs/fs/xfs/xfs_attr.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_attr.c 2009-02-24 15:32:16.115370119 +0100 > > +++ xfs/fs/xfs/xfs_attr.c 2009-02-24 15:32:35.857495152 +0100 > > @@ -249,8 +249,9 @@ xfs_attr_set_int(xfs_inode_t *dp, struct > > /* > > * Attach the dquots to the inode. > > */ > > - if ((error = XFS_QM_DQATTACH(mp, dp, 0))) > > - return (error); > > + error = xfs_qm_dqattach(dp, 0); > > + if (error) > > + return error; > > > > /* > > * If the inode doesn't have an attribute fork, add one. > > @@ -311,7 +312,7 @@ xfs_attr_set_int(xfs_inode_t *dp, struct > > } > > xfs_ilock(dp, XFS_ILOCK_EXCL); > > > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, > > + error = xfs_trans_reserve_quota_nblks(args.trans, dp, args.total, 0, > > rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : > > XFS_QMOPT_RES_REGBLKS); > > if (error) { > > @@ -501,8 +502,9 @@ xfs_attr_remove_int(xfs_inode_t *dp, str > > /* > > * Attach the dquots to the inode. > > */ > > - if ((error = XFS_QM_DQATTACH(mp, dp, 0))) > > - return (error); > > + error = xfs_qm_dqattach(dp, 0); > > + if (error) > > + return error; > > > > /* > > * Start our first transaction of the day. > > Index: xfs/fs/xfs/xfs_iomap.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_iomap.c 2009-02-24 15:32:16.119370349 +0100 > > +++ xfs/fs/xfs/xfs_iomap.c 2009-02-24 15:32:35.858495489 +0100 > > @@ -417,7 +417,7 @@ xfs_iomap_write_direct( > > * Make sure that the dquots are there. This doesn't hold > > * the ilock across a disk read. > > */ > > - error = XFS_QM_DQATTACH(ip->i_mount, ip, XFS_QMOPT_ILOCKED); > > + error = xfs_qm_dqattach_locked(ip, 0); > > if (error) > > return XFS_ERROR(error); > > > > @@ -476,8 +476,7 @@ xfs_iomap_write_direct( > > if (error) > > goto error_out; > > > > - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, > > - qblocks, 0, quota_flag); > > + error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > > if (error) > > goto error1; > > > > @@ -527,7 +526,7 @@ xfs_iomap_write_direct( > > > > error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ > > xfs_bmap_cancel(&free_list); > > - XFS_TRANS_UNRESERVE_QUOTA_NBLKS(mp, tp, ip, qblocks, 0, quota_flag); > > + xfs_trans_unreserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); > > > > error1: /* Just cancel transaction */ > > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT); > > @@ -620,7 +619,7 @@ xfs_iomap_write_delay( > > * Make sure that the dquots are there. This doesn't hold > > * the ilock across a disk read. > > */ > > - error = XFS_QM_DQATTACH(mp, ip, XFS_QMOPT_ILOCKED); > > + error = xfs_qm_dqattach_locked(ip, 0); > > if (error) > > return XFS_ERROR(error); > > > > @@ -715,7 +714,8 @@ xfs_iomap_write_allocate( > > /* > > * Make sure that the dquots are there. > > */ > > - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) > > + error = xfs_qm_dqattach(ip, 0); > > + if (error) > > return XFS_ERROR(error); > > > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > > Index: xfs/fs/xfs/xfs_mount.h > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_mount.h 2009-02-24 15:32:16.124369938 +0100 > > +++ xfs/fs/xfs/xfs_mount.h 2009-02-24 15:32:35.859495267 +0100 > > @@ -18,6 +18,7 @@ > > #ifndef __XFS_MOUNT_H__ > > #define __XFS_MOUNT_H__ > > > > + > > typedef struct xfs_trans_reservations { > > uint tr_write; /* extent alloc trans */ > > uint tr_itruncate; /* truncate trans */ > > @@ -64,6 +65,8 @@ struct xfs_swapext; > > struct xfs_mru_cache; > > struct xfs_nameops; > > struct xfs_ail; > > +struct xfs_quotainfo; > > + > > > > /* > > * Prototypes and functions for the Data Migration subsystem. > > @@ -107,86 +110,6 @@ typedef struct xfs_dmops { > > (*(mp)->m_dm_ops->xfs_send_unmount)(mp,ip,right,mode,rval,fl) > > > > > > -/* > > - * Prototypes and functions for the Quota Management subsystem. > > - */ > > - > > -struct xfs_dquot; > > -struct xfs_dqtrxops; > > -struct xfs_quotainfo; > > - > > -typedef int (*xfs_qminit_t)(struct xfs_mount *, uint *, uint *); > > -typedef int (*xfs_qmmount_t)(struct xfs_mount *, uint, uint); > > -typedef void (*xfs_qmunmount_t)(struct xfs_mount *); > > -typedef void (*xfs_qmdone_t)(struct xfs_mount *); > > -typedef void (*xfs_dqrele_t)(struct xfs_dquot *); > > -typedef int (*xfs_dqattach_t)(struct xfs_inode *, uint); > > -typedef void (*xfs_dqdetach_t)(struct xfs_inode *); > > -typedef int (*xfs_dqpurgeall_t)(struct xfs_mount *, uint); > > -typedef int (*xfs_dqvopalloc_t)(struct xfs_mount *, > > - struct xfs_inode *, uid_t, gid_t, prid_t, uint, > > - struct xfs_dquot **, struct xfs_dquot **); > > -typedef void (*xfs_dqvopcreate_t)(struct xfs_trans *, struct xfs_inode *, > > - struct xfs_dquot *, struct xfs_dquot *); > > -typedef int (*xfs_dqvoprename_t)(struct xfs_inode **); > > -typedef struct xfs_dquot * (*xfs_dqvopchown_t)( > > - struct xfs_trans *, struct xfs_inode *, > > - struct xfs_dquot **, struct xfs_dquot *); > > -typedef int (*xfs_dqvopchownresv_t)(struct xfs_trans *, struct xfs_inode *, > > - struct xfs_dquot *, struct xfs_dquot *, uint); > > -typedef void (*xfs_dqstatvfs_t)(struct xfs_inode *, struct kstatfs *); > > -typedef int (*xfs_dqsync_t)(struct xfs_mount *, int flags); > > - > > -typedef struct xfs_qmops { > > - xfs_qminit_t xfs_qminit; > > - xfs_qmdone_t xfs_qmdone; > > - xfs_qmmount_t xfs_qmmount; > > - xfs_qmunmount_t xfs_qmunmount; > > - xfs_dqrele_t xfs_dqrele; > > - xfs_dqattach_t xfs_dqattach; > > - xfs_dqdetach_t xfs_dqdetach; > > - xfs_dqpurgeall_t xfs_dqpurgeall; > > - xfs_dqvopalloc_t xfs_dqvopalloc; > > - xfs_dqvopcreate_t xfs_dqvopcreate; > > - xfs_dqvoprename_t xfs_dqvoprename; > > - xfs_dqvopchown_t xfs_dqvopchown; > > - xfs_dqvopchownresv_t xfs_dqvopchownresv; > > - xfs_dqstatvfs_t xfs_dqstatvfs; > > - xfs_dqsync_t xfs_dqsync; > > - struct xfs_dqtrxops *xfs_dqtrxops; > > -} xfs_qmops_t; > > - > > -#define XFS_QM_INIT(mp, mnt, fl) \ > > - (*(mp)->m_qm_ops->xfs_qminit)(mp, mnt, fl) > > -#define XFS_QM_MOUNT(mp, mnt, fl) \ > > - (*(mp)->m_qm_ops->xfs_qmmount)(mp, mnt, fl) > > -#define XFS_QM_UNMOUNT(mp) \ > > - (*(mp)->m_qm_ops->xfs_qmunmount)(mp) > > -#define XFS_QM_DONE(mp) \ > > - (*(mp)->m_qm_ops->xfs_qmdone)(mp) > > -#define XFS_QM_DQRELE(mp, dq) \ > > - (*(mp)->m_qm_ops->xfs_dqrele)(dq) > > -#define XFS_QM_DQATTACH(mp, ip, fl) \ > > - (*(mp)->m_qm_ops->xfs_dqattach)(ip, fl) > > -#define XFS_QM_DQDETACH(mp, ip) \ > > - (*(mp)->m_qm_ops->xfs_dqdetach)(ip) > > -#define XFS_QM_DQPURGEALL(mp, fl) \ > > - (*(mp)->m_qm_ops->xfs_dqpurgeall)(mp, fl) > > -#define XFS_QM_DQVOPALLOC(mp, ip, uid, gid, prid, fl, dq1, dq2) \ > > - (*(mp)->m_qm_ops->xfs_dqvopalloc)(mp, ip, uid, gid, prid, fl, dq1, dq2) > > -#define XFS_QM_DQVOPCREATE(mp, tp, ip, dq1, dq2) \ > > - (*(mp)->m_qm_ops->xfs_dqvopcreate)(tp, ip, dq1, dq2) > > -#define XFS_QM_DQVOPRENAME(mp, ip) \ > > - (*(mp)->m_qm_ops->xfs_dqvoprename)(ip) > > -#define XFS_QM_DQVOPCHOWN(mp, tp, ip, dqp, dq) \ > > - (*(mp)->m_qm_ops->xfs_dqvopchown)(tp, ip, dqp, dq) > > -#define XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, dq1, dq2, fl) \ > > - (*(mp)->m_qm_ops->xfs_dqvopchownresv)(tp, ip, dq1, dq2, fl) > > -#define XFS_QM_DQSTATVFS(ip, statp) \ > > - (*(ip)->i_mount->m_qm_ops->xfs_dqstatvfs)(ip, statp) > > -#define XFS_QM_DQSYNC(mp, flags) \ > > - (*(mp)->m_qm_ops->xfs_dqsync)(mp, flags) > > - > > #ifdef HAVE_PERCPU_SB > > > > /* > > @@ -516,8 +439,6 @@ extern int xfs_sb_validate_fsb_count(str > > > > extern int xfs_dmops_get(struct xfs_mount *); > > extern void xfs_dmops_put(struct xfs_mount *); > > -extern int xfs_qmops_get(struct xfs_mount *); > > -extern void xfs_qmops_put(struct xfs_mount *); > > > > extern struct xfs_dmops xfs_dmcore_xfs; > > > > Index: xfs/fs/xfs/Makefile > > =================================================================== > > --- xfs.orig/fs/xfs/Makefile 2009-02-24 15:32:16.158369937 +0100 > > +++ xfs/fs/xfs/Makefile 2009-02-24 15:32:35.859495267 +0100 > > @@ -88,8 +88,7 @@ xfs-y += xfs_alloc.o \ > > xfs_utils.o \ > > xfs_vnodeops.o \ > > xfs_rw.o \ > > - xfs_dmops.o \ > > - xfs_qmops.o > > + xfs_dmops.o > > > > xfs-$(CONFIG_XFS_TRACE) += xfs_btree_trace.o \ > > xfs_dir2_trace.o > > 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:16.137370546 +0100 > > +++ xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2009-02-24 15:32:35.865370666 +0100 > > @@ -907,7 +907,7 @@ xfs_ioctl_setattr( > > struct xfs_mount *mp = ip->i_mount; > > struct xfs_trans *tp; > > unsigned int lock_flags = 0; > > - struct xfs_dquot *udqp = NULL, *gdqp = NULL; > > + struct xfs_dquot *udqp, *gdqp; > > struct xfs_dquot *olddquot = NULL; > > int code; > > > > @@ -918,6 +918,9 @@ xfs_ioctl_setattr( > > if (XFS_FORCED_SHUTDOWN(mp)) > > return XFS_ERROR(EIO); > > > > + udqp = NULL; > > + gdqp = NULL; > > + > > /* > > * If disk quotas is on, we make sure that the dquots do exist on disk, > > * before we start any other transactions. Trying to do this later > > @@ -927,7 +930,7 @@ xfs_ioctl_setattr( > > * because the i_*dquot fields will get updated anyway. > > */ > > if (XFS_IS_QUOTA_ON(mp) && (mask & FSX_PROJID)) { > > - code = XFS_QM_DQVOPALLOC(mp, ip, ip->i_d.di_uid, > > + code = xfs_qm_vop_dqalloc(ip, ip->i_d.di_uid, > > ip->i_d.di_gid, fa->fsx_projid, > > XFS_QMOPT_PQUOTA, &udqp, &gdqp); > > if (code) > > @@ -965,7 +968,7 @@ xfs_ioctl_setattr( > > if (XFS_IS_PQUOTA_ON(mp) && > > ip->i_d.di_projid != fa->fsx_projid) { > > ASSERT(tp); > > - code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > > + code = xfs_qm_vop_chown_reserve(tp, ip, udqp, gdqp, > > capable(CAP_FOWNER) ? > > XFS_QMOPT_FORCE_RES : 0); > > if (code) /* out of quota */ > > @@ -1068,7 +1071,7 @@ xfs_ioctl_setattr( > > */ > > if (ip->i_d.di_projid != fa->fsx_projid) { > > if (XFS_IS_PQUOTA_ON(mp)) { > > - olddquot = XFS_QM_DQVOPCHOWN(mp, tp, ip, > > + olddquot = xfs_qm_vop_chown(tp, ip, > > &ip->i_gdquot, gdqp); > > } > > ip->i_d.di_projid = fa->fsx_projid; > > @@ -1114,9 +1117,9 @@ xfs_ioctl_setattr( > > /* > > * Release any dquot(s) the inode had kept before chown. > > */ > > - XFS_QM_DQRELE(mp, olddquot); > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(olddquot); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > > > if (code) > > return code; > > @@ -1130,8 +1133,8 @@ xfs_ioctl_setattr( > > return 0; > > > > error_return: > > - XFS_QM_DQRELE(mp, udqp); > > - XFS_QM_DQRELE(mp, gdqp); > > + xfs_qm_dqrele(udqp); > > + xfs_qm_dqrele(gdqp); > > xfs_trans_cancel(tp, 0); > > if (lock_flags) > > xfs_iunlock(ip, lock_flags); > > 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:16.141370566 +0100 > > +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-02-24 15:32:35.866394539 +0100 > > @@ -416,6 +416,14 @@ xfs_parseargs( > > return EINVAL; > > } > > > > +#ifndef CONFIG_XFS_QUOTA > > + if (XFS_IS_QUOTA_RUNNING(mp)) { > > + cmn_err(CE_WARN, > > + "XFS: quota support not available in this kernel."); > > + return EINVAL; > > + } > > +#endif > > + > > if ((mp->m_qflags & (XFS_GQUOTA_ACCT | XFS_GQUOTA_ACTIVE)) && > > (mp->m_qflags & (XFS_PQUOTA_ACCT | XFS_PQUOTA_ACTIVE))) { > > cmn_err(CE_WARN, > > @@ -1110,7 +1118,6 @@ xfs_fs_put_super( > > xfs_freesb(mp); > > xfs_icsb_destroy_counters(mp); > > xfs_close_devices(mp); > > - xfs_qmops_put(mp); > > xfs_dmops_put(mp); > > xfs_free_fsname(mp); > > kfree(mp); > > @@ -1180,6 +1187,7 @@ xfs_fs_statfs( > > { > > struct xfs_mount *mp = XFS_M(dentry->d_sb); > > xfs_sb_t *sbp = &mp->m_sb; > > + struct xfs_inode *ip = XFS_I(dentry->d_inode); > > __uint64_t fakeinos, id; > > xfs_extlen_t lsize; > > > > @@ -1214,7 +1222,10 @@ xfs_fs_statfs( > > statp->f_ffree = statp->f_files - (sbp->sb_icount - sbp->sb_ifree); > > spin_unlock(&mp->m_sb_lock); > > > > - XFS_QM_DQSTATVFS(XFS_I(dentry->d_inode), statp); > > + if ((ip->i_d.di_flags & XFS_DIFLAG_PROJINHERIT) || > > + ((mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD))) == > > + (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD)) > > + xfs_qm_statvfs(ip, statp); > > return 0; > > } > > > > @@ -1422,16 +1433,13 @@ xfs_fs_fill_super( > > error = xfs_dmops_get(mp); > > if (error) > > goto out_free_fsname; > > - error = xfs_qmops_get(mp); > > - if (error) > > - goto out_put_dmops; > > > > if (silent) > > flags |= XFS_MFSI_QUIET; > > > > error = xfs_open_devices(mp); > > if (error) > > - goto out_put_qmops; > > + goto out_put_dmops; > > > > if (xfs_icsb_init_counters(mp)) > > mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; > > @@ -1500,8 +1508,6 @@ xfs_fs_fill_super( > > out_destroy_counters: > > xfs_icsb_destroy_counters(mp); > > xfs_close_devices(mp); > > - out_put_qmops: > > - xfs_qmops_put(mp); > > out_put_dmops: > > xfs_dmops_put(mp); > > out_free_fsname: > > Index: xfs/fs/xfs/linux-2.6/xfs_sync.c > > =================================================================== > > --- xfs.orig/fs/xfs/linux-2.6/xfs_sync.c 2009-02-24 15:32:16.149399312 +0100 > > +++ xfs/fs/xfs/linux-2.6/xfs_sync.c 2009-02-24 15:32:35.867425537 +0100 > > @@ -43,6 +43,7 @@ > > #include "xfs_buf_item.h" > > #include "xfs_inode_item.h" > > #include "xfs_rw.h" > > +#include "xfs_quota.h" > > > > #include > > #include > > @@ -311,12 +312,12 @@ xfs_quiesce_data( > > > > /* push non-blocking */ > > xfs_sync_inodes(mp, SYNC_DELWRI|SYNC_BDFLUSH); > > - XFS_QM_DQSYNC(mp, SYNC_BDFLUSH); > > + xfs_qm_sync(mp, SYNC_BDFLUSH); > > xfs_filestream_flush(mp); > > > > /* push and block */ > > xfs_sync_inodes(mp, SYNC_DELWRI|SYNC_WAIT|SYNC_IOWAIT); > > - XFS_QM_DQSYNC(mp, SYNC_WAIT); > > + xfs_qm_sync(mp, SYNC_WAIT); > > > > /* write superblock and hoover up shutdown errors */ > > error = xfs_sync_fsdata(mp, 0); > > @@ -482,7 +483,7 @@ xfs_sync_worker( > > xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE); > > xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_DELWRI_ELSE_ASYNC); > > /* dgc: errors ignored here */ > > - error = XFS_QM_DQSYNC(mp, SYNC_BDFLUSH); > > + error = xfs_qm_sync(mp, SYNC_BDFLUSH); > > error = xfs_sync_fsdata(mp, SYNC_BDFLUSH); > > if (xfs_log_need_covered(mp)) > > error = xfs_commit_dummy_trans(mp, XFS_LOG_FORCE); > > Index: xfs/fs/xfs/quota/xfs_dquot.c > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_dquot.c 2009-02-24 15:32:16.080370342 +0100 > > +++ xfs/fs/xfs/quota/xfs_dquot.c 2009-02-24 15:32:35.867425537 +0100 > > @@ -1194,7 +1194,9 @@ void > > xfs_qm_dqrele( > > xfs_dquot_t *dqp) > > { > > - ASSERT(dqp); > > + if (!dqp) > > + return; > > + > > xfs_dqtrace_entry(dqp, "DQRELE"); > > > > xfs_dqlock(dqp); > > Index: xfs/fs/xfs/quota/xfs_dquot.h > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_dquot.h 2009-02-24 15:32:16.085370350 +0100 > > +++ xfs/fs/xfs/quota/xfs_dquot.h 2009-02-24 15:32:35.868518762 +0100 > > @@ -181,7 +181,6 @@ extern void xfs_qm_adjust_dqlimits(xfs_ > > extern int xfs_qm_dqget(xfs_mount_t *, xfs_inode_t *, > > xfs_dqid_t, uint, uint, xfs_dquot_t **); > > extern void xfs_qm_dqput(xfs_dquot_t *); > > -extern void xfs_qm_dqrele(xfs_dquot_t *); > > extern void xfs_dqlock(xfs_dquot_t *); > > extern void xfs_dqlock2(xfs_dquot_t *, xfs_dquot_t *); > > extern void xfs_dqunlock(xfs_dquot_t *); > > Index: xfs/fs/xfs/quota/xfs_qm.c > > =================================================================== > > --- xfs.orig/fs/xfs/quota/xfs_qm.c 2009-02-24 15:32:16.076370112 +0100 > > +++ xfs/fs/xfs/quota/xfs_qm.c 2009-02-24 15:32:35.869518471 +0100 > > @@ -287,11 +287,13 @@ xfs_qm_rele_quotafs_ref( > > * Just destroy the quotainfo structure. > > */ > > void > > -xfs_qm_unmount_quotadestroy( > > - xfs_mount_t *mp) > > +xfs_qm_unmount( > > + struct xfs_mount *mp) > > { > > - if (mp->m_quotainfo) > > + if (mp->m_quotainfo) { > > + xfs_qm_dqpurge_all(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); > > xfs_qm_destroy_quotainfo(mp); > > + } > > } > > > > > > @@ -311,6 +313,9 @@ xfs_qm_mount_quotas( > > int error = 0; > > uint sbf; > > > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > > + return; > > + > > /* > > * If quotas on realtime volumes is not supported, we disable > > * quotas immediately. > > @@ -323,8 +328,6 @@ xfs_qm_mount_quotas( > > goto write_changes; > > } > > > > - ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > > - > > /* > > * Allocate the quotainfo structure inside the mount struct, and > > * create quotainode(s), and change/rev superblock if necessary. > > @@ -385,8 +388,13 @@ xfs_qm_mount_quotas( > > if (error) { > > xfs_fs_cmn_err(CE_WARN, mp, > > "Failed to initialize disk quotas."); > > + return; > > } > > - return; > > + > > +#ifdef QUOTADEBUG > > + if (XFS_IS_QUOTA_ON(mp)) > > + xfs_qm_internalqcheck(mp); > > +#endif > > } > > > > /* > > @@ -774,12 +782,11 @@ xfs_qm_dqattach_grouphint( > > * Given a locked inode, attach dquot(s) to it, taking U/G/P-QUOTAON > > * into account. > > * If XFS_QMOPT_DQALLOC, the dquot(s) will be allocated if needed. > > - * If XFS_QMOPT_ILOCKED, then inode sent is already locked EXCL. > > * Inode may get unlocked and relocked in here, and the caller must deal with > > * the consequences. > > */ > > int > > -xfs_qm_dqattach( > > +xfs_qm_dqattach_locked( > > xfs_inode_t *ip, > > uint flags) > > { > > @@ -787,17 +794,14 @@ xfs_qm_dqattach( > > uint nquotas = 0; > > int error = 0; > > > > - if ((! XFS_IS_QUOTA_ON(mp)) || > > - (! XFS_NOT_DQATTACHED(mp, ip)) || > > - (ip->i_ino == mp->m_sb.sb_uquotino) || > > - (ip->i_ino == mp->m_sb.sb_gquotino)) > > + if (!XFS_IS_QUOTA_RUNNING(mp) || > > + !XFS_IS_QUOTA_ON(mp) || > > + !XFS_NOT_DQATTACHED(mp, ip) || > > + ip->i_ino == mp->m_sb.sb_uquotino || > > + ip->i_ino == mp->m_sb.sb_gquotino) > > return 0; > > > > - ASSERT((flags & XFS_QMOPT_ILOCKED) == 0 || > > - xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > - > > - if (! (flags & XFS_QMOPT_ILOCKED)) > > - xfs_ilock(ip, XFS_ILOCK_EXCL); > > + ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > > > if (XFS_IS_UQUOTA_ON(mp)) { > > error = xfs_qm_dqattach_one(ip, ip->i_d.di_uid, XFS_DQ_USER, > > @@ -849,8 +853,7 @@ xfs_qm_dqattach( > > xfs_qm_dqattach_grouphint(ip->i_udquot, ip->i_gdquot); > > } > > > > - done: > > - > > + done: > > #ifdef QUOTADEBUG > > if (! error) { > > if (XFS_IS_UQUOTA_ON(mp)) > > @@ -858,15 +861,22 @@ xfs_qm_dqattach( > > if (XFS_IS_OQUOTA_ON(mp)) > > ASSERT(ip->i_gdquot); > > } > > + ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > #endif > > + return error; > > +} > > + > > +int > > +xfs_qm_dqattach( > > + struct xfs_inode *ip, > > + uint flags) > > +{ > > + int error; > > > > - if (! (flags & XFS_QMOPT_ILOCKED)) > > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > > + xfs_ilock(ip, XFS_ILOCK_EXCL); > > + error = xfs_qm_dqattach_locked(ip, flags); > > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > > > > -#ifdef QUOTADEBUG > > - else > > - ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > -#endif > > return error; > > } > > > > @@ -912,7 +922,7 @@ xfs_qm_sync( > > boolean_t nowait; > > int error; > > > > - if (! XFS_IS_QUOTA_ON(mp)) > > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > > return 0; > > > > restarts = 0; > > @@ -2319,20 +2329,20 @@ xfs_qm_write_sb_changes( > > */ > > int > > xfs_qm_vop_dqalloc( > > - xfs_mount_t *mp, > > - xfs_inode_t *ip, > > - uid_t uid, > > - gid_t gid, > > - prid_t prid, > > - uint flags, > > - xfs_dquot_t **O_udqpp, > > - xfs_dquot_t **O_gdqpp) > > -{ > > - int error; > > - xfs_dquot_t *uq, *gq; > > - uint lockflags; > > + struct xfs_inode *ip, > > + uid_t uid, > > + gid_t gid, > > + prid_t prid, > > + uint flags, > > + struct xfs_dquot **O_udqpp, > > + struct xfs_dquot **O_gdqpp) > > +{ > > + struct xfs_mount *mp = ip->i_mount; > > + struct xfs_dquot *uq, *gq; > > + int error; > > + uint lockflags; > > > > - if (!XFS_IS_QUOTA_ON(mp)) > > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > > return 0; > > > > lockflags = XFS_ILOCK_EXCL; > > @@ -2346,8 +2356,8 @@ xfs_qm_vop_dqalloc( > > * if necessary. The dquot(s) will not be locked. > > */ > > if (XFS_NOT_DQATTACHED(mp, ip)) { > > - if ((error = xfs_qm_dqattach(ip, XFS_QMOPT_DQALLOC | > > - XFS_QMOPT_ILOCKED))) { > > + error = xfs_qm_dqattach_locked(ip, XFS_QMOPT_DQALLOC); > > + if (error) { > > xfs_iunlock(ip, lockflags); > > return error; > > } > > @@ -2469,8 +2479,10 @@ xfs_qm_vop_chown( > > uint bfield = XFS_IS_REALTIME_INODE(ip) ? > > XFS_TRANS_DQ_RTBCOUNT : XFS_TRANS_DQ_BCOUNT; > > > > + if (!XFS_IS_QUOTA_RUNNING(ip->i_mount)) > > + return NULL; > > + > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > - ASSERT(XFS_IS_QUOTA_RUNNING(ip->i_mount)); > > > > /* old dquot */ > > prevdq = *IO_olddq; > > @@ -2508,14 +2520,15 @@ xfs_qm_vop_chown_reserve( > > xfs_dquot_t *gdqp, > > uint flags) > > { > > - int error; > > - xfs_mount_t *mp; > > + xfs_mount_t *mp = ip->i_mount; > > uint delblks, blkflags, prjflags = 0; > > xfs_dquot_t *unresudq, *unresgdq, *delblksudq, *delblksgdq; > > + int error; > > + > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > > + return 0; > > > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); > > - mp = ip->i_mount; > > - ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > > > > delblks = ip->i_delayed_blks; > > delblksudq = delblksgdq = unresudq = unresgdq = NULL; > > @@ -2582,28 +2595,23 @@ xfs_qm_vop_chown_reserve( > > > > int > > xfs_qm_vop_rename_dqattach( > > - xfs_inode_t **i_tab) > > + struct xfs_inode **i_tab) > > { > > - xfs_inode_t *ip; > > - int i; > > - int error; > > - > > - ip = i_tab[0]; > > + struct xfs_mount *mp = i_tab[0]->i_mount; > > + int i; > > > > - if (! XFS_IS_QUOTA_ON(ip->i_mount)) > > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > > return 0; > > > > - if (XFS_NOT_DQATTACHED(ip->i_mount, ip)) { > > - error = xfs_qm_dqattach(ip, 0); > > - if (error) > > - return error; > > - } > > for (i = 1; (i < 4 && i_tab[i]); i++) { > > + struct xfs_inode *ip = i_tab[i]; > > + int error; > > + > > /* > > * Watch out for duplicate entries in the table. > > */ > > - if ((ip = i_tab[i]) != i_tab[i-1]) { > > - if (XFS_NOT_DQATTACHED(ip->i_mount, ip)) { > > + if (i == 0 || ip != i_tab[i-1]) { > > + if (XFS_NOT_DQATTACHED(mp, ip)) { > > error = xfs_qm_dqattach(ip, 0); > > if (error) > > return error; > > @@ -2614,17 +2622,19 @@ xfs_qm_vop_rename_dqattach( > > } > > > > void > > -xfs_qm_vop_dqattach_and_dqmod_newinode( > > - xfs_trans_t *tp, > > - xfs_inode_t *ip, > > - xfs_dquot_t *udqp, > > - xfs_dquot_t *gdqp) > > +xfs_qm_vop_create_dqattach( > > + struct xfs_trans *tp, > > + struct xfs_inode *ip, > > + struct xfs_dquot *udqp, > > + struct xfs_dquot *gdqp) > > { > > - if (!XFS_IS_QUOTA_ON(tp->t_mountp)) > > + struct xfs_mount *mp = tp->t_mountp; > > + > > + if (!XFS_IS_QUOTA_RUNNING(mp) || !XFS_IS_QUOTA_ON(mp)) > > return; > > > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > - ASSERT(XFS_IS_QUOTA_RUNNING(tp->t_mountp)); > > + ASSERT(XFS_IS_QUOTA_RUNNING(mp)); > > > > if (udqp) { > > xfs_dqlock(udqp); > > @@ -2632,7 +2642,7 @@ xfs_qm_vop_dqattach_and_dqmod_newinode( > > xfs_dqunlock(udqp); > > ASSERT(ip->i_udquot == NULL); > > ip->i_udquot = udqp; > > - ASSERT(XFS_IS_UQUOTA_ON(tp->t_mountp)); > > + ASSERT(XFS_IS_UQUOTA_ON(mp)); > > ASSERT(ip->i_d.di_uid == be32_to_cpu(udqp->q_core.d_id)); > > xfs_trans_mod_dquot(tp, udqp, XFS_TRANS_DQ_ICOUNT, 1); > > } > > @@ -2642,8 +2652,8 @@ xfs_qm_vop_dqattach_and_dqmod_newinode( > > xfs_dqunlock(gdqp); > > ASSERT(ip->i_gdquot == NULL); > > ip->i_gdquot = gdqp; > > - ASSERT(XFS_IS_OQUOTA_ON(tp->t_mountp)); > > - ASSERT((XFS_IS_GQUOTA_ON(tp->t_mountp) ? > > + ASSERT(XFS_IS_OQUOTA_ON(mp)); > > + ASSERT((XFS_IS_GQUOTA_ON(mp) ? > > ip->i_d.di_gid : ip->i_d.di_projid) == > > be32_to_cpu(gdqp->q_core.d_id)); > > xfs_trans_mod_dquot(tp, gdqp, XFS_TRANS_DQ_ICOUNT, 1); > > Index: xfs/fs/xfs/xfs_iget.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_iget.c 2009-02-24 15:32:16.153369650 +0100 > > +++ xfs/fs/xfs/xfs_iget.c 2009-02-24 15:32:35.870518109 +0100 > > @@ -490,10 +490,7 @@ xfs_ireclaim( > > * ilock one but will still hold the iolock. > > */ > > xfs_ilock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); > > - /* > > - * Release dquots (and their references) if any. > > - */ > > - XFS_QM_DQDETACH(ip->i_mount, ip); > > + xfs_qm_dqdetach(ip); > > xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); > > > > switch (ip->i_d.di_mode & S_IFMT) { > > Index: xfs/fs/xfs/xfs_mount.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_mount.c 2009-02-24 15:32:16.164399755 +0100 > > +++ xfs/fs/xfs/xfs_mount.c 2009-02-24 15:32:35.871518446 +0100 > > @@ -886,6 +886,53 @@ xfs_check_sizes(xfs_mount_t *mp) > > } > > > > /* > > + * Clear the quotaflags in memory and in the superblock. > > + */ > > +int > > +xfs_mount_reset_sbqflags( > > + struct xfs_mount *mp) > > +{ > > + int error; > > + struct xfs_trans *tp; > > + > > + mp->m_qflags = 0; > > + > > + /* > > + * It is OK to look at sb_qflags here in mount path, > > + * without m_sb_lock. > > + */ > > + if (mp->m_sb.sb_qflags == 0) > > + return 0; > > + spin_lock(&mp->m_sb_lock); > > + mp->m_sb.sb_qflags = 0; > > + spin_unlock(&mp->m_sb_lock); > > + > > + /* > > + * If the fs is readonly, let the incore superblock run > > + * with quotas off but don't flush the update out to disk > > + */ > > + if (mp->m_flags & XFS_MOUNT_RDONLY) > > + return 0; > > + > > +#ifdef QUOTADEBUG > > + xfs_fs_cmn_err(CE_NOTE, mp, "Writing superblock quota changes"); > > +#endif > > + > > + tp = xfs_trans_alloc(mp, XFS_TRANS_QM_SBCHANGE); > > + error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0, > > + XFS_DEFAULT_LOG_COUNT); > > + if (error) { > > + xfs_trans_cancel(tp, 0); > > + xfs_fs_cmn_err(CE_ALERT, mp, > > + "xfs_mount_reset_sbqflags: Superblock update failed!"); > > + return error; > > + } > > + > > + xfs_mod_sb(tp, XFS_SB_QFLAGS); > > + return xfs_trans_commit(tp, 0); > > +} > > + > > +/* > > * This function does the following on an initial mount of a file system: > > * - reads the superblock from disk and init the mount struct > > * - if we're a 32-bit kernel, do a size check on the superblock > > @@ -902,7 +949,8 @@ xfs_mountfs( > > xfs_sb_t *sbp = &(mp->m_sb); > > xfs_inode_t *rip; > > __uint64_t resblks; > > - uint quotamount, quotaflags; > > + uint quotamount = 0; > > + uint quotaflags = 0; > > int error = 0; > > > > xfs_mount_common(mp, sbp); > > @@ -1145,9 +1193,28 @@ xfs_mountfs( > > /* > > * Initialise the XFS quota management subsystem for this mount > > */ > > - error = XFS_QM_INIT(mp, "amount, "aflags); > > - if (error) > > - goto out_rtunmount; > > + if (XFS_IS_QUOTA_RUNNING(mp)) { > > + error = xfs_qm_newmount(mp, "amount, "aflags); > > + if (error) > > + goto out_rtunmount; > > + } else { > > + ASSERT(!XFS_IS_QUOTA_ON(mp)); > > + > > + /* > > + * If a file system had quotas running earlier, but decided to > > + * mount without -o uquota/pquota/gquota options, revoke the > > + * quotachecked license. > > + */ > > + if (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT) { > > + cmn_err(CE_NOTE, > > + "XFS: resetting qflags for filesystem %s", > > + mp->m_fsname); > > + > > + error = xfs_mount_reset_sbqflags(mp); > > + if (error) > > + return error; > > + } > > + } > > > > /* > > * Finish recovering the file system. This part needed to be > > @@ -1163,9 +1230,19 @@ xfs_mountfs( > > /* > > * Complete the quota initialisation, post-log-replay component. > > */ > > - error = XFS_QM_MOUNT(mp, quotamount, quotaflags); > > - if (error) > > - goto out_rtunmount; > > + if (quotamount) { > > + ASSERT(mp->m_qflags == 0); > > + mp->m_qflags = quotaflags; > > + > > + xfs_qm_mount_quotas(mp); > > + } > > + > > +#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) > > + if (XFS_IS_QUOTA_ON(mp)) > > + xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas turned on"); > > + else > > + xfs_fs_cmn_err(CE_NOTE, mp, "Disk quotas not turned on"); > > +#endif > > > > /* > > * Now we are mounted, reserve a small amount of unused space for > > @@ -1215,12 +1292,7 @@ xfs_unmountfs( > > __uint64_t resblks; > > int error; > > > > - /* > > - * Release dquot that rootinode, rbmino and rsumino might be holding, > > - * and release the quota inodes. > > - */ > > - XFS_QM_UNMOUNT(mp); > > - > > + xfs_qm_unmount_quotas(mp); > > xfs_rtunmount_inodes(mp); > > IRELE(mp->m_rootip); > > > > @@ -1237,10 +1309,7 @@ xfs_unmountfs( > > xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); > > xfs_reclaim_inodes(mp, 0, XFS_IFLUSH_ASYNC); > > > > - XFS_QM_DQPURGEALL(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); > > - > > - if (mp->m_quotainfo) > > - XFS_QM_DONE(mp); > > + xfs_qm_unmount(mp); > > > > /* > > * Flush out the log synchronously so that we know for sure > > Index: xfs/fs/xfs/xfs_qmops.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_qmops.c 2009-02-24 15:32:16.128369539 +0100 > > +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 > > @@ -1,152 +0,0 @@ > > -/* > > - * Copyright (c) 2000-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_log.h" > > -#include "xfs_inum.h" > > -#include "xfs_trans.h" > > -#include "xfs_sb.h" > > -#include "xfs_ag.h" > > -#include "xfs_dir2.h" > > -#include "xfs_dmapi.h" > > -#include "xfs_mount.h" > > -#include "xfs_quota.h" > > -#include "xfs_error.h" > > - > > - > > -STATIC struct xfs_dquot * > > -xfs_dqvopchown_default( > > - struct xfs_trans *tp, > > - struct xfs_inode *ip, > > - struct xfs_dquot **dqp, > > - struct xfs_dquot *dq) > > -{ > > - return NULL; > > -} > > - > > -/* > > - * Clear the quotaflags in memory and in the superblock. > > - */ > > -int > > -xfs_mount_reset_sbqflags(xfs_mount_t *mp) > > -{ > > - int error; > > - xfs_trans_t *tp; > > - > > - mp->m_qflags = 0; > > - /* > > - * It is OK to look at sb_qflags here in mount path, > > - * without m_sb_lock. > > - */ > > - if (mp->m_sb.sb_qflags == 0) > > - return 0; > > - spin_lock(&mp->m_sb_lock); > > - mp->m_sb.sb_qflags = 0; > > - spin_unlock(&mp->m_sb_lock); > > - > > - /* > > - * if the fs is readonly, let the incore superblock run > > - * with quotas off but don't flush the update out to disk > > - */ > > - if (mp->m_flags & XFS_MOUNT_RDONLY) > > - return 0; > > -#ifdef QUOTADEBUG > > - xfs_fs_cmn_err(CE_NOTE, mp, "Writing superblock quota changes"); > > -#endif > > - tp = xfs_trans_alloc(mp, XFS_TRANS_QM_SBCHANGE); > > - if ((error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0, > > - XFS_DEFAULT_LOG_COUNT))) { > > - xfs_trans_cancel(tp, 0); > > - xfs_fs_cmn_err(CE_ALERT, mp, > > - "xfs_mount_reset_sbqflags: Superblock update failed!"); > > - return error; > > - } > > - xfs_mod_sb(tp, XFS_SB_QFLAGS); > > - error = xfs_trans_commit(tp, 0); > > - return error; > > -} > > - > > -STATIC int > > -xfs_noquota_init( > > - xfs_mount_t *mp, > > - uint *needquotamount, > > - uint *quotaflags) > > -{ > > - int error = 0; > > - > > - *quotaflags = 0; > > - *needquotamount = B_FALSE; > > - > > - ASSERT(!XFS_IS_QUOTA_ON(mp)); > > - > > - /* > > - * If a file system had quotas running earlier, but decided to > > - * mount without -o uquota/pquota/gquota options, revoke the > > - * quotachecked license. > > - */ > > - if (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_ACCT) { > > - cmn_err(CE_NOTE, > > - "XFS resetting qflags for filesystem %s", > > - mp->m_fsname); > > - > > - error = xfs_mount_reset_sbqflags(mp); > > - } > > - return error; > > -} > > - > > -static struct xfs_qmops xfs_qmcore_stub = { > > - .xfs_qminit = (xfs_qminit_t) xfs_noquota_init, > > - .xfs_qmdone = (xfs_qmdone_t) fs_noerr, > > - .xfs_qmmount = (xfs_qmmount_t) fs_noerr, > > - .xfs_qmunmount = (xfs_qmunmount_t) fs_noerr, > > - .xfs_dqrele = (xfs_dqrele_t) fs_noerr, > > - .xfs_dqattach = (xfs_dqattach_t) fs_noerr, > > - .xfs_dqdetach = (xfs_dqdetach_t) fs_noerr, > > - .xfs_dqpurgeall = (xfs_dqpurgeall_t) fs_noerr, > > - .xfs_dqvopalloc = (xfs_dqvopalloc_t) fs_noerr, > > - .xfs_dqvopcreate = (xfs_dqvopcreate_t) fs_noerr, > > - .xfs_dqvoprename = (xfs_dqvoprename_t) fs_noerr, > > - .xfs_dqvopchown = xfs_dqvopchown_default, > > - .xfs_dqvopchownresv = (xfs_dqvopchownresv_t) fs_noerr, > > - .xfs_dqstatvfs = (xfs_dqstatvfs_t) fs_noval, > > - .xfs_dqsync = (xfs_dqsync_t) fs_noerr, > > -}; > > - > > -int > > -xfs_qmops_get(struct xfs_mount *mp) > > -{ > > - if (XFS_IS_QUOTA_RUNNING(mp)) { > > -#ifdef CONFIG_XFS_QUOTA > > - mp->m_qm_ops = &xfs_qmcore_xfs; > > -#else > > - cmn_err(CE_WARN, > > - "XFS: qouta support not available in this kernel."); > > - return EINVAL; > > -#endif > > - } else { > > - mp->m_qm_ops = &xfs_qmcore_stub; > > - } > > - > > - return 0; > > -} > > - > > -void > > -xfs_qmops_put(struct xfs_mount *mp) > > -{ > > -} > > Index: xfs/fs/xfs/xfs_rename.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_rename.c 2009-02-24 15:32:16.132369560 +0100 > > +++ xfs/fs/xfs/xfs_rename.c 2009-02-24 15:32:35.872519970 +0100 > > @@ -166,7 +166,8 @@ xfs_rename( > > /* > > * Attach the dquots to the inodes > > */ > > - if ((error = XFS_QM_DQVOPRENAME(mp, inodes))) { > > + error = xfs_qm_vop_rename_dqattach(inodes); > > + if (error) { > > xfs_trans_cancel(tp, cancel_flags); > > goto std_return; > > } > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:45: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2T7iwXO118121 for ; Sun, 29 Mar 2009 02:45:13 -0500 X-ASG-Debug-ID: 1238312709-555402920000-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 DBFD713D8322 for ; Sun, 29 Mar 2009 00:45:09 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id D5ib3tMMo0V9zEdv for ; Sun, 29 Mar 2009 00:45:09 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnph3-0004NE-61 for xfs@oss.sgi.com; Sun, 29 Mar 2009 07:44:33 +0000 Date: Sun, 29 Mar 2009 03:44:33 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Message-ID: <20090329074433.GD16402@infradead.org> References: <20090224133902.GC15820@infradead.org> <20090316063057.GC4957@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316063057.GC4957@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: 1238312709 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 ping^2? On Mon, Mar 16, 2009 at 02:30:57AM -0400, Christoph Hellwig wrote: > ping? > > On Tue, Feb 24, 2009 at 08:39:02AM -0500, Christoph Hellwig wrote: > > xfs_getbmap (or rather the formatters called by it) copy out the getbmap > > structures under the ilock, which can deadlock against mmap. This has > > been reported via bugzilla a while ago (#717) and has recently also > > shown up via lockdep. > > > > So allocate a temporary buffer to format the kernel getbmap structures > > into and then copy them out after dropping the locks. > > > > A little problem with this is that we limit the number of extents we > > can copy out by the maximum allocation size, but I see no real way > > around that. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: xfs/fs/xfs/xfs_bmap.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 20:38:27.512925014 +0100 > > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 20:40:46.720926193 +0100 > > @@ -5867,12 +5867,13 @@ xfs_getbmap( > > int nexleft; /* # of user extents left */ > > int subnex; /* # of bmapi's can do */ > > int nmap; /* number of map entries */ > > - struct getbmapx out; /* output structure */ > > + struct getbmapx *out; /* output structure */ > > int whichfork; /* data or attr fork */ > > int prealloced; /* this is a file with > > * preallocated data space */ > > int iflags; /* interface flags */ > > int bmapi_flags; /* flags for xfs_bmapi */ > > + int cur_ext = 0; > > > > mp = ip->i_mount; > > iflags = bmv->bmv_iflags; > > @@ -5948,6 +5949,13 @@ xfs_getbmap( > > return XFS_ERROR(EINVAL); > > bmvend = bmv->bmv_offset + bmv->bmv_length; > > > > + > > + if (bmv->bmv_count > ULONG_MAX / sizeof(struct getbmapx)) > > + return XFS_ERROR(ENOMEM); > > + out = kmem_zalloc(bmv->bmv_count * sizeof(struct getbmapx), KM_MAYFAIL); > > + if (!out) > > + return XFS_ERROR(ENOMEM); > > + > > xfs_ilock(ip, XFS_IOLOCK_SHARED); > > if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > > if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > > @@ -6001,39 +6009,39 @@ xfs_getbmap( > > ASSERT(nmap <= subnex); > > > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > > - int full = 0; /* user array is full */ > > - > > - out.bmv_oflags = 0; > > + out[cur_ext].bmv_oflags = 0; > > if (map[i].br_state == XFS_EXT_UNWRITTEN) > > - out.bmv_oflags |= BMV_OF_PREALLOC; > > + out[cur_ext].bmv_oflags |= BMV_OF_PREALLOC; > > else if (map[i].br_startblock == DELAYSTARTBLOCK) > > - out.bmv_oflags |= BMV_OF_DELALLOC; > > - out.bmv_offset = XFS_FSB_TO_BB(mp, map[i].br_startoff); > > - out.bmv_length = XFS_FSB_TO_BB(mp, map[i].br_blockcount); > > - out.bmv_unused1 = out.bmv_unused2 = 0; > > + out[cur_ext].bmv_oflags |= BMV_OF_DELALLOC; > > + out[cur_ext].bmv_offset = > > + XFS_FSB_TO_BB(mp, map[i].br_startoff); > > + out[cur_ext].bmv_length = > > + XFS_FSB_TO_BB(mp, map[i].br_blockcount); > > + out[cur_ext].bmv_unused1 = 0; > > + out[cur_ext].bmv_unused2 = 0; > > ASSERT(((iflags & BMV_IF_DELALLOC) != 0) || > > (map[i].br_startblock != DELAYSTARTBLOCK)); > > if (map[i].br_startblock == HOLESTARTBLOCK && > > whichfork == XFS_ATTR_FORK) { > > /* came to the end of attribute fork */ > > - out.bmv_oflags |= BMV_OF_LAST; > > + out[cur_ext].bmv_oflags |= BMV_OF_LAST; > > goto out_free_map; > > } > > > > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > > - bmvend, map[i].br_startblock)) > > + if (!xfs_getbmapx_fix_eof_hole(ip, &out[cur_ext], > > + prealloced, bmvend, > > + map[i].br_startblock)) > > goto out_free_map; > > > > - /* format results & advance arg */ > > - error = formatter(&arg, &out, &full); > > - if (error || full) > > - goto out_free_map; > > nexleft--; > > bmv->bmv_offset = > > - out.bmv_offset + out.bmv_length; > > + out[cur_ext].bmv_offset + > > + out[cur_ext].bmv_length; > > bmv->bmv_length = > > max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > > bmv->bmv_entries++; > > + cur_ext++; > > } > > } while (nmap && nexleft && bmv->bmv_length); > > > > @@ -6043,6 +6051,16 @@ xfs_getbmap( > > xfs_iunlock_map_shared(ip, lock); > > out_unlock_iolock: > > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > > + > > + for (i = 0; i < cur_ext; i++) { > > + int full = 0; /* user array is full */ > > + > > + /* format results & advance arg */ > > + error = formatter(&arg, &out[i], &full); > > + if (error || full) > > + break; > > + } > > + > > return error; > > } > > > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:45: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,J_CHICKENPOX_64 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 n2T7jBG2118139 for ; Sun, 29 Mar 2009 02:45:26 -0500 X-ASG-Debug-ID: 1238312666-4e51029e0000-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 E79131C7B697 for ; Sun, 29 Mar 2009 00:44:26 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id DEMrT8Pa0x1Gww9x for ; Sun, 29 Mar 2009 00:44:26 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnpgw-0004N8-Dd for xfs@oss.sgi.com; Sun, 29 Mar 2009 07:44:26 +0000 Date: Sun, 29 Mar 2009 03:44:26 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Subject: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Message-ID: <20090329074426.GC16402@infradead.org> References: <20090224133858.GB15820@infradead.org> <20090316063053.GB4957@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316063053.GB4957@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: 1238312686 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 ping^2? On Mon, Mar 16, 2009 at 02:30:53AM -0400, Christoph Hellwig wrote: > ping? > > On Tue, Feb 24, 2009 at 08:38:58AM -0500, Christoph Hellwig wrote: > > - reshuffle various conditionals for data vs attr fork to make the code > > more readable > > - do fine-grainded goto-based error handling > > - exit early from conditionals instead of keeping a long else branch > > around > > - allow kmem_alloc to fail > > > > Signed-off-by: Christoph Hellwig > > > > Index: xfs/fs/xfs/xfs_bmap.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 18:08:35.352924726 +0100 > > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 18:23:49.527051836 +0100 > > @@ -5857,7 +5857,7 @@ xfs_getbmap( > > void *arg) /* formatter arg */ > > { > > __int64_t bmvend; /* last block requested */ > > - int error; /* return value */ > > + int error = 0; /* return value */ > > __int64_t fixlen; /* length for -1 case */ > > int i; /* extent number */ > > int lock; /* lock state */ > > @@ -5876,30 +5876,8 @@ xfs_getbmap( > > > > mp = ip->i_mount; > > iflags = bmv->bmv_iflags; > > - > > whichfork = iflags & BMV_IF_ATTRFORK ? XFS_ATTR_FORK : XFS_DATA_FORK; > > > > - /* If the BMV_IF_NO_DMAPI_READ interface bit specified, do not > > - * generate a DMAPI read event. Otherwise, if the DM_EVENT_READ > > - * bit is set for the file, generate a read event in order > > - * that the DMAPI application may do its thing before we return > > - * the extents. Usually this means restoring user file data to > > - * regions of the file that look like holes. > > - * > > - * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > > - * BMV_IF_NO_DMAPI_READ so that read events are generated. > > - * If this were not true, callers of ioctl( XFS_IOC_GETBMAP ) > > - * could misinterpret holes in a DMAPI file as true holes, > > - * when in fact they may represent offline user data. > > - */ > > - if ((iflags & BMV_IF_NO_DMAPI_READ) == 0 && > > - DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > > - whichfork == XFS_DATA_FORK) { > > - error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, 0, 0, 0, NULL); > > - if (error) > > - return XFS_ERROR(error); > > - } > > - > > if (whichfork == XFS_ATTR_FORK) { > > if (XFS_IFORK_Q(ip)) { > > if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS && > > @@ -5913,11 +5891,37 @@ xfs_getbmap( > > ip->i_mount); > > return XFS_ERROR(EFSCORRUPTED); > > } > > - } else if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > > - ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > > - ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > > - return XFS_ERROR(EINVAL); > > - if (whichfork == XFS_DATA_FORK) { > > + > > + prealloced = 0; > > + fixlen = 1LL << 32; > > + } else { > > + /* > > + * If the BMV_IF_NO_DMAPI_READ interface bit specified, do > > + * not generate a DMAPI read event. Otherwise, if the > > + * DM_EVENT_READ bit is set for the file, generate a read > > + * event in order that the DMAPI application may do its thing > > + * before we return the extents. Usually this means restoring > > + * user file data to regions of the file that look like holes. > > + * > > + * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > > + * BMV_IF_NO_DMAPI_READ so that read events are generated. > > + * If this were not true, callers of ioctl(XFS_IOC_GETBMAP) > > + * could misinterpret holes in a DMAPI file as true holes, > > + * when in fact they may represent offline user data. > > + */ > > + if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > > + !(iflags & BMV_IF_NO_DMAPI_READ)) { > > + error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, > > + 0, 0, 0, NULL); > > + if (error) > > + return XFS_ERROR(error); > > + } > > + > > + if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > > + ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > > + ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > > + return XFS_ERROR(EINVAL); > > + > > if (xfs_get_extsz_hint(ip) || > > ip->i_d.di_flags & (XFS_DIFLAG_PREALLOC|XFS_DIFLAG_APPEND)){ > > prealloced = 1; > > @@ -5926,42 +5930,34 @@ xfs_getbmap( > > prealloced = 0; > > fixlen = ip->i_size; > > } > > - } else { > > - prealloced = 0; > > - fixlen = 1LL << 32; > > } > > > > if (bmv->bmv_length == -1) { > > fixlen = XFS_FSB_TO_BB(mp, XFS_B_TO_FSB(mp, fixlen)); > > - bmv->bmv_length = MAX( (__int64_t)(fixlen - bmv->bmv_offset), > > - (__int64_t)0); > > - } else if (bmv->bmv_length < 0) > > - return XFS_ERROR(EINVAL); > > - if (bmv->bmv_length == 0) { > > + bmv->bmv_length = > > + max_t(__int64_t, fixlen - bmv->bmv_offset, 0); > > + } else if (bmv->bmv_length == 0) { > > bmv->bmv_entries = 0; > > return 0; > > + } else if (bmv->bmv_length < 0) { > > + return XFS_ERROR(EINVAL); > > } > > + > > nex = bmv->bmv_count - 1; > > if (nex <= 0) > > return XFS_ERROR(EINVAL); > > bmvend = bmv->bmv_offset + bmv->bmv_length; > > > > xfs_ilock(ip, XFS_IOLOCK_SHARED); > > - > > - if (((iflags & BMV_IF_DELALLOC) == 0) && > > - (whichfork == XFS_DATA_FORK) && > > - (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size)) { > > - /* xfs_fsize_t last_byte = xfs_file_last_byte(ip); */ > > - error = xfs_flush_pages(ip, (xfs_off_t)0, > > - -1, 0, FI_REMAPF); > > - if (error) { > > - xfs_iunlock(ip, XFS_IOLOCK_SHARED); > > - return error; > > + if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > > + if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > > + error = xfs_flush_pages(ip, 0, -1, 0, FI_REMAPF); > > + if (error) > > + goto out_unlock_iolock; > > } > > - } > > > > - ASSERT(whichfork == XFS_ATTR_FORK || (iflags & BMV_IF_DELALLOC) || > > - ip->i_delayed_blks == 0); > > + ASSERT(ip->i_delayed_blks == 0); > > + } > > > > lock = xfs_ilock_map_shared(ip); > > > > @@ -5972,23 +5968,24 @@ xfs_getbmap( > > if (nex > XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1) > > nex = XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1; > > > > - bmapi_flags = xfs_bmapi_aflag(whichfork) | > > - ((iflags & BMV_IF_PREALLOC) ? 0 : XFS_BMAPI_IGSTATE); > > + bmapi_flags = xfs_bmapi_aflag(whichfork); > > + if (!(iflags & BMV_IF_PREALLOC)) > > + bmapi_flags |= XFS_BMAPI_IGSTATE; > > > > /* > > * Allocate enough space to handle "subnex" maps at a time. > > */ > > subnex = 16; > > - map = kmem_alloc(subnex * sizeof(*map), KM_SLEEP); > > + map = kmem_alloc(subnex * sizeof(*map), KM_MAYFAIL); > > + if (!map) > > + goto out_unlock_ilock; > > > > bmv->bmv_entries = 0; > > > > - if ((XFS_IFORK_NEXTENTS(ip, whichfork) == 0)) { > > - if (((iflags & BMV_IF_DELALLOC) == 0) || > > - whichfork == XFS_ATTR_FORK) { > > - error = 0; > > - goto unlock_and_return; > > - } > > + if (XFS_IFORK_NEXTENTS(ip, whichfork) == 0 && > > + (whichfork == XFS_ATTR_FORK || !(iflags & BMV_IF_DELALLOC))) { > > + error = 0; > > + goto out_free_map; > > } > > > > nexleft = nex; > > @@ -6000,10 +5997,12 @@ xfs_getbmap( > > bmapi_flags, NULL, 0, map, &nmap, > > NULL, NULL); > > if (error) > > - goto unlock_and_return; > > + goto out_free_map; > > ASSERT(nmap <= subnex); > > > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > > + int full = 0; /* user array is full */ > > + > > out.bmv_oflags = 0; > > if (map[i].br_state == XFS_EXT_UNWRITTEN) > > out.bmv_oflags |= BMV_OF_PREALLOC; > > @@ -6018,36 +6017,32 @@ xfs_getbmap( > > whichfork == XFS_ATTR_FORK) { > > /* came to the end of attribute fork */ > > out.bmv_oflags |= BMV_OF_LAST; > > - goto unlock_and_return; > > - } else { > > - int full = 0; /* user array is full */ > > - > > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, > > - prealloced, bmvend, > > - map[i].br_startblock)) { > > - goto unlock_and_return; > > - } > > - > > - /* format results & advance arg */ > > - error = formatter(&arg, &out, &full); > > - if (error || full) > > - goto unlock_and_return; > > - nexleft--; > > - bmv->bmv_offset = > > - out.bmv_offset + out.bmv_length; > > - bmv->bmv_length = MAX((__int64_t)0, > > - (__int64_t)(bmvend - bmv->bmv_offset)); > > - bmv->bmv_entries++; > > + goto out_free_map; > > } > > + > > + if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > > + bmvend, map[i].br_startblock)) > > + goto out_free_map; > > + > > + /* format results & advance arg */ > > + error = formatter(&arg, &out, &full); > > + if (error || full) > > + goto out_free_map; > > + nexleft--; > > + bmv->bmv_offset = > > + out.bmv_offset + out.bmv_length; > > + bmv->bmv_length = > > + max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > > + bmv->bmv_entries++; > > } > > } while (nmap && nexleft && bmv->bmv_length); > > > > -unlock_and_return: > > + out_free_map: > > + kmem_free(map); > > + out_unlock_ilock: > > xfs_iunlock_map_shared(ip, lock); > > + out_unlock_iolock: > > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > > - > > - kmem_free(map); > > - > > return error; > > } > > > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:45:46 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 n2T7jLuM118172 for ; Sun, 29 Mar 2009 02:45:36 -0500 X-ASG-Debug-ID: 1238312696-013c01b40000-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 34C861C7B697 for ; Sun, 29 Mar 2009 00:44:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id WfmtT4EYaAOLdOGa for ; Sun, 29 Mar 2009 00:44:57 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnphQ-0004NR-Dh; Sun, 29 Mar 2009 07:44:56 +0000 Date: Sun, 29 Mar 2009 03:44:56 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com Cc: Nick Piggin , linux-fsdevel@vger.kernel.org X-ASG-Orig-Subj: Re: xfs: properly truncate blocks outsize i_size on write_begin failure Subject: Re: xfs: properly truncate blocks outsize i_size on write_begin failure Message-ID: <20090329074456.GE16402@infradead.org> References: <20090318063425.GA18386@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090318063425.GA18386@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: 1238312697 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 ping? On Wed, Mar 18, 2009 at 02:34:25AM -0400, Christoph Hellwig wrote: > As pointed out by Dave in the thread starting at > http://oss.sgi.com/archives/xfs/2008-04/msg00542.html the current use > of vmtruncate in block_write_begin is incorrect for filesystem not > using ->truncate for doing the actual on-disk truncatation. Doing > it in ->truncate for a filesystem like XFS means it would be split > over multiple transactions leading to violations of the atomicy guarantee. > Historically (and still documented in Documentation/filesystems/Locking) > ->truncate is not a method but only a helper for setattr implementations > so this is correct. > > The correct fix would be to use ->setattr but that needs a new ATTR_NOLOCK > flag and an audit of all filesystems. I'm still hoping to do that later > but for now I really want XFS fixed. > > So just duplicate block_write_begin in XFS to do the proper truncation, > note that I need to export __block_prepare_write to no duplicate even > more code than nessecary. > > GFS2 and UFS and possibly others wants the same kind of fix, too. > > And I need to get rid of ->truncate one day to prevent people from using > it in stupid ways. > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/buffer.c > =================================================================== > --- xfs.orig/fs/buffer.c 2009-03-01 04:22:47.091430206 +0100 > +++ xfs/fs/buffer.c 2009-03-01 04:22:59.913336991 +0100 > @@ -1910,7 +1910,7 @@ void page_zero_new_buffers(struct page * > } > EXPORT_SYMBOL(page_zero_new_buffers); > > -static int __block_prepare_write(struct inode *inode, struct page *page, > +int __block_prepare_write(struct inode *inode, struct page *page, > unsigned from, unsigned to, get_block_t *get_block) > { > unsigned block_start, block_end; > @@ -1989,6 +1989,7 @@ static int __block_prepare_write(struct > page_zero_new_buffers(page, from, to); > return err; > } > +EXPORT_SYMBOL(__block_prepare_write); > > static int __block_commit_write(struct inode *inode, struct page *page, > unsigned from, unsigned to) > Index: xfs/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2009-03-01 04:16:12.003305119 +0100 > +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2009-03-01 04:21:55.618306704 +0100 > @@ -1598,6 +1598,71 @@ xfs_vm_direct_IO( > return ret; > } > > +/* > + * This is a copy of fs/buffer.c:block_write_begin except for doing > + * the correct setattr call in the error case instead of the wrong > + * vmtruncate. > + */ > +static int > +xfs_block_write_begin(struct file *file, struct address_space *mapping, > + loff_t pos, unsigned len, unsigned flags, > + struct page **pagep, void **fsdata, > + get_block_t *get_block) > +{ > + struct inode *inode = mapping->host; > + int status = 0; > + struct page *page; > + pgoff_t index; > + unsigned start, end; > + int ownpage = 0; > + > + index = pos >> PAGE_CACHE_SHIFT; > + start = pos & (PAGE_CACHE_SIZE - 1); > + end = start + len; > + > + page = *pagep; > + if (page == NULL) { > + ownpage = 1; > + page = grab_cache_page_write_begin(mapping, index, flags); > + if (!page) { > + status = -ENOMEM; > + goto out; > + } > + *pagep = page; > + } else > + BUG_ON(!PageLocked(page)); > + > + status = __block_prepare_write(inode, page, start, end, get_block); > + if (unlikely(status)) { > + ClearPageUptodate(page); > + > + if (ownpage) { > + unlock_page(page); > + page_cache_release(page); > + *pagep = NULL; > + > + /* > + * prepare_write() may have instantiated a few blocks > + * outside i_size. Trim these off again. Don't need > + * i_size_read because we hold i_mutex. > + */ > + if (pos + len > inode->i_size) { > + struct iattr newattrs; > + int error; > + > + newattrs.ia_size = inode->i_size; > + newattrs.ia_valid = ATTR_SIZE | ATTR_FORCE; > + error = xfs_setattr(XFS_I(inode), &newattrs, > + XFS_ATTR_NOLOCK); > + WARN_ON(error); /* not much we can do.. */ > + } > + } > + } > + > +out: > + return status; > +} > + > STATIC int > xfs_vm_write_begin( > struct file *file, > Index: xfs/include/linux/buffer_head.h > =================================================================== > --- xfs.orig/include/linux/buffer_head.h 2009-03-01 04:23:14.364305635 +0100 > +++ xfs/include/linux/buffer_head.h 2009-03-01 04:23:19.081305583 +0100 > @@ -218,6 +218,8 @@ int generic_write_end(struct file *, str > struct page *, void *); > void page_zero_new_buffers(struct page *page, unsigned from, unsigned to); > int block_prepare_write(struct page*, unsigned, unsigned, get_block_t*); > +int __block_prepare_write(struct inode *inode, struct page *page, > + unsigned from, unsigned to, get_block_t *get_block); > int cont_write_begin(struct file *, struct address_space *, loff_t, > unsigned, unsigned, struct page **, void **, > get_block_t *, loff_t *); > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:45: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, J_CHICKENPOX_64 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 n2T7jWFD118178 for ; Sun, 29 Mar 2009 02:45:47 -0500 X-ASG-Debug-ID: 1238312707-657601990000-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 125801D1566 for ; Sun, 29 Mar 2009 00:45:07 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RaVwvR6rykYkaU0h for ; Sun, 29 Mar 2009 00:45:07 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnphb-0004pD-NG for xfs@oss.sgi.com; Sun, 29 Mar 2009 07:45:07 +0000 Date: Sun, 29 Mar 2009 03:45:07 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/5] xfs: cleanup uuid handling Subject: Re: [PATCH 1/5] xfs: cleanup uuid handling Message-ID: <20090329074507.GF16402@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094131.771403000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090318094131.771403000@bombadil.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: 1238312708 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 ping? On Wed, Mar 18, 2009 at 05:41:20AM -0400, Christoph Hellwig wrote: > The uuid table handling should not be part of a semi-generic uuid library > but in the XFS code using it, so move those bits to xfs_mount.c and > refactor the whole glob to give a proper abstraction. > > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/support/uuid.c > =================================================================== > --- xfs.orig/fs/xfs/support/uuid.c 2009-02-15 19:40:08.564944522 +0100 > +++ xfs/fs/xfs/support/uuid.c 2009-02-24 21:50:49.051029140 +0100 > @@ -17,10 +17,6 @@ > */ > #include > > -static DEFINE_MUTEX(uuid_monitor); > -static int uuid_table_size; > -static uuid_t *uuid_table; > - > /* IRIX interpretation of an uuid_t */ > typedef struct { > __be32 uu_timelow; > @@ -46,12 +42,6 @@ uuid_getnodeuniq(uuid_t *uuid, int fsid > fsid[1] = be32_to_cpu(uup->uu_timelow); > } > > -void > -uuid_create_nil(uuid_t *uuid) > -{ > - memset(uuid, 0, sizeof(*uuid)); > -} > - > int > uuid_is_nil(uuid_t *uuid) > { > @@ -71,64 +61,3 @@ uuid_equal(uuid_t *uuid1, uuid_t *uuid2) > { > return memcmp(uuid1, uuid2, sizeof(uuid_t)) ? 0 : 1; > } > - > -/* > - * Given a 128-bit uuid, return a 64-bit value by adding the top and bottom > - * 64-bit words. NOTE: This function can not be changed EVER. Although > - * brain-dead, some applications depend on this 64-bit value remaining > - * persistent. Specifically, DMI vendors store the value as a persistent > - * filehandle. > - */ > -__uint64_t > -uuid_hash64(uuid_t *uuid) > -{ > - __uint64_t *sp = (__uint64_t *)uuid; > - > - return sp[0] + sp[1]; > -} > - > -int > -uuid_table_insert(uuid_t *uuid) > -{ > - int i, hole; > - > - mutex_lock(&uuid_monitor); > - for (i = 0, hole = -1; i < uuid_table_size; i++) { > - if (uuid_is_nil(&uuid_table[i])) { > - hole = i; > - continue; > - } > - if (uuid_equal(uuid, &uuid_table[i])) { > - mutex_unlock(&uuid_monitor); > - return 0; > - } > - } > - if (hole < 0) { > - uuid_table = kmem_realloc(uuid_table, > - (uuid_table_size + 1) * sizeof(*uuid_table), > - uuid_table_size * sizeof(*uuid_table), > - KM_SLEEP); > - hole = uuid_table_size++; > - } > - uuid_table[hole] = *uuid; > - mutex_unlock(&uuid_monitor); > - return 1; > -} > - > -void > -uuid_table_remove(uuid_t *uuid) > -{ > - int i; > - > - mutex_lock(&uuid_monitor); > - for (i = 0; i < uuid_table_size; i++) { > - if (uuid_is_nil(&uuid_table[i])) > - continue; > - if (!uuid_equal(uuid, &uuid_table[i])) > - continue; > - uuid_create_nil(&uuid_table[i]); > - break; > - } > - ASSERT(i < uuid_table_size); > - mutex_unlock(&uuid_monitor); > -} > Index: xfs/fs/xfs/support/uuid.h > =================================================================== > --- xfs.orig/fs/xfs/support/uuid.h 2009-02-15 19:40:08.569944670 +0100 > +++ xfs/fs/xfs/support/uuid.h 2009-02-24 21:50:37.206029255 +0100 > @@ -22,12 +22,8 @@ typedef struct { > unsigned char __u_bits[16]; > } uuid_t; > > -extern void uuid_create_nil(uuid_t *uuid); > extern int uuid_is_nil(uuid_t *uuid); > extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2); > extern void uuid_getnodeuniq(uuid_t *uuid, int fsid [2]); > -extern __uint64_t uuid_hash64(uuid_t *uuid); > -extern int uuid_table_insert(uuid_t *uuid); > -extern void uuid_table_remove(uuid_t *uuid); > > #endif /* __XFS_SUPPORT_UUID_H__ */ > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2009-02-24 15:32:35.871518446 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2009-02-24 21:51:03.558027729 +0100 > @@ -45,7 +45,6 @@ > #include "xfs_fsops.h" > #include "xfs_utils.h" > > -STATIC int xfs_uuid_mount(xfs_mount_t *); > STATIC void xfs_unmountfs_wait(xfs_mount_t *); > > > @@ -121,6 +120,84 @@ static const struct { > { sizeof(xfs_sb_t), 0 } > }; > > +static DEFINE_MUTEX(xfs_uuid_table_mutex); > +static int xfs_uuid_table_size; > +static uuid_t *xfs_uuid_table; > + > +/* > + * See if the UUID is unique among mounted XFS filesystems. > + * Mount fails if UUID is nil or a FS with the same UUID is already mounted. > + */ > +STATIC int > +xfs_uuid_mount( > + struct xfs_mount *mp) > +{ > + uuid_t *uuid = &mp->m_sb.sb_uuid; > + int hole, i; > + > + if (mp->m_flags & XFS_MOUNT_NOUUID) > + return 0; > + > + if (uuid_is_nil(uuid)) { > + cmn_err(CE_WARN, > + "XFS: Filesystem %s has nil UUID - can't mount", > + mp->m_fsname); > + return XFS_ERROR(EINVAL); > + } > + > + mutex_lock(&xfs_uuid_table_mutex); > + for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) { > + if (uuid_is_nil(&xfs_uuid_table[i])) { > + hole = i; > + continue; > + } > + if (uuid_equal(uuid, &xfs_uuid_table[i])) > + goto out_duplicate; > + } > + > + if (hole < 0) { > + xfs_uuid_table = kmem_realloc(xfs_uuid_table, > + (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), > + xfs_uuid_table_size * sizeof(*xfs_uuid_table), > + KM_SLEEP); > + hole = xfs_uuid_table_size++; > + } > + xfs_uuid_table[hole] = *uuid; > + mutex_unlock(&xfs_uuid_table_mutex); > + > + return 0; > + > + out_duplicate: > + mutex_unlock(&xfs_uuid_table_mutex); > + cmn_err(CE_WARN, "XFS: Filesystem %s has duplicate UUID - can't mount", > + mp->m_fsname); > + return XFS_ERROR(EINVAL); > +} > + > +STATIC void > +xfs_uuid_unmount( > + struct xfs_mount *mp) > +{ > + uuid_t *uuid = &mp->m_sb.sb_uuid; > + int i; > + > + if (mp->m_flags & XFS_MOUNT_NOUUID) > + return; > + > + mutex_lock(&xfs_uuid_table_mutex); > + for (i = 0; i < xfs_uuid_table_size; i++) { > + if (uuid_is_nil(&xfs_uuid_table[i])) > + continue; > + if (!uuid_equal(uuid, &xfs_uuid_table[i])) > + continue; > + memset(&xfs_uuid_table[i], 0, sizeof(uuid_t)); > + break; > + } > + ASSERT(i < xfs_uuid_table_size); > + mutex_unlock(&xfs_uuid_table_mutex); > +} > + > + > /* > * Free up the resources associated with a mount structure. Assume that > * the structure was initially zeroed, so we can tell which fields got > @@ -1016,18 +1093,9 @@ xfs_mountfs( > > mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); > > - /* > - * XFS uses the uuid from the superblock as the unique > - * identifier for fsid. We can not use the uuid from the volume > - * since a single partition filesystem is identical to a single > - * partition volume/filesystem. > - */ > - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) { > - if (xfs_uuid_mount(mp)) { > - error = XFS_ERROR(EINVAL); > - goto out; > - } > - } > + error = xfs_uuid_mount(mp); > + if (error) > + goto out; > > /* > * Set the minimum read and write sizes > @@ -1275,8 +1343,7 @@ xfs_mountfs( > out_free_perag: > xfs_free_perag(mp); > out_remove_uuid: > - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) > - uuid_table_remove(&mp->m_sb.sb_uuid); > + xfs_uuid_unmount(mp); > out: > return error; > } > @@ -1351,9 +1418,7 @@ xfs_unmountfs( > xfs_unmountfs_wait(mp); /* wait for async bufs */ > xfs_log_unmount_write(mp); > xfs_log_unmount(mp); > - > - if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) > - uuid_table_remove(&mp->m_sb.sb_uuid); > + xfs_uuid_unmount(mp); > > #if defined(DEBUG) > xfs_errortag_clearall(mp, 0); > @@ -1855,29 +1920,6 @@ xfs_freesb( > } > > /* > - * See if the UUID is unique among mounted XFS filesystems. > - * Mount fails if UUID is nil or a FS with the same UUID is already mounted. > - */ > -STATIC int > -xfs_uuid_mount( > - xfs_mount_t *mp) > -{ > - if (uuid_is_nil(&mp->m_sb.sb_uuid)) { > - cmn_err(CE_WARN, > - "XFS: Filesystem %s has nil UUID - can't mount", > - mp->m_fsname); > - return -1; > - } > - if (!uuid_table_insert(&mp->m_sb.sb_uuid)) { > - cmn_err(CE_WARN, > - "XFS: Filesystem %s has duplicate UUID - can't mount", > - mp->m_fsname); > - return -1; > - } > - return 0; > -} > - > -/* > * Used to log changes to the superblock unit and width fields which could > * be altered by the mount options, as well as any potential sb_features2 > * fixup. Only the first superblock is updated. > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:49:50 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 n2T7nOfZ118411 for ; Sun, 29 Mar 2009 02:49:40 -0500 X-ASG-Debug-ID: 1238312940-7fd101d00000-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 72C1D1C7B6C5; Sun, 29 Mar 2009 00:49:00 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AOrxXT638L2EueXc; Sun, 29 Mar 2009 00:49:00 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnplL-00050R-US; Sun, 29 Mar 2009 07:48:59 +0000 Date: Sun, 29 Mar 2009 03:48:59 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/5] xfs: remove m_litino Subject: Re: [PATCH 4/5] xfs: remove m_litino Message-ID: <20090329074859.GG16402@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.224487000@bombadil.infradead.org> <3D659CF1-738E-4580-B390-9E7B65C4BE2F@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D659CF1-738E-4580-B390-9E7B65C4BE2F@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: 1238312940 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 26, 2009 at 05:41:16PM -0500, Felix Blyakher wrote: > > On Mar 18, 2009, at 4:41 AM, Christoph Hellwig wrote: > >> With the upcoming v3 inodes the inode data/attr area size needs to be >> calculated for each specific inode, so we can't cache it in the >> superblock >> anymore. > > The change looks fine. But what is "v3 inodes"? I'm sure it's been > mentioned on the list, I'm just missing the history. It's the new inode format including a crc and uuid in the CRC patches. Because it has a larger core dinode the litoral area calculcations need to be more dynamic. From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 02:51: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 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2T7opdC118483 for ; Sun, 29 Mar 2009 02:51:07 -0500 X-ASG-Debug-ID: 1238313063-695c02140000-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 A6DF813D8349 for ; Sun, 29 Mar 2009 00:51:03 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id irszUBy3R9ABQld6 for ; Sun, 29 Mar 2009 00:51:03 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lnpmk-0005Rg-Pp; Sun, 29 Mar 2009 07:50:26 +0000 Date: Sun, 29 Mar 2009 03:50:26 -0400 From: Christoph Hellwig To: "Josef 'Jeff' Sipek" Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: remove m_attroffset Subject: Re: [PATCH 5/5] xfs: remove m_attroffset Message-ID: <20090329075026.GH16402@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.430583000@bombadil.infradead.org> <20090326194206.GV27222@josefsipek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090326194206.GV27222@josefsipek.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: 1238313063 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 26, 2009 at 03:42:06PM -0400, Josef 'Jeff' Sipek wrote: > On Wed, Mar 18, 2009 at 05:41:24AM -0400, Christoph Hellwig wrote: > > With the upcoming v3 inodes the default attroffset needs to be calculated > > for each specific inode, so we can't cache it in the superblock anymore. > > > > Also replace the assert for wrong inode sizes with a proper error check > > also included in non-debug builds. Note that the ENOSYS retourn for > ^^^^^^^ > > Typo. > > Otherwise it makes sense. > > Josef 'Jeff' Sipek. > > P.S. feel free to consider this an acked-by Acked or reviewed? This matters as I still need a formal review for this one.. From BATV+f5c4f00ca6f221f9c58f+2044+infradead.org+hch@bombadil.srs.infradead.org Sun Mar 29 04:29: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 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 n2T9TDim123859 for ; Sun, 29 Mar 2009 04:29:28 -0500 X-ASG-Debug-ID: 1238318929-657003710000-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 41DFF1D1623 for ; Sun, 29 Mar 2009 02:28:49 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AqaXne1PYTbfCBVX for ; Sun, 29 Mar 2009 02:28:49 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LnrJw-0004dz-U8 for xfs@oss.sgi.com; Sun, 29 Mar 2009 09:28:48 +0000 Date: Sun, 29 Mar 2009 05:28:48 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/5] A couple more patches for 2.6.30 Subject: Re: [PATCH 0/5] A couple more patches for 2.6.30 Message-ID: <20090329092848.GA16880@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090318094119.561416000@bombadil.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: 1238318929 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 I pushed out the patches that go review, plus Hisashi Hifumi's pagecache usage optimization and Malcolm Parsons' typo fixes to git://git.kernel.org/pub/scm/fs/xfs/xfs.git I still need a couple more reviews and we also need to decide how to pull in Dave's patches. From felixb@sgi.com Mon Mar 30 00:39: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_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2U5clor179037 for ; Mon, 30 Mar 2009 00:38:57 -0500 Received: from snoot.americas.sgi.com (cxfsopus16.americas.sgi.com [128.162.240.194]) by relay3.corp.sgi.com (Postfix) with ESMTP id 831A0AC005 for ; Sun, 29 Mar 2009 22:38:23 -0700 (PDT) Received: by snoot.americas.sgi.com (Postfix, from userid 29043) id D398E1A8CD10; Mon, 30 Mar 2009 00:30:50 -0500 (CDT) From: Felix Blyakher To: xfs@oss.sgi.com Cc: Felix Blyakher Subject: [PATCH] xfstests: fix async io error handling in fsx Date: Mon, 30 Mar 2009 00:30:50 -0500 Message-Id: <1238391050-14211-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 The result of async io returned in the event.res in addition to the number of bytes read/written provides negated error number. The broken libaio defines event.res as unsigned while the same structure in ithe kernel defines it as signed. The kernel indeed treat it as signed, and returns the negated error number. Till libaio is fixed we provide the signed long temp var. Also set errno for each error condition in aio_rw, as the caller is not aio aware and expects ret(-1)+errno by the traditional libc convention. Signed-off-by: Felix Blyakher --- ltp/fsx.c | 34 ++++++++++++++++++++++++++++------ 1 files changed, 28 insertions(+), 6 deletions(-) diff --git a/ltp/fsx.c b/ltp/fsx.c index ebe5324..81402be 100644 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -976,19 +976,41 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) fprintf(stderr, "errcode=%d\n", ret); fprintf(stderr, "aio_rw: io_submit failed: %s\n", strerror(ret)); - return(-1); + errno = -ret; + return -1; } ret = io_getevents(io_ctx, 1, 1, &event, &ts); if (ret != 1) { - fprintf(stderr, "errcode=%d\n", ret); - fprintf(stderr, "aio_rw: io_getevents failed: %s\n", - strerror(ret)); + if (ret == 0) + fprintf(stderr, "aio_rw: no events available\n"); + else { + fprintf(stderr, "errcode=%d\n", -ret); + fprintf(stderr, "aio_rw: io_getevents failed: %s\n", + strerror(-ret)); + } + errno = -ret; return -1; } if (len != event.res) { - fprintf(stderr, "bad read length: %lu instead of %u\n", - event.res, len); + /* + * The b0rked libaio defines event.res as signed. + * However the kernel strucuture has it unsigned, + * and it's used to pass negated error value. + * Till the library is fixed use the temp var. + */ + long res = (long)event.res; + if (res >= 0) + fprintf(stderr, "bad io length: %lu instead of %u\n", + res, len); + else { + fprintf(stderr, "errcode=%d\n", -res); + fprintf(stderr, "aio_rw: async io failed: %s\n", + strerror(-res)); + errno = -res; + return -1; + } + } return event.res; } -- 1.5.4.rc3 From felixb@sgi.com Mon Mar 30 01:21: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, J_CHICKENPOX_64 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2U6LVeo181374 for ; Mon, 30 Mar 2009 01:21:41 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6CD86AC017 for ; Sun, 29 Mar 2009 23:21:06 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id 1266970001C8; Mon, 30 Mar 2009 01:06:10 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090318094131.771403000@bombadil.infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [PATCH 1/5] xfs: cleanup uuid handling Date: Mon, 30 Mar 2009 01:06:09 -0500 References: <20090318094119.561416000@bombadil.infradead.org> <20090318094131.771403000@bombadil.infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 18, 2009, at 4:41 AM, Christoph Hellwig wrote: > The uuid table handling should not be part of a semi-generic uuid > library > but in the XFS code using it, so move those bits to xfs_mount.c and > refactor the whole glob to give a proper abstraction. > > Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher > > > Index: xfs/fs/xfs/support/uuid.c > =================================================================== > --- xfs.orig/fs/xfs/support/uuid.c 2009-02-15 19:40:08.564944522 +0100 > +++ xfs/fs/xfs/support/uuid.c 2009-02-24 21:50:49.051029140 +0100 > @@ -17,10 +17,6 @@ > */ > #include > > -static DEFINE_MUTEX(uuid_monitor); > -static int uuid_table_size; > -static uuid_t *uuid_table; > - > /* IRIX interpretation of an uuid_t */ > typedef struct { > __be32 uu_timelow; > @@ -46,12 +42,6 @@ uuid_getnodeuniq(uuid_t *uuid, int fsid > fsid[1] = be32_to_cpu(uup->uu_timelow); > } > > -void > -uuid_create_nil(uuid_t *uuid) > -{ > - memset(uuid, 0, sizeof(*uuid)); > -} > - > int > uuid_is_nil(uuid_t *uuid) > { > @@ -71,64 +61,3 @@ uuid_equal(uuid_t *uuid1, uuid_t *uuid2) > { > return memcmp(uuid1, uuid2, sizeof(uuid_t)) ? 0 : 1; > } > - > -/* > - * Given a 128-bit uuid, return a 64-bit value by adding the top > and bottom > - * 64-bit words. NOTE: This function can not be changed EVER. > Although > - * brain-dead, some applications depend on this 64-bit value > remaining > - * persistent. Specifically, DMI vendors store the value as a > persistent > - * filehandle. > - */ > -__uint64_t > -uuid_hash64(uuid_t *uuid) > -{ > - __uint64_t *sp = (__uint64_t *)uuid; > - > - return sp[0] + sp[1]; > -} > - > -int > -uuid_table_insert(uuid_t *uuid) > -{ > - int i, hole; > - > - mutex_lock(&uuid_monitor); > - for (i = 0, hole = -1; i < uuid_table_size; i++) { > - if (uuid_is_nil(&uuid_table[i])) { > - hole = i; > - continue; > - } > - if (uuid_equal(uuid, &uuid_table[i])) { > - mutex_unlock(&uuid_monitor); > - return 0; > - } > - } > - if (hole < 0) { > - uuid_table = kmem_realloc(uuid_table, > - (uuid_table_size + 1) * sizeof(*uuid_table), > - uuid_table_size * sizeof(*uuid_table), > - KM_SLEEP); > - hole = uuid_table_size++; > - } > - uuid_table[hole] = *uuid; > - mutex_unlock(&uuid_monitor); > - return 1; > -} > - > -void > -uuid_table_remove(uuid_t *uuid) > -{ > - int i; > - > - mutex_lock(&uuid_monitor); > - for (i = 0; i < uuid_table_size; i++) { > - if (uuid_is_nil(&uuid_table[i])) > - continue; > - if (!uuid_equal(uuid, &uuid_table[i])) > - continue; > - uuid_create_nil(&uuid_table[i]); > - break; > - } > - ASSERT(i < uuid_table_size); > - mutex_unlock(&uuid_monitor); > -} > Index: xfs/fs/xfs/support/uuid.h > =================================================================== > --- xfs.orig/fs/xfs/support/uuid.h 2009-02-15 19:40:08.569944670 +0100 > +++ xfs/fs/xfs/support/uuid.h 2009-02-24 21:50:37.206029255 +0100 > @@ -22,12 +22,8 @@ typedef struct { > unsigned char __u_bits[16]; > } uuid_t; > > -extern void uuid_create_nil(uuid_t *uuid); > extern int uuid_is_nil(uuid_t *uuid); > extern int uuid_equal(uuid_t *uuid1, uuid_t *uuid2); > extern void uuid_getnodeuniq(uuid_t *uuid, int fsid [2]); > -extern __uint64_t uuid_hash64(uuid_t *uuid); > -extern int uuid_table_insert(uuid_t *uuid); > -extern void uuid_table_remove(uuid_t *uuid); > > #endif /* __XFS_SUPPORT_UUID_H__ */ > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2009-02-24 15:32:35.871518446 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2009-02-24 21:51:03.558027729 +0100 > @@ -45,7 +45,6 @@ > #include "xfs_fsops.h" > #include "xfs_utils.h" > > -STATIC int xfs_uuid_mount(xfs_mount_t *); > STATIC void xfs_unmountfs_wait(xfs_mount_t *); > > > @@ -121,6 +120,84 @@ static const struct { > { sizeof(xfs_sb_t), 0 } > }; > > +static DEFINE_MUTEX(xfs_uuid_table_mutex); > +static int xfs_uuid_table_size; > +static uuid_t *xfs_uuid_table; > + > +/* > + * See if the UUID is unique among mounted XFS filesystems. > + * Mount fails if UUID is nil or a FS with the same UUID is already > mounted. > + */ > +STATIC int > +xfs_uuid_mount( > + struct xfs_mount *mp) > +{ > + uuid_t *uuid = &mp->m_sb.sb_uuid; > + int hole, i; > + > + if (mp->m_flags & XFS_MOUNT_NOUUID) > + return 0; > + > + if (uuid_is_nil(uuid)) { > + cmn_err(CE_WARN, > + "XFS: Filesystem %s has nil UUID - can't mount", > + mp->m_fsname); > + return XFS_ERROR(EINVAL); > + } > + > + mutex_lock(&xfs_uuid_table_mutex); > + for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) { > + if (uuid_is_nil(&xfs_uuid_table[i])) { > + hole = i; > + continue; > + } > + if (uuid_equal(uuid, &xfs_uuid_table[i])) > + goto out_duplicate; > + } > + > + if (hole < 0) { > + xfs_uuid_table = kmem_realloc(xfs_uuid_table, > + (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), > + xfs_uuid_table_size * sizeof(*xfs_uuid_table), > + KM_SLEEP); > + hole = xfs_uuid_table_size++; > + } > + xfs_uuid_table[hole] = *uuid; > + mutex_unlock(&xfs_uuid_table_mutex); > + > + return 0; > + > + out_duplicate: > + mutex_unlock(&xfs_uuid_table_mutex); > + cmn_err(CE_WARN, "XFS: Filesystem %s has duplicate UUID - can't > mount", > + mp->m_fsname); > + return XFS_ERROR(EINVAL); > +} > + > +STATIC void > +xfs_uuid_unmount( > + struct xfs_mount *mp) > +{ > + uuid_t *uuid = &mp->m_sb.sb_uuid; > + int i; > + > + if (mp->m_flags & XFS_MOUNT_NOUUID) > + return; > + > + mutex_lock(&xfs_uuid_table_mutex); > + for (i = 0; i < xfs_uuid_table_size; i++) { > + if (uuid_is_nil(&xfs_uuid_table[i])) > + continue; > + if (!uuid_equal(uuid, &xfs_uuid_table[i])) > + continue; > + memset(&xfs_uuid_table[i], 0, sizeof(uuid_t)); > + break; > + } > + ASSERT(i < xfs_uuid_table_size); > + mutex_unlock(&xfs_uuid_table_mutex); > +} > + > + > /* > * Free up the resources associated with a mount structure. Assume > that > * the structure was initially zeroed, so we can tell which fields got > @@ -1016,18 +1093,9 @@ xfs_mountfs( > > mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); > > - /* > - * XFS uses the uuid from the superblock as the unique > - * identifier for fsid. We can not use the uuid from the volume > - * since a single partition filesystem is identical to a single > - * partition volume/filesystem. > - */ > - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) { > - if (xfs_uuid_mount(mp)) { > - error = XFS_ERROR(EINVAL); > - goto out; > - } > - } > + error = xfs_uuid_mount(mp); > + if (error) > + goto out; > > /* > * Set the minimum read and write sizes > @@ -1275,8 +1343,7 @@ xfs_mountfs( > out_free_perag: > xfs_free_perag(mp); > out_remove_uuid: > - if (!(mp->m_flags & XFS_MOUNT_NOUUID)) > - uuid_table_remove(&mp->m_sb.sb_uuid); > + xfs_uuid_unmount(mp); > out: > return error; > } > @@ -1351,9 +1418,7 @@ xfs_unmountfs( > xfs_unmountfs_wait(mp); /* wait for async bufs */ > xfs_log_unmount_write(mp); > xfs_log_unmount(mp); > - > - if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) > - uuid_table_remove(&mp->m_sb.sb_uuid); > + xfs_uuid_unmount(mp); > > #if defined(DEBUG) > xfs_errortag_clearall(mp, 0); > @@ -1855,29 +1920,6 @@ xfs_freesb( > } > > /* > - * See if the UUID is unique among mounted XFS filesystems. > - * Mount fails if UUID is nil or a FS with the same UUID is already > mounted. > - */ > -STATIC int > -xfs_uuid_mount( > - xfs_mount_t *mp) > -{ > - if (uuid_is_nil(&mp->m_sb.sb_uuid)) { > - cmn_err(CE_WARN, > - "XFS: Filesystem %s has nil UUID - can't mount", > - mp->m_fsname); > - return -1; > - } > - if (!uuid_table_insert(&mp->m_sb.sb_uuid)) { > - cmn_err(CE_WARN, > - "XFS: Filesystem %s has duplicate UUID - can't mount", > - mp->m_fsname); > - return -1; > - } > - return 0; > -} > - > -/* > * Used to log changes to the superblock unit and width fields which > could > * be altered by the mount options, as well as any potential > sb_features2 > * fixup. Only the first superblock is updated. > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From strr-debian@decisionsoft.co.uk Mon Mar 30 05:30: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UAUXf3190174 for ; Mon, 30 Mar 2009 05:30:44 -0500 X-ASG-Debug-ID: 1238409050-4dbc00260000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from knox.decisionsoft.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E24F313DAB2A for ; Mon, 30 Mar 2009 03:30:51 -0700 (PDT) Received: from knox.decisionsoft.com (knox-be.decisionsoft.com [87.194.172.100]) by cuda.sgi.com with ESMTP id tZfqI9yIIYUTfOkX for ; Mon, 30 Mar 2009 03:30:51 -0700 (PDT) Received: from kennet.dsl.local ([10.0.0.11]) by knox.decisionsoft.com with esmtp (Exim 4.69) (envelope-from ) id 1LoEkm-000513-Rj for xfs@oss.sgi.com; Mon, 30 Mar 2009 11:30:04 +0100 Message-ID: <49D09F2C.8060406@decisionsoft.co.uk> Date: Mon, 30 Mar 2009 11:30:04 +0100 From: Stuart Rowan Reply-To: strr-debian@decisionsoft.co.uk User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Subject: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 10.0.0.11 X-SA-Exim-Mail-From: strr-debian@decisionsoft.co.uk X-SA-Exim-Scanned: No (on knox.decisionsoft.com); SAEximRunCond expanded to false X-SystemFilter-new-T: not expanding X-SystemFilter-new-S: not expanding X-SystemFilter-new-F: not expanding X-Barracuda-Connect: knox-be.decisionsoft.com[87.194.172.100] X-Barracuda-Start-Time: 1238409051 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.21759 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, We have a backup script running on another machine that ssh's in to the affected server and does the following: mkdir -p /tmp/foo; /usr/sbin/xfs_freeze -f /home; /sbin/lvcreate -s -L 20G -n snap-shot home ; /usr/sbin/xfs_freeze -u /home; mount -o nouuid,ro /dev/data/snap-shot /tmp/foo; It then rsyncs (over ssh) the data to the backup store from /tmp/foo The above command set hangs at running "/sbin/lvcreate -s -L 20G -n snap-shot home;" All I/O to /home is of course blocked at this point so for example exim starts queueing up all the mail. As soon as I manually log in some hours later and run /usr/sbin/xfs_freeze -u /home; ... the lvcreate succeeds, the backup runs etc. We recently upgraded this server to lenny from etch. It is still using the same kernel as it did with etch. The kernel is 2.6.26-bpo.1-amd64. So this has never happened before and it occurring directly coincides with my upgrade to lenny on Friday. The error occurred on Friday night Backup proceeded normally on Saturday night The error occurred on Sunday night This suggests to me that there's some sort of race going on? Previous version of xfsprogs (using etch): 2.8.11-1 Current version of xfsprogs (using lenny): 2.9.8-1lenny1 Anyone have any thoughts / is this a known issue with the 2.9.8 release? Kind regards, Stu. From sandeen@sandeen.net Mon Mar 30 08:46:21 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,J_CHICKENPOX_62 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 n2UDk0mu197140 for ; Mon, 30 Mar 2009 08:46:11 -0500 X-ASG-Debug-ID: 1238420716-0b2f005e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5125F1D46E1 for ; Mon, 30 Mar 2009 06:45:17 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id IQcTxdcF1scp7P4E for ; Mon, 30 Mar 2009 06:45:17 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 41A95AC08DD; Mon, 30 Mar 2009 08:45:16 -0500 (CDT) Message-ID: <49D0CCEB.1000404@sandeen.net> Date: Mon, 30 Mar 2009 08:45:15 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: strr-debian@decisionsoft.co.uk CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Subject: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 References: <49D09F2C.8060406@decisionsoft.co.uk> In-Reply-To: <49D09F2C.8060406@decisionsoft.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1238420737 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.21772 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 Stuart Rowan wrote: > Hi, > > We have a backup script running on another machine that ssh's in to the > affected server and does the following: > mkdir -p /tmp/foo; > /usr/sbin/xfs_freeze -f /home; > /sbin/lvcreate -s -L 20G -n snap-shot home ; > /usr/sbin/xfs_freeze -u /home; > mount -o nouuid,ro /dev/data/snap-shot /tmp/foo; > > It then rsyncs (over ssh) the data to the backup store from /tmp/foo > > The above command set hangs at running "/sbin/lvcreate -s -L 20G -n > snap-shot home;" > > All I/O to /home is of course blocked at this point so for example exim > starts queueing up all the mail. lvcreate now does the fs freeze on its own via the snapshot ioctl, so if you run freeze manually first, you are stuck behind that first freeze. Just drop the xfs_freeze's from the above, and all should be well. -Eric From strr-debian@decisionsoft.co.uk Mon Mar 30 08:59: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UDxJJn197621 for ; Mon, 30 Mar 2009 08:59:29 -0500 X-ASG-Debug-ID: 1238421577-444b01ba0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from knox.decisionsoft.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8FC5D13DB7B0 for ; Mon, 30 Mar 2009 06:59:38 -0700 (PDT) Received: from knox.decisionsoft.com (knox-be.decisionsoft.com [87.194.172.100]) by cuda.sgi.com with ESMTP id 3janRbkOKqh8riHI for ; Mon, 30 Mar 2009 06:59:38 -0700 (PDT) Received: from kennet.dsl.local ([10.0.0.11]) by knox.decisionsoft.com with esmtp (Exim 4.69) (envelope-from ) id 1LoI0r-0005mu-SM; Mon, 30 Mar 2009 14:58:53 +0100 Message-ID: <49D0D01A.8090608@decisionsoft.co.uk> Date: Mon, 30 Mar 2009 14:58:50 +0100 From: Stuart Rowan Reply-To: strr-debian@decisionsoft.co.uk User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Subject: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 References: <49D09F2C.8060406@decisionsoft.co.uk> <49D0CCEB.1000404@sandeen.net> In-Reply-To: <49D0CCEB.1000404@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 10.0.0.11 X-SA-Exim-Mail-From: strr-debian@decisionsoft.co.uk X-SA-Exim-Scanned: No (on knox.decisionsoft.com); SAEximRunCond expanded to false X-SystemFilter-new-T: not expanding X-SystemFilter-new-S: not expanding X-SystemFilter-new-F: not expanding X-Barracuda-Connect: knox-be.decisionsoft.com[87.194.172.100] X-Barracuda-Start-Time: 1238421578 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.21773 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, on 30/03/09 14:45: > Stuart Rowan wrote: >> Hi, >> >> We have a backup script running on another machine that ssh's in to the >> affected server and does the following: >> mkdir -p /tmp/foo; >> /usr/sbin/xfs_freeze -f /home; >> /sbin/lvcreate -s -L 20G -n snap-shot home ; >> /usr/sbin/xfs_freeze -u /home; >> mount -o nouuid,ro /dev/data/snap-shot /tmp/foo; >> >> It then rsyncs (over ssh) the data to the backup store from /tmp/foo >> >> The above command set hangs at running "/sbin/lvcreate -s -L 20G -n >> snap-shot home;" >> >> All I/O to /home is of course blocked at this point so for example exim >> starts queueing up all the mail. > > > lvcreate now does the fs freeze on its own via the snapshot ioctl, so if > you run freeze manually first, you are stuck behind that first freeze. > > Just drop the xfs_freeze's from the above, and all should be well. > > -Eric Eric, Many thanks for your prompt reply and explanation :-) It's good to know that there's an easy solution ... except we now have to differentiate the commands to run in the backup script based on the version of lvm on the remote system :-$ OOI when implementing the freeze ioctl, what made the developers decide that a freeze can't succeed on an already frozen filesystem ... you'd expect it to just be a no-op really? Cheers, Stu. From sandeen@sandeen.net Mon Mar 30 09:12:03 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,J_CHICKENPOX_62 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 n2UEBh9h198043 for ; Mon, 30 Mar 2009 09:11:53 -0500 X-ASG-Debug-ID: 1238422278-0b1301180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9ABD61D4968 for ; Mon, 30 Mar 2009 07:11:19 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id kK0wsvx9ymr2IOLg for ; Mon, 30 Mar 2009 07:11:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id B919EAC356A; Mon, 30 Mar 2009 09:11:18 -0500 (CDT) Message-ID: <49D0D306.5040204@sandeen.net> Date: Mon, 30 Mar 2009 09:11:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: strr-debian@decisionsoft.co.uk CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Subject: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 References: <49D09F2C.8060406@decisionsoft.co.uk> <49D0CCEB.1000404@sandeen.net> <49D0D01A.8090608@decisionsoft.co.uk> In-Reply-To: <49D0D01A.8090608@decisionsoft.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1238422279 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.21774 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 Stuart Rowan wrote: > Eric Sandeen wrote, on 30/03/09 14:45: >> Stuart Rowan wrote: >>> Hi, >>> >>> We have a backup script running on another machine that ssh's in to the >>> affected server and does the following: >>> mkdir -p /tmp/foo; >>> /usr/sbin/xfs_freeze -f /home; >>> /sbin/lvcreate -s -L 20G -n snap-shot home ; >>> /usr/sbin/xfs_freeze -u /home; >>> mount -o nouuid,ro /dev/data/snap-shot /tmp/foo; >>> >>> It then rsyncs (over ssh) the data to the backup store from /tmp/foo >>> >>> The above command set hangs at running "/sbin/lvcreate -s -L 20G -n >>> snap-shot home;" >>> >>> All I/O to /home is of course blocked at this point so for example exim >>> starts queueing up all the mail. >> >> lvcreate now does the fs freeze on its own via the snapshot ioctl, so if >> you run freeze manually first, you are stuck behind that first freeze. >> >> Just drop the xfs_freeze's from the above, and all should be well. >> >> -Eric > Eric, > > Many thanks for your prompt reply and explanation :-) > > It's good to know that there's an easy solution ... except we now have to > differentiate the commands to run in the backup script based on the version > of lvm on the remote system :-$ can't be *that* bad ... ;) > OOI when implementing the freeze ioctl, what made the developers decide > that a freeze can't succeed on an already frozen filesystem ... you'd > expect it to just be a no-op really? To complicate matters more, on newer upstream kernels w/ the freeze ioctl exposed for all filesystems, nested freezes are in fact supported. I'm not sure why sequential freezes were serialized initially, TBH... -Eric > Cheers, > Stu. > From sandeen@sandeen.net Mon Mar 30 10:18: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UFIM0Q201505 for ; Mon, 30 Mar 2009 10:18:33 -0500 X-ASG-Debug-ID: 1238426321-185000610000-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 0E7A913DBC09 for ; Mon, 30 Mar 2009 08:18:41 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id EIL4keObAoiZW9nL for ; Mon, 30 Mar 2009 08:18:41 -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 n2UFHZGJ011885; Mon, 30 Mar 2009 11:17:36 -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 n2UFHZkg023379; Mon, 30 Mar 2009 11:17:35 -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 n2UFHXtA026293; Mon, 30 Mar 2009 11:17:33 -0400 Message-ID: <49D0E28B.4090207@sandeen.net> Date: Mon, 30 Mar 2009 10:17:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: David Greaves CC: "Rafael J. Wysocki" , xfs@oss.sgi.com, Dave Chinner X-ASG-Orig-Subj: Re: Regression? 2.6.27-rc3 segfault on cold boot; not on warm boot. Subject: Re: Regression? 2.6.27-rc3 segfault on cold boot; not on warm boot. References: <48AD3921.5090709@dgreaves.com> <200808212026.17590.rjw@sisk.pl> <48AFDCE7.7010508@dgreaves.com> In-Reply-To: <48AFDCE7.7010508@dgreaves.com> 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: 1238426322 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.21779 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 David Greaves wrote: > Rafael J. Wysocki wrote: >> [Adding CCs] >> >> [The issue is probably present in 2.6.26 too] > > Yes, below is a netconsole boot of 2.26.6.3 > > I cold booted - lots of segfaults. I then did a ctrl-Alt-SysRq-S-U-B to a warm > boot. No segfaults > (lots of #### mark the split) > > I've just started 2.6.25.14 building for tomorrow to confirm how far back it > goes. (I'm 99% sure 2.6.25 is OK) > > David (trimming cc's to xfs) David, did you get anywhere with identifying this further? Thanks, -Eric From david@dgreaves.com Mon Mar 30 11:54:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 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 n2UGs1dk205094 for ; Mon, 30 Mar 2009 11:54:11 -0500 X-ASG-Debug-ID: 1238431997-2b6200f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 414B11D5482 for ; Mon, 30 Mar 2009 09:53:17 -0700 (PDT) Received: from mail.ukfsn.org (mail.ukfsn.org [77.75.108.10]) by cuda.sgi.com with ESMTP id VFV4JIG1OxZLEVxy for ; Mon, 30 Mar 2009 09:53:17 -0700 (PDT) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 3853BDEBA4; Mon, 30 Mar 2009 17:53:19 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id Cy2Em4Tn2iZW; Mon, 30 Mar 2009 17:31:47 +0100 (BST) Received: from elm.dgreaves.com (unknown [78.32.229.233]) by mail.ukfsn.org (Postfix) with ESMTP id 05D8DDEBA3; Mon, 30 Mar 2009 17:53:19 +0100 (BST) Received: from ash.local ([10.0.0.111]) by elm.dgreaves.com with esmtp (Exim 4.63) (envelope-from ) id 1LoKja-0006oX-Ti; Mon, 30 Mar 2009 17:53:14 +0100 Message-ID: <49D0F8F9.3010906@dgreaves.com> Date: Mon, 30 Mar 2009 17:53:13 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Eric Sandeen CC: "Rafael J. Wysocki" , xfs@oss.sgi.com, Dave Chinner X-ASG-Orig-Subj: Re: Regression? 2.6.27-rc3 segfault on cold boot; not on warm boot. Subject: Re: Regression? 2.6.27-rc3 segfault on cold boot; not on warm boot. References: <48AD3921.5090709@dgreaves.com> <200808212026.17590.rjw@sisk.pl> <48AFDCE7.7010508@dgreaves.com> <49D0E28B.4090207@sandeen.net> In-Reply-To: <49D0E28B.4090207@sandeen.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.ukfsn.org[77.75.108.10] X-Barracuda-Start-Time: 1238432018 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0007 1.0000 -2.0166 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.21786 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: > David Greaves wrote: >> Rafael J. Wysocki wrote: >>> [Adding CCs] >>> >>> [The issue is probably present in 2.6.26 too] >> Yes, below is a netconsole boot of 2.26.6.3 >> >> I cold booted - lots of segfaults. I then did a ctrl-Alt-SysRq-S-U-B to a warm >> boot. No segfaults >> (lots of #### mark the split) >> >> I've just started 2.6.25.14 building for tomorrow to confirm how far back it >> goes. (I'm 99% sure 2.6.25 is OK) >> >> David > > (trimming cc's to xfs) > > David, did you get anywhere with identifying this further? > > Thanks, > -Eric Sorry, I didn't. IIRC I spent a couple of weeks on it and found it too unpredictable to bisect. I have been running 2.6.27.4 on that machine for a few months (checks... Nov 08) and it's been good since then. Linus suspected HW and we got into a habit of warming the machine up before booting. That habit has long since gone and the last xfs hissy-fit was on 13 Sep 08. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." From fhines@blackopscode.com Mon Mar 30 12:02: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=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UH2JY9205363 for ; Mon, 30 Mar 2009 12:02:30 -0500 X-ASG-Debug-ID: 1238432538-183e01c70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sensor2.syn-recon.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E6FC13DC808 for ; Mon, 30 Mar 2009 10:02:18 -0700 (PDT) Received: from sensor2.syn-recon.net (sensor2.syn-recon.net [209.61.158.40]) by cuda.sgi.com with ESMTP id o4qnLHoKkl8bEBao for ; Mon, 30 Mar 2009 10:02:18 -0700 (PDT) Received: by sensor2.syn-recon.net (Postfix, from userid 99) id B8D663F26B7; Mon, 30 Mar 2009 12:01:29 -0500 (CDT) Received: from localhost.localdomain (unknown [64.39.1.185]) by sensor2.syn-recon.net (Postfix) with ESMTP id 5B6D23F269C for ; Mon, 30 Mar 2009 12:01:24 -0500 (CDT) Message-ID: <49D0FAE3.1090001@blackopscode.com> Date: Mon, 30 Mar 2009 12:01:23 -0500 From: Florian Hines User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data Subject: Re: Corruption of in-memory data References: <49CD2EF0.9060009@blackopscode.com> <49CD359E.905@sandeen.net> In-Reply-To: <49CD359E.905@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sensor2.syn-recon.net[209.61.158.40] X-Barracuda-Start-Time: 1238432559 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0062 1.0000 -1.9804 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.98 X-Barracuda-Spam-Status: No, SCORE=-1.98 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.21785 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: > Florian Hines wrote: >> Hey everybody, >> >> Over the last few day's I've been getting a rash (8 so far) of disk's >> throwing the error "Filesystem "sdxX": Corruption of in-memory data >> detected. Shutting down filesystem: sdxX". xfs_check never seem's to >> find anything and just unmounting and remounting solves the issue at >> least for awhile. > > try xfs_repair, with -n if you want a dry run. > > It's canceling a dirty transaction, I'm not sure why. The message is a > little misleading. Want to try 2.6.29? :) I'll give xfs_repair a run next time I get one. Thanks! Florian From BATV+92d2cf98dbc6d97ff70c+2045+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 30 12:55: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UHtGDd207540 for ; Mon, 30 Mar 2009 12:55:31 -0500 X-ASG-Debug-ID: 1238435735-5ae701820000-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 4780213DC8AA; Mon, 30 Mar 2009 10:55:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jQTyvu8uXVmVFDu7; Mon, 30 Mar 2009 10:55:36 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LoLhD-0003jw-65; Mon, 30 Mar 2009 17:54:51 +0000 Date: Mon, 30 Mar 2009 13:54:51 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix async io error handling in fsx Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Message-ID: <20090330175451.GA1041@infradead.org> References: <1238391050-14211-1-git-send-email-felixb@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238391050-14211-1-git-send-email-felixb@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: 1238435736 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, Mar 30, 2009 at 12:30:50AM -0500, Felix Blyakher wrote: > --- a/ltp/fsx.c > +++ b/ltp/fsx.c > @@ -976,19 +976,41 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) > fprintf(stderr, "errcode=%d\n", ret); > fprintf(stderr, "aio_rw: io_submit failed: %s\n", > strerror(ret)); > - return(-1); > + errno = -ret; > + return -1; I think we'd be better off having all these places that set errno in one place and use goto labels. That way you can also add a small comment about it. > + /* > + * The b0rked libaio defines event.res as signed. > + * However the kernel strucuture has it unsigned, > + * and it's used to pass negated error value. > + * Till the library is fixed use the temp var. > + */ This comment seems backwards to the patch description and the actual code. From Martin@lichtvoll.de Mon Mar 30 13:20: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 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 n2UIKNYZ208512 for ; Mon, 30 Mar 2009 13:20:33 -0500 X-ASG-Debug-ID: 1238437177-2c3d03000000-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 5411A1C7FE08 for ; Mon, 30 Mar 2009 11:19:37 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id wdy4LjSIu707SRyZ for ; Mon, 30 Mar 2009 11:19:37 -0700 (PDT) Received: from shambhala.lichtvoll.home (DSL01.212.114.235.145.ip-pool.NEFkom.net [212.114.235.145]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 5A34A5ADF6 for ; Mon, 30 Mar 2009 20:19:36 +0200 (CEST) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Corruption of in-memory data Subject: Re: Corruption of in-memory data Date: Mon, 30 Mar 2009 20:20:18 +0200 User-Agent: KMail/1.9.9 References: <49CD2EF0.9060009@blackopscode.com> (sfid-20090328_131214_312532_57B5FB47) In-Reply-To: <49CD2EF0.9060009@blackopscode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903302020.19511.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1238437198 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.21792 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 Freitag 27 M=E4rz 2009 schrieb Florian Hines: > Hey everybody, Hi, > Over the last few day's I've been getting a rash (8 so far) of disk's > throwing the error "Filesystem "sdxX": Corruption of in-memory data > detected. Shutting down filesystem: sdxX". xfs_check never seem's to > find anything and just unmounting and remounting solves the issue at > least for awhile. Is this usually caused by bad ram ? It's happened > on 6 systems so far (all using Debian Etch AMD64 with the stock 2.6.18 > kernel, each system as a 5 sata drives, not raided). > > Can anyone shed some light on what this error actually indicates for me > ? > > --Full error from dmesg below-- > Filesystem "sda3": XFS internal error xfs_trans_cancel at line 1138 of > file fs/xfs/xfs_trans.c. Caller 0xffffffff8818ead5 > > Call Trace: > [] :xfs:xfs_trans_cancel+0x5b/0xfe > [] :xfs:xfs_rename+0xa13/0xa9a > [] :xfs:xfs_vn_rename+0x2c/0x6f > [] __up_read+0x13/0x8a > [] :xfs:xfs_iunlock+0x57/0x79 > [] __up_read+0x13/0x8a > [] :xfs:xfs_iunlock+0x57/0x79 > [] :xfs:xfs_access+0x3d/0x46 > [] vfs_rename+0x2d5/0x426 > [] sys_renameat+0x180/0x1f9 > [] sys_newstat+0x28/0x31 > [] system_call+0x7e/0x83 > > xfs_force_shutdown(sda3,0x8) called from line 1139 of file > fs/xfs/xfs_trans.c. Return address =3D 0xffffffff8818fdee > Filesystem "sda3": Corruption of in-memory data detected. Shutting > down filesystem: sda3 Well we had "Corruption of in-memory data detected" errors with Debian AMD= =20 64 and the 2.6.22 backports.org kernel. They went away after we upgraded=20 to 2.6.26 backports.org kernel. Don't remember the trace tough anymore. I=20 posted it on the mailinglist... I think not a long time ago. Well here is: Is it possible the check an frozen XFS filesytem to avoid downtime?=20 2008-07-14 (was longer ago than I expected ;). http://oss.sgi.com/archives/xfs/2008-07/msg01475.html Backtrace look different, but that doesn't have to mean much.=20 I would try a newer kernel! I also recommend having a newer version of xfsprogs at hand in case of=20 problems. The one in Etch is completely out-dated. I have made a backport=20 back then which is still quite recent: http://people.teamix.net/~ms/debian/etch-backports/xfsprogs/ Ciao, =2D-=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From BATV+92d2cf98dbc6d97ff70c+2045+infradead.org+hch@bombadil.srs.infradead.org Mon Mar 30 13:57:34 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_14, 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 n2UIv96D209917 for ; Mon, 30 Mar 2009 13:57:24 -0500 X-ASG-Debug-ID: 1238439385-431503bd0000-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 97E051D5F67; Mon, 30 Mar 2009 11:56:25 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id fVf22eLdQxuf4QNM; Mon, 30 Mar 2009 11:56:25 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LoMem-0006Jz-97; Mon, 30 Mar 2009 18:56:24 +0000 Date: Mon, 30 Mar 2009 14:56:24 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix async io error handling in fsx Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Message-ID: <20090330185624.GA21753@infradead.org> References: <1238391050-14211-1-git-send-email-felixb@sgi.com> <20090330175451.GA1041@infradead.org> <2466E954-2122-4FEB-B3DA-8F06AA22BAB7@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2466E954-2122-4FEB-B3DA-8F06AA22BAB7@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: 1238439405 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, Mar 30, 2009 at 01:53:21PM -0500, Felix Blyakher wrote: >>> + /* >>> + * The b0rked libaio defines event.res as signed. >>> + * However the kernel strucuture has it unsigned, >>> + * and it's used to pass negated error value. >>> + * Till the library is fixed use the temp var. >>> + */ >> >> This comment seems backwards to the patch description and the actual >> code. > > Hmm, not really. > If the libaio library would be correct (do you know whom to talk > to and where to send a patch), the code would look like this: Yeah, but shouldn't the comment read: /* * The b0rked libaio defines event.res as *unsigned*. * However the kernel strucuture has it *signed*, * and it's used to pass negated error value. * Till the library is fixed use the temp var. */ From felixb@sgi.com Mon Mar 30 14:00: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=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_53 autolearn=no 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 n2UJ02mW210018 for ; Mon, 30 Mar 2009 14:00:12 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0F2558F80C3 for ; Mon, 30 Mar 2009 11:59:38 -0700 (PDT) Received: from eagdhcp-232-146.americas.sgi.com (eagdhcp-232-146.americas.sgi.com [128.162.232.146]) by estes.americas.sgi.com (Postfix) with ESMTP id A513470001C8; Mon, 30 Mar 2009 13:59:38 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <62A5B706-A608-4E51-8837-7F9EDCE69634@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090330185624.GA21753@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Date: Mon, 30 Mar 2009 13:59:38 -0500 References: <1238391050-14211-1-git-send-email-felixb@sgi.com> <20090330175451.GA1041@infradead.org> <2466E954-2122-4FEB-B3DA-8F06AA22BAB7@sgi.com> <20090330185624.GA21753@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 Mar 30, 2009, at 1:56 PM, Christoph Hellwig wrote: > On Mon, Mar 30, 2009 at 01:53:21PM -0500, Felix Blyakher wrote: >>>> + /* >>>> + * The b0rked libaio defines event.res as signed. >>>> + * However the kernel strucuture has it unsigned, >>>> + * and it's used to pass negated error value. >>>> + * Till the library is fixed use the temp var. >>>> + */ >>> >>> This comment seems backwards to the patch description and the actual >>> code. >> >> Hmm, not really. >> If the libaio library would be correct (do you know whom to talk >> to and where to send a patch), the code would look like this: > > Yeah, but shouldn't the comment read: > > /* > * The b0rked libaio defines event.res as *unsigned*. > * However the kernel strucuture has it *signed*, Ohh, I was blind twice. Sure, you're right. Thanks for pointing it out. Felix > > * and it's used to pass negated error value. > * Till the library is fixed use the temp var. > */ From felixb@sgi.com Mon Mar 30 14:37: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.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UJbYt1211374 for ; Mon, 30 Mar 2009 14:37:45 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 24B45AC01F for ; Mon, 30 Mar 2009 12:37:11 -0700 (PDT) Received: from eagdhcp-232-146.americas.sgi.com (eagdhcp-232-146.americas.sgi.com [128.162.232.146]) by estes.americas.sgi.com (Postfix) with ESMTP id BA1F8700016A; Mon, 30 Mar 2009 13:53:21 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <2466E954-2122-4FEB-B3DA-8F06AA22BAB7@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090330175451.GA1041@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: [PATCH] xfstests: fix async io error handling in fsx Date: Mon, 30 Mar 2009 13:53:21 -0500 References: <1238391050-14211-1-git-send-email-felixb@sgi.com> <20090330175451.GA1041@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 Mar 30, 2009, at 12:54 PM, Christoph Hellwig wrote: > On Mon, Mar 30, 2009 at 12:30:50AM -0500, Felix Blyakher wrote: >> --- a/ltp/fsx.c >> +++ b/ltp/fsx.c >> @@ -976,19 +976,41 @@ __aio_rw(int rw, int fd, char *buf, unsigned >> len, unsigned offset) >> fprintf(stderr, "errcode=%d\n", ret); >> fprintf(stderr, "aio_rw: io_submit failed: %s\n", >> strerror(ret)); >> - return(-1); >> + errno = -ret; >> + return -1; > > I think we'd be better off having all these places that set errno in > one > place and use goto labels. That way you can also add a small comment > about it. Makes sense, will do. > > >> + /* >> + * The b0rked libaio defines event.res as signed. >> + * However the kernel strucuture has it unsigned, >> + * and it's used to pass negated error value. >> + * Till the library is fixed use the temp var. >> + */ > > This comment seems backwards to the patch description and the actual > code. Hmm, not really. If the libaio library would be correct (do you know whom to talk to and where to send a patch), the code would look like this: if (event.res >= 0) fprintf(stderr, "bad io length: %lu instead of %u\n", event.res, len); else { fprintf(stderr, "errcode=%d\n", -event.res); fprintf(stderr, "aio_rw: async io failed: %s \n", strerror(-event.res)); errno = -event.res; return -1; } and no need for the temp var of right type, as in a patch now. The comments just explains the need for that "long res" var. It does not really describe the need to check the error value, that's just the part of interface, I assume. Though, I think, it would be clearer if I state the need to check the error first, and then note why it could not be done as above. I'll repost. Thanks, Felix From felixb@sgi.com Mon Mar 30 14:42: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_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2UJg6WZ211571 for ; Mon, 30 Mar 2009 14:42:16 -0500 Received: from snoot.americas.sgi.com (cxfsopus16.americas.sgi.com [128.162.240.194]) by relay3.corp.sgi.com (Postfix) with ESMTP id ABB52AC01F; Mon, 30 Mar 2009 12:41:42 -0700 (PDT) Received: by snoot.americas.sgi.com (Postfix, from userid 29043) id 2C3DC1A8CD10; Mon, 30 Mar 2009 14:41:41 -0500 (CDT) From: Felix Blyakher To: xfs@oss.sgi.com Cc: Felix Blyakher Subject: [PATCH] xfstests: fix async io error handling in fsx Date: Mon, 30 Mar 2009 14:41:41 -0500 Message-Id: <1238442101-24311-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 The result of async io returned in the event.res in addition to the number of bytes read/written provides negated error number. The broken libaio defines event.res as unsigned while the same structure in the kernel defines it as signed. The kernel indeed treat it as signed, and returns the negated error number. Till libaio is fixed we provide the signed long temp var. Also set errno for each error condition in aio_rw, as the caller is not aio aware and expects ret(-1)+errno by the traditional libc convention. Signed-off-by: Felix Blyakher --- ltp/fsx.c | 42 +++++++++++++++++++++++++++++++++++------- 1 files changed, 35 insertions(+), 7 deletions(-) diff --git a/ltp/fsx.c b/ltp/fsx.c index ebe5324..739d56c 100644 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -962,6 +962,7 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) static struct timespec ts; struct iocb *iocbs[] = { &iocb }; int ret; + long res; if (rw == READ) { io_prep_pread(&iocb, fd, buf, len, offset); @@ -976,21 +977,48 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) fprintf(stderr, "errcode=%d\n", ret); fprintf(stderr, "aio_rw: io_submit failed: %s\n", strerror(ret)); - return(-1); + goto out_error; } ret = io_getevents(io_ctx, 1, 1, &event, &ts); if (ret != 1) { - fprintf(stderr, "errcode=%d\n", ret); - fprintf(stderr, "aio_rw: io_getevents failed: %s\n", - strerror(ret)); - return -1; + if (ret == 0) + fprintf(stderr, "aio_rw: no events available\n"); + else { + fprintf(stderr, "errcode=%d\n", -ret); + fprintf(stderr, "aio_rw: io_getevents failed: %s\n", + strerror(-ret)); + } + goto out_error; } if (len != event.res) { - fprintf(stderr, "bad read length: %lu instead of %u\n", - event.res, len); + /* + * The b0rked libaio defines event.res as unsigned. + * However the kernel strucuture has it signed, + * and it's used to pass negated error value. + * Till the library is fixed use the temp var. + */ + res = (long)event.res; + if (res >= 0) + fprintf(stderr, "bad io length: %lu instead of %u\n", + res, len); + else { + fprintf(stderr, "errcode=%d\n", -res); + fprintf(stderr, "aio_rw: async io failed: %s\n", + strerror(-res)); + goto out_error; + } + } return event.res; + +out_error: + /* + * The caller expects error return in traditional libc + * convention, i.e. -1 and the errno set to error. + */ + errno = ret <= 0 ? -ret : -res; + return -1; } int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) -- 1.5.4.rc3 From sandeen@sandeen.net Mon Mar 30 17:02: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 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 n2UM1uTE216841 for ; Mon, 30 Mar 2009 17:02:06 -0500 X-ASG-Debug-ID: 1238450471-4348014d0000-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 B4FF21D6CAC for ; Mon, 30 Mar 2009 15:01:11 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id DBZUMY0ame2zfAqr for ; Mon, 30 Mar 2009 15:01: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 n2UM1Af1007243 for ; Mon, 30 Mar 2009 18:01:11 -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 n2UM1B82014759 for ; Mon, 30 Mar 2009 18:01:11 -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 n2UM16Ld005723 for ; Mon, 30 Mar 2009 18:01:10 -0400 Message-ID: <49D14120.8040804@sandeen.net> Date: Mon, 30 Mar 2009 17:01:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: xfs mailing list X-ASG-Orig-Subj: Mystery solved? files not written for days... Subject: Mystery solved? files not written for days... 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: 1238450492 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1294 1.0000 -1.2190 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.22 X-Barracuda-Spam-Status: No, SCORE=-1.22 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.21806 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 LKML: [PATCH] writeback: guard against jiffies wraparound on inode->dirtied_when checks When a file is continually dirtied, the check in sync_sb_inodes: /* Was this inode dirtied after sync_sb_inodes was called? */ if (time_after(inode->dirtied_when, start)) break; may have large windows where this trips on the first (continually-dirtied) inode on the list when the time_after check has wrapped, causing the nothing to be written out for that superblock, potentially for days. Could this be the reason for those various "hey, my file disappeared after a crash and I hadn't written to it for *days*" reports we got now and then, leaving us all scratching our heads? -Eric From felixb@sgi.com Mon Mar 30 17:57:53 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 n2UMvXHo219832 for ; Mon, 30 Mar 2009 17:57:43 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8CDD58F80BB for ; Mon, 30 Mar 2009 15:57:10 -0700 (PDT) Received: from eagdhcp-232-146.americas.sgi.com (eagdhcp-232-146.americas.sgi.com [128.162.232.146]) by estes.americas.sgi.com (Postfix) with ESMTP id 62C1D700016A; Mon, 30 Mar 2009 17:30:55 -0500 (CDT) Cc: xfs mailing list Message-Id: <7FC08527-82CE-4D3F-A1C6-76FAAE4389AB@sgi.com> From: Felix Blyakher To: Eric Sandeen In-Reply-To: <49D14120.8040804@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: Mystery solved? files not written for days... Date: Mon, 30 Mar 2009 17:30:54 -0500 References: <49D14120.8040804@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 30, 2009, at 5:01 PM, Eric Sandeen wrote: > On LKML: > > [PATCH] writeback: guard against jiffies wraparound on > inode->dirtied_when checks The "jiffies wraparound" sounds very familiar, but I thought it's been fixed ages ago. > When a file is continually dirtied, the check in sync_sb_inodes: > > /* Was this inode dirtied after sync_sb_inodes was called? */ > if (time_after(inode->dirtied_when, start)) > break; > > may have large windows where this trips on the first > (continually-dirtied) inode on the list when the time_after check has > wrapped, causing the nothing to be written out for that superblock, > potentially for days. > > Could this be the reason for those various "hey, my file disappeared > after a crash and I hadn't written to it for *days*" reports we got > now > and then, leaving us all scratching our heads? The "jiffies wraparound" could definitely cause this. Felix > > > -Eric > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From felixb@oss.sgi.com Mon Mar 30 22:23:29 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,AWL,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 n2V3NOxn232145 for ; Mon, 30 Mar 2009 22:23:29 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V3NOKL232113; Mon, 30 Mar 2009 22:23:24 -0500 Date: Mon, 30 Mar 2009 22:23:24 -0500 Message-Id: <200903310323.n2V3NOKL232113@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-20755-g15f7176 X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 X-Git-Newrev: 15f7176eb1cccec0a332541285ee752b935c1c85 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 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 (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 Mon Mar 30 22:23:55 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,AWL,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 n2V3NoOw232245 for ; Mon, 30 Mar 2009 22:23:55 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V3NoRK232157; Mon, 30 Mar 2009 22:23:50 -0500 Date: Mon, 30 Mar 2009 22:23:50 -0500 Message-Id: <200903310323.n2V3NoRK232157@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-20838-g5123bc3 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 61454f33389ecfac68846e07d29c8d18af342c43 X-Git-Newrev: 5123bc35d2bd2e5c344a53e634edec2cd0861a0e 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 5123bc3 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs 2717420 xfs: cleanup uuid handling 1a5902c xfs: remove m_attroffset 9da096f xfs: fix various typos bddaafa xfs: pagecache usage optimization 6447c36 xfs: remove m_litino a19d9f8 xfs: kill ino64 mount option a0b0b8a xfs: kill mutex_t typedef 8b11217 xfs: increase the maximum number of supported ACL entries from 61454f33389ecfac68846e07d29c8d18af342c43 (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 5123bc35d2bd2e5c344a53e634edec2cd0861a0e Merge: 930861c4e6f13ce2e7d06cd1ef11441a065517d9 27174203f570b923e5c02c618a5557295bab8755 Author: Felix Blyakher Date: Mon Mar 30 22:17:44 2009 -0500 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs commit 27174203f570b923e5c02c618a5557295bab8755 Author: Christoph Hellwig Date: Mon Mar 30 10:21:31 2009 +0200 xfs: cleanup uuid handling The uuid table handling should not be part of a semi-generic uuid library but in the XFS code using it, so move those bits to xfs_mount.c and refactor the whole glob to make it a proper abstraction. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 1a5902c5d2ad4f3aa1ee747017622d5d4edfa20f Author: Christoph Hellwig Date: Sun Mar 29 19:26:46 2009 +0200 xfs: remove m_attroffset With the upcoming v3 inodes the default attroffset needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Also replace the assert for wrong inode sizes with a proper error check also included in non-debug builds. Note that the ENOSYS return for that might seem odd, but that error is returned by xfs_mount_validate_sb for all theoretically valid but not supported filesystem geometries. Signed-off-by: Christoph Hellwig Reviewed-by: Josef 'Jeff' Sipek commit 9da096fd13e63031662566e5e868ec3dcc70824e Author: Malcolm Parsons Date: Sun Mar 29 09:55:42 2009 +0200 xfs: fix various typos Signed-off-by: Malcolm Parsons Reviewed-by: Christoph Hellwig commit bddaafa11a549fff311bcf2e04bbfb5139812cb7 Author: Hisashi Hifumi Date: Sun Mar 29 09:53:38 2009 +0200 xfs: pagecache usage optimization 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 Signed-off-by: Hisashi Hifumi Reviewed-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 6447c36209c4268352d55d04d041396ebb8add4a Author: Christoph Hellwig Date: Sun Mar 29 09:51:14 2009 +0200 xfs: remove m_litino With the upcoming v3 inodes the inode data/attr area size needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit a19d9f887d81106d52cacbc9930207b487e07e0e Author: Christoph Hellwig Date: Sun Mar 29 09:51:08 2009 +0200 xfs: kill ino64 mount option The ino64 mount option adds a fixed offset to 32bit inode numbers to bring them into the 64bit range. There's no need for this kind of debug tool given that it's easy to produce real 64bit inode numbers for testing. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit a0b0b8a5b3cb47892b5984cd86272446bee5f511 Author: Christoph Hellwig Date: Sun Mar 29 09:51:00 2009 +0200 xfs: kill mutex_t typedef People continue to complain about this for weird reasons, but there's really no point in keeping this typedef for a couple of users anyway. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit 8b112171734c791afaf43ccc8c6ec492e7006e44 Author: Felix Blyakher Date: Fri Mar 27 17:28:43 2009 -0500 xfs: increase the maximum number of supported ACL entries With big installation current 25 maximum number of supported ACL entries is not enough any more. Increase the limit to 100. Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/mutex.h | 25 ------ fs/xfs/linux-2.6/xfs_aops.c | 1 + fs/xfs/linux-2.6/xfs_iops.c | 3 - fs/xfs/linux-2.6/xfs_linux.h | 2 +- fs/xfs/linux-2.6/xfs_super.c | 24 +----- fs/xfs/quota/xfs_dquot.h | 4 +- fs/xfs/quota/xfs_qm.c | 4 +- fs/xfs/quota/xfs_qm.h | 6 +- fs/xfs/quota/xfs_qm_syscalls.c | 2 +- fs/xfs/support/uuid.c | 71 ----------------- fs/xfs/support/uuid.h | 4 - fs/xfs/xfs_acl.h | 2 +- fs/xfs/xfs_attr_leaf.c | 3 +- fs/xfs/xfs_bmap.c | 62 ++++++++++----- fs/xfs/xfs_bmap.h | 6 +- fs/xfs/xfs_btree.c | 4 +- fs/xfs/xfs_btree.h | 2 +- fs/xfs/xfs_da_btree.h | 2 +- fs/xfs/xfs_dinode.h | 4 +- fs/xfs/xfs_dir2_block.c | 7 +-- fs/xfs/xfs_dir2_data.h | 2 +- fs/xfs/xfs_dir2_leaf.c | 15 +---- fs/xfs/xfs_dir2_node.c | 2 +- fs/xfs/xfs_dir2_sf.c | 13 +--- 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 | 170 ++++++++++++++++++++++++---------------- fs/xfs/xfs_mount.h | 10 +-- 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 +- 39 files changed, 205 insertions(+), 293 deletions(-) delete mode 100644 fs/xfs/linux-2.6/mutex.h hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Mon Mar 30 23:32:55 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,AWL,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 n2V4Wo92235407 for ; Mon, 30 Mar 2009 23:32:55 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V4WotS235373; Mon, 30 Mar 2009 23:32:50 -0500 Date: Mon, 30 Mar 2009 23:32:50 -0500 Message-Id: <200903310432.n2V4WotS235373@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-20755-g15f7176 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: c141b2928fe20396a9ecdec85526e4b66ae96c90 X-Git-Newrev: 15f7176eb1cccec0a332541285ee752b935c1c85 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 from c141b2928fe20396a9ecdec85526e4b66ae96c90 (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 Mon Mar 30 23:34:37 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_24 autolearn=no 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 n2V4YWXV235883 for ; Mon, 30 Mar 2009 23:34:37 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V4YWUo235534; Mon, 30 Mar 2009 23:34:32 -0500 Date: Mon, 30 Mar 2009 23:34:32 -0500 Message-Id: <200903310434.n2V4YWUo235534@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-20838-g5123bc3 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: 15f7176eb1cccec0a332541285ee752b935c1c85 X-Git-Newrev: 5123bc35d2bd2e5c344a53e634edec2cd0861a0e 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 5123bc3 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs 2717420 xfs: cleanup uuid handling 1a5902c xfs: remove m_attroffset 9da096f xfs: fix various typos bddaafa xfs: pagecache usage optimization 6447c36 xfs: remove m_litino a19d9f8 xfs: kill ino64 mount option a0b0b8a xfs: kill mutex_t typedef 8b11217 xfs: increase the maximum number of supported ACL entries 6cc8764 xfs: factor out code to find the longest free extent in the AG cb4c8cc xfs: kill VN_BAD 8fab451 xfs: kill vn_atime_* helpers. 076e6ac xfs: cleanup xlog_bread ff0205e xfs: cleanup xlog_recover_do_trans dd0bbad xfs: remove another leftover of the old inode log item format 21b699c xfs: cleanup log unmount handling da5309c Fix xfs debug build breakage by pushing xfs_error.h after 7bf446f xfs: include header files for prototypes 3180e66 xfs: make symbols static 2441849 xfs: move declaration to header file 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 3a011a1 Revert "[XFS] remove old vmap cache" cf7dab8 Revert "[XFS] use scalable vmap API" 7c8f7af xfs: reject swapext ioctl on swapfiles 2643075 xfs: fix error handling in xfs_log_mount fcafb71 xfs: get rid of indirections in the quotaops implementation c9a192d xfs: sanitize qh_lock wrappers 7201813 xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED e249458 xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE 517b5e8 xfs: merge xfs_mkdir into xfs_create a568778 xfs: remove uchar_t/ushort_t/uint_t/ulong_t types 0d87e65 xfs: remove superflous inobt macros 7153f8b xfs: remove iclog calculation special cases 8e9b6e7 xfs: remove the unused XFS_QMOPT_DQLOCK flag 4346cdd xfs: cleanup xfs_find_handle ef8f7fc xfs: cleanup error handling in xfs_swap_extents d4bb6d0 xfs: merge xfs_inode_flush into xfs_fs_write_inode e1486de xfs: factor out attr fork reset handling c52e9fd xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK cb3f35b xfs: tiny cleanup for xfs_link b93b6e4 xfs: make sure to free the real-time inodes in the mount error path f9057e3 xfs: cleanup error handling in xfs_mountfs: 3228149 xfs: Check buffer lengths in log recovery ac12b4e don't reallocate sxp variable passed into xfs_swapext 5e10657 [XFS] Warn on transaction in flight on read-only remount 957274d Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs 5253a11 [XFS] remove always-true #ifndef HAVE_FORMAT32 tests 33ad965 Long btree pointers are still 64 bit on disk 2809f76 xfs: sanity check attr fork size 7884bc8 xfs: fix bad_features2 fixups for the root filesystem 98b8c7a xfs: add a lock class for group/project dquots 5bb87a3 xfs: lockdep annotations for xfs_dqlock2 a4edd1d xfs: add a separate lock class for the per-mount list of dquots 178eae3 xfs: use mnt_want_write in compat_attrmulti ioctl d296d30 xfs: fix dentry aliasing issues in open_by_handle 9d87c31 [XFS] Remove the rest of the macro-to-function indirections. c088f4e Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 ce79735 Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/xfs 6206aa8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 95f8e30 [XFS] use scalable vmap API d285975 [XFS] remove old vmap cache from 15f7176eb1cccec0a332541285ee752b935c1c85 (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 5123bc35d2bd2e5c344a53e634edec2cd0861a0e Merge: 930861c4e6f13ce2e7d06cd1ef11441a065517d9 27174203f570b923e5c02c618a5557295bab8755 Author: Felix Blyakher Date: Mon Mar 30 22:17:44 2009 -0500 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs commit 27174203f570b923e5c02c618a5557295bab8755 Author: Christoph Hellwig Date: Mon Mar 30 10:21:31 2009 +0200 xfs: cleanup uuid handling The uuid table handling should not be part of a semi-generic uuid library but in the XFS code using it, so move those bits to xfs_mount.c and refactor the whole glob to make it a proper abstraction. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 1a5902c5d2ad4f3aa1ee747017622d5d4edfa20f Author: Christoph Hellwig Date: Sun Mar 29 19:26:46 2009 +0200 xfs: remove m_attroffset With the upcoming v3 inodes the default attroffset needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Also replace the assert for wrong inode sizes with a proper error check also included in non-debug builds. Note that the ENOSYS return for that might seem odd, but that error is returned by xfs_mount_validate_sb for all theoretically valid but not supported filesystem geometries. Signed-off-by: Christoph Hellwig Reviewed-by: Josef 'Jeff' Sipek commit 9da096fd13e63031662566e5e868ec3dcc70824e Author: Malcolm Parsons Date: Sun Mar 29 09:55:42 2009 +0200 xfs: fix various typos Signed-off-by: Malcolm Parsons Reviewed-by: Christoph Hellwig commit bddaafa11a549fff311bcf2e04bbfb5139812cb7 Author: Hisashi Hifumi Date: Sun Mar 29 09:53:38 2009 +0200 xfs: pagecache usage optimization 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 Signed-off-by: Hisashi Hifumi Reviewed-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 6447c36209c4268352d55d04d041396ebb8add4a Author: Christoph Hellwig Date: Sun Mar 29 09:51:14 2009 +0200 xfs: remove m_litino With the upcoming v3 inodes the inode data/attr area size needs to be calculated for each specific inode, so we can't cache it in the superblock anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit a19d9f887d81106d52cacbc9930207b487e07e0e Author: Christoph Hellwig Date: Sun Mar 29 09:51:08 2009 +0200 xfs: kill ino64 mount option The ino64 mount option adds a fixed offset to 32bit inode numbers to bring them into the 64bit range. There's no need for this kind of debug tool given that it's easy to produce real 64bit inode numbers for testing. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit a0b0b8a5b3cb47892b5984cd86272446bee5f511 Author: Christoph Hellwig Date: Sun Mar 29 09:51:00 2009 +0200 xfs: kill mutex_t typedef People continue to complain about this for weird reasons, but there's really no point in keeping this typedef for a couple of users anyway. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reviewed-by: Felix Blyakher commit 8b112171734c791afaf43ccc8c6ec492e7006e44 Author: Felix Blyakher Date: Fri Mar 27 17:28:43 2009 -0500 xfs: increase the maximum number of supported ACL entries With big installation current 25 maximum number of supported ACL entries is not enough any more. Increase the limit to 100. Signed-off-by: Felix Blyakher commit 6cc87645e2a3c28d857b074e90bf88bfcd117afa Author: Dave Chinner Date: Mon Mar 16 08:29:46 2009 +0100 xfs: factor out code to find the longest free extent in the AG Signed-off-by: Dave Chinner Signed-off-by: Christoph Hellwig commit cb4c8cc1e92bc68c952e9a81a9fb9736bd8150de Author: Christoph Hellwig Date: Mon Mar 16 08:25:25 2009 +0100 xfs: kill VN_BAD Remove this rather pointless wrapper and use is_bad_inode directly. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 8fab451e3cfe02a5e3dfc4bab3cfb975bc11fc09 Author: Christoph Hellwig Date: Mon Mar 16 08:24:46 2009 +0100 xfs: kill vn_atime_* helpers. Two out of three are unused already, and the third is better done open-coded with a comment describing what's going on here. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 076e6acb8f0d9532ee6c50512c1927c0a8e34f2f Author: Christoph Hellwig Date: Mon Mar 16 08:24:13 2009 +0100 xfs: cleanup xlog_bread Most callers of xlog_bread need to call xlog_align to get the actual offset. Consolidate that call into the main xlog_bread and provide a _xlog_bread for those few that don't want the actual offset. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit ff0205e032b9733bb634ad5dadc79a0f6d30c721 Author: Christoph Hellwig Date: Mon Mar 16 08:20:52 2009 +0100 xfs: cleanup xlog_recover_do_trans Change the big if-elsif-else block handling the different item types into a more natural switch, remove assignments in conditionals and remove an out of place comment from centuries ago on IRIX. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit dd0bbad81c8d02315a5035d3d6ea441dd1254dc1 Author: Christoph Hellwig Date: Mon Mar 16 08:19:59 2009 +0100 xfs: remove another leftover of the old inode log item format There's another little snipplet of code left from the handling of the old inode log item format in xlog_recover_do_inode_trans. Kill it as it can't be reached anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 21b699c89545ed94d9a1c6fcc8ac704784f68f40 Author: Christoph Hellwig Date: Mon Mar 16 08:19:29 2009 +0100 xfs: cleanup log unmount handling Kill the current xfs_log_unmount wrapper and opencode the two function calls in the only caller. Rename the current xfs_log_unmount_dealloc to xfs_log_unmount as it undoes xfs_log_mount and the new name makes that more clear. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit da5309cd28ffda6ed8a4147bd14f1e4fbbd6503d Author: Felix Blyakher Date: Thu Mar 12 09:33:37 2009 -0500 Fix xfs debug build breakage by pushing xfs_error.h after xfs_mount.h, which it depends on. Reported-by: Stephen Rothwell Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Felix Blyakher 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 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 commit 3a011a171906a3a51a43bb860fb7c66a64cab140 Author: Felix Blyakher Date: Wed Feb 18 15:56:51 2009 -0600 Revert "[XFS] remove old vmap cache" This reverts commit d2859751cd0bf586941ffa7308635a293f943c17. This commit caused regression. We'll try to fix use of new vmap API for next release. Signed-off-by: Christoph Hellwig Signed-off-by: Felix Blyakher commit cf7dab801796b9ee52a6dc99888a66bf476538ec Author: Felix Blyakher Date: Wed Feb 18 15:41:28 2009 -0600 Revert "[XFS] use scalable vmap API" This reverts commit 95f8e302c04c0b0c6de35ab399a5551605eeb006. This commit caused regression. We'll try to fix use of new vmap API for next release. Signed-off-by: Christoph Hellwig Signed-off-by: Felix Blyakher commit 7c8f7af67de19a7ae33a6fc06764771265b0cc56 Author: Christoph Hellwig Date: Thu Feb 12 19:56:00 2009 +0100 xfs: reject swapext ioctl on swapfiles Swapfiles are magic - I/O is directly initialized by the VM without involving the filesystem. Swapping out extents underneath the VM thus can cause severe problems. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 264307520b120593ba63c4a23c58dd5e2ec5e822 Author: Christoph Hellwig Date: Thu Feb 12 19:55:48 2009 +0100 xfs: fix error handling in xfs_log_mount We can't just call xfs_log_unmount_dealloc on any failure because the ail thread which is torn down by xfs_log_unmount_dealloc might not be initialized yet. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher Reported-by: Lachlan McIlroy commit fcafb71b57a039f2113b0321b3b5535fea3a0aca Author: Christoph Hellwig Date: Mon Feb 9 08:47:34 2009 +0100 xfs: get rid of indirections in the quotaops implementation Currently we call from the nicely abstracted linux quotaops into a ugly multiplexer just to split the calls out at the same boundary again. Rewrite the quota ops handling to remove that obfucation. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit c9a192dcf906a33f59c555924e7796a4b9454217 Author: Christoph Hellwig Date: Mon Feb 9 08:47:22 2009 +0100 xfs: sanitize qh_lock wrappers Get rid of various obsfucating wrappers for accessing the quota hash lock, we only keep the accessors for accessing the mplist and freelist locks as they encode a multi-level datastructure walk. But make sure all of them are defined in the same way as simple macros. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 7201813bf55cc06e6a7405831f63df96ee7842e7 Author: Christoph Hellwig Date: Mon Feb 9 08:39:24 2009 +0100 xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED Now that we have a helper to test if a mutex is held use it instead of our own little hacks. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit e249458220c9799fe94573abd341d29c83579671 Author: Christoph Hellwig Date: Mon Feb 9 08:38:39 2009 +0100 xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE Remove these macros which only obsfucated the code in rather nast ways. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 517b5e8c8516a25a0df3b530fd183eb493a96698 Author: Christoph Hellwig Date: Mon Feb 9 08:38:02 2009 +0100 xfs: merge xfs_mkdir into xfs_create xfs_create and xfs_mkdir only have minor differences, so merge both of them into a sigle function. While we're at it also make the error handling code more straight-forward. Signed-off-by: Christoph Hellwig Dave Chinner commit a568778739030fb68805dda1af2f4ebbc3adad7d Author: Christoph Hellwig Date: Mon Feb 9 08:37:39 2009 +0100 xfs: remove uchar_t/ushort_t/uint_t/ulong_t types Just another set of types obsfucating the code, remove them. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 0d87e656dd961145f47ede5e37eceecfdc7d8197 Author: Christoph Hellwig Date: Mon Feb 9 08:37:14 2009 +0100 xfs: remove superflous inobt macros xfs_ialloc_btree.h has a a cuple of macros that only obsfucate the code but don't provide any abstraction benefits. This patches removes those and cleans up the reamaining defintions up a little. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 7153f8ba2b18f18f661d5cb172782bcae2eadce9 Author: Christoph Hellwig Date: Mon Feb 9 08:36:46 2009 +0100 xfs: remove iclog calculation special cases Our default has been to always use 8 32KB log buffers for a while now, so remove the special casing for larger block size filesystem to use the same or even lower number of buffers. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 8e9b6e7fa4544ea8a0e030c8987b918509c8ff47 Author: Christoph Hellwig Date: Sun Feb 8 21:51:42 2009 +0100 xfs: remove the unused XFS_QMOPT_DQLOCK flag The XFS_QMOPT_DQLOCK flag introduces major complexity in the quota subsystem but isn't actually used anywhere. So remove it and all the hazzles it introduces. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 4346cdd4647e5eef15817dbfc2c091cac55e33d9 Author: Christoph Hellwig Date: Sun Feb 8 21:51:14 2009 +0100 xfs: cleanup xfs_find_handle Remove the superflous igrab by keeping a reference on the path/file all the time and clean up various bits of surrounding code. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit ef8f7fc549bf345d92f396f5aa7b152b4969cbf7 Author: Josef 'Jeff' Sipek Date: Wed Feb 4 09:37:43 2009 +0100 xfs: cleanup error handling in xfs_swap_extents Use multiple lables for proper error unwinding and get rid of some now superflous variables. Signed-off-by: Josef 'Jeff' Sipek Signed-off-by: Christoph Hellwig Tested-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit d4bb6d0698090c485e2e80e8a13852be5a8bfb04 Author: Christoph Hellwig Date: Wed Feb 4 09:36:19 2009 +0100 xfs: merge xfs_inode_flush into xfs_fs_write_inode Splitting the task for a VFS-induced inode flush into two functions doesn't make any sense, so merge the two functions dealing with it. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher Reviewed-by: Dave Chinner commit e1486dea0bf4bc75a52a983281076f454a894b66 Author: Christoph Hellwig Date: Wed Feb 4 09:36:00 2009 +0100 xfs: factor out attr fork reset handling We currently duplicate code to reset the attribute fork after the last attribute has been deleted. Factor this out into a small helper. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit c52e9fd8a9d3ac019680ffa315c1a0689d401ce3 Author: Christoph Hellwig Date: Wed Feb 4 09:34:34 2009 +0100 xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK These aren't only unused but also reference a lock that doesn't exist anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit cb3f35bb3bf0759e00cd4f68155da9b636421f84 Author: Christoph Hellwig Date: Wed Feb 4 09:34:20 2009 +0100 xfs: tiny cleanup for xfs_link The source and target inodes are guaranteed to never be the same by the VFS, so no need to check for that (and we would get into bad trouble later anyway if that were the case). Also clean up the error handling to use two gotos instead of nested conditions. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit b93b6e434c046459cf3111c76dce46ba4abcb2b6 Author: Christoph Hellwig Date: Wed Feb 4 09:33:58 2009 +0100 xfs: make sure to free the real-time inodes in the mount error path When mount fails after allocating the real-time inodes we currently leak them. Add a new helper to free the real-time inodes which can be used by both the mount and unmount path. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit f9057e3da79d18fdbd9d6adbb183f032c614feeb Author: Christoph Hellwig Date: Wed Feb 4 09:31:52 2009 +0100 xfs: cleanup error handling in xfs_mountfs: Clean up the error handling in xfs_mountfs. Use readable goto label names, simplify the uuid handling and other error conditions. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 3228149ceb8b045e324cd268be9182bb26e6488b Author: Dave Chinner Date: Thu Jan 22 15:37:47 2009 +1100 xfs: Check buffer lengths in log recovery Before trying to obtain, read or write a buffer, check that the buffer length is actually valid. If it is not valid, then something read in the recovery process has been corrupted and we should abort recovery. Reported-by: Eric Sesterhenn Tested-by: Eric Sesterhenn Reviewed-by: Christoph Hellwig Reviewed-by: Felix Blyakher Signed-off-by: Dave Chinner Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/Makefile | 1 + fs/xfs/linux-2.6/mutex.h | 25 --- fs/xfs/linux-2.6/xfs_aops.c | 1 + fs/xfs/linux-2.6/xfs_ioctl.c | 117 +++++------- fs/xfs/linux-2.6/xfs_iops.c | 33 +--- fs/xfs/linux-2.6/xfs_linux.h | 13 +-- fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++ fs/xfs/linux-2.6/xfs_super.c | 137 +++++--------- fs/xfs/linux-2.6/xfs_super.h | 1 + fs/xfs/linux-2.6/xfs_sync.h | 1 + fs/xfs/linux-2.6/xfs_vnode.h | 32 --- fs/xfs/quota/xfs_dquot.c | 28 ++-- fs/xfs/quota/xfs_dquot.h | 18 +-- fs/xfs/quota/xfs_qm.c | 212 ++++++--------------- fs/xfs/quota/xfs_qm.h | 26 ++-- fs/xfs/quota/xfs_qm_bhv.c | 1 - fs/xfs/quota/xfs_qm_syscalls.c | 190 +----------------- fs/xfs/quota/xfs_quota_priv.h | 38 ++--- fs/xfs/quota/xfs_trans_dquot.c | 16 +- fs/xfs/support/debug.c | 1 + fs/xfs/support/uuid.c | 71 ------- fs/xfs/support/uuid.h | 4 - fs/xfs/xfs_acl.h | 2 +- fs/xfs/xfs_ag.h | 4 +- fs/xfs/xfs_alloc.c | 26 ++- fs/xfs/xfs_alloc.h | 6 + fs/xfs/xfs_attr_leaf.c | 58 +++--- fs/xfs/xfs_bmap.c | 76 +++++--- fs/xfs/xfs_bmap.h | 6 +- fs/xfs/xfs_btree.c | 4 +- fs/xfs/xfs_btree.h | 2 +- fs/xfs/xfs_da_btree.c | 2 +- fs/xfs/xfs_da_btree.h | 9 +- fs/xfs/xfs_dfrag.c | 68 +++---- fs/xfs/xfs_dinode.h | 4 +- fs/xfs/xfs_dir2.c | 2 - fs/xfs/xfs_dir2_block.c | 7 +- fs/xfs/xfs_dir2_data.h | 2 +- fs/xfs/xfs_dir2_leaf.c | 17 +-- fs/xfs/xfs_dir2_node.c | 2 +- fs/xfs/xfs_dir2_sf.c | 13 +-- fs/xfs/xfs_extfree_item.h | 6 - fs/xfs/xfs_filestream.c | 9 +- fs/xfs/xfs_fsops.c | 2 +- fs/xfs/xfs_ialloc.c | 12 +- fs/xfs/xfs_ialloc_btree.c | 2 +- fs/xfs/xfs_ialloc_btree.h | 22 +-- fs/xfs/xfs_inode.h | 2 +- fs/xfs/xfs_inode_item.h | 2 - fs/xfs/xfs_iomap.h | 2 +- fs/xfs/xfs_itable.c | 9 +- fs/xfs/xfs_log.c | 67 ++----- fs/xfs/xfs_log.h | 3 +- fs/xfs/xfs_log_priv.h | 3 +- fs/xfs/xfs_log_recover.c | 308 +++++++++++++++++------------- fs/xfs/xfs_mount.c | 253 ++++++++++++++----------- fs/xfs/xfs_mount.h | 19 +-- fs/xfs/xfs_qmops.c | 1 - fs/xfs/xfs_quota.h | 3 +- fs/xfs/xfs_rtalloc.c | 10 + fs/xfs/xfs_rtalloc.h | 8 +- fs/xfs/xfs_trans.h | 24 ++-- fs/xfs/xfs_trans_ail.c | 4 +- fs/xfs/xfs_trans_item.c | 2 +- fs/xfs/xfs_trans_space.h | 2 +- fs/xfs/xfs_types.h | 8 - fs/xfs/xfs_utils.c | 2 +- fs/xfs/xfs_vnodeops.c | 408 +++++++++------------------------------ fs/xfs/xfs_vnodeops.h | 3 - 69 files changed, 1030 insertions(+), 1599 deletions(-) delete mode 100644 fs/xfs/linux-2.6/mutex.h create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Tue Mar 31 00:25:36 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,AWL,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 n2V5PV4P240458 for ; Tue, 31 Mar 2009 00:25:36 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V5PVRV240429; Tue, 31 Mar 2009 00:25:31 -0500 Date: Tue, 31 Mar 2009 00:25:31 -0500 Message-Id: <200903310525.n2V5PVRV240429@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-20839-g1aacc06 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 5123bc35d2bd2e5c344a53e634edec2cd0861a0e X-Git-Newrev: 1aacc064e029f0017384e463121b98f06d3a2cc3 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 1aacc06 Revert "xfs: increase the maximum number of supported ACL entries" from 5123bc35d2bd2e5c344a53e634edec2cd0861a0e (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 1aacc064e029f0017384e463121b98f06d3a2cc3 Author: Felix Blyakher Date: Tue Mar 31 00:23:37 2009 -0500 Revert "xfs: increase the maximum number of supported ACL entries" This reverts commit 8b112171734c791afaf43ccc8c6ec492e7006e44. Premature unintended commit. Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/xfs_acl.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Tue Mar 31 00:27:05 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,AWL,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 n2V5R0Lo240602 for ; Tue, 31 Mar 2009 00:27:05 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n2V5R0Dx240564; Tue, 31 Mar 2009 00:27:00 -0500 Date: Tue, 31 Mar 2009 00:27:00 -0500 Message-Id: <200903310527.n2V5R0Dx240564@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-20839-g1aacc06 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: 5123bc35d2bd2e5c344a53e634edec2cd0861a0e X-Git-Newrev: 1aacc064e029f0017384e463121b98f06d3a2cc3 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 1aacc06 Revert "xfs: increase the maximum number of supported ACL entries" from 5123bc35d2bd2e5c344a53e634edec2cd0861a0e (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 1aacc064e029f0017384e463121b98f06d3a2cc3 Author: Felix Blyakher Date: Tue Mar 31 00:23:37 2009 -0500 Revert "xfs: increase the maximum number of supported ACL entries" This reverts commit 8b112171734c791afaf43ccc8c6ec492e7006e44. Premature unintended commit. Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/xfs_acl.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- XFS development tree From felixb@sgi.com Tue Mar 31 00:40: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 n2V5eKg7241140 for ; Tue, 31 Mar 2009 00:40:30 -0500 Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by relay2.corp.sgi.com (Postfix) with ESMTP id A885A304067 for ; Mon, 30 Mar 2009 22:39:57 -0700 (PDT) Received: by attica.americas.sgi.com (Postfix, from userid 29043) id 7642414167108; Tue, 31 Mar 2009 00:30:13 -0500 (CDT) Date: Tue, 31 Mar 2009 00:30:13 -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.30 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: <20090331053013.7642414167108@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 15f7176eb1cccec0a332541285ee752b935c1c85: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://oss.sgi.com/xfs/xfs for-linus Christoph Hellwig (39): xfs: fix dentry aliasing issues in open_by_handle xfs: use mnt_want_write in compat_attrmulti ioctl xfs: add a separate lock class for the per-mount list of dquots xfs: lockdep annotations for xfs_dqlock2 xfs: add a lock class for group/project dquots xfs: fix bad_features2 fixups for the root filesystem xfs: sanity check attr fork size xfs: cleanup error handling in xfs_mountfs: xfs: make sure to free the real-time inodes in the mount error path xfs: tiny cleanup for xfs_link xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK xfs: factor out attr fork reset handling xfs: merge xfs_inode_flush into xfs_fs_write_inode xfs: cleanup xfs_find_handle xfs: remove the unused XFS_QMOPT_DQLOCK flag xfs: remove iclog calculation special cases xfs: remove superflous inobt macros xfs: remove uchar_t/ushort_t/uint_t/ulong_t types xfs: merge xfs_mkdir into xfs_create xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED xfs: sanitize qh_lock wrappers xfs: get rid of indirections in the quotaops implementation xfs: fix error handling in xfs_log_mount xfs: reject swapext ioctl on swapfiles 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 xfs: cleanup log unmount handling xfs: remove another leftover of the old inode log item format xfs: cleanup xlog_recover_do_trans xfs: cleanup xlog_bread xfs: kill vn_atime_* helpers. xfs: kill VN_BAD xfs: kill mutex_t typedef xfs: kill ino64 mount option xfs: remove m_litino xfs: remove m_attroffset xfs: cleanup uuid handling Dave Chinner (3): Long btree pointers are still 64 bit on disk xfs: Check buffer lengths in log recovery xfs: factor out code to find the longest free extent in the AG Eric Sandeen (3): [XFS] Remove the rest of the macro-to-function indirections. [XFS] remove always-true #ifndef HAVE_FORMAT32 tests don't reallocate sxp variable passed into xfs_swapext Felix Blyakher (25): Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs [XFS] Warn on transaction in flight on read-only remount Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 xfs: Update maintainers Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Revert "[XFS] use scalable vmap API" Revert "[XFS] remove old vmap cache" Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Fix xfs debug build breakage by pushing xfs_error.h after Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 xfs: increase the maximum number of supported ACL entries Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Revert "xfs: increase the maximum number of supported ACL entries" Hannes Eder (3): xfs: move declaration to header file xfs: make symbols static xfs: include header files for prototypes Hisashi Hifumi (1): xfs: pagecache usage optimization Josef 'Jeff' Sipek (1): xfs: cleanup error handling in xfs_swap_extents Lachlan McIlroy (6): [XFS] Update maintainers Merge git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/xfs Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Merge git://git.kernel.org/.../torvalds/linux-2.6 Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs Malcolm Parsons (1): xfs: fix various typos Nick Piggin (2): [XFS] remove old vmap cache [XFS] use scalable vmap API MAINTAINERS | 3 +- fs/xfs/Makefile | 1 + fs/xfs/linux-2.6/mutex.h | 25 --- fs/xfs/linux-2.6/xfs_aops.c | 1 + fs/xfs/linux-2.6/xfs_ioctl.c | 117 +++++------- fs/xfs/linux-2.6/xfs_iops.c | 33 +--- fs/xfs/linux-2.6/xfs_linux.h | 13 +-- fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++ fs/xfs/linux-2.6/xfs_super.c | 137 +++++--------- fs/xfs/linux-2.6/xfs_super.h | 1 + fs/xfs/linux-2.6/xfs_sync.h | 1 + fs/xfs/linux-2.6/xfs_vnode.h | 32 --- fs/xfs/quota/xfs_dquot.c | 28 ++-- fs/xfs/quota/xfs_dquot.h | 18 +-- fs/xfs/quota/xfs_qm.c | 212 ++++++--------------- fs/xfs/quota/xfs_qm.h | 26 ++-- fs/xfs/quota/xfs_qm_bhv.c | 1 - fs/xfs/quota/xfs_qm_syscalls.c | 190 +----------------- fs/xfs/quota/xfs_quota_priv.h | 38 ++--- fs/xfs/quota/xfs_trans_dquot.c | 16 +- fs/xfs/support/debug.c | 1 + fs/xfs/support/uuid.c | 71 ------- fs/xfs/support/uuid.h | 4 - fs/xfs/xfs_ag.h | 4 +- fs/xfs/xfs_alloc.c | 26 ++- fs/xfs/xfs_alloc.h | 6 + fs/xfs/xfs_attr_leaf.c | 58 +++--- fs/xfs/xfs_bmap.c | 76 +++++--- fs/xfs/xfs_bmap.h | 6 +- fs/xfs/xfs_btree.c | 4 +- fs/xfs/xfs_btree.h | 2 +- fs/xfs/xfs_da_btree.c | 2 +- fs/xfs/xfs_da_btree.h | 9 +- fs/xfs/xfs_dfrag.c | 68 +++---- fs/xfs/xfs_dinode.h | 4 +- fs/xfs/xfs_dir2.c | 2 - fs/xfs/xfs_dir2_block.c | 7 +- fs/xfs/xfs_dir2_data.h | 2 +- fs/xfs/xfs_dir2_leaf.c | 17 +-- fs/xfs/xfs_dir2_node.c | 2 +- fs/xfs/xfs_dir2_sf.c | 13 +-- fs/xfs/xfs_extfree_item.h | 6 - fs/xfs/xfs_filestream.c | 9 +- fs/xfs/xfs_fsops.c | 2 +- fs/xfs/xfs_ialloc.c | 12 +- fs/xfs/xfs_ialloc_btree.c | 2 +- fs/xfs/xfs_ialloc_btree.h | 22 +-- fs/xfs/xfs_inode.h | 2 +- fs/xfs/xfs_inode_item.h | 2 - fs/xfs/xfs_iomap.h | 2 +- fs/xfs/xfs_itable.c | 9 +- fs/xfs/xfs_log.c | 67 ++----- fs/xfs/xfs_log.h | 3 +- fs/xfs/xfs_log_priv.h | 3 +- fs/xfs/xfs_log_recover.c | 308 +++++++++++++++++------------- fs/xfs/xfs_mount.c | 253 ++++++++++++++----------- fs/xfs/xfs_mount.h | 19 +-- fs/xfs/xfs_qmops.c | 1 - fs/xfs/xfs_quota.h | 3 +- fs/xfs/xfs_rtalloc.c | 10 + fs/xfs/xfs_rtalloc.h | 8 +- fs/xfs/xfs_trans.h | 24 ++-- fs/xfs/xfs_trans_ail.c | 4 +- fs/xfs/xfs_trans_item.c | 2 +- fs/xfs/xfs_trans_space.h | 2 +- fs/xfs/xfs_types.h | 8 - fs/xfs/xfs_utils.c | 2 +- fs/xfs/xfs_vnodeops.c | 408 +++++++++------------------------------ fs/xfs/xfs_vnodeops.h | 3 - 69 files changed, 1031 insertions(+), 1599 deletions(-) delete mode 100644 fs/xfs/linux-2.6/mutex.h create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c From BATV+741eb74ea26c275d8180+2046+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 31 02:12:34 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 n2V7C8jL245086 for ; Tue, 31 Mar 2009 02:12:24 -0500 X-ASG-Debug-ID: 1238483484-4411033e0000-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 29C2C1C828BC for ; Tue, 31 Mar 2009 00:11:24 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id wc5marKpRbLg4FxC for ; Tue, 31 Mar 2009 00:11:24 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LoY84-0005OE-8L for xfs@oss.sgi.com; Tue, 31 Mar 2009 07:11:24 +0000 Date: Tue, 31 Mar 2009 03:11:24 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Message-ID: <20090331071124.GA12889@infradead.org> References: <200903310323.n2V3NoRK232157@oss.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903310323.n2V3NoRK232157@oss.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: 1238483505 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, Mar 30, 2009 at 10:23:50PM -0500, xfs@oss.sgi.com wrote: > commit 8b112171734c791afaf43ccc8c6ec492e7006e44 > Author: Felix Blyakher > Date: Fri Mar 27 17:28:43 2009 -0500 > > xfs: increase the maximum number of supported ACL entries > > With big installation current 25 maximum number of > supported ACL entries is not enough any more. > Increase the limit to 100. > > Signed-off-by: Felix Blyakher Can you please send your patches through the usual review channels? The reason why we haven't done this before is becuase the obvious solutions break the disk format, so this at least needs an explanation why it doesn't. From BATV+741eb74ea26c275d8180+2046+infradead.org+hch@bombadil.srs.infradead.org Tue Mar 31 02:25: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.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 n2V7OjvI245674 for ; Tue, 31 Mar 2009 02:25:00 -0500 X-ASG-Debug-ID: 1238484242-7f2301dc0000-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 B84CD1D82D7 for ; Tue, 31 Mar 2009 00:24:02 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 9MCuIM47TzxzFTi2 for ; Tue, 31 Mar 2009 00:24:02 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LoYKI-0000mk-8t for xfs@oss.sgi.com; Tue, 31 Mar 2009 07:24:02 +0000 Date: Tue, 31 Mar 2009 03:24:02 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Message-ID: <20090331072402.GA1897@infradead.org> References: <200903310323.n2V3NoRK232157@oss.sgi.com> <20090331071124.GA12889@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090331071124.GA12889@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: 1238484262 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 > Can you please send your patches through the usual review channels? Sorry, saw this got reverted again ASAP. From michael.monnerie@is.it-management.at Tue Mar 31 07:36: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_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 n2VCZhwC260495 for ; Tue, 31 Mar 2009 07:35:58 -0500 X-ASG-Debug-ID: 1238502898-76a403cd0000-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 47B3A1C8353D for ; Tue, 31 Mar 2009 05:34:58 -0700 (PDT) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id kvADFkNBgX9NUqaK for ; Tue, 31 Mar 2009 05:34:58 -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 2E3654F74 for ; Tue, 31 Mar 2009 14:34:57 +0200 (CEST) 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 0ABB5400160 for ; Tue, 31 Mar 2009 14:34:57 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Subject: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8 Date: Tue, 31 Mar 2009 14:34:56 +0200 User-Agent: KMail/1.10.3 (Linux/2.6.28.9-ZMI; KDE/4.1.3; x86_64; ; ) References: <49D09F2C.8060406@decisionsoft.co.uk> <49D0CCEB.1000404@sandeen.net> <49D0D01A.8090608@decisionsoft.co.uk> In-Reply-To: <49D0D01A.8090608@decisionsoft.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903311434.56662@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1238502919 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.21854 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 Montag 30 M=E4rz 2009 Stuart Rowan wrote: > OOI when implementing the freeze ioctl, what made the developers > decide that a freeze can't succeed on an already frozen filesystem > ... you'd expect it to just be a no-op really? So you would break the unfreeze: xfs_freeze -f lvcreate -s (lvcreate does freeze;work;unfreeze) *now you are unfrozen* xfs_freeze -u The problem would be if you expect to be frozen still after the lvcreate=20 command and do some processing, that might be bad. 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 felixb@sgi.com Tue Mar 31 08:24:34 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 relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2VDODBp001055 for ; Tue, 31 Mar 2009 08:24:24 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id E0648AC002 for ; Tue, 31 Mar 2009 06:23:50 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id 429547000103; Tue, 31 Mar 2009 07:59:20 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <730FBF20-6F2C-42FA-A19F-67F6C6279445@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090331071124.GA12889@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Date: Tue, 31 Mar 2009 07:59:19 -0500 References: <200903310323.n2V3NoRK232157@oss.sgi.com> <20090331071124.GA12889@infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 31, 2009, at 2:11 AM, Christoph Hellwig wrote: > On Mon, Mar 30, 2009 at 10:23:50PM -0500, xfs@oss.sgi.com wrote: >> commit 8b112171734c791afaf43ccc8c6ec492e7006e44 >> Author: Felix Blyakher >> Date: Fri Mar 27 17:28:43 2009 -0500 >> >> xfs: increase the maximum number of supported ACL entries >> >> With big installation current 25 maximum number of >> supported ACL entries is not enough any more. >> Increase the limit to 100. >> >> Signed-off-by: Felix Blyakher > > Can you please send your patches through the usual review channels? That wasn't intended for check in yet. > The reason why we haven't done this before is becuase the obvious > solutions break the disk format, That was exactly the reason I hadn't sent it for review yet. I stop short of sending it for review realizing that it's not complete and more work may be needed. Unfortunately, it was left in my tree. > so this at least needs an explanation > why it doesn't. It does, though it's not as severe as other disk format changes. I don't have a final solution yet, but since it's already escaped in public, I may as well show my current thinking, and invite comments. So, the older kernels would be able to mount and work with the new filesystem, with exception of seeing only first 25 ACL entries. The user may still would like to mount it as such confirming that he aware of consequences. This feature validation would not follow the current scheme of black and white. With the presence of the force_mount (new) option, we emit a warning and allow to mount. Comments? Felix From felixb@sgi.com Tue Mar 31 08:41:14 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 relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2VDessN001890 for ; Tue, 31 Mar 2009 08:41:04 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 59DE1AC00A for ; Tue, 31 Mar 2009 06:40:31 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id E89F8700016A; Tue, 31 Mar 2009 08:15:51 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <3255DAB2-9D1A-40A6-AD85-7DDFE8D45796@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090331072402.GA1897@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Date: Tue, 31 Mar 2009 08:15:51 -0500 References: <200903310323.n2V3NoRK232157@oss.sgi.com> <20090331071124.GA12889@infradead.org> <20090331072402.GA1897@infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 31, 2009, at 2:24 AM, Christoph Hellwig wrote: >> Can you please send your patches through the usual review channels? > > Sorry, saw this got reverted again ASAP. Yeah, I've changed my process to avoid such things. Actually, did it even before this, but started the merge from the wrong tree. Felix From raziebe@gmail.com Tue Mar 31 09:36: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.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 n2VEa0HW008377 for ; Tue, 31 Mar 2009 09:36:10 -0500 X-ASG-Debug-ID: 1238510136-5d56008c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f121.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B5BD41C83D8F for ; Tue, 31 Mar 2009 07:35:36 -0700 (PDT) Received: from mail-qy0-f121.google.com (mail-qy0-f121.google.com [209.85.221.121]) by cuda.sgi.com with ESMTP id eafcqhd1C5JhjTCj for ; Tue, 31 Mar 2009 07:35:36 -0700 (PDT) Received: by qyk27 with SMTP id 27so4642274qyk.20 for ; Tue, 31 Mar 2009 07:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:received:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Udn7XeOIF7CYQSX64gCMHRSk6iR4c/zwhi9ZHvlnK9c=; b=fI6YPNhjqZt5mSDN3lwrh4pSIRkv+X+bMBaIQkw8ahiDw8qxQIHEHfYhA0UVhnX93d 7+i6te8jzV+PIeMG8ungJPt1dwJxbzNysaVfzC8sRK0IKL5SdbB6XUuigYwI+72mwaaM AmIZxVOsaYXce+xoiQyzU36dKQbno6GpnYD0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=U+dGdCAkmWq787E/6aLoSx8rGpHA5m5e4OPmyt/R+Cr+KryZH7ERI7Dq1f67uh/L7f dwZTTeN1OPB8zp8XjUVY8KQPTpEV0DjY/VL/UR7cqe0wEGm42ltz3ch/yJQHWnfY+PUq 3UGtEmWfprHJBjRLRfN5LcdxSFTJ4q4a7d490= MIME-Version: 1.0 Date: Tue, 31 Mar 2009 17:35:18 +0300 Received: by 10.220.85.1 with SMTP id m1mr2154618vcl.46.1238510133894; Tue, 31 Mar 2009 07:35:33 -0700 (PDT) Message-ID: <5d96567b0903310735h2fb8544eyab7cb3706754649a@mail.gmail.com> X-ASG-Orig-Subj: df updates over xfs Subject: df updates over xfs From: Raz To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-qy0-f121.google.com[209.85.221.121] X-Barracuda-Start-Time: 1238510136 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4970 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.21862 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 Hello when does the "used" blocks is updated by xfs ? I can copy a file or remove a file and df will not display the correct figures. How can control it ? thank you raz From jsipek@ten.citi.umich.edu Tue Mar 31 16:53: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2VLr7M1029551 for ; Tue, 31 Mar 2009 16:53:17 -0500 X-ASG-Debug-ID: 1238536413-680a006e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ten.citi.umich.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3B09813E2FFF for ; Tue, 31 Mar 2009 14:53:33 -0700 (PDT) Received: from ten.citi.umich.edu (ten.citi.umich.edu [141.211.133.138]) by cuda.sgi.com with ESMTP id 8THjWZ5ErA0AR6dj for ; Tue, 31 Mar 2009 14:53:33 -0700 (PDT) Received: from ten.citi.umich.edu (localhost.localdomain [127.0.0.1]) by ten.citi.umich.edu (8.14.3/8.14.3) with ESMTP id n2VLoY5D026999 for ; Tue, 31 Mar 2009 17:50:34 -0400 Received: (from jsipek@localhost) by ten.citi.umich.edu (8.14.3/8.14.3/Submit) id n2VLoYAi026997 for xfs@oss.sgi.com; Tue, 31 Mar 2009 17:50:34 -0400 From: "Josef 'Jeff' Sipek" To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/2] Misc xfstests patches Subject: [PATCH 0/2] Misc xfstests patches Date: Tue, 31 Mar 2009 17:50:32 -0400 Message-Id: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> X-Mailer: git-send-email 1.6.0.6 X-Barracuda-Connect: ten.citi.umich.edu[141.211.133.138] X-Barracuda-Start-Time: 1238536414 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.21891 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 Just two simple patches to clean things up a little bit. Josef 'Jeff' Sipek. From jsipek@ten.citi.umich.edu Tue Mar 31 16:53: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2VLrFo3029563 for ; Tue, 31 Mar 2009 16:53:25 -0500 X-ASG-Debug-ID: 1238536413-680a006e0004-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ten.citi.umich.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1FBF013E2FFF for ; Tue, 31 Mar 2009 14:53:41 -0700 (PDT) Received: from ten.citi.umich.edu (ten.citi.umich.edu [141.211.133.138]) by cuda.sgi.com with ESMTP id ikGaHRUjJJhdvfro for ; Tue, 31 Mar 2009 14:53:41 -0700 (PDT) Received: from ten.citi.umich.edu (localhost.localdomain [127.0.0.1]) by ten.citi.umich.edu (8.14.3/8.14.3) with ESMTP id n2VLoYFD027001; Tue, 31 Mar 2009 17:50:34 -0400 Received: (from jsipek@localhost) by ten.citi.umich.edu (8.14.3/8.14.3/Submit) id n2VLoY5R027000; Tue, 31 Mar 2009 17:50:34 -0400 From: "Josef 'Jeff' Sipek" To: xfs@oss.sgi.com Cc: "Josef 'Jeff' Sipek" , "Josef 'Jeff' Sipek" X-ASG-Orig-Subj: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Subject: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Date: Tue, 31 Mar 2009 17:50:33 -0400 Message-Id: <1238536234-26969-2-git-send-email-jsipek@eecs.umich.edu> X-Mailer: git-send-email 1.6.0.6 In-Reply-To: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> X-Barracuda-Connect: ten.citi.umich.edu[141.211.133.138] X-Barracuda-Start-Time: 1238536422 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.21891 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: Josef 'Jeff' Sipek Signed-off-by: Josef 'Jeff' Sipek Signed-off-by: Josef 'Jeff' Sipek --- 0 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 104 mode change 100755 => 100644 112.out mode change 100644 => 100755 141 mode change 100644 => 100755 164 mode change 100644 => 100755 165 mode change 100644 => 100755 166 mode change 100644 => 100755 167 mode change 100644 => 100755 170 mode change 100644 => 100755 171 mode change 100644 => 100755 172 mode change 100644 => 100755 173 mode change 100644 => 100755 174 mode change 100644 => 100755 179 mode change 100644 => 100755 180 mode change 100644 => 100755 182 mode change 100644 => 100755 183 mode change 100644 => 100755 184 mode change 100644 => 100755 185 mode change 100644 => 100755 188 mode change 100644 => 100755 189 mode change 100644 => 100755 194 mode change 100644 => 100755 195 mode change 100644 => 100755 196 mode change 100644 => 100755 197 mode change 100644 => 100755 198 mode change 100644 => 100755 199 mode change 100644 => 100755 200 mode change 100644 => 100755 201 mode change 100644 => 100755 202 mode change 100644 => 100755 203 diff --git a/104 b/104 old mode 100644 new mode 100755 diff --git a/112.out b/112.out old mode 100755 new mode 100644 diff --git a/141 b/141 old mode 100644 new mode 100755 diff --git a/164 b/164 old mode 100644 new mode 100755 diff --git a/165 b/165 old mode 100644 new mode 100755 diff --git a/166 b/166 old mode 100644 new mode 100755 diff --git a/167 b/167 old mode 100644 new mode 100755 diff --git a/170 b/170 old mode 100644 new mode 100755 diff --git a/171 b/171 old mode 100644 new mode 100755 diff --git a/172 b/172 old mode 100644 new mode 100755 diff --git a/173 b/173 old mode 100644 new mode 100755 diff --git a/174 b/174 old mode 100644 new mode 100755 diff --git a/179 b/179 old mode 100644 new mode 100755 diff --git a/180 b/180 old mode 100644 new mode 100755 diff --git a/182 b/182 old mode 100644 new mode 100755 diff --git a/183 b/183 old mode 100644 new mode 100755 diff --git a/184 b/184 old mode 100644 new mode 100755 diff --git a/185 b/185 old mode 100644 new mode 100755 diff --git a/188 b/188 old mode 100644 new mode 100755 diff --git a/189 b/189 old mode 100644 new mode 100755 diff --git a/194 b/194 old mode 100644 new mode 100755 diff --git a/195 b/195 old mode 100644 new mode 100755 diff --git a/196 b/196 old mode 100644 new mode 100755 diff --git a/197 b/197 old mode 100644 new mode 100755 diff --git a/198 b/198 old mode 100644 new mode 100755 diff --git a/199 b/199 old mode 100644 new mode 100755 diff --git a/200 b/200 old mode 100644 new mode 100755 diff --git a/201 b/201 old mode 100644 new mode 100755 diff --git a/202 b/202 old mode 100644 new mode 100755 diff --git a/203 b/203 old mode 100644 new mode 100755 -- 1.6.0.6 From jsipek@ten.citi.umich.edu Tue Mar 31 16:53:30 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 (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n2VLr9nd029553 for ; Tue, 31 Mar 2009 16:53:19 -0500 X-ASG-Debug-ID: 1238536413-680a006e0002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ten.citi.umich.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 389A613E2FFF for ; Tue, 31 Mar 2009 14:53:34 -0700 (PDT) Received: from ten.citi.umich.edu (ten.citi.umich.edu [141.211.133.138]) by cuda.sgi.com with ESMTP id WYGmNdv7fFeYbcey for ; Tue, 31 Mar 2009 14:53:34 -0700 (PDT) Received: from ten.citi.umich.edu (localhost.localdomain [127.0.0.1]) by ten.citi.umich.edu (8.14.3/8.14.3) with ESMTP id n2VLoYlu027003; Tue, 31 Mar 2009 17:50:34 -0400 Received: (from jsipek@localhost) by ten.citi.umich.edu (8.14.3/8.14.3/Submit) id n2VLoYiF027002; Tue, 31 Mar 2009 17:50:34 -0400 From: "Josef 'Jeff' Sipek" To: xfs@oss.sgi.com Cc: "Josef 'Jeff' Sipek" , "Josef 'Jeff' Sipek" X-ASG-Orig-Subj: [PATCH 2/2] xfstests: Add an ignore file Subject: [PATCH 2/2] xfstests: Add an ignore file Date: Tue, 31 Mar 2009 17:50:34 -0400 Message-Id: <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> X-Mailer: git-send-email 1.6.0.6 In-Reply-To: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> X-Barracuda-Connect: ten.citi.umich.edu[141.211.133.138] X-Barracuda-Start-Time: 1238536415 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.21891 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: Josef 'Jeff' Sipek Ignore generated files. Signed-off-by: Josef 'Jeff' Sipek Signed-off-by: Josef 'Jeff' Sipek --- .gitignore | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 90 insertions(+), 0 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..2cd722b --- /dev/null +++ b/.gitignore @@ -0,0 +1,90 @@ +*.lo +*.o +*.la + +autom4te.cache +configure +include/builddefs +include/config.h +include/config.h.in +lib/.libs + +dmapi/Makefile +dmapi/config.log +dmapi/config.status +dmapi/libtool +dmapi/src/Makefile +dmapi/src/common/Makefile +dmapi/src/common/cmd/.deps +dmapi/src/common/cmd/Makefile +dmapi/src/common/lib/.deps +dmapi/src/common/lib/Makefile +dmapi/src/sample_hsm/.deps +dmapi/src/sample_hsm/Makefile +dmapi/src/simple/.deps +dmapi/src/simple/Makefile +dmapi/src/suite1/Makefile +dmapi/src/suite1/cmd/.deps +dmapi/src/suite1/cmd/Makefile +dmapi/src/suite2/Makefile +dmapi/src/suite2/src/.deps +dmapi/src/suite2/src/Makefile + +ltp/aio-stress +ltp/doio +ltp/fsstress +ltp/fsx +ltp/growfiles +ltp/iogen + +src/alloc +src/append_reader +src/append_writer +src/bstat +src/bulkstat_unlink_test +src/bulkstat_unlink_test_modified +src/devzero +src/dirperf +src/dirstress +src/dmiperf +src/fault +src/feature +src/fill +src/fill2 +src/fs_perms +src/fstest +src/ftrunc +src/genhashnames +src/getdevicesize +src/getpagesize +src/godown +src/holes +src/itrash +src/locktest +src/loggen +src/looptest +src/lstat64 +src/makeextents +src/metaperf +src/mmapcat +src/multi_open_unlink +src/nametest +src/permname +src/preallo_rw_pattern_reader +src/preallo_rw_pattern_writer +src/randholes +src/rename +src/resvtest +src/runas +src/t_access_root +src/t_dir_offset +src/t_immutable +src/t_mtab +src/testx +src/trunc +src/truncfile +src/unwritten_mmap +src/unwritten_sync +src/usemem +src/writemod +src/xfsctl -- 1.6.0.6 From felixb@sgi.com Tue Mar 31 18:41: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 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 n2VNexxE036311 for ; Tue, 31 Mar 2009 18:41:09 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id B7AD18F80B7 for ; Tue, 31 Mar 2009 16:40:36 -0700 (PDT) Received: from eagdhcp-232-185.americas.sgi.com (eagdhcp-232-185.americas.sgi.com [128.162.232.185]) by estes.americas.sgi.com (Postfix) with ESMTP id 25A6C7000103; Tue, 31 Mar 2009 18:13:07 -0500 (CDT) Cc: xfs@oss.sgi.com, "Josef 'Jeff' Sipek" Message-Id: <7373F19F-AE1D-479C-9FAA-FF8DEF5BA2B7@sgi.com> From: Felix Blyakher To: "Josef 'Jeff' Sipek" In-Reply-To: <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> 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: [PATCH 2/2] xfstests: Add an ignore file Date: Tue, 31 Mar 2009 18:13:07 -0500 References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> 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 31, 2009, at 4:50 PM, Josef 'Jeff' Sipek wrote: > From: Josef 'Jeff' Sipek > > Ignore generated files. > > Signed-off-by: Josef 'Jeff' Sipek > Signed-off-by: Josef 'Jeff' Sipek Do we really need two "Signed-off-by"s :) Which one do you prefer? Nice idea. I started doing the same in my tree and was about to submit the patch. Reviewed-by: Felix Blyakher > > --- > .gitignore | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++ > 1 files changed, 90 insertions(+), 0 deletions(-) > create mode 100644 .gitignore > > diff --git a/.gitignore b/.gitignore > new file mode 100644 > index 0000000..2cd722b > --- /dev/null > +++ b/.gitignore > @@ -0,0 +1,90 @@ > +*.lo > +*.o > +*.la > + > +autom4te.cache > +configure > +include/builddefs > +include/config.h > +include/config.h.in > +lib/.libs > + > +dmapi/Makefile > +dmapi/config.log > +dmapi/config.status > +dmapi/libtool > +dmapi/src/Makefile > +dmapi/src/common/Makefile > +dmapi/src/common/cmd/.deps > +dmapi/src/common/cmd/Makefile > +dmapi/src/common/lib/.deps > +dmapi/src/common/lib/Makefile > +dmapi/src/sample_hsm/.deps > +dmapi/src/sample_hsm/Makefile > +dmapi/src/simple/.deps > +dmapi/src/simple/Makefile > +dmapi/src/suite1/Makefile > +dmapi/src/suite1/cmd/.deps > +dmapi/src/suite1/cmd/Makefile > +dmapi/src/suite2/Makefile > +dmapi/src/suite2/src/.deps > +dmapi/src/suite2/src/Makefile > + > +ltp/aio-stress > +ltp/doio > +ltp/fsstress > +ltp/fsx > +ltp/growfiles > +ltp/iogen > + > +src/alloc > +src/append_reader > +src/append_writer > +src/bstat > +src/bulkstat_unlink_test > +src/bulkstat_unlink_test_modified > +src/devzero > +src/dirperf > +src/dirstress > +src/dmiperf > +src/fault > +src/feature > +src/fill > +src/fill2 > +src/fs_perms > +src/fstest > +src/ftrunc > +src/genhashnames > +src/getdevicesize > +src/getpagesize > +src/godown > +src/holes > +src/itrash > +src/locktest > +src/loggen > +src/looptest > +src/lstat64 > +src/makeextents > +src/metaperf > +src/mmapcat > +src/multi_open_unlink > +src/nametest > +src/permname > +src/preallo_rw_pattern_reader > +src/preallo_rw_pattern_writer > +src/randholes > +src/rename > +src/resvtest > +src/runas > +src/t_access_root > +src/t_dir_offset > +src/t_immutable > +src/t_mtab > +src/testx > +src/trunc > +src/truncfile > +src/unwritten_mmap > +src/unwritten_sync > +src/usemem > +src/writemod > +src/xfsctl > -- > 1.6.0.6 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From jeffpc@josefsipek.net Tue Mar 31 22:35:32 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 (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n313ZCJG046562 for ; Tue, 31 Mar 2009 22:35:22 -0500 X-ASG-Debug-ID: 1238556919-0fa3004b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from josefsipek.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6A2CC13E414B for ; Tue, 31 Mar 2009 20:35:19 -0700 (PDT) Received: from josefsipek.net (josefsipek.net [141.211.133.196]) by cuda.sgi.com with ESMTP id mlltMZro0JUQh7vq for ; Tue, 31 Mar 2009 20:35:19 -0700 (PDT) Received: by josefsipek.net (Postfix, from userid 1000) id EF8791C00DEC; Tue, 31 Mar 2009 23:34:27 -0400 (EDT) Date: Tue, 31 Mar 2009 23:34:27 -0400 From: "Josef 'Jeff' Sipek" To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] xfstests: Add an ignore file Subject: Re: [PATCH 2/2] xfstests: Add an ignore file Message-ID: <20090401033427.GL19690@josefsipek.net> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> <7373F19F-AE1D-479C-9FAA-FF8DEF5BA2B7@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7373F19F-AE1D-479C-9FAA-FF8DEF5BA2B7@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: josefsipek.net[141.211.133.196] X-Barracuda-Start-Time: 1238556940 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.21915 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 Tue, Mar 31, 2009 at 06:13:07PM -0500, Felix Blyakher wrote: > > On Mar 31, 2009, at 4:50 PM, Josef 'Jeff' Sipek wrote: > >> From: Josef 'Jeff' Sipek >> >> Ignore generated files. >> >> Signed-off-by: Josef 'Jeff' Sipek >> Signed-off-by: Josef 'Jeff' Sipek > > Do we really need two "Signed-off-by"s :) > Which one do you prefer? Gah! Silly git! Let's make it . > Nice idea. I started doing the same in my tree and was > about to submit the patch. :) > Reviewed-by: Felix Blyakher Thanks. Josef 'Jeff' Sipek. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. From a818b044.758425.7b39c0ba1f12b194.16.n.3@pq.jigsaw-promotions.com Tue Mar 31 23:26:37 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=BAYES_50,HTML_MESSAGE, URIBL_BLACK autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n314QGKB048489 for ; Tue, 31 Mar 2009 23:26:27 -0500 X-ASG-Debug-ID: 1238560003-29c600780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pq.jigsaw-promotions.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0A5F513E43A8 for ; Tue, 31 Mar 2009 21:26:44 -0700 (PDT) Received: from pq.jigsaw-promotions.com (pq.jigsaw-promotions.com [65.244.80.44]) by cuda.sgi.com with SMTP id 75Lcmg9RxFmct7DX for ; Tue, 31 Mar 2009 21:26:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pq.jigsaw-promotions.com; b=Gp4opSDZSU5mJPdgrL0mZyE47kvHi0FtzNbhMtr/OwgaHziIV7Fh9jCOb1D2rhL8wdCBoFvsDleWj+8DH+CtkqqtkV2wOOL33tc2++Sy2/Q+nqLV+9exrTsm5qew7HrApWxuK0/SfZoW00PXD6g0kY0bLhYT2LA6PddmNVOPyQ8=; Date: Wed, 01 Apr 2009 00:25:52 -0400 Message-ID: thread-index: a818b044.758425.7b39c0ba1f12b194.16.n.3 Reply-To: "Jigsaw" From: "Jigsaw" To: "David Chinner" X-ASG-Orig-Subj: A notice from Jigsaw Subject: A notice from Jigsaw MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0942_01C9B260.69E80E30" Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-Barracuda-Connect: pq.jigsaw-promotions.com[65.244.80.44] X-Barracuda-Start-Time: 1238560005 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6352 1.0000 0.9318 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.93 X-Barracuda-Spam-Status: No, SCORE=0.93 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ADVANCE_FEE_1, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21917 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 ADVANCE_FEE_1 Appears to be advance fee fraud (Nigerian 419) 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. ------=_NextPart_000_0942_01C9B260.69E80E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This message is brought to you by Jigsaw. If you no longer wish to = receive email=20 messages please scroll to the end of this message for removal = instructions. _____________________________________________________________ Dear David, =20 Your company and business contact information are listed in=20 Jigsaw's online directory of business information. We ask that=20 you take a minute to learn about our service and notify us if you=20 do not want your business contact information included.=20 Jigsaw provides an online directory of companies and business=20 professionals. Our directory is built and used by our members to=20 identify potential business partners and to present relevant=20 offers that may be of interest to you. As a business contact in=20 Jigsaw, you have the ability to state your preferences on what=20 you wish to receive and how you wish to be reached. Jigsaw=20 contains only business contact information of the type typically=20 printed on a business card. Jigsaw does not allow home addresses,=20 home telephone numbers, or mobile telephone numbers. We invite you to learn more about Jigsaw by clicking on the=20 link below:=20 Learn more About Jigsaw=20 http://pq.jigsaw-promotions.com/c.asp?758425&7b39c0ba1f12b194&1 If you would like to set your communications preferences and=20 provide specific instructions on how you would like to be communicated=20 to, click here to start the process:=20 Set Preferences=20 http://pq.jigsaw-promotions.com/c.asp?758425&7b39c0ba1f12b194&2 If you would like to remove your business contact information=20 from our directory, please click here:=20 Remove=20 http://pq.jigsaw-promotions.com/r/r_jgs2.asp?758425&xfs@oss.sgi.com&T Sincerely,=20 The Jigsaw Team =20 ***********************************************************=20 =20 For more about Jigsaw and Jigsaw products or to share your=20 thoughts, call 1-877-JIGSAW9, click here to contact support, http://pq.jigsaw-promotions.com/c.asp?758425&7b39c0ba1f12b194&4 or click here to contact sales http://pq.jigsaw-promotions.com/c.asp?758425&7b39c0ba1f12b194&5 =20 Thank you for taking the time to read our message. It was=20 sent to: xfs@oss.sgi.com. If this is in error, please accept our = apologies.=20 To stop receiving emails from Jigsaw in the future, simply=20 click here to unsubscribe. http://pq.jigsaw-promotions.com/r/r_jgs.asp?758425&xfs@oss.sgi.com&T =20 *********************************************************** *********************************************************** 2 Waters Park Drive Suite 250, San Mateo, CA 94403 *********************************************************** *********************************************************** ------=_NextPart_000_0942_01C9B260.69E80E30 Content-Type: text/html Content-Transfer-Encoding: 7bit
Jigsaw

Dear David,

Your company and business contact information are listed in Jigsaw's online directory of business information. We ask that you take a minute to learn about our service and notify us if you do not want your business contact information included.

Jigsaw provides an online directory of companies and business professionals. Our directory is built and used by our members to identify potential business partners and to present relevant offers that may be of interest to you. As a business contact in Jigsaw, you have the ability to state your preferences on what you wish to receive and how you wish to be reached. Jigsaw contains only business contact information of the type typically printed on a business card. Jigsaw does not allow home addresses, home telephone numbers, or mobile telephone numbers.

We invite you to learn more about Jigsaw by clicking on the link below:

If you would like to set your communications preferences and provide specific instructions on how you would like to be communicated to, click here to start the process:

If you would like to remove your business contact information from our directory, please click here:

Sincerely,

The Jigsaw Team
green line

For more about Jigsaw and Jigsaw products or to share your thoughts,
call 1-877-JIGSAW9, click here to contact support, or  click here to contact sales.

Thank you for taking the time to read our message. It was sent to: xfs@oss.sgi.com. If this is in error, please accept our apologies. To stop receiving emails from Jigsaw in the future, simply click here to unsubscribe

www.jigsaw.com | 2 Waters Park Drive Suite 250, San Mateo, CA 94403
green line
------=_NextPart_000_0942_01C9B260.69E80E30--