From owner-linux-xfs@oss.sgi.com Wed May 1 00:26:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g417QXwJ002047 for ; Wed, 1 May 2002 00:26:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g417QWbT002046 for linux-xfs-outgoing; Wed, 1 May 2002 00:26:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g417QFwJ002014 for ; Wed, 1 May 2002 00:26:15 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA1595278 for ; Wed, 1 May 2002 00:27:09 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA32026; Wed, 1 May 2002 17:25:50 +1000 (AEST) Date: Wed, 1 May 2002 17:25:50 +1000 From: Timothy Shimmin To: jtrostel@snapserver.com Cc: linux-xfs@oss.sgi.com Subject: Re: Query about setfacl behavior Message-ID: <20020501172550.Q793932@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from jtrostel@snapserver.com on Tue, Apr 30, 2002 at 01:20:28PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 30, 2002 at 01:20:28PM -0400, jtrostel@snapserver.com wrote: > I am wondering if this is correct behavior... > Yeah it looks wrong, John. It looks like the mask ACE is getting the group permissions. e.g. ======================================================== [root@sagan xfs1]# getfacl wow # file: wow # owner: root # group: root user::r-- group::rw- other::rwx [root@sagan xfs1]# setfacl -m m::--- wow [root@sagan xfs1]# getfacl wow # file: wow # owner: root # group: root user::r-- group::rw- #effective:--- mask::--- other::rwx [root@sagan xfs1]# setfacl -m u::r-x wow [root@sagan xfs1]# getfacl wow # file: wow # owner: root # group: root user::r-x group::rw- mask::rw- other::rwx ======================================================== I'll look into it... --Tim > Using XFS CVS tip as of this morning (4/30/02) which gives me acl 2.0.10 > > [jt@jtsdevel xfs_part]$ getfacl --version > getfacl 2.0.10 > > Set up an xfs partition with acls as follows: > > [jt@jtsdevel xfs_part]$ pwd > /mnt/xfs_part > [jt@jtsdevel xfs_part]$ getfacl . > # file: . > # owner: root > # group: root > user::rwx > group::rwx > mask::rwx > other::rwx > default:user::rwx > default:group::rwx > default:mask::rwx > default:other::rwx > > I then created a new directoryon that partition, named jts_dir > > [jt@jtsdevel xfs_part]$ mkdir jts_dir > > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > # file: jts_dir > # owner: jt > # group: jt > user::rwx > group::rwx > mask::rwx > other::rwx > default:user::rwx > default:group::rwx > default:mask::rwx > default:other::rwx > > Now.. I added an auxillary user 'a1' to the access aces. > > [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rwx jts_dir/ > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > # file: jts_dir > # owner: jt > # group: jt > user::rwx > user:a1:rwx > group::rwx > mask::rwx > other::rwx > default:user::rwx > default:group::rwx > default:mask::rwx > default:other::rwx > > Change the mask ace to no perms > > [jt@jtsdevel xfs_part]$ setfacl -m m::--- jts_dir/ > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > # file: jts_dir > # owner: jt > # group: jt > user::rwx > user:a1:rwx #effective:--- > group::rwx #effective:--- > mask::--- > other::rwx > default:user::rwx > default:group::rwx > default:mask::rwx > default:other::rwx > > NOW! Change the aux. user 'a1' perms to something else, for instance 'rw'. The > mask ace is also changed now. (It went from --- to rwx) Why? > > > [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rw jts_dir/ > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > # file: jts_dir > # owner: jt > # group: jt > user::rwx > user:a1:rw- > group::rwx > mask::rwx > other::rwx > default:user::rwx > default:group::rwx > default:mask::rwx > default:other::rwx > > P.S. (For XFS folks: chacl -l returns the same values) > > -- > John M. Trostel > Senior Software Engineer > Quantum Corp. / NASD > jtrostel@snapserver.com > From owner-linux-xfs@oss.sgi.com Wed May 1 00:26:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g417Q6wJ002005 for ; Wed, 1 May 2002 00:26:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g417Q6oM002004 for linux-xfs-outgoing; Wed, 1 May 2002 00:26:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g417PrwJ001976 for ; Wed, 1 May 2002 00:25:54 -0700 Received: from erbenson.alaska.net (195-pm32.nwc.alaska.net [209.112.158.195]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g417QkV77617 for ; Tue, 30 Apr 2002 23:26:46 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E72FE3924 for ; Tue, 30 Apr 2002 23:26:43 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id BF4291028A; Tue, 30 Apr 2002 23:26:43 -0800 (AKDT) Date: Tue, 30 Apr 2002 23:26:43 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430232643.Q21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> <1020210550.1179.3.camel@localhost.localdomain> <1020211474.1179.6.camel@localhost.localdomain> <20020501023726.A15270@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h9WqFG8zn/Mwlkpe" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020501023726.A15270@wotan.suse.de>; from ak@suse.de on Wed, May 01, 2002 at 02:37:26AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --h9WqFG8zn/Mwlkpe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 01, 2002 at 02:37:26AM +0200, Andi Kleen wrote: > > > Andi, is immutable checking all done above the vfs or do filesystems > > > have to enforce it as well? >=20 > I think it's done in the file system.=20 id have to check but i think i saw some macros used for this in the VFS layers. look for IS_IMMUTABLE iirc. > > OK, I answered that myself - maybe we can do this quickly - provided > > chattr does not check the filesystem type it is applied too. >=20 > I don't think it does. It just does the ioctl.=20 yup: eb@dogbert /home/eb$ chattr +i foo chattr: Inappropriate ioctl for device while reading flags on foo eb@dogbert /home/eb$ strace chattr +i foo 2>&1 | grep ioctl ioctl(3, 0x40046601, 0x7ffff918) =3D -1 ENOTTY (Inappropriate ioctl = for device) write(2, "Inappropriate ioctl for device", 30Inappropriate ioctl for device= ) =3D 30 > P.S.: Overall I don't think immutable/append-only are too useful because= =20 > attackers can always get rid of them by mknod'ing a device and writing to= the=20 > disk directly and forcing an inode flush. So it may not be worth much eff= ort=20 > for the pseudo security ones, as they only give a false sense of security= .=20 this is only because linux' capability system is currently broken, on *BSD once the secure level is raised root can no longer access raw devices of mounted filesystems, if you raise it to 2 then all raw disk devices are blocked. linux just either needs to add a capability to restrict access to mounted fs block devices and/or all block devices, or just deny access when CAP_LINUX_IMMUTABLE (or maybe CAP_SYS_RAWIO) is removed.=20=20 in any event its not that hard to fix the hole your describing (and it didn't exist on 2.0 kernels which used the same securelevel mechenism as *bsd). i beleive there is already a patch floating around somewhere to make linux 2.2+ block raw disk access via some capability. > immutable is sometimes useful to prevent mistakes, but not for more. not true, see above. > The only ones that may be worth it are 'S' (force O_SYNC, especially > for directories e.g. to handle qmail/postfix spool dirs without forcing > synchronous for the whole fs), 'A' (no atime) and 'd' for incremental=20 > backup purposes. noatime is not that useful IMO, if your worried about atime updates there is a mount option, agreed on S(ync). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --h9WqFG8zn/Mwlkpe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzPmLMACgkQJKx7GixEevxrrACeIiBTBMoJtOzsyjTPMl86No+o cgwAnjS1ak5+fywqEgRCZFARVm6e7duv =nylv -----END PGP SIGNATURE----- --h9WqFG8zn/Mwlkpe-- From owner-linux-xfs@oss.sgi.com Wed May 1 01:15:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g418F6wJ002587 for ; Wed, 1 May 2002 01:15:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g418F60O002586 for linux-xfs-outgoing; Wed, 1 May 2002 01:15:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g418EvwJ002558 for ; Wed, 1 May 2002 01:14:57 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 3BFC41ED7B; Wed, 1 May 2002 10:15:47 +0200 (MEST) Date: Wed, 1 May 2002 10:15:45 +0200 From: Andi Kleen To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020501101545.A26317@wotan.suse.de> References: <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> <1020210550.1179.3.camel@localhost.localdomain> <1020211474.1179.6.camel@localhost.localdomain> <20020501023726.A15270@wotan.suse.de> <20020430232643.Q21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020430232643.Q21791@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 30, 2002 at 11:26:43PM -0800, Ethan Benson wrote: > > P.S.: Overall I don't think immutable/append-only are too useful because > > attackers can always get rid of them by mknod'ing a device and writing to the > > disk directly and forcing an inode flush. So it may not be worth much effort > > for the pseudo security ones, as they only give a false sense of security. > > this is only because linux' capability system is currently broken, on > *BSD once the secure level is raised root can no longer access raw > devices of mounted filesystems, if you raise it to 2 then all raw disk > devices are blocked. linux just either needs to add a capability to > restrict access to mounted fs block devices and/or all block devices, > or just deny access when CAP_LINUX_IMMUTABLE (or maybe CAP_SYS_RAWIO) is > removed. It's still useless. As long as you have access to /dev/mem you can patch kernel code which eventually leads to being able to access raw disks (just load your own driver, not very difficult). When you disable /dev/mem e.g. your X server stops working. Even when you disable /dev/mem there are often other ways to access kernel memory as root, e.g. often drivers have some mainteance ioctls that can be used to trick some hardware into doing DMA from/to your buffer. As soon as you can do DMA you have full access to all memory, equivalent to /dev/mem. There are good reasons linux never implemented the BSD security level concept (it was briefly there in 2.0, but dropped because it was showed to be useless). It's also the reason why few people use the existing linux capabilities BTW. With some creativity most capabilities can be used to eventually access memory or change raw disk, and that leads to "super root". > > The only ones that may be worth it are 'S' (force O_SYNC, especially > > for directories e.g. to handle qmail/postfix spool dirs without forcing > > synchronous for the whole fs), 'A' (no atime) and 'd' for incremental > > backup purposes. > > noatime is not that useful IMO, if your worried about atime updates > there is a mount option, agreed on S(ync). It is useful for crontab on laptops for example to prevent the disk spinning up just for the inode flush. noatime is too big a sledgehammer. -Andi From owner-linux-xfs@oss.sgi.com Wed May 1 01:29:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g418TxwJ002856 for ; Wed, 1 May 2002 01:29:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g418TwsX002855 for linux-xfs-outgoing; Wed, 1 May 2002 01:29:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g418TjwJ002827 for ; Wed, 1 May 2002 01:29:45 -0700 Received: from erbenson.alaska.net (195-pm32.nwc.alaska.net [209.112.158.195]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g418Udu84902 for ; Wed, 1 May 2002 00:30:39 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 1A4A03924 for ; Wed, 1 May 2002 00:30:38 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 2CD931028A; Wed, 1 May 2002 00:30:38 -0800 (AKDT) Date: Wed, 1 May 2002 00:30:38 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020501003038.R21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> <1020210550.1179.3.camel@localhost.localdomain> <1020211474.1179.6.camel@localhost.localdomain> <20020501023726.A15270@wotan.suse.de> <20020430232643.Q21791@plato.local.lan> <20020501101545.A26317@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cnBsrynPgIOyCJkL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020501101545.A26317@wotan.suse.de>; from ak@suse.de on Wed, May 01, 2002 at 10:15:45AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --cnBsrynPgIOyCJkL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 01, 2002 at 10:15:45AM +0200, Andi Kleen wrote: >=20 > It's still useless. As long as you have access to /dev/mem you can > patch kernel code which eventually leads to being able to access > raw disks (just load your own driver, not very difficult). wrong again, revoke CAP_SYS_RAWIO and you can no longer access /dev/*mem /proc/kcore etc. > When you disable /dev/mem e.g. your X server stops working. the places where you are going to use immutable bits and hardening things down with capabilities is not GUI workstations, its text only firewalls and such. my firewall has been running for around a year now with access to /dev/*mem and module insertion completly disabled without any breakage. > Even when you disable /dev/mem there are often other ways to access > kernel memory as root, e.g. often drivers have some mainteance ioctls > that can be used to trick some hardware into doing DMA from/to your > buffer. As soon as you can do DMA you have full access to all memory, > equivalent to /dev/mem. now you're going into the realm of `you can't have 100% security so lets not bother trying' > There are good reasons linux never implemented the BSD security level > concept 2.0 did implement it. > (it was briefly there in 2.0, but dropped because it was showed to be=20 > useless). It's also the reason why few people use the existing linux it was not dropped it was obsoleted by capabilities, but capabilities have not been fully completed to match the securelevel abilities. > capabilities BTW. With some creativity most capabilities can be used > to eventually access memory or change raw disk, and that leads to=20 > "super root". see above about 100% security and not bothering to try. we may as well say `there will always be security bugs in software and so on, so lets just forget it and chmod -R 6777 /'=20 of COURSE there is no such thing as 100% security, no matter how much you harden a box there is probably still some obfuscated way to crack it. the POINT is to make it more *difficult* to crack the box, more difficult, time consuming, etc. that extra PITA you add to a security sensitive box is quite likly to cause the attacker to say `fuck it' and move on to a nice easy default redhat. or at the very least delay things long enough for the attentive admin to notice some shady crap going on before serious damage is already done. > > noatime is not that useful IMO, if your worried about atime updates > > there is a mount option, agreed on S(ync). >=20 > It is useful for crontab on laptops for example to prevent the disk > spinning up just for the inode flush. noatime is too big a sledgehammer. on a laptop you need to use the noatime mount option to cover the entire filesystem, running around adding a bit to every file that might be accessed to avoid disk spinup is insane. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --cnBsrynPgIOyCJkL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzPp60ACgkQJKx7GixEevy5CACfXfyqPqgh/x1SIjoWJ2rYtSmv 5XUAn02bYg9lJ99cxwasI1b2IZjb37gU =RTmv -----END PGP SIGNATURE----- --cnBsrynPgIOyCJkL-- From owner-linux-xfs@oss.sgi.com Wed May 1 02:12:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g419CpwJ003279 for ; Wed, 1 May 2002 02:12:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g419Cpiv003278 for linux-xfs-outgoing; Wed, 1 May 2002 02:12:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g419CRwJ003249 for ; Wed, 1 May 2002 02:12:27 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA2574409 for ; Wed, 1 May 2002 02:13:21 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA34056; Wed, 1 May 2002 19:11:58 +1000 (AEST) Date: Wed, 1 May 2002 19:11:58 +1000 From: Timothy Shimmin To: jtrostel@snapserver.com Cc: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: Re: Query about setfacl behavior Message-ID: <20020501191158.R793932@boing.melbourne.sgi.com> References: <20020501172550.Q793932@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020501172550.Q793932@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Wed, May 01, 2002 at 05:25:50PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi John, I now have more of an idea of what is happening - I'll need to get some feedback from Andreas G. on setfacl(1) for this. If I have: [root@sagan xfs1]# getfacl wow # file: wow # owner: root # group: root user::r-x group::rw- #effective:--- mask::--- other::r-- [root@sagan xfs1]# ls -l | grep 'wow$' dr-x---r-- 2 root root 6 May 1 16:02 wow And I use setfacl compiled to allow -t, I see: [root@sagan xfs1]# setfacl -m u::--- -t wow wow: u::---,g::rw-,m::rw-,o::r--,* i.e. setfacl is about to set the acl with a mask ACE of m::rw- even though the mask ACE is currently m::---. It seems that setfacl(1) is looking at the GROUP_OBJ ace and setting the mask ACE to this ! In XFS, if we have a mask ACE then it is kept in sync with the group permissions (as per the standard), but the GROUP_OBJ ACE is left unaltered. So setfacl(1) is sync'ing the mask ACE with the GROUP_OBJ ACE and we are in trouble. The question is, why is setfacl(1) doing this ? Andreas ? Thanks a bunch, Tim. On Wed, May 01, 2002 at 05:25:50PM +1000, Timothy Shimmin wrote: > On Tue, Apr 30, 2002 at 01:20:28PM -0400, jtrostel@snapserver.com wrote: > > I am wondering if this is correct behavior... > > > Yeah it looks wrong, John. > It looks like the mask ACE is getting the group permissions. > > e.g. > ======================================================== > [root@sagan xfs1]# getfacl wow > # file: wow > # owner: root > # group: root > user::r-- > group::rw- > other::rwx > > [root@sagan xfs1]# setfacl -m m::--- wow > [root@sagan xfs1]# getfacl wow > # file: wow > # owner: root > # group: root > user::r-- > group::rw- #effective:--- > mask::--- > other::rwx > > [root@sagan xfs1]# setfacl -m u::r-x wow > [root@sagan xfs1]# getfacl wow > # file: wow > # owner: root > # group: root > user::r-x > group::rw- > mask::rw- > other::rwx > ======================================================== > > I'll look into it... > > --Tim > > > > > Using XFS CVS tip as of this morning (4/30/02) which gives me acl 2.0.10 > > > > [jt@jtsdevel xfs_part]$ getfacl --version > > getfacl 2.0.10 > > > > Set up an xfs partition with acls as follows: > > > > [jt@jtsdevel xfs_part]$ pwd > > /mnt/xfs_part > > [jt@jtsdevel xfs_part]$ getfacl . > > # file: . > > # owner: root > > # group: root > > user::rwx > > group::rwx > > mask::rwx > > other::rwx > > default:user::rwx > > default:group::rwx > > default:mask::rwx > > default:other::rwx > > > > I then created a new directoryon that partition, named jts_dir > > > > [jt@jtsdevel xfs_part]$ mkdir jts_dir > > > > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > > # file: jts_dir > > # owner: jt > > # group: jt > > user::rwx > > group::rwx > > mask::rwx > > other::rwx > > default:user::rwx > > default:group::rwx > > default:mask::rwx > > default:other::rwx > > > > Now.. I added an auxillary user 'a1' to the access aces. > > > > [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rwx jts_dir/ > > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > > # file: jts_dir > > # owner: jt > > # group: jt > > user::rwx > > user:a1:rwx > > group::rwx > > mask::rwx > > other::rwx > > default:user::rwx > > default:group::rwx > > default:mask::rwx > > default:other::rwx > > > > Change the mask ace to no perms > > > > [jt@jtsdevel xfs_part]$ setfacl -m m::--- jts_dir/ > > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > > # file: jts_dir > > # owner: jt > > # group: jt > > user::rwx > > user:a1:rwx #effective:--- > > group::rwx #effective:--- > > mask::--- > > other::rwx > > default:user::rwx > > default:group::rwx > > default:mask::rwx > > default:other::rwx > > > > NOW! Change the aux. user 'a1' perms to something else, for instance 'rw'. The > > mask ace is also changed now. (It went from --- to rwx) Why? > > > > > > [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rw jts_dir/ > > [jt@jtsdevel xfs_part]$ getfacl jts_dir/ > > # file: jts_dir > > # owner: jt > > # group: jt > > user::rwx > > user:a1:rw- > > group::rwx > > mask::rwx > > other::rwx > > default:user::rwx > > default:group::rwx > > default:mask::rwx > > default:other::rwx > > > > P.S. (For XFS folks: chacl -l returns the same values) > > > > -- > > John M. Trostel > > Senior Software Engineer > > Quantum Corp. / NASD > > jtrostel@snapserver.com > > > From owner-linux-xfs@oss.sgi.com Wed May 1 03:44:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41AiXwJ003994 for ; Wed, 1 May 2002 03:44:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41AiXjh003993 for linux-xfs-outgoing; Wed, 1 May 2002 03:44:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41AiKwJ003967 for ; Wed, 1 May 2002 03:44:21 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g41AidP09203; Wed, 1 May 2002 12:44:39 +0200 Date: Wed, 1 May 2002 12:44:39 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Timothy Shimmin cc: , Subject: Re: Query about setfacl behavior In-Reply-To: <20020501191158.R793932@boing.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 1 May 2002, Timothy Shimmin wrote: > Hi John, > > I now have more of an idea of what is happening - > I'll need to get some feedback from Andreas G. on > setfacl(1) for this. > > If I have: > > [root@sagan xfs1]# getfacl wow > # file: wow > # owner: root > # group: root > user::r-x > group::rw- #effective:--- > mask::--- > other::r-- > > [root@sagan xfs1]# ls -l | grep 'wow$' > dr-x---r-- 2 root root 6 May 1 16:02 wow > > > And I use setfacl compiled to allow -t, I see: > > [root@sagan xfs1]# setfacl -m u::--- -t wow > wow: u::---,g::rw-,m::rw-,o::r--,* > > i.e. > setfacl is about to set the acl with a mask ACE of m::rw- > even though the mask ACE is currently m::---. > It seems that setfacl(1) is looking at the GROUP_OBJ ace and > setting the mask ACE to this ! > > In XFS, if we have a mask ACE then it is kept in sync with the > group permissions (as per the standard), > but the GROUP_OBJ ACE is left unaltered. > So setfacl(1) is sync'ing the mask ACE with the GROUP_OBJ ACE > and we are in trouble. > The question is, why is setfacl(1) doing this ? Because this is what setfacl is supposed to do accorindg to the specification. Unless the -n option is not used, setfacl recalculates the permissions in the ACL mask entry whenever the ACL changes, as long as no mask entry is explicitly given. The permissions are set to the union of the permissions of all ACL_USER, ACL_GROUP_OBJ, and ACL_GROUP entries. This gives: $ touch f $ setfacl -m u:joe:rw,m::r f $ getfacl f # file: f # owner: ag # group: users user::rw- user:joe:rw- #effective:r-- group::r-- mask::r-- other::r-- $ setfacl -m u:lisa:rw f $ # file: f # owner: ag # group: users user::rw- user:joe:rw- user:lisa:rw- group::r-- mask::rw- other::r-- Or, if -n had been used: $ getfacl f # file: f # owner: ag # group: users user::rw- user:joe:rw- #effective:r-- user:lisa:rw- #effective:r-- group::r-- mask::r-- other::r-- Cheers, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Wed May 1 03:56:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41Au0wJ004228 for ; Wed, 1 May 2002 03:56:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Au030004227 for linux-xfs-outgoing; Wed, 1 May 2002 03:56:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from svr-ganmtc-appserv-mgmt.ncf.coxexpress.com (svr-ganmtc-appserv-mgmt.ncf.coxexpress.com [24.136.46.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41AtqwJ004195 for ; Wed, 1 May 2002 03:55:52 -0700 Received: from darkstar.doublethink.cx (cpe-oca-24-136-59-202-cmcpe.ncf.coxexpress.com [24.136.59.202]) by svr-ganmtc-appserv-mgmt.ncf.coxexpress.com (8.11.4/8.11.4) with ESMTP id g41AuW719093; Wed, 1 May 2002 06:56:33 -0400 Received: by darkstar.doublethink.cx (Postfix, from userid 1000) id 808E523D; Wed, 1 May 2002 06:56:31 -0400 (EDT) Date: Wed, 1 May 2002 06:56:31 -0400 From: Chris Faulhaber To: jtrostel@snapserver.com Cc: acl-devel@bestbits.at, Timothy Shimmin , XFS list Subject: Re: [Acl-Devel] Query about setfacl behavior Message-ID: <20020501105631.GA65803@darkstar.doublethink.cx> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 01:20:28PM -0400, jtrostel@snapserver.com wrote: > I am wondering if this is correct behavior... >=20 > Using XFS CVS tip as of this morning (4/30/02) which gives me acl 2.0.10 >=20 ... > NOW! Change the aux. user 'a1' perms to something else, for instance 'rw= '. The > mask ace is also changed now. (It went from --- to rwx) Why? >=20 Unless the -n option is used and/or the mask is specified, the mask is recalulated everytime you change the permissions. --=20 Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: FreeBSD: The Power To Serve iEYEARECAAYFAjzPyd8ACgkQObaG4P6BelD8MACeMT2j5UpCJgdipZavoC4pVP+7 8rwAoIr/l/AJIMtiBrplZe/q4YQRb7zD =xLrx -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-linux-xfs@oss.sgi.com Wed May 1 05:54:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41CsawJ008873 for ; Wed, 1 May 2002 05:54:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41CsZKs008872 for linux-xfs-outgoing; Wed, 1 May 2002 05:54:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41CsTwJ008844 for ; Wed, 1 May 2002 05:54:29 -0700 Received: from erbenson.alaska.net (195-pm32.nwc.alaska.net [209.112.158.195]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g41CtOu22560 for ; Wed, 1 May 2002 04:55:24 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 10A943924 for ; Wed, 1 May 2002 04:55:23 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 4027F1028A; Wed, 1 May 2002 04:55:23 -0800 (AKDT) Date: Wed, 1 May 2002 04:55:22 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: errno return for setting acls Message-ID: <20020501045522.T21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jo46wx5DSA4a/gWG" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --jo46wx5DSA4a/gWG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable XFS seems to return EACCES instead of EPERM when a user tries to set/alter an acl on a file they don't own. from looking at the withdrawn posix spec i believe it should be EPERM, and that is more consistent with the equivilent; chmod. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --jo46wx5DSA4a/gWG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzP5boACgkQJKx7GixEevwIYwCfRzWUi3v4gKlYUyf7Y2ej20G+ CB0An0lsSHoVWUXFDUyHF/0i0iyHHFTm =2saF -----END PGP SIGNATURE----- --jo46wx5DSA4a/gWG-- From owner-linux-xfs@oss.sgi.com Wed May 1 07:52:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41EqbwJ014617 for ; Wed, 1 May 2002 07:52:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Eqamr014616 for linux-xfs-outgoing; Wed, 1 May 2002 07:52:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41EqUwJ014589 for ; Wed, 1 May 2002 07:52:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA47159 for ; Wed, 1 May 2002 09:53:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA06185; Wed, 1 May 2002 09:53:20 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41EqMx29495; Wed, 1 May 2002 09:52:22 -0500 Subject: Re: TAKE - better mmap write support in pagebuf From: Steve Lord To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020185612.7562.32.camel@jen.americas.sgi.com> References: <200204300955.g3U9tKZ02413@jen.americas.sgi.com> <1020185612.7562.32.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 09:52:22 -0500 Message-Id: <1020264742.28901.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 11:53, Steve Lord wrote: > On Tue, 2002-04-30 at 04:55, Steve Lord wrote: > > Some multiple blocksize work, and better optimization of allocation > > and writes in the mmap write case where memory pressure is the cause > > of data getting flushed. We used to fragment files really badly in > > this case, now fragmentation is reasonable - which causes major > > speedup of some loads. > > > > I would hold off taking this code until I do some more work on it, looks > like I fixed one lot of performance by killing another one.... dbench > throughput has gone down the tubes. > > Not sure yet when it came in - sometime in the last 24 hours I think. > > Steve OK, I take that back, performance has not been killed by this, it was my machine configuration on this end. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 08:52:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41FqUwJ022961 for ; Wed, 1 May 2002 08:52:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41FqUx7022960 for linux-xfs-outgoing; Wed, 1 May 2002 08:52:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41FqOwJ022932 for ; Wed, 1 May 2002 08:52:24 -0700 Received: (qmail-ldap/ctrl 8882 invoked by uid 0); 1 May 2002 15:53:20 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 10:53:20 -0500 Message-ID: <1020268400.3cd00f70a6d51@webmail.midco.net> Date: Wed, 1 May 2002 10:53:20 -0500 From: bren@sio.midco.net To: linux-xfs@oss.sgi.com Subject: Free space question MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, We were spammed in the number of tens of thousands of e-mails recently. I have an approx. 1G XFS qmail queue (/var/qmail/queue) which was filled with e-mail. My mount options are: /dev/sda5 /var/qmail/queue xfs rw,noatime,nodiratime 0 0 df reports over 200MB free space, yet I cannot create a file as it reports "touch: file: No space left on device." Here is what df reports (I had to remount the queue under /mnt): df --version df (GNU fileutils) 4.0l df -h: /dev/scsi/host0/bus0/target0/lun0/part5 948M 745M 204M 79% /mnt df -i: /dev/scsi/host0/bus0/target0/lun0/part5 952000 117248 834752 12% /mnt We're running 2.4.16-xfs. I've checked the filesystem with xfs_check and xfs_repair and it's clean. Any ideas here? Thanks, Brendon Colby From owner-linux-xfs@oss.sgi.com Wed May 1 09:02:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41G2NwJ024033 for ; Wed, 1 May 2002 09:02:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41G2NYq024032 for linux-xfs-outgoing; Wed, 1 May 2002 09:02:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41G2IwJ024006 for ; Wed, 1 May 2002 09:02:18 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA20543; Wed, 1 May 2002 11:03:09 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA38219; Wed, 1 May 2002 11:03:09 -0500 (CDT) Subject: Re: Free space question From: Eric Sandeen To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020268400.3cd00f70a6d51@webmail.midco.net> References: <1020268400.3cd00f70a6d51@webmail.midco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 May 2002 11:03:09 -0500 Message-Id: <1020268989.1202.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 10:53, bren@sio.midco.net wrote: > df reports over 200MB free space, yet I cannot create a file as it reports > "touch: file: No space left on device." Here is what df reports (I had to > remount the queue under /mnt): Are you unable to create a new file after you've remounted the filesystem, as well? A fix went in fairly recently that handled flushing out reserved space as the filesystem got full, but in that case "df" would report no space left until a manual "sync" freed it up. Looks like your case is a bit different. I don't suppose you could upgrade to a newer kernel? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 1 09:04:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41G4mwJ024195 for ; Wed, 1 May 2002 09:04:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41G4mDW024194 for linux-xfs-outgoing; Wed, 1 May 2002 09:04:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41G4gwJ024159 for ; Wed, 1 May 2002 09:04:42 -0700 Received: (qmail-ldap/ctrl 8910 invoked by uid 0); 1 May 2002 16:05:39 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 11:05:39 -0500 Message-ID: <1020269139.3cd0125334c80@webmail.midco.net> Date: Wed, 1 May 2002 11:05:39 -0500 From: bren@sio.midco.net To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020268400.3cd00f70a6d51@webmail.midco.net> <1020268989.1202.13.camel@stout.americas.sgi.com> In-Reply-To: <1020268989.1202.13.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I get the same results when I remount as well. At this point upgrading to a new kernel would be no big deal. I have 2.4.18 and the xfs patch ready to go. I think I'll try that now... Thanks. Quoting Eric Sandeen : > On Wed, 2002-05-01 at 10:53, bren@sio.midco.net wrote: > > > df reports over 200MB free space, yet I cannot create a file as it > reports > > "touch: file: No space left on device." Here is what df reports (I had to > > remount the queue under /mnt): > > Are you unable to create a new file after you've remounted the > filesystem, as well? A fix went in fairly recently that handled > flushing out reserved space as the filesystem got full, but in that case > "df" would report no space left until a manual "sync" freed it up. > Looks like your case is a bit different. > > I don't suppose you could upgrade to a newer kernel? > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > From owner-linux-xfs@oss.sgi.com Wed May 1 09:15:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41GF7wJ024474 for ; Wed, 1 May 2002 09:15:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41GF7Y7024473 for linux-xfs-outgoing; Wed, 1 May 2002 09:15:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13106.mail.yahoo.com (web13106.mail.yahoo.com [216.136.174.151]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41GEowJ024442 for ; Wed, 1 May 2002 09:14:50 -0700 Message-ID: <20020501161546.10052.qmail@web13106.mail.yahoo.com> Received: from [208.35.40.2] by web13106.mail.yahoo.com via HTTP; Wed, 01 May 2002 09:15:46 PDT Date: Wed, 1 May 2002 09:15:46 -0700 (PDT) From: Ravi Wijayaratne Subject: oops in xlog_unpack_data() To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, We had a situation where XFS persistent logs were damaged irreparably due to hot swapping of disks. The damage to the logs are expected. However when trying to recover from the process XFS oopsed. The ksymoops is attached at the end of the email. After having examined the code we discovered that the kernel is trying to access a NULL value in xlog_rec_header_t rhead->h_cycle_data in function xlog_unpack_data(). A simple fix as if(!rhead->h_cycle_data){ log->l_flags |= ( XLOG_DISK_LOG_CORRUPTED | XLOG_IO_ERROR); return; } and checking for XLOG_DISK_LOG_CORRUPTED in xlog_do_recovery_pass and returning EFSCORRUPTED caused mount to exit complaining about the file system corruption. However the question is what caused rhead->h_cycle_data to have a NULL value ? In xlog_do_recovery_pass() we notice that rhead->h_magicno is compared to XLOG_HEADER_MAGIC_NUM in several places. However EFSCORRUPTED is returned only for the case where (!(tail_blk <= head_blk)) and in other cases is simply ASSERTED but ignored. For the case where it oopsed there was a magic number discrepancy. Is this a possible oversight ? I am an XFS newbie and am greatly impaired by not being able to access the XFS design docs in oss. Anybody know where I could get them ? Thank you Ravi --------------- ksymoops ----------------------- Unable to handle kernel paging request at virtual address d0000000 c01c7bee *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00280006 ebx: 00000000 ecx: 00000380 edx: 00000000 esi: 00000380 edi: cff3902c ebp: d0000000 esp: cff6b778 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 41, stackpage=cff6b000) Stack: 00000000 00001090 00000000 00000000 00000380 cff3902c c01c7dcd cff38200 cff90000 ce5b12e0 00000000 ce5b12e0 0000108e 00000000 c028ff11 cff6b7c0 ce5b12e0 cff6b8e8 72617453 cff90000 cff62800 cff62800 7265766f 6e6f2079 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 89 45 00 81 c5 00 02 00 00 83 c7 04 89 7c 24 14 ff 44 24 10 >>EIP; c01c7bee <===== Trace; c01c7dcd Trace; c01c8226 Trace; c01c82ae Trace; c01c8450 Trace; c01c2192 Trace; c01c9ec7 Trace; c01a63a0 Trace; c0105c69 <__down+a1/ac> Trace; c01c8b21 Trace; c01c8d06 Trace; c01c8d51 Trace; c01e74f1 Trace; c01d18ed Trace; c01d1a6e Trace; c01d1a9b Trace; c01e76e9 Trace; c01284cf <__alloc_pages+3b/17c> Trace; c011f529 Trace; c0128330 <_alloc_pages+18/1c> Trace; c011f5a0 Trace; c011f655 Trace; c01325e6 Trace; c01417e7 Trace; c01329ec Trace; c0142654 Trace; c0142a0e Trace; c0142874 Trace; c0142aac Trace; c0106dfb Code; c01c7bee 00000000 <_EIP>: Code; c01c7bee <===== 0: 89 45 00 mov %eax,0x0(%ebp) <===== Code; c01c7bf1 3: 81 c5 00 02 00 00 add $0x200,%ebp Code; c01c7bf7 9: 83 c7 04 add $0x4,%edi Code; c01c7bfa c: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c01c7bfe 10: ff 44 24 10 incl 0x10(%esp,1) ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-linux-xfs@oss.sgi.com Wed May 1 09:34:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41GYswJ024863 for ; Wed, 1 May 2002 09:34:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41GYsTM024862 for linux-xfs-outgoing; Wed, 1 May 2002 09:34:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41GYowJ024830 for ; Wed, 1 May 2002 09:34:51 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 5B63E1ED8B; Wed, 1 May 2002 18:35:41 +0200 (MEST) Date: Wed, 1 May 2002 18:35:39 +0200 From: Andi Kleen To: bren@sio.midco.net Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Free space question Message-ID: <20020501183539.A13462@wotan.suse.de> References: <1020268400.3cd00f70a6d51@webmail.midco.net> <1020268989.1202.13.camel@stout.americas.sgi.com> <1020269139.3cd0125334c80@webmail.midco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020269139.3cd0125334c80@webmail.midco.net> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 01, 2002 at 11:05:39AM -0500, bren@sio.midco.net wrote: > I get the same results when I remount as well. Are you sure you didn't run out of inodes? XFS has some builtin inode limit I think, they cannot exceed some fraction of the total disk space. -Andi From owner-linux-xfs@oss.sgi.com Wed May 1 10:01:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41H1IwJ028198 for ; Wed, 1 May 2002 10:01:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41H1IiA028196 for linux-xfs-outgoing; Wed, 1 May 2002 10:01:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41H1CwJ028168 for ; Wed, 1 May 2002 10:01:13 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g41H28dR036072; Wed, 1 May 2002 19:02:08 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA25378; Wed, 1 May 2002 19:02:08 +0200 (CEST) Date: Wed, 1 May 2002 19:02:08 +0200 (CEST) From: Seth Mos To: cc: Subject: Re: Free space question In-Reply-To: <1020268400.3cd00f70a6d51@webmail.midco.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 1 May 2002 bren@sio.midco.net wrote: > Hello all, > > We were spammed in the number of tens of thousands of e-mails recently. I have > an approx. 1G XFS qmail queue (/var/qmail/queue) which was filled with e-mail. > My mount options are: > > /dev/sda5 /var/qmail/queue xfs rw,noatime,nodiratime 0 0 > > df reports over 200MB free space, yet I cannot create a file as it reports > "touch: file: No space left on device." Here is what df reports (I had to > remount the queue under /mnt): Did you ran out of inodes perhaps? I think a mail spool would be susceptible to this. I don't know if the inode usage is representative. I believe the default is 25% of the fs. Can you try a newer kernel? I know steve had a fix to make it give back space faster under memory pressure. Normally it locates a larger chunk to reduce fragmentation but you need that space back fast in such a case. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed May 1 10:11:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41HBvwJ028607 for ; Wed, 1 May 2002 10:11:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41HBu0W028606 for linux-xfs-outgoing; Wed, 1 May 2002 10:11:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41HBqwJ028580 for ; Wed, 1 May 2002 10:11:53 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g41HCndR040319; Wed, 1 May 2002 19:12:49 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA26381; Wed, 1 May 2002 19:12:49 +0200 (CEST) Date: Wed, 1 May 2002 19:12:48 +0200 (CEST) From: Seth Mos To: Ravi Wijayaratne cc: Subject: Re: oops in xlog_unpack_data() In-Reply-To: <20020501161546.10052.qmail@web13106.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 1 May 2002, Ravi Wijayaratne wrote: > I am an XFS newbie and am greatly impaired by not > being able to access the XFS design docs in oss. > Anybody know where I could get them ? By checking out the xfs-website CVS or go here: http://iserv.nl/files/xfs/design_docs Cheers Seth From owner-linux-xfs@oss.sgi.com Wed May 1 10:23:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41HN9wJ029020 for ; Wed, 1 May 2002 10:23:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41HN8rw029019 for linux-xfs-outgoing; Wed, 1 May 2002 10:23:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41HN2wJ028993 for ; Wed, 1 May 2002 10:23:03 -0700 Received: (qmail-ldap/ctrl 9111 invoked by uid 0); 1 May 2002 17:23:59 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 12:23:59 -0500 Message-ID: <1020273839.3cd024af9c1aa@webmail.midco.net> Date: Wed, 1 May 2002 12:23:59 -0500 From: bren@sio.midco.net To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok. I've upgraded to 2.4.18 with XFS 1.1. Same results... df -i reports: /dev/scsi/host0/bus0/target0/lun0/part5 952000 117248 834752 12% /mnt df -h: /dev/scsi/host0/bus0/target0/lun0/part5 948M 745M 204M 79% /mnt Yet simply touching a new file returns: touch: file: No space left on device I'm stumped on this one. Is there a better way to check free space and inode use? Quoting Seth Mos : > > Did you ran out of inodes perhaps? I think a mail spool would be > susceptible to this. > > I don't know if the inode usage is representative. I believe the default > is 25% of the fs. > > Can you try a newer kernel? I know steve had a fix to make it give back > space faster under memory pressure. Normally it locates a larger chunk to > reduce fragmentation but you need that space back fast in such a case. > > Cheers > Seth > > From owner-linux-xfs@oss.sgi.com Wed May 1 10:46:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41Hk9wJ029366 for ; Wed, 1 May 2002 10:46:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Hk9cv029365 for linux-xfs-outgoing; Wed, 1 May 2002 10:46:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41Hk5wJ029339 for ; Wed, 1 May 2002 10:46:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA18483; Wed, 1 May 2002 12:46:56 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA75664; Wed, 1 May 2002 12:46:56 -0500 (CDT) Subject: Re: Free space question From: Eric Sandeen To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020273839.3cd024af9c1aa@webmail.midco.net> References: <1020273839.3cd024af9c1aa@webmail.midco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 May 2002 12:46:56 -0500 Message-Id: <1020275216.1266.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just for kicks you could try using xfs_growfs to bump the inode maxpct a bit, although from df -i I don't think that's the problem... -Eric On Wed, 2002-05-01 at 12:23, bren@sio.midco.net wrote: > Ok. I've upgraded to 2.4.18 with XFS 1.1. Same results... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 1 11:12:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41ICWwJ030093 for ; Wed, 1 May 2002 11:12:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41ICWgq030092 for linux-xfs-outgoing; Wed, 1 May 2002 11:12:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41ICMwJ030060 for ; Wed, 1 May 2002 11:12:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA86547; Wed, 1 May 2002 13:13:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA37915; Wed, 1 May 2002 13:13:13 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41ICEN22705; Wed, 1 May 2002 13:12:14 -0500 Subject: Re: oops in xlog_unpack_data() From: Steve Lord To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020501161546.10052.qmail@web13106.mail.yahoo.com> References: <20020501161546.10052.qmail@web13106.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 13:12:13 -0500 Message-Id: <1020276733.28901.59.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 11:15, Ravi Wijayaratne wrote: > Hi All, > > We had a situation where XFS persistent logs were > damaged irreparably due to hot swapping of disks. The > damage to the logs are expected. However when trying > to recover from the process XFS oopsed. The ksymoops > is > attached at the end of the email. > > After having examined the code we discovered that the > kernel is trying to access a NULL value in > > xlog_rec_header_t rhead->h_cycle_data > in function xlog_unpack_data(). A simple fix as > > if(!rhead->h_cycle_data){ > > log->l_flags |= ( XLOG_DISK_LOG_CORRUPTED | > XLOG_IO_ERROR); > return; > } > > and checking for XLOG_DISK_LOG_CORRUPTED in > xlog_do_recovery_pass and returning EFSCORRUPTED > caused mount to exit complaining about the file system > corruption. > > However the question is what caused > rhead->h_cycle_data to have a NULL value ? > > In xlog_do_recovery_pass() we notice that > rhead->h_magicno is compared to XLOG_HEADER_MAGIC_NUM > in several places. However EFSCORRUPTED is returned > only for the case where (!(tail_blk <= head_blk)) and > in other cases is simply ASSERTED but ignored. For the > case where it oopsed there was a magic number > discrepancy. > > Is this a possible oversight ? It does look that way. I suspect you need to run xfs_repair -L on this filesystem to ignore the log and rebuild the rest of the fs. > > I am an XFS newbie and am greatly impaired by not > being able to access the XFS design docs in oss. > Anybody know where I could get them ? Seth answered this, we are working on getting oss sorted out again - some web site config was lost. > > Thank you > Ravi > Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 11:22:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41IMiwJ030507 for ; Wed, 1 May 2002 11:22:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41IMisM030506 for linux-xfs-outgoing; Wed, 1 May 2002 11:22:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41IMdwJ030480 for ; Wed, 1 May 2002 11:22:39 -0700 Received: (qmail-ldap/ctrl 9306 invoked by uid 0); 1 May 2002 18:23:36 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 13:23:36 -0500 Message-ID: <1020277416.3cd032a880faf@webmail.midco.net> Date: Wed, 1 May 2002 13:23:36 -0500 From: bren@sio.midco.net To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> In-Reply-To: <1020275216.1266.17.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So 25% of the drive is reserved for inodes. There is roughly 25% free space reported. Is the space that is reported as being free actually reserved? I tried lowering the imaxpct, with no change. Quoting Eric Sandeen : > Just for kicks you could try using xfs_growfs to bump the inode maxpct a > bit, although from df -i I don't think that's the problem... > > -Eric > > On Wed, 2002-05-01 at 12:23, bren@sio.midco.net wrote: > > Ok. I've upgraded to 2.4.18 with XFS 1.1. Same results... > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > From owner-linux-xfs@oss.sgi.com Wed May 1 11:26:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41IQEwJ030709 for ; Wed, 1 May 2002 11:26:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41IQEXN030708 for linux-xfs-outgoing; Wed, 1 May 2002 11:26:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41IQ7wJ030682 for ; Wed, 1 May 2002 11:26:08 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA39570; Wed, 1 May 2002 13:26:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA32401; Wed, 1 May 2002 13:26:59 -0500 (CDT) Subject: Re: Free space question From: Eric Sandeen To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020277416.3cd032a880faf@webmail.midco.net> References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 May 2002 13:26:59 -0500 Message-Id: <1020277619.1202.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk imaxpct sets how much filesystem space can be consumed by the inodes themselves. It is not reserved, just an upper bound. You would want to raise the imaxpct, if anything, to test this. However, if you were able to lower it, that means that you had not yet hit the old max, so that's not the problem. Still thinking... -Eric On Wed, 2002-05-01 at 13:23, bren@sio.midco.net wrote: > So 25% of the drive is reserved for inodes. There is roughly 25% free space > reported. Is the space that is reported as being free actually reserved? I tried > lowering the imaxpct, with no change. > > Quoting Eric Sandeen : > > > Just for kicks you could try using xfs_growfs to bump the inode maxpct a > > bit, although from df -i I don't think that's the problem... > > > > -Eric > > > > On Wed, 2002-05-01 at 12:23, bren@sio.midco.net wrote: > > > Ok. I've upgraded to 2.4.18 with XFS 1.1. Same results... > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > > > > > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 1 11:37:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41IbmwJ031052 for ; Wed, 1 May 2002 11:37:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Ibm2L031051 for linux-xfs-outgoing; Wed, 1 May 2002 11:37:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41IbhwJ031025 for ; Wed, 1 May 2002 11:37:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA35560; Wed, 1 May 2002 13:38:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA45592; Wed, 1 May 2002 13:38:35 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41IbZg22764; Wed, 1 May 2002 13:37:35 -0500 Subject: Re: Free space question From: Steve Lord To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020277619.1202.21.camel@stout.americas.sgi.com> References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 13:37:35 -0500 Message-Id: <1020278255.28928.63.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 13:26, Eric Sandeen wrote: > imaxpct sets how much filesystem space can be consumed by the inodes > themselves. It is not reserved, just an upper bound. > > You would want to raise the imaxpct, if anything, to test this. > However, if you were able to lower it, that means that you had not yet > hit the old max, so that's not the problem. > > Still thinking... > > -Eric > Try running xfs_db -r /dev/xxx then run the freesp command, this will report how freespace is distributed on the filesystem. quit gets you out of xfs_db. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 11:50:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41Io7wJ031290 for ; Wed, 1 May 2002 11:50:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Io7WE031289 for linux-xfs-outgoing; Wed, 1 May 2002 11:50:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41Io0wJ031262 for ; Wed, 1 May 2002 11:50:01 -0700 Received: (qmail-ldap/ctrl 9403 invoked by uid 0); 1 May 2002 18:50:58 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 13:50:58 -0500 Message-ID: <1020279058.3cd0391210692@webmail.midco.net> Date: Wed, 1 May 2002 13:50:58 -0500 From: bren@sio.midco.net To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> <1020278255.28928.63.camel@jen.americas.sgi.com> In-Reply-To: <1020278255.28928.63.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Odd...I get this a bunch of times: can't seek in filesystem at bb 8861651024 can't read btree block 7/1107492864 can't seek in filesystem at bb 17048932432 can't read btree block 7/2130903040 when I do a freesp with xfs_db. I've checked this fs with xfs_repair more than once... Quoting Steve Lord : > On Wed, 2002-05-01 at 13:26, Eric Sandeen wrote: > > imaxpct sets how much filesystem space can be consumed by the inodes > > themselves. It is not reserved, just an upper bound. > > > > You would want to raise the imaxpct, if anything, to test this. > > However, if you were able to lower it, that means that you had not yet > > hit the old max, so that's not the problem. > > > > Still thinking... > > > > -Eric > > > > > Try running xfs_db -r /dev/xxx > > then run the freesp command, this will report how freespace is > distributed on the filesystem. quit gets you out of xfs_db. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > From owner-linux-xfs@oss.sgi.com Wed May 1 11:55:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41ItdwJ031587 for ; Wed, 1 May 2002 11:55:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41ItdIw031586 for linux-xfs-outgoing; Wed, 1 May 2002 11:55:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41ItVwJ031558 for ; Wed, 1 May 2002 11:55:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA41185; Wed, 1 May 2002 13:56:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA17364; Wed, 1 May 2002 13:56:23 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41ItNC23145; Wed, 1 May 2002 13:55:23 -0500 Subject: Re: Free space question From: Steve Lord To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020279058.3cd0391210692@webmail.midco.net> References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> <1020278255.28928.63.camel@jen.americas.sgi.com> <1020279058.3cd0391210692@webmail.midco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 13:55:23 -0500 Message-Id: <1020279323.28928.67.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 13:50, bren@sio.midco.net wrote: > Odd...I get this a bunch of times: > > can't seek in filesystem at bb 8861651024 > can't read btree block 7/1107492864 > can't seek in filesystem at bb 17048932432 > can't read btree block 7/2130903040 > > when I do a freesp with xfs_db. I've checked this fs with xfs_repair more than > once... Ugh, try xfs_check on the unmounted device, it will look at different things. Those numbers look way out of bounds. Steve > > Quoting Steve Lord : > > > On Wed, 2002-05-01 at 13:26, Eric Sandeen wrote: > > > imaxpct sets how much filesystem space can be consumed by the inodes > > > themselves. It is not reserved, just an upper bound. > > > > > > You would want to raise the imaxpct, if anything, to test this. > > > However, if you were able to lower it, that means that you had not yet > > > hit the old max, so that's not the problem. > > > > > > Still thinking... > > > > > > -Eric > > > > > > > > > Try running xfs_db -r /dev/xxx > > > > then run the freesp command, this will report how freespace is > > distributed on the filesystem. quit gets you out of xfs_db. > > > > Steve > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 12:00:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41J0dwJ031818 for ; Wed, 1 May 2002 12:00:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41J0dYV031817 for linux-xfs-outgoing; Wed, 1 May 2002 12:00:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41J0ZwJ031790 for ; Wed, 1 May 2002 12:00:36 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA38395 for ; Wed, 1 May 2002 14:01:27 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA59421 for ; Wed, 1 May 2002 14:01:27 -0500 (CDT) Subject: papers & design docs available again on oss From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 May 2002 14:01:27 -0500 Message-Id: <1020279687.1202.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, the links to the PDF and PostScript papers and design docs on oss.sgi.com should be working again. If you find other problems let me know... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 1 12:05:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41J51wJ032019 for ; Wed, 1 May 2002 12:05:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41J51Te032018 for linux-xfs-outgoing; Wed, 1 May 2002 12:05:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41J4swJ031979 for ; Wed, 1 May 2002 12:04:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA41428; Wed, 1 May 2002 14:05:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA22669; Wed, 1 May 2002 14:05:45 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41J4jZ23188; Wed, 1 May 2002 14:04:45 -0500 Subject: Re: Free space question From: Steve Lord To: bren@sio.midco.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020279724.3cd03bac1cece@webmail.midco.net> References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> <1020278255.28928.63.camel@jen.americas.sgi.com> <1020279058.3cd0391210692@webmail.midco.net> <1020279323.28928.67.camel@jen.americas.sgi.com> <1020279724.3cd03bac1cece@webmail.midco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 14:04:45 -0500 Message-Id: <1020279885.28901.71.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 14:02, bren@sio.midco.net wrote: > xfs_repair reports nothing. What if I were to dump the fs, rebuild the > partition, and restore the dump? I've tried about everything else.. Please try xfs_check on it - it is a different program, it does not fix things, but it does a good consistency check using a different algorithm. The freesp output suggests there is corruption, we at least need to capture that before doing anything else. Steve . > > Quoting Steve Lord : > > > > Ugh, try xfs_check on the unmounted device, it will look at different > > things. Those numbers look way out of bounds. > > > > Steve > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 12:11:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41JBdwJ032301 for ; Wed, 1 May 2002 12:11:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41JBdZ8032300 for linux-xfs-outgoing; Wed, 1 May 2002 12:11:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41JBWwJ032274 for ; Wed, 1 May 2002 12:11:33 -0700 Received: (qmail-ldap/ctrl 9469 invoked by uid 0); 1 May 2002 19:12:30 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 14:12:29 -0500 Message-ID: <1020280349.3cd03e1df0373@webmail.midco.net> Date: Wed, 1 May 2002 14:12:29 -0500 From: bren@sio.midco.net To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> <1020278255.28928.63.camel@jen.americas.sgi.com> <1020279058.3cd0391210692@webmail.midco.net> <1020279323.28928.67.camel@jen.americas.sgi.com> <1020279724.3cd03bac1cece@webmail.midco.net> <1020279885.28901.71.camel@jen.americas.sgi.com> In-Reply-To: <1020279885.28901.71.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ooops...a little quick on the send. I meant to say that xfs_check reports nothing. Quoting Steve Lord : > On Wed, 2002-05-01 at 14:02, bren@sio.midco.net wrote: > > xfs_repair reports nothing. What if I were to dump the fs, rebuild the > > partition, and restore the dump? I've tried about everything else.. > > Please try xfs_check on it - it is a different program, it does not > fix things, but it does a good consistency check using a different > algorithm. The freesp output suggests there is corruption, we at least > need to capture that before doing anything else. > > Steve > > . > > > > Quoting Steve Lord : > > > > > > > Ugh, try xfs_check on the unmounted device, it will look at different > > > things. Those numbers look way out of bounds. > > > > > > Steve > > > > > > -- > > > > > > Steve Lord voice: +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > From owner-linux-xfs@oss.sgi.com Wed May 1 12:44:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41JiYwJ032697 for ; Wed, 1 May 2002 12:44:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41JiYGm032696 for linux-xfs-outgoing; Wed, 1 May 2002 12:44:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41JiTwJ032669 for ; Wed, 1 May 2002 12:44:30 -0700 Received: (qmail-ldap/ctrl 9442 invoked by uid 0); 1 May 2002 19:02:04 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Wed, 1 May 2002 14:02:04 -0500 Message-ID: <1020279724.3cd03bac1cece@webmail.midco.net> Date: Wed, 1 May 2002 14:02:04 -0500 From: bren@sio.midco.net To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020273839.3cd024af9c1aa@webmail.midco.net> <1020275216.1266.17.camel@stout.americas.sgi.com> <1020277416.3cd032a880faf@webmail.midco.net> <1020277619.1202.21.camel@stout.americas.sgi.com> <1020278255.28928.63.camel@jen.americas.sgi.com> <1020279058.3cd0391210692@webmail.midco.net> <1020279323.28928.67.camel@jen.americas.sgi.com> In-Reply-To: <1020279323.28928.67.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk xfs_repair reports nothing. What if I were to dump the fs, rebuild the partition, and restore the dump? I've tried about everything else... Quoting Steve Lord : > Ugh, try xfs_check on the unmounted device, it will look at different > things. Those numbers look way out of bounds. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Wed May 1 13:22:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41KMJwJ002606 for ; Wed, 1 May 2002 13:22:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41KMJQs002605 for linux-xfs-outgoing; Wed, 1 May 2002 13:22:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41KMEwJ002578 for ; Wed, 1 May 2002 13:22:14 -0700 Received: (qmail 32356 invoked by uid 0); 1 May 2002 20:23:01 -0000 Received: from b1ef2.pppool.de (HELO gmx.de) (213.7.30.242) by mail.gmx.net (mp013-rz3) with SMTP; 1 May 2002 20:23:01 -0000 Message-ID: <3CD04E86.D6B0C21@gmx.de> Date: Wed, 01 May 2002 22:22:30 +0200 From: Martin Stricker Organization: http://martin-stricker.de/ http://www.surfo.net/ http://www.masterportal24.com/cgi-bin/YaBB.cgi X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Free space question References: <1020268400.3cd00f70a6d51@webmail.midco.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk bren@sio.midco.net wrote: > df reports over 200MB free space, yet I cannot create a file as it > reports "touch: file: No space left on device." Here is what df > reports (I had to remount the queue under /mnt): I'm not sure about XFS, but with ext2 mke2fs defaults to leaving 5% of the disk reserved to root. This is absolutely necessary on the / partition to allow root to log in even when some luser filled the / filesystem. Maybe something similar is true for XFS? Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Webmaster-Forum: http://www.masterportal24.com/cgi-bin/YaBB.cgi Red Hat Linux 7.2 for low memory: http://www.rule-project.org/rule/ Registered Linux user #210635: http://counter.li.org/ From owner-linux-xfs@oss.sgi.com Wed May 1 13:25:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41KPgwJ002780 for ; Wed, 1 May 2002 13:25:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41KPgbs002779 for linux-xfs-outgoing; Wed, 1 May 2002 13:25:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41KPcwJ002753 for ; Wed, 1 May 2002 13:25:38 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA26251; Wed, 1 May 2002 15:26:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA46243; Wed, 1 May 2002 15:26:29 -0500 (CDT) Subject: Re: Free space question From: Eric Sandeen To: Martin Stricker Cc: linux-xfs@oss.sgi.com In-Reply-To: <3CD04E86.D6B0C21@gmx.de> References: <1020268400.3cd00f70a6d51@webmail.midco.net> <3CD04E86.D6B0C21@gmx.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 May 2002 15:26:29 -0500 Message-Id: <1020284790.1266.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Martin - Nope, no such thing on xfs. -Eric On Wed, 2002-05-01 at 15:22, Martin Stricker wrote: > I'm not sure about XFS, but with ext2 mke2fs defaults to leaving 5% of > the disk reserved to root. This is absolutely necessary on the / > partition to allow root to log in even when some luser filled the / > filesystem. Maybe something similar is true for XFS? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 1 14:37:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41LbcwJ019886 for ; Wed, 1 May 2002 14:37:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Lbc2b019885 for linux-xfs-outgoing; Wed, 1 May 2002 14:37:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41LbXwJ019859 for ; Wed, 1 May 2002 14:37:34 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g41LcTb2093992; Wed, 1 May 2002 23:38:30 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA17239; Wed, 1 May 2002 23:38:29 +0200 (CEST) Date: Wed, 1 May 2002 23:38:29 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: , Subject: Re: Free space question In-Reply-To: <1020275216.1266.17.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 1 May 2002, Eric Sandeen wrote: > Just for kicks you could try using xfs_growfs to bump the inode maxpct a > bit, although from df -i I don't think that's the problem... Do you happen to know if maxpct inodes is based upon size of the fs or just a constant? 12 could be interpreted as 12.5% which would be exactly half. And that sounds fishy to me. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed May 1 14:50:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41Lo1wJ020139 for ; Wed, 1 May 2002 14:50:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41Lo1U5020138 for linux-xfs-outgoing; Wed, 1 May 2002 14:50:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41LnuwJ020106 for ; Wed, 1 May 2002 14:49:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA43757; Wed, 1 May 2002 16:50:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA70878; Wed, 1 May 2002 16:50:48 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g41LnlG25741; Wed, 1 May 2002 16:49:47 -0500 Subject: Re: Free space question From: Steve Lord To: Seth Mos Cc: Eric Sandeen , bren@sio.midco.net, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 16:49:47 -0500 Message-Id: <1020289787.25315.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 16:38, Seth Mos wrote: > On 1 May 2002, Eric Sandeen wrote: > > > Just for kicks you could try using xfs_growfs to bump the inode maxpct a > > bit, although from df -i I don't think that's the problem... > > Do you happen to know if maxpct inodes is based upon size of the fs or > just a constant? > 12 could be interpreted as 12.5% which would be exactly half. > > And that sounds fishy to me. The maximum inode percentage defaults to 20 or 25% of the disk space as inodes. So the maximum number of inodes you see in df -i is a function of the size of the filesystem. It is possible to run out of inode space before this percentage has been reached - inodes are allocated in 8K chunks, there may not be space for another 8K chunk. That does not appear to be the case here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 1 16:36:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41NaVwJ025187 for ; Wed, 1 May 2002 16:36:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41NaVLT025186 for linux-xfs-outgoing; Wed, 1 May 2002 16:36:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from C9Mailgw01.amadis.com (c9mailgw.ctmail.com [216.163.188.200] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41NaPwJ025159 for ; Wed, 1 May 2002 16:36:25 -0700 Received: from c9service11.amadis.com (10.9.0.1) id 3CBB7E64001D90F1 for linux-xfs@oss.sgi.com; Wed, 1 May 2002 16:34:16 -0700 Received: from cnode8 (148.64.21.114) by c9service11.amadis.com (NPlex 6.5.012) id 3CB463C400032260 for linux-xfs@oss.sgi.com; Wed, 1 May 2002 16:34:16 -0700 Date: Wed, 1 May 2002 19:36:23 -0400 From: Jason Giglio To: linux-xfs@oss.sgi.com Subject: Loss of file system after lockup Message-Id: <20020501193623.145b41f8.jgiglio@netmar.com> X-Mailer: Sylpheed version 0.6.3 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On a server that I recently constructed, the file system became corrupt twice and I had to abandon XFS on it. During file write operations, the system would completely lock up, requiring a reboot, and upon rebooting the XFS file system could not be mounted. Dmesg output: XFS mounting filesystem sd(8,1) Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS: bad magic number XFS: SB validate failed xfs_check came up with tons of errors, xfs_repair could not repair without a force, and I could not afford the time required to revalidate all the files that had been written, so I just started over with EXT2 instead. I don't have the option to continue testing XFS on this system, I was under pressure to ship it. XFS did this twice, a lockup, then loss of file system on reset. The filesystem was about 980GB, /dev/sda1, /dev/sda is a 3ware 8 port RAID card. System is Tyan Tiger MP dual Athlon MP with noapic and nopentium options. Distro is RH 7.2, XFS CVS kernel 2.4.18. mkfs was: mkfs.xfs -b size=4096 -d agsize=1048575b,su=64k,sw=7 -i maxpct=5 -f /dev/sda1 The reason for the strange mkfs.xfs options is because without them, mkfs.xfs creates an invalid XFS file system. It will create one too many ag's, which leaves the last ag with no blocks. Apparently telling it bogus agsizes causes it to round correctly. Please CC: me personally on replies, as I don't subscribe to the list. I will however CC: the list any replies to replies. From owner-linux-xfs@oss.sgi.com Wed May 1 17:59:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g420xswJ030920 for ; Wed, 1 May 2002 17:59:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g420xsIF030919 for linux-xfs-outgoing; Wed, 1 May 2002 17:59:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g420xlwJ030893 for ; Wed, 1 May 2002 17:59:47 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA2745660 for ; Wed, 1 May 2002 18:00:39 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA53057; Thu, 2 May 2002 10:59:17 +1000 (AEST) Date: Thu, 2 May 2002 10:59:17 +1000 From: Timothy Shimmin To: Andreas Gruenbacher Cc: jtrostel@snapserver.com, linux-xfs@oss.sgi.com Subject: Re: Query about setfacl behavior Message-ID: <20020502105917.T793932@boing.melbourne.sgi.com> References: <20020501191158.R793932@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from ag@bestbits.at on Wed, May 01, 2002 at 12:44:39PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Andreas, On Wed, May 01, 2002 at 12:44:39PM +0200, Andreas Gruenbacher wrote: > On Wed, 1 May 2002, Timothy Shimmin wrote: > > > > > setfacl is about to set the acl with a mask ACE of m::rw- > > even though the mask ACE is currently m::---. > > It seems that setfacl(1) is looking at the GROUP_OBJ ace and > > setting the mask ACE to this ! > > > > In XFS, if we have a mask ACE then it is kept in sync with the > > group permissions (as per the standard), > > but the GROUP_OBJ ACE is left unaltered. > > So setfacl(1) is sync'ing the mask ACE with the GROUP_OBJ ACE > > and we are in trouble. > > The question is, why is setfacl(1) doing this ? > > Because this is what setfacl is supposed to do accorindg to the > specification. > > Unless the -n option is not used, setfacl recalculates the permissions in I think you mean "unless the -n option is used" > the ACL mask entry whenever the ACL changes, as long as no mask entry is > explicitly given. The permissions are set to the union of the permissions > of all ACL_USER, ACL_GROUP_OBJ, and ACL_GROUP entries. This gives: > This ACL stuff is weird. Looking at the std (1003.2c sect.8.2.7) it says: "For both the -m and -M options, ... If no mask entry is specified and the -n option is not specified then the permissions of the resulting ACL mask entry shall be set to the union of the permissions associated with all entries which belong to the file group class in the resulting ACL ..." So is ACL_USER part of the file group class (noting what you said above) ? What is the definition of "entries which belong to the file group class" ? --Tim From owner-linux-xfs@oss.sgi.com Wed May 1 19:54:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g422sgwJ031791 for ; Wed, 1 May 2002 19:54:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g422sgdg031790 for linux-xfs-outgoing; Wed, 1 May 2002 19:54:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from reefedge.reefedge.com (reefedge.com [216.10.14.212]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g422sawJ031764 for ; Wed, 1 May 2002 19:54:36 -0700 Received: from pla-muek.reefedge.com (mocha.reefedge.com [64.50.29.181]) by reefedge.reefedge.com (8.12.1/8.12.1) with ESMTP id g422oP3u006716 for ; Wed, 1 May 2002 22:50:25 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g422tYI20529 for linux-xfs@oss.sgi.com; Wed, 1 May 2002 22:55:34 -0400 (EDT) Date: Wed, 1 May 2002 22:55:34 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: Re: Free space question Message-ID: <20020501225534.A20522@pla-muek.reefedge.com> References: <1020273839.3cd024af9c1aa@webmail.midco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020273839.3cd024af9c1aa@webmail.midco.net>; from bren@sio.midco.net on Wed, May 01, 2002 at 12:23:59PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 01, 2002 at 12:23:59PM -0500, bren@sio.midco.net wrote: > Ok. I've upgraded to 2.4.18 with XFS 1.1. Same results... > > df -i reports: > > /dev/scsi/host0/bus0/target0/lun0/part5 > 952000 117248 834752 12% /mnt > > df -h: > > /dev/scsi/host0/bus0/target0/lun0/part5 > 948M 745M 204M 79% /mnt > > Yet simply touching a new file returns: > > touch: file: No space left on device This is quite a common problem with XFS filesystems in academic fileserver applications. What's probably going on here is that you have enough fragmentation that XFS cannot find a 64K extent to allocate for inodes. Back when it wasn't safe to use xfs_fsr on Irix (it had a nasty habit of eating files with lseek holes, among other ugliness) we used to have to regularly dump, recreate, and restore the student home directories at the university where I worked, in order to get around this. Have a look at xfs_db -c freesp and see if you've got any extents 64K or larger left free. If you don't, you won't be able to create files once you've used up all the inodes in the extents already thus allocated. However, if you can find a little bit of stuff to delete so fsr can do its thing, it will probably solve your problem for you. Thor From owner-linux-xfs@oss.sgi.com Wed May 1 20:22:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g423MDwJ032106 for ; Wed, 1 May 2002 20:22:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g423MDae032105 for linux-xfs-outgoing; Wed, 1 May 2002 20:22:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g423M6wJ032079 for ; Wed, 1 May 2002 20:22:07 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA45404; Wed, 1 May 2002 22:23:00 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-11.corp.sgi.com [134.15.64.11]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id WAA72701; Wed, 1 May 2002 22:22:59 -0500 (CDT) Subject: Re: Free space question From: Stephen Lord To: Thor Lancelot Simon Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020501225534.A20522@pla-muek.reefedge.com> References: <1020273839.3cd024af9c1aa@webmail.midco.net> <20020501225534.A20522@pla-muek.reefedge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 01 May 2002 22:14:37 -0500 Message-Id: <1020309278.8096.24.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-01 at 21:55, Thor Lancelot Simon wrote: > > This is quite a common problem with XFS filesystems in academic > fileserver applications. What's probably going on here is that > you have enough fragmentation that XFS cannot find a 64K extent to > allocate for inodes. Back when it wasn't safe to use xfs_fsr on > Irix (it had a nasty habit of eating files with lseek holes, among > other ugliness) we used to have to regularly dump, recreate, and > restore the student home directories at the university where I > worked, in order to get around this. > > Have a look at xfs_db -c freesp and see if you've got any extents > 64K or larger left free. If you don't, you won't be able to create > files once you've used up all the inodes in the extents already thus > allocated. However, if you can find a little bit of stuff to delete > so fsr can do its thing, it will probably solve your problem for you. > > Thor Just to correct this - XFS does not allocate inodes in 64K chunks, for filesystems with block sizes less than 8K it uses 8K for each inode cluster, for larger block sizes it uses one filesystem block. On ia32 linux we are currently limited to 4K filesystem blocks, so inodes are allocated in 8K chunks. We have seen filesystems get into the state where there is no room for another inode cluster, but it is not something we in the SGI filesystem group have seen very often. Steve From owner-linux-xfs@oss.sgi.com Wed May 1 23:05:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4265CwJ000667 for ; Wed, 1 May 2002 23:05:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4265CTQ000666 for linux-xfs-outgoing; Wed, 1 May 2002 23:05:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42650wJ000608 for ; Wed, 1 May 2002 23:05:02 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g4265b428362; Thu, 2 May 2002 08:05:38 +0200 Date: Thu, 2 May 2002 08:05:37 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Timothy Shimmin cc: , Subject: Re: Query about setfacl behavior In-Reply-To: <20020502105917.T793932@boing.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 May 2002, Timothy Shimmin wrote: > Hi Andreas, > > On Wed, May 01, 2002 at 12:44:39PM +0200, Andreas Gruenbacher wrote: > > On Wed, 1 May 2002, Timothy Shimmin wrote: > > > > > > > > setfacl is about to set the acl with a mask ACE of m::rw- > > > even though the mask ACE is currently m::---. > > > It seems that setfacl(1) is looking at the GROUP_OBJ ace and > > > setting the mask ACE to this ! > > > > > > In XFS, if we have a mask ACE then it is kept in sync with the > > > group permissions (as per the standard), > > > but the GROUP_OBJ ACE is left unaltered. > > > So setfacl(1) is sync'ing the mask ACE with the GROUP_OBJ ACE > > > and we are in trouble. > > > The question is, why is setfacl(1) doing this ? > > > > Because this is what setfacl is supposed to do according to the > > specification. > > > > Unless the -n option is not used, setfacl recalculates the permissions in > I think you mean "unless the -n option is used" Yes. > > the ACL mask entry whenever the ACL changes, as long as no mask entry is > > explicitly given. The permissions are set to the union of the permissions > > of all ACL_USER, ACL_GROUP_OBJ, and ACL_GROUP entries. This gives: > > > This ACL stuff is weird. > Looking at the std (1003.2c sect.8.2.7) it says: > "For both the -m and -M options, ... > If no mask entry is specified and the -n option is not specified > then the permissions of the resulting ACL mask entry shall be set > to the union of the permissions associated with all entries > which belong to the file group class in the resulting ACL ..." > So is ACL_USER part of the file group class (noting what you said above) ? > What is the definition of "entries which belong to the file group class" ? The changes to the interpretation of the file group class concept is explained in Section 2.2.2.28. The file group class contains all entries which are affected by the mask entry. These are the entries of type ACL_USER, ACL_GROUP_OBJ, and ACL_GROUP, as was said before. The ACL specification is a bit complex because it tries to be as compatible with traditional POSIX systems as possible. --Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Thu May 2 00:07:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42779wJ001250 for ; Thu, 2 May 2002 00:07:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42779UU001249 for linux-xfs-outgoing; Thu, 2 May 2002 00:07:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from netsgo.com ([211.39.34.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4276lwJ001219 for ; Thu, 2 May 2002 00:06:48 -0700 Received: from unknown[210.93.208.137] (envelope sender: ) by 211.39.34.131 (TERRACE MAILCENTER) with ESMTP for ; Thu, 02 May 2002 16:06:59 KST +0900 Message-ID: <000001c1f1a8$0a4fb480$89d05dd2@netsgo.com> From: "Heejoon Park" To: Subject: Cannot see pdf or ps files Date: Tue, 30 Apr 2002 20:51:55 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g42779wJ001251 Hello, I cannot see any pdf or ps files in http://oss.sgi.com/projects/xfs page. I got the following error. I'd appreciated if you can fix it. -------------------> Mason error error in file: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf line 13: '<%' with no matching '%>' context: ... 9: H‰ŒV?£H}??bÍÕ‰ve?)ì¾8?Cc??º‰×û??Ûë¬V??rêÔ©‚ûÒ??‚²?/font> 10: ñ¯€œAž†A–C?!¬½ÛÇ??ïËšþí¼?,:Q+ CµÝˆZÃïÃŒ?÷Õv???~ó¾–èðè1??@???~åk?/MBH?LŽ×?öî?D 2F€?–À??:wu͵žÍ?dIú¿ÕF??D‹E<›³8 11: ºÛp|:@%O ??E["‰kh?"ŽN?@½×†÷'I Wg]ut?wA¹Áxª?K ×õ VX???GUáí?Ï»q?µYÏ»C ?/font> 12: t?u??ˆS?$¡±.õ¦’k?œž?Ç®??äµ9eÕéS)à &1°S1„“?Q-zò«??JT?Ke&?6?~??†KM%’·"1YµäŠJ?1|F²Õ???c „Õ?vŸt?W2;‰Ÿ‘µ©Þ)? ?¼ê€z¶½q?¶˜???z:J?·ž?æñ"™–??gÿ‡F?9KB?B?ª œåiPøû-Æø|›ÄYA¡æM\úè?³Ðÿ_ûÄ ³U???Cy??uxmj:N?äí æê¯q[\e…–??©jÕ¶YòÝ8ëôÄúDl?Ñ©v-????l°JcIŒu 13: ‹ ?NhÜ­qO»4q à½?;ÞíØÙÚô–×ÂUt.Q‡¤??çÓŠÈ?™ù?F?ÕâoŒk?", ÇÊd?RN?r?n?m³©(!?l?¤© ¨/>{?«it??j??x??ôÍ8??N{?O?1gù¤ýð¨½Ô¿??DÁYxŒE<%þ±aâø¢´â¥???Ì»$?f?.b”ó???­zZ?âªH]0m??6/¢boh¼G?’µ§Ûª‰f?lt;Ãc?l–ñ? 14: Ýã4Ew¼¿p?ƒx?–úôãâ\vB¾¡Ašçh`]XŒ¢9ÆÇ?ÓõÉé?j¿Ä?,?0/ ?/?}s-?wÿÅûG€<â´ 15: endstream 16: endobj 17: 3 0 obj ... code stack: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf:13 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm:374 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm:116 raw_error raw error: Error during compilation of /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf: '' (line 13) HTML::Mason::Interp::__ANON__('Error during compilation of /oss/www/projects/xfs/design_docs/xf...') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 418 HTML::Mason::Interp::_compilation_error('HTML::Mason::Interp=HASH(0x80e6c04)', '/oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf', '\'\' (line 13)^J') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 374 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x80e6c04)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)', 'HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x8539ff0)') called at /dev/null line 0 eval {...} called at /dev/null line 0 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu May 2 03:11:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42ABhwJ003764 for ; Thu, 2 May 2002 03:11:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42ABhZK003763 for linux-xfs-outgoing; Thu, 2 May 2002 03:11:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ev6.be.wanadoo.com (ev6.be.wanadoo.com [195.74.212.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42ABZwJ003735 for ; Thu, 2 May 2002 03:11:36 -0700 Received: from Gehirn (adsl-130-117.wanadoo.be [213.177.130.117]) by ev6.be.wanadoo.com (8.11.1/8.11.1) with SMTP id g42ACKP09979 for ; Thu, 2 May 2002 12:12:20 +0200 Message-ID: <006b01c1f1c1$ddba97e0$4332a8c0@Gehirn> From: "Jean-Luc Gason" To: Subject: Problem Installing XFS support into my kernel.... Date: Thu, 2 May 2002 12:12:28 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-DCC-wanadoo-be-Metrics: ev6 1016; IP=0 env_From=0 From=0 Subject=0 Message-ID=0 Body=1 Fuz1=1 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Well, before going on, I apologize asking perhaps a dumb question, but I'm not realy a programmer, i'm a compositing artist who has to implement XFS support into his linux workstation to be hable to share a fiberchannel raid with octanes.... I'm going to do you a quick history of my attempt to compile XFS support into my kernel. First i'm on RedHat 7.2 distro with a 2.4.18-0.13 beta kernel. I've a Qlogic QLA2200 fiber HBA with v6 beta of the drivers. On this is a Vixel fiber switch where a Raidtec SAN is connected. I've downloaded via CVS the sources of XFS for Linux (following the TLDP HowTo) Added into my already tweaked version of kernel source (tweaked to add support for QLA2200v6) of 2.4.18 the "/fs/xfs"," /fs/xfs_dmapi","/fs/xfs_support" directories to my kernel sources, as well as the "/fs/xattr.c" and the "/include/linux/xfs_support" directory and the "/include/linux/xattr.h", "xfs_fs.h", "xfs_fs_i.h", "xfs_fs_sb.h" and "behavior.h". Then i copy-pasted the SGI XFS lines from Makefile and Config.in run make menuconfig, made XFS support and all his modules compiled into kernel ( [*] ), run make dep, when ok, run make bzImage modules modules_install when ok (at least, went to the end without error i saw), mkinitrd initrd_xfs_qla_support.img 2.4.18-0.13, copied the bzimage and initrd into /boot, append my grub.conf, boot, everything work fine execpt that when it comes to mount my XFS fiberarray, it says me fs type xfs not supported by kernel.... I don't understand, i followed the howto, got no compilation error, verified again if in menuconfig everything was selected [*], and it was.... Can someone help me please? (and remember that i'm everything except a programmer... so for me C source are as understable as old babylonian cuneiform language...) Thanks a lot Jean-Luc Gason Main Frame Facilities [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu May 2 04:32:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42BWkwJ004707 for ; Thu, 2 May 2002 04:32:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42BWkvZ004706 for linux-xfs-outgoing; Thu, 2 May 2002 04:32:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42BWewJ004680 for ; Thu, 2 May 2002 04:32:41 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g42BXc022276; Thu, 2 May 2002 07:33:38 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 2 May 2002 07:33:38 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Jean-Luc Gason cc: linux-xfs@oss.sgi.com Subject: Re: Problem Installing XFS support into my kernel.... In-Reply-To: <006b01c1f1c1$ddba97e0$4332a8c0@Gehirn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 May 2002 at 12:12pm, Jean-Luc Gason wrote > Well, before going on, I apologize asking perhaps a dumb question, but > I'm not realy a programmer, i'm a compositing artist who has to > implement XFS support into his linux workstation to be hable to share a > fiberchannel raid with octanes.... > > I'm going to do you a quick history of my attempt to compile XFS > support into my kernel. *tale of woe snipped* Since you're on redhat, why not just use the RPMs? Download the Release 1.1 RPMS, install those (kernel upgrade via RPM instructions are on RedHat's site) and then add the FC support to the running kernel. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu May 2 04:42:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42BgBwJ004938 for ; Thu, 2 May 2002 04:42:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42BgACl004937 for linux-xfs-outgoing; Thu, 2 May 2002 04:42:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ev6.be.wanadoo.com (ev6.be.wanadoo.com [195.74.212.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42Bg6wJ004911 for ; Thu, 2 May 2002 04:42:06 -0700 Received: from Gehirn (adsl-130-117.wanadoo.be [213.177.130.117]) by ev6.be.wanadoo.com (8.11.1/8.11.1) with SMTP id g42BgoP11606 for ; Thu, 2 May 2002 13:42:51 +0200 Message-ID: <00ac01c1f1ce$832f80d0$4332a8c0@Gehirn> From: "Jean-Luc Gason" To: References: Subject: Re: Problem Installing XFS support into my kernel.... Date: Thu, 2 May 2002 13:43:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-DCC-wanadoo-be-Metrics: ev6 1016; IP=0 env_From=0 From=0 Subject=0 Message-ID=0 Body=1 Fuz1=1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Joshua Baker-LePain" To: "Jean-Luc Gason" Cc: Sent: Thursday, May 02, 2002 1:33 PM Subject: Re: Problem Installing XFS support into my kernel.... > Since you're on redhat, why not just use the RPMs? Download the Release > 1.1 RPMS, install those (kernel upgrade via RPM instructions are on > RedHat's site) and then add the FC support to the running kernel. Well, I tryed, but the problem was the same so I though about doing "the hard way"... Jean-Luc Gason From owner-linux-xfs@oss.sgi.com Thu May 2 05:34:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42CYLwJ005501 for ; Thu, 2 May 2002 05:34:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42CYLNZ005500 for linux-xfs-outgoing; Thu, 2 May 2002 05:34:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42CYHwJ005474 for ; Thu, 2 May 2002 05:34:17 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA52444; Thu, 2 May 2002 07:35:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA03255; Thu, 2 May 2002 07:35:12 -0500 (CDT) Date: Thu, 2 May 2002 07:35:11 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Heejoon Park cc: linux-xfs@oss.sgi.com Subject: Re: Cannot see pdf or ps files In-Reply-To: <000001c1f1a8$0a4fb480$89d05dd2@netsgo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We fixed this yesterday; it works for me now. Are you still having trouble? -Eric On Tue, 30 Apr 2002, Heejoon Park wrote: > Hello, I cannot see any pdf or ps files in http://oss.sgi.com/projects/xfs page. > > I got the following error. > I'd appreciated if you can fix it. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu May 2 05:45:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42CjewJ005731 for ; Thu, 2 May 2002 05:45:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42Cjeku005730 for linux-xfs-outgoing; Thu, 2 May 2002 05:45:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42CjXwJ005704 for ; Thu, 2 May 2002 05:45:34 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA54072; Thu, 2 May 2002 07:46:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA68896; Thu, 2 May 2002 07:46:28 -0500 (CDT) Date: Thu, 2 May 2002 07:46:28 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jean-Luc Gason cc: linux-xfs@oss.sgi.com Subject: Re: Problem Installing XFS support into my kernel.... In-Reply-To: <00ac01c1f1ce$832f80d0$4332a8c0@Gehirn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So you booted the 1.1 rpms (verified by "uname -r" showing 2.4.9-31SGI_XFS_1.1)? If you get that result after booting the RPM kernel, you have xfs support. If not, please see http://oss.sgi.com/projects/xfs/102_rpm.html for instructions on installing and booting from the RPM packages. Then, if you are trying to mount filesystems from IRIX, please see http://oss.sgi.com/projects/xfs/faq.html#useirixdisks for caveats and limitations when doing this. In particular, your filesystem block size on the IRIX filesystem must be 4k, currently. This requirement will (hopefully) be going away fairly soon. By the way, the reason your source compiled kernel didn't work is that it sounds like you picked bits and pieces of the XFS source tree and copied it into a standard tree; that won't work. If you ever do want to compile it from the source, please see http://oss.sgi.com/projects/xfs/source.html Good luck, -Eric On Thu, 2 May 2002, Jean-Luc Gason wrote: > > Since you're on redhat, why not just use the RPMs? Download the Release > > 1.1 RPMS, install those (kernel upgrade via RPM instructions are on > > RedHat's site) and then add the FC support to the running kernel. > > Well, I tryed, but the problem was the same so I though about doing "the > hard way"... > > Jean-Luc Gason > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu May 2 08:42:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42Fg3wJ008808 for ; Thu, 2 May 2002 08:42:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42Fg3D6008807 for linux-xfs-outgoing; Thu, 2 May 2002 08:42:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from messageii.ucentric.com ([63.164.206.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42FfwwJ008780 for ; Thu, 2 May 2002 08:41:59 -0700 Received: from ucentric.com (unverified) by messageii.ucentric.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 11:42:54 -0400 Message-ID: <3CD15E4B.DC8E8BAE@ucentric.com> Date: Thu, 02 May 2002 11:42:03 -0400 From: Mike Keefe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-xfs-1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Suggested memory size Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I noticed that the Technical Specifications for XFS specified that at least 64 MB of memory is suggested for a Linux-based XFS system. What I'd like to know is: what is the smallest memory configuration that Linux XFS has been installed on and run successfully ? Do you even see it as being feasible to run on a signle processor embedded system with 16 MB of main memory ? Mike Keefe From owner-linux-xfs@oss.sgi.com Thu May 2 09:04:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42G4ZwJ009231 for ; Thu, 2 May 2002 09:04:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42G4Zh8009230 for linux-xfs-outgoing; Thu, 2 May 2002 09:04:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42G4TwJ009204 for ; Thu, 2 May 2002 09:04:30 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g42G5T83031115; Thu, 2 May 2002 18:05:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA11023; Thu, 2 May 2002 18:05:29 +0200 (CEST) Date: Thu, 2 May 2002 18:05:29 +0200 (CEST) From: Seth Mos To: Mike Keefe cc: Subject: Re: Suggested memory size In-Reply-To: <3CD15E4B.DC8E8BAE@ucentric.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 May 2002, Mike Keefe wrote: > Hello, > I noticed that the Technical Specifications for XFS specified > that at least 64 MB of memory is suggested for a Linux-based > XFS system. What I'd like to know is: what is the smallest memory > configuration that Linux XFS has been installed on and run > successfully ? 12MB > Do you even see it as being feasible to run on a signle processor > embedded > system with 16 MB of main memory ? Others already are. Performance won't be stellar but it will do just fine. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu May 2 09:09:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42G9AwJ009493 for ; Thu, 2 May 2002 09:09:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42G99vA009492 for linux-xfs-outgoing; Thu, 2 May 2002 09:09:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42G94wJ009466 for ; Thu, 2 May 2002 09:09:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA55866; Thu, 2 May 2002 11:09:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA80744; Thu, 2 May 2002 11:09:59 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g42G8ou07419; Thu, 2 May 2002 11:08:50 -0500 Subject: Re: Suggested memory size From: Steve Lord To: Seth Mos Cc: Mike Keefe , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 02 May 2002 11:08:50 -0500 Message-Id: <1020355730.652.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-02 at 11:05, Seth Mos wrote: > On Thu, 2 May 2002, Mike Keefe wrote: > > > Hello, > > I noticed that the Technical Specifications for XFS specified > > that at least 64 MB of memory is suggested for a Linux-based > > XFS system. What I'd like to know is: what is the smallest memory > > configuration that Linux XFS has been installed on and run > > successfully ? > > 12MB > > > Do you even see it as being feasible to run on a signle processor > > embedded > > system with 16 MB of main memory ? > > Others already are. Performance won't be stellar but it will do just > fine. There used to be some issues with filesystem recovery using a lot of memory, these should be gone now. I would not recommend 16M if you are looking for streaming data on or off the filesystem, other than that is should not be a problem. Steve > > Cheers > Seth -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu May 2 09:26:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42GQ5wJ009749 for ; Thu, 2 May 2002 09:26:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42GQ5g4009748 for linux-xfs-outgoing; Thu, 2 May 2002 09:26:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.tvol.net (HIDDEN-USER@[66.150.46.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42GPpwJ009720 for ; Thu, 2 May 2002 09:25:52 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCKWL6; Thu, 2 May 2002 12:24:03 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g42GQqH94130; Thu, 2 May 2002 12:26:52 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CD168CC.19370010@wgate.com> Date: Thu, 02 May 2002 12:26:52 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Keefe CC: linux-xfs@oss.sgi.com Subject: Re: Suggested memory size References: <3CD15E4B.DC8E8BAE@ucentric.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Keefe wrote: > > Hello, > I noticed that the Technical Specifications for XFS specified > that at least 64 MB of memory is suggested for a Linux-based > XFS system. What I'd like to know is: what is the smallest memory > configuration that Linux XFS has been installed on and run > successfully ? I have one test system I use that is running 2.4.18-xfs from the SGI tree and the machine has only a total of 24Meg of RAM. Not only does this system run that filesystem, it also builds its own kernel (and some other stuff) This is a 486-DX/4-100 laptop of many, many years ago. BTW - Switching to XFS from EXT2 on that laptop actually made the kernel compile slightly faster (for the exact same kernel and options) Amazing as I did not expect that on a system with such limited resources. > Do you even see it as being feasible to run on a signle processor > embedded > system with 16 MB of main memory ? I don't know, depends on what other stuff you want to run in the background. Note that XFS itself really does not make sense for small disk drives. (I once put it on a 32meg CF drive just to test it, not a good idea given the amount of space you loose) This is the output of top on that machine - it happens to have a top running on the console too... Note the amount of cache in the system is reasonably high. I am also running FBCon (800x600) on the console and that is taking some RAM away too. PCMCIA ethernet and a kernel with lots of features compiled in add to the amount of overhead. I can say that I don't have ext2 compiled in as this machine has no physical access to other drives (not even a floppy) 12:22pm up 3 days, 21:59, 1 user, load average: 0.09, 0.04, 0.00 47 processes: 46 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 5.3% user, 3.9% system, 0.0% nice, 90.6% idle Mem: 21864K av, 21172K used, 692K free, 0K shrd, 0K buff Swap: 529192K av, 5576K used, 523616K free 14276K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 838 root 13 0 548 480 480 S 3.9 2.1 206:07 top 7683 root 14 0 1036 1036 828 R 3.7 4.7 0:00 top 7660 root 10 0 2020 1984 1420 S 1.7 9.0 0:01 sshd 1 root 8 0 128 84 84 S 0.0 0.3 0:04 init 2 root 8 0 0 0 0 SW 0.0 0.0 0:00 keventd 3 root 9 0 0 0 0 SW 0.0 0.0 0:01 kapmd 4 root 19 19 0 0 0 SWN 0.0 0.0 0:16 ksoftirqd_CPU0 5 root 9 0 0 0 0 SW 0.0 0.0 3:45 kswapd 6 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush 7 root 9 0 0 0 0 SW 0.0 0.0 0:42 kupdated 8 root 9 0 0 0 0 SW 0.0 0.0 0:10 pagebuf_daemon 393 root 9 0 344 288 288 S 0.0 1.3 0:09 syslogd 398 root 9 0 332 200 200 S 0.0 0.9 0:00 klogd 418 rpc 9 0 284 192 192 S 0.0 0.8 0:00 portmap 530 ntp 9 0 1892 1892 1708 S 0.0 8.6 0:02 ntpd 554 root 8 0 168 4 4 S 0.0 0.0 0:00 cardmgr 592 root 9 0 424 312 280 S 0.0 1.4 0:31 sshd 653 root 9 0 88 4 4 S 0.0 0.0 0:00 rpc.rquotad 666 root 9 0 96 8 8 S 0.0 0.0 0:00 rpc.mountd 672 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 673 root 9 0 0 0 0 SW 0.0 0.0 0:00 lockd 674 root 9 0 0 0 0 SW 0.0 0.0 0:00 rpciod 675 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 676 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 677 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 678 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 679 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 680 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 681 root 9 0 0 0 0 SW 0.0 0.0 0:01 nfsd 747 root 9 0 852 352 300 S 0.0 1.6 0:02 sendmail 766 root 9 0 68 4 4 S 0.0 0.0 0:00 gpm 784 root 8 0 180 116 92 S 0.0 0.5 0:01 crond 820 daemon 9 0 112 52 52 S 0.0 0.2 0:00 atd 827 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 828 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 829 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 830 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 831 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 832 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 835 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 836 root 9 0 64 4 4 S 0.0 0.0 0:00 mingetty 837 root 9 0 80 20 20 S 0.0 0.0 0:00 mingetty 3024 root 9 0 112 4 4 S 0.0 0.0 0:00 crond 6198 root 9 0 116 8 8 S 0.0 0.0 0:00 crond 7662 root 9 0 1680 1680 888 S 0.0 7.6 0:01 tcsh -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Thu May 2 09:33:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42GXmwJ009983 for ; Thu, 2 May 2002 09:33:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42GXmIQ009982 for linux-xfs-outgoing; Thu, 2 May 2002 09:33:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from messageii.ucentric.com ([63.164.206.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42GXfwJ009955 for ; Thu, 2 May 2002 09:33:41 -0700 Received: from ucentric.com (unverified) by messageii.ucentric.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 12:34:37 -0400 Message-ID: <3CD16A69.B166CACC@ucentric.com> Date: Thu, 02 May 2002 12:33:45 -0400 From: Mike Keefe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-xfs-1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Suggested memory size References: <1020355730.652.1.camel@jen.americas.sgi.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > On Thu, 2002-05-02 at 11:05, Seth Mos wrote: > > On Thu, 2 May 2002, Mike Keefe wrote: > > > > > Hello, > > > I noticed that the Technical Specifications for XFS specified > > > that at least 64 MB of memory is suggested for a Linux-based > > > XFS system. What I'd like to know is: what is the smallest memory > > > configuration that Linux XFS has been installed on and run > > > successfully ? > > > > 12MB > > > > > Do you even see it as being feasible to run on a signle processor > > > embedded > > > system with 16 MB of main memory ? > > > > Others already are. Performance won't be stellar but it will do just > > fine. > > There used to be some issues with filesystem recovery using a lot of > memory, these should be gone now. I would not recommend 16M if you > are looking for streaming data on or off the filesystem, other than > that is should not be a problem. > > Steve > > > > > Cheers > > Seth > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com ====================================================== What if you were using direct i/o (O_DIRECT) to stream data from a 16M system ? Would that still be as much of an issue - would the same performance considerations still hold ? Thanks, Mike Keefe From owner-linux-xfs@oss.sgi.com Thu May 2 09:37:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42Gb7wJ010148 for ; Thu, 2 May 2002 09:37:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42Gb7B4010147 for linux-xfs-outgoing; Thu, 2 May 2002 09:37:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42Gb2wJ010099 for ; Thu, 2 May 2002 09:37:03 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA31998; Thu, 2 May 2002 11:37:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA87530; Thu, 2 May 2002 11:37:58 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g42Gani10313; Thu, 2 May 2002 11:36:49 -0500 Subject: Re: Suggested memory size From: Steve Lord To: Mike Keefe Cc: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <3CD16A69.B166CACC@ucentric.com> References: <1020355730.652.1.camel@jen.americas.sgi.com> <3CD16A69.B166CACC@ucentric.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 02 May 2002 11:36:49 -0500 Message-Id: <1020357409.652.25.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-02 at 11:33, Mike Keefe wrote: > > What if you were using direct i/o (O_DIRECT) to stream data from a 16M > system ? Would that still be as much of an issue - would the same > performance > considerations still hold ? > > Thanks, > Mike Keefe O_DIRECT would be better, memory size should not be the issue then, more can device A and the CPU keep up with device B. I would recommend trying it out on a regular box with this amount of memory (use the boot options to trim it down) and a similar bandwidth for data input and output before you invest a lot of effort into the embedded setup. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu May 2 09:52:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42GqhwJ010643 for ; Thu, 2 May 2002 09:52:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42GqhpP010642 for linux-xfs-outgoing; Thu, 2 May 2002 09:52:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf00bis.bellsouth.net (mail100.mail.bellsouth.net [205.152.58.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42GqcwJ010615 for ; Thu, 2 May 2002 09:52:39 -0700 Received: from taz ([65.81.168.196]) by imf00bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020502165502.BNSV7141.imf00bis.bellsouth.net@taz> for ; Thu, 2 May 2002 12:55:02 -0400 Date: Thu, 2 May 2002 12:47:06 -0400 From: Greg Freemyer Subject: Snapshots To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020502165502.BNSV7141.imf00bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g42GqdwJ010616 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS team, I've just become aware of a problem on another Journaled file-system (it is not a Linux filesystem). With this filesystem, the meta-data can be out of sync during a snapshot operation. If this happens, the snapshot is corrupt and can't be counted on to be a valid backup. They are introducing a new feature for it: "freeze/thaw". The idea is that you issue a freeze prior to taking the snapshot and a thaw after the snapshot is complete. Does XFS have any similar problems, and if so are there fixes in place, or in the pipeline. Note that this was a very occasional problem on the other filesystem, so anecdotal statements of it "works fine for me" may not mean much. Greg Freemyer From owner-linux-xfs@oss.sgi.com Thu May 2 10:06:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42H6iwJ011728 for ; Thu, 2 May 2002 10:06:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42H6iPC011727 for linux-xfs-outgoing; Thu, 2 May 2002 10:06:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42H6dwJ011697 for ; Thu, 2 May 2002 10:06:39 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.3/8.12.3) with ESMTP id g42H7bj5077138; Thu, 2 May 2002 19:07:37 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA05149; Thu, 2 May 2002 19:07:37 +0200 (CEST) Date: Thu, 2 May 2002 19:07:36 +0200 (CEST) From: Seth Mos To: Greg Freemyer cc: Subject: Re: Snapshots In-Reply-To: <20020502165502.BNSV7141.imf00bis.bellsouth.net@taz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2 May 2002, Greg Freemyer wrote: > XFS team, > > I've just become aware of a problem on another Journaled file-system (it is not a Linux filesystem). A NAS device perhaps? > With this filesystem, the meta-data can be out of sync during a snapshot operation. > If this happens, the snapshot is corrupt and can't be counted on to be a valid backup. > They are introducing a new feature for it: "freeze/thaw". > The idea is that you issue a freeze prior to taking the snapshot and a thaw after the snapshot is complete. > Does XFS have any similar problems, and if so are there fixes in place, or in the pipeline. > Note that this was a very occasional problem on the other filesystem, so anecdotal statements of it "works fine for me" may not mean much. AFAIK XFS has a freeze/thaw operation and some others are using it together with LVM to create snapshots of filesystems. I have no idea how heavy this is used out there but we do see the occasional message fly by. You can find more user experiences with respect to snapshots using the mailinglist archive. Maybe others will chime in as well. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu May 2 10:02:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42H2BwJ011570 for ; Thu, 2 May 2002 10:02:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42H2BhX011569 for linux-xfs-outgoing; Thu, 2 May 2002 10:02:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42H25wJ011542 for ; Thu, 2 May 2002 10:02:05 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA52724; Thu, 2 May 2002 12:03:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA23040; Thu, 2 May 2002 12:03:00 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g42H1pu11076; Thu, 2 May 2002 12:01:51 -0500 Subject: Re: Snapshots From: Steve Lord To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020502165502.BNSV7141.imf00bis.bellsouth.net@taz> References: <20020502165502.BNSV7141.imf00bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 02 May 2002 12:01:51 -0500 Message-Id: <1020358911.652.27.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-02 at 11:47, Greg Freemyer wrote: > XFS team, > > I've just become aware of a problem on another Journaled file-system (it is not a Linux filesystem). > > With this filesystem, the meta-data can be out of sync during a snapshot operation. > > If this happens, the snapshot is corrupt and can't be counted on to be a valid backup. > > They are introducing a new feature for it: "freeze/thaw". > > The idea is that you issue a freeze prior to taking the snapshot and a thaw after the snapshot is complete. > > Does XFS have any similar problems, and if so are there fixes in place, or in the pipeline. > > Note that this was a very occasional problem on the other filesystem, so anecdotal statements of it "works fine for me" may not mean much. > > > Greg Freemyer > man xfs_freeze Or if you have the correct LVM patches in place then the kernel does it all for you. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu May 2 10:17:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42HHfwJ012007 for ; Thu, 2 May 2002 10:17:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42HHfBr012006 for linux-xfs-outgoing; Thu, 2 May 2002 10:17:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42HHXwJ011979 for ; Thu, 2 May 2002 10:17:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA53981 for ; Thu, 2 May 2002 12:18:29 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA29617 for ; Thu, 2 May 2002 12:18:29 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g42HITw20937; Thu, 2 May 2002 12:18:29 -0500 Message-Id: <200205021718.g42HITw20937@stout.americas.sgi.com> Date: Thu, 2 May 2002 12:18:29 -0500 Subject: TAKE - Close window on inodes that aren't fully set up Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The various reports of oopses with NFS + xfsdump should be solved with this mod. If xfs_iget created a new linux inode, we would unlock it before we set the inode ops. This wasn't a problem for most cases, but for things like nfs and xfsdump that can just reach in and grab an inode, we had a window of time where inodes were "in the wild" with no ops set; NFS tries to execute these ops without checking first, and it would oops. This mod keeps the inodes locked until the ops have been set. It also rearranges where linvfs_set_inode_ops gets called from; it's gone from most of the linvfs layer now, instead called out of xfs_iget_vnode_init for inodes which are already on-disk, or xfs_ialloc for newly created inodes. Explicit calls to unlock_new_inode are moved as well; it's now done at the bottom of linvfs_set_inode_ops. This _may_ allow us to re-enable the fh_to_dentry/dentry_to_fh methods for nfs; still testing that. Date: Thu May 2 10:13:43 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-iops The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118073a linux/fs/xfs/xfs_vfsops.c - 1.343 - Remove call to linvfs_set_inode_ops, done elsewhere now linux/fs/xfs/xfs_iget.c - 1.153 - Set linux inode ops in xfs_iget_vnode_init if we have the vn_type Remove unlock_new_inode except for error cases linux/fs/xfs/xfs_inode.c - 1.336 - Set linux inode ops in xfs_ialloc for new inodes linux/fs/xfs/linux/xfs_vnode.c - 1.73 - Remove call to linvfs_set_inode_ops, done elsewhere now linux/fs/xfs/linux/xfs_super.c - 1.166 - Remove linvfs_set_inode_ops from linvfs_read_super, done elsewhere now Return immediately from linvfs_set_inode_ops if it's not a new inode Unlock new inode when livnfs_set_inode_ops is finished. linux/fs/xfs/linux/xfs_iops.c - 1.137 linux/fs/xfs/linux/xfs_ioctl.c - 1.58 - Remove call to linvfs_set_inode_ops, done elsewhere now From owner-linux-xfs@oss.sgi.com Thu May 2 10:22:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42HMLwJ012201 for ; Thu, 2 May 2002 10:22:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42HMKpd012200 for linux-xfs-outgoing; Thu, 2 May 2002 10:22:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42HMAwJ012162 for ; Thu, 2 May 2002 10:22:16 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 173KHH-0004k0-00; Thu, 02 May 2002 19:21:59 +0200 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "bren@sio.midco.net" Date: Thu, 02 May 2002 19:21:58 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2475) For Windows 2000 (5.0.2195;2) In-Reply-To: <1020268400.3cd00f70a6d51@webmail.midco.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: "nodiratime" mount option??? (was Re: Free space question Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 1 May 2002 10:53:20 -0500, bren@sio.midco.net wrote: >/dev/sda5 /var/qmail/queue xfs rw,noatime,nodiratime 0 0 This option does not seem to exist, at least according to a grep in xfs.o and to the mount(8) man page. Where did you get that from, and are you sure that your xfs/mount understands it? -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Thu May 2 10:47:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42Hl9wJ012619 for ; Thu, 2 May 2002 10:47:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42Hl90i012618 for linux-xfs-outgoing; Thu, 2 May 2002 10:47:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web1.midco.net (web1.midco.net [24.220.0.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42Hl3wJ012591 for ; Thu, 2 May 2002 10:47:04 -0700 Received: (qmail-ldap/ctrl 13954 invoked by uid 0); 2 May 2002 17:48:04 -0000 Received: from 24.220.8.227 ( [24.220.8.227]) as user bren@sio.midco.net@pop.midco.net by webmail.midco.net with HTTP; Thu, 2 May 2002 12:48:04 -0500 Message-ID: <1020361684.3cd17bd4ae75a@webmail.midco.net> Date: Thu, 2 May 2002 12:48:04 -0500 From: bren@sio.midco.net To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" Subject: Re: "nodiratime" mount option??? (was Re: Free space question References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 24.220.8.227 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The partition mounts cleanly. That option is probably a hold over from the ext2 to xfs switch (this is a mail server). You are right though...I can't find the option in any documentation. Quoting "Ralf G. R. Bergs" : > On Wed, 1 May 2002 10:53:20 -0500, bren@sio.midco.net wrote: > > >/dev/sda5 /var/qmail/queue xfs rw,noatime,nodiratime 0 > 0 > > This option does not seem to exist, at least according to a grep in xfs.o and > to > the mount(8) man page. Where did you get that from, and are you sure that > your > xfs/mount understands it? > > > -- > Sign the EU petition against SPAM: L I N U X .~. > http://www.politik-digital.de/spam/ The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > > > From owner-linux-xfs@oss.sgi.com Thu May 2 11:24:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42IOwwJ013036 for ; Thu, 2 May 2002 11:24:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42IOv2Z013035 for linux-xfs-outgoing; Thu, 2 May 2002 11:24:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42IOrwJ013009 for ; Thu, 2 May 2002 11:24:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA57223 for ; Thu, 2 May 2002 13:25:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA32472 for ; Thu, 2 May 2002 13:25:49 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g42IOdK18599; Thu, 2 May 2002 13:24:39 -0500 Message-Id: <200205021824.g42IOdK18599@jen.americas.sgi.com> Date: Thu, 2 May 2002 13:24:39 -0500 Subject: TAKE - fix last checkin To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric must have switched from his debug version of the code to the real one without a rebuild. This fixes it again. Steve Date: Thu May 2 11:24:35 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-jen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118083a linux/fs/xfs/xfs_iget.c - 1.154 - fix a build error From owner-linux-xfs@oss.sgi.com Thu May 2 13:20:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42KKCwJ020052 for ; Thu, 2 May 2002 13:20:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42KKCR4020051 for linux-xfs-outgoing; Thu, 2 May 2002 13:20:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf14bis.bellsouth.net (mail114.mail.bellsouth.net [205.152.58.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42KK7wJ020025 for ; Thu, 2 May 2002 13:20:07 -0700 Received: from taz ([65.81.168.196]) by imf14bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020502202231.PZIL9714.imf14bis.bellsouth.net@taz>; Thu, 2 May 2002 16:22:31 -0400 Date: Thu, 2 May 2002 16:14:11 -0400 From: Greg Freemyer Subject: re[2]: Snapshots To: Seth Mos cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020502202231.PZIL9714.imf14bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g42KK8wJ020026 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> On Thu, 2 May 2002, Greg Freemyer wrote: >> > XFS team, >> > >> > I've just become aware of a problem on another Journaled file-system (it >> is not a Linux filesystem). >> A NAS device perhaps? Thanks for the info, and no it is a normal everyday FS. (And a mature one at that. Atleast 5 years old, but I guess hardware snapshots are relatively new. ) The problem apparently occurs in both direct connect and SAN environments. As I understand it the trouble is that some meta-data can be in transition even for just a few millisecs. If the hardware snapshot is made at this time, you get corruption. As you and Steve said, xfs_freeze looks like it is specifically designed to handle the problem, so I'm happy. Greg Freemyer From owner-linux-xfs@oss.sgi.com Thu May 2 13:31:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42KVbwJ020436 for ; Thu, 2 May 2002 13:31:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42KVbGE020435 for linux-xfs-outgoing; Thu, 2 May 2002 13:31:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42KVVwJ020409 for ; Thu, 2 May 2002 13:31:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA61247; Thu, 2 May 2002 15:32:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24695; Thu, 2 May 2002 15:32:27 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g42KVGI22081; Thu, 2 May 2002 15:31:16 -0500 Subject: Re: re[2]: Snapshots From: Steve Lord To: Greg Freemyer Cc: Seth Mos , xfs mailing list In-Reply-To: <20020502202231.PZIL9714.imf14bis.bellsouth.net@taz> References: <20020502202231.PZIL9714.imf14bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 02 May 2002 15:31:16 -0500 Message-Id: <1020371476.652.86.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-02 at 15:14, Greg Freemyer wrote: > >> On Thu, 2 May 2002, Greg Freemyer wrote: > > >> > XFS team, > >> > > >> > I've just become aware of a problem on another Journaled file-system (it > >> is not a Linux filesystem). > > >> A NAS device perhaps? > > Thanks for the info, and no it is a normal everyday FS. (And a mature one at that. Atleast 5 years old, but I guess hardware snapshots are relatively new. ) > > The problem apparently occurs in both direct connect and SAN environments. > > As I understand it the trouble is that some meta-data can be in transition even for just a few millisecs. If the hardware snapshot is made at this time, you get corruption. > There is always data in transit, if you have a journaled filesystem then if it is working correctly you should be able to do a hardware based snapshot at any point in time and get a consistent filesystem back. In that scenario the snapshot is basically the same sort of end result as a sudden power failure. Your snapshot must be atomic across the whole volume though, if you are running on top of some sort of raid and internally its snapshot is actually a multi step process you can end up with one part of the raid out of sync with the rest - actually multiple raid cabinets is the case where that was possible. The combination of that scenario, and the fact that you really want to know what it is you are snapshotting led to the xfs_freeze command and associated kernel code - it basically stops the filesystem and simulates an unmount. Some raid hardware vendors actually have hooks into filesystems so that they can get a flush to happen at the right instant in time. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu May 2 14:14:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42LEIwJ023497 for ; Thu, 2 May 2002 14:14:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42LEIY0023496 for linux-xfs-outgoing; Thu, 2 May 2002 14:14:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42LE7wJ023459 for ; Thu, 2 May 2002 14:14:07 -0700 Received: (qmail 7848 invoked by uid 500); 2 May 2002 21:14:32 -0000 Subject: Re: Chattr From: Austin Gonyou To: Andi Kleen Cc: Stephen Lord , Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <20020501023726.A15270@wotan.suse.de> References: <20020501023726.A15270@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EwH2NVD0EdtT7rhZDcaE" X-Mailer: Ximian Evolution 1.0.4.99 Date: 02 May 2002 16:14:32 -0500 Message-Id: <1020374072.7768.5.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-EwH2NVD0EdtT7rhZDcaE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-04-30 at 19:37, Andi Kleen wrote: > On Tue, Apr 30, 2002 at 07:04:33PM -0500, Steve Lord wrote: > > On Tue, 2002-04-30 at 18:49, Stephen Lord wrote: ... > P.S.: Overall I don't think immutable/append-only are too useful because >=20 > attackers can always get rid of them by mknod'ing a device and writing > to the=20 > disk directly and forcing an inode flush. So it may not be worth much > effort=20 > for the pseudo security ones, as they only give a false sense of > security.=20 Right, and I didn't ask because of security, we're thinking more along the lines of mistakes, which could lead to flags with file monitors, etc. That is more important in this way, than *just* security, for the purpose of the question posed. >=20 > immutable is sometimes useful to prevent mistakes, but not for more. Right. See above.=20 >=20 > The only ones that may be worth it are 'S' (force O_SYNC, especially > for directories e.g. to handle qmail/postfix spool dirs without forcing > synchronous for the whole fs), 'A' (no atime) and 'd' for incremental=20 > backup purposes. They all have *some* usefulness, but trying to make then do things they weren't really designed to do in the first place, or putting too much stock in the base implementation, isn't always the best idea anyway. :) >=20 >=20 > -And --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-EwH2NVD0EdtT7rhZDcaE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA80aw494g6ZVmFMoIRAoskAKDBw4U3XIE7fTMOTCWnMXTDI1zTIwCg3jpx ODGOnvDQMkgLXfy5a6jPpxc= =o/K5 -----END PGP SIGNATURE----- --=-EwH2NVD0EdtT7rhZDcaE-- From owner-linux-xfs@oss.sgi.com Thu May 2 14:50:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42LoIwJ023992 for ; Thu, 2 May 2002 14:50:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42LoIpB023991 for linux-xfs-outgoing; Thu, 2 May 2002 14:50:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42LoCwJ023965 for ; Thu, 2 May 2002 14:50:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA61583 for ; Thu, 2 May 2002 16:51:09 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA57290 for ; Thu, 2 May 2002 16:51:08 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g42Lp8M00993; Thu, 2 May 2002 16:51:08 -0500 Message-Id: <200205022151.g42Lp8M00993@stout.americas.sgi.com> Date: Thu, 2 May 2002 16:51:08 -0500 Subject: TAKE - Update mkfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merging in changes from IRIX (see below). Date: Thu May 2 14:50:05 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118123a cmd/xfsprogs/VERSION - 1.46 - Bump to 2.0.5 cmd/xfsprogs/doc/CHANGES - 1.63 - Update for 2.0.5 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.23 - Merge irix6.5f:irix:117954a 1) size AGs so that they do not always start on the same part of a striped disk; that is, AG size % Stripe Width is not 0. With 4GB AGs we are always starting AGs on first disk in a stripe. 2) Fix an off-by-one error on rounding down an AG that is too small to be an AG 3) don't auto-grow the log to be larger than an AG 4) change the error philosophy for -d su=,sw= away from forcing the XFS stripe size to match the XLV stripe size and instead accept, with a warning, the stripe unit & width supplied on the commandline. From owner-linux-xfs@oss.sgi.com Fri May 3 00:35:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g437ZuwJ028448 for ; Fri, 3 May 2002 00:35:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g437Zutj028447 for linux-xfs-outgoing; Fri, 3 May 2002 00:35:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g437ZqwJ028419 for ; Fri, 3 May 2002 00:35:52 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA2823429 for ; Fri, 3 May 2002 00:36:49 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA04253; Fri, 3 May 2002 17:35:29 +1000 (EST) Date: Fri, 3 May 2002 17:35:29 +1000 (EST) From: Nathan Scott Message-Id: <200205030735.RAA04253@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: jack@ucw.cz Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri May 3 00:34:12 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:118147a linux/include/linux/quota.h - 1.15 linux/include/linux/fs.h - 1.169 linux/fs/super.c - 1.86 linux/fs/dquot.c - 1.55 linux/fs/quota.c - 1.12 linux/fs/quota_v2.c - 1.2 linux/fs/quota_v1.c - 1.2 - sync up with a more recent version of Jan's VFS quota patches. From owner-linux-xfs@oss.sgi.com Fri May 3 08:51:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43Fp1wJ020158 for ; Fri, 3 May 2002 08:51:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43Fp14q020157 for linux-xfs-outgoing; Fri, 3 May 2002 08:51:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43FovwJ020010 for ; Fri, 3 May 2002 08:50:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA73952 for ; Fri, 3 May 2002 10:51:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA33124 for ; Fri, 3 May 2002 10:51:56 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g43Fpu318083; Fri, 3 May 2002 10:51:56 -0500 Message-Id: <200205031551.g43Fpu318083@stout.americas.sgi.com> Date: Fri, 3 May 2002 10:51:56 -0500 Subject: TAKE - Merge irix6.5f:irix:117830a (move m_peraglock locking) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This fixes create performance dropoff as filesystems fill up. Date: Fri May 3 08:46:30 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118173a linux/fs/xfs/xfs_ialloc.c - 1.155 - Merge irix6.5f:irix:117830a Move the mrlock/mrunlock of m_peraglock outside of the for loop that searches AGs for one with free space for inodes. linux/fs/xfs/xfs_alloc.c - 1.149 - Merge irix6.5f:irix:117830a Move the mrlock/mrunlock of m_peraglock outside of the for loop that searches AGs for one with space. Fixes a near-full-filesystem performance problem. From owner-linux-xfs@oss.sgi.com Fri May 3 09:26:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43GQPwJ026033 for ; Fri, 3 May 2002 09:26:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43GQPjj026032 for linux-xfs-outgoing; Fri, 3 May 2002 09:26:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43GPkwJ026000 for ; Fri, 3 May 2002 09:25:46 -0700 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 09:31:22 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F146@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'Steve Lord'" , Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: RE: Snapshots Date: Fri, 3 May 2002 09:31:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F2BF.F3565040" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F2BF.F3565040 Content-Type: text/plain; charset="iso-8859-1" [on XFS with LVM snapshots...] > man xfs_freeze > > Or if you have the correct LVM patches in place then the > kernel does it > all for you. > I've been using XFS with snapshots off-and-on for quite a while, mostly with good results (currently using XFS CVS from March 19th and LVM 1.0.3, both with some patches). That said, the comment with the last change to xfs_fs_freeze in XFS's CVS tree still worries me: ---Begin TAKE from Eric Sandeen--- There are still some problems with xfs_freeze, but this solves part of the problem. Even with this change, people are still seeing consistency problems on a frozen filesystem, so don't trust xfs_freeze just yet. Date: Mon Feb 4 08:39:30 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110921a linux/fs/xfs/xfs_fsops.c - 1.73 - Remove xfs_iflush_all() from xfs_fs_freeze(). This doesn't play well with Linux, leaving us with dentries no longer connected to xfs_inodes. ---End TAKE ---- Now, I haven't seen consistency problems. I have seen lvcreate (the LVM snapshot creation command) get stuck in D state with the VFS lock patch and XFS, without the [LVM] VFS lock patch and surrounded by xfs_freeze -f, xfs_freeze -u, and with the VFS lock patch and surrounded by xfs_freeze -f. Certainly not every time, but under heavy load and multiple snapshots already existing on the XFS volume we were making a new snapshot, we'd hit it eventually. That led to the first attached patch, no_freeze.patch. It's not really a fix, just a kludge to make sure some things don't get stuck because of the freeze. An unused process flag is used to set PF_NO_FREEZE, which is a signal to xfs_check_frozen to let things through. By using the flag to protect fsync_dev() and kupdate(), the situation was greatly improved. (The patch also contains a protection against writing the log to a read-only device--an unrelated problem). The no_freeze_lockfs_patch (second attached patch) protects fsync_dev_lockfs, in case you're using LVM's VFS lock patch. After those patches were applied, I still saw a couple situations where xfs_freeze -f and xfs_freeze -u froze up (not at the same time :->). In both cases, it was an xfs_check_frozen() descending from xfs_unmountfs_writesb() calls. Can't have the freeze stopping xfs_freeze calls, so I added PF_NO_FREEZE protection inside xfs_fs_freeze and xfs_fs_thaw (also in the second patch). That solved that problem. Finally, I saw a few cases under load (mixed smb/nfs) where lvcreate would consume 98% of the CPU and never complete. In that case, lvcreate wasn't stuck itself, but was looping endlessly inside write_unlocked_buffers(). The cause seemed to be nfsd, which was stuck in xfs_check_frozen() descending from write_buffer_delay(). It wasn't from the original write nfs was trying to process, but came down from balance_dirty() calling write_some_buffers(). I figured balance_dirty() should be allowed to write buffers, so I protected that call from freeze as well (also in the second patch). Haven't seen a lockup since, but I'm not convinced that another one isn't out there. So that's my experience with XFS and LVM snapshots. YMMV. Dale Stephenson steph@snapserver.com ------_=_NextPart_000_01C1F2BF.F3565040 Content-Type: application/octet-stream; name="no_freeze.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="no_freeze.patch" --- linux.old/fs/xfs/xfs_log.c Wed Mar 20 04:51:25 2002 +++ linux/fs/xfs/xfs_log.c Sat Mar 30 00:38:58 2002 @@ -324,6 +324,11 @@ int rval; xlog_t *log =3D mp->m_log; =20 + if (XFS_MTOVFS(mp)->vfs_flag & VFS_RDONLY) { + printk("ignoring xfs_log_force on a read-only filesystem\n"); + return 0; + } + #if defined(DEBUG) || defined(XLOG_NOLOG) if (! xlog_debug && xlog_devt =3D=3D log->l_dev) return 0; --- linux.old/fs/xfs/xfs_mount.c Sat Mar 9 03:21:26 2002 +++ linux/fs/xfs/xfs_mount.c Sat Mar 30 00:39:39 2002 @@ -1680,6 +1680,7 @@ int level) { int s =3D mutex_spinlock(&mp->m_freeze_lock); + unsigned long flags; =20 mp->m_frozen =3D level; mutex_spinunlock(&mp->m_freeze_lock, s); @@ -1688,13 +1689,27 @@ while (atomic_read(&mp->m_active_trans) > 0) delay(100); } + + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + + /* make sure the log is written after we freeze */ + xfs_log_force(mp, 0, XFS_LOG_FORCE|XFS_LOG_SYNC); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } } =20 void xfs_finish_freeze( xfs_mount_t *mp) { - int s =3D mutex_spinlock(&mp->m_freeze_lock); + int s; + + if (current->flags & PF_NO_FREEZE) return; + + s =3D mutex_spinlock(&mp->m_freeze_lock); =20 if (mp->m_frozen) { mp->m_frozen =3D 0; @@ -1713,6 +1728,10 @@ { int s; int do_lock =3D 0; + + /* some processes must not freeze - eg. a lvcreate or kupdated, otherwise + lvcreate locks solid as it tries to flush blocks, and that gets here */ + if (current->flags & PF_NO_FREEZE) return; =20 if (!mp->m_frozen) { if (level =3D=3D XFS_FREEZE_TRANS) --- linux.old/fs/buffer.c Sat Mar 30 00:28:28 2002 +++ linux/fs/buffer.c Sat Mar 30 00:40:54 2002 @@ -392,6 +392,14 @@ =20 int fsync_dev(kdev_t dev) { + int ret; + unsigned long flags; + + flags =3D current->flags; + /* we set this flag to prevent the XFS pagebuf code causing a deadlock=20 + during a sync - a frozen filesystem should freeze only new IO, not + existing data waiting to be flushed */ + current->flags |=3D PF_NO_FREEZE; sync_buffers(dev, 0); =20 lock_kernel(); @@ -400,7 +408,13 @@ sync_supers(dev); unlock_kernel(); =20 - return sync_buffers(dev, 1); + ret =3D sync_buffers(dev, 1); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + + return ret; } =20 /* @@ -3038,6 +3052,9 @@ siginitsetinv(¤t->blocked, sigmask(SIGCONT) | sigmask(SIGSTOP)); recalc_sigpending(tsk); spin_unlock_irq(&tsk->sigmask_lock); + + /* kupdated can also do IO of old blocks on a frozen filesystem */ + current->flags |=3D PF_NO_FREEZE; =20 complete((struct completion *)startup); =20 --- linux.old/include/linux/sched.h Sat Mar 30 00:30:23 2002 +++ linux/include/linux/sched.h Fri Mar 29 23:34:13 2002 @@ -428,6 +428,7 @@ #define PF_FREE_PAGES 0x00002000 /* per process page freeing */ #define PF_NOIO 0x00004000 /* avoid generating further I/O */ #define PF_FSTRANS 0x00008000 /* inside a filesystem transaction */ +#define PF_NO_FREEZE 0x01000000 /* ignore fs freeze flag */ =20 #define PF_USEDFPU 0x00100000 /* task used FPU this quantum (SMP) */ =20 ------_=_NextPart_000_01C1F2BF.F3565040 Content-Type: application/octet-stream; name="no_freeze_lockfs.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="no_freeze_lockfs.patch" --- linux/fs/buffer.c.old Tue Apr 2 10:47:30 2002 +++ linux/fs/buffer.c Tue Apr 2 10:48:35 2002 @@ -428,6 +428,9 @@ =20 int fsync_dev_lockfs(kdev_t dev) { + unsigned long flags; + int ret; + /* you are not allowed to try locking all the filesystems ** on the system, your chances of getting through without ** total deadlock are slim to none. @@ -435,6 +438,9 @@ if (!dev) return fsync_dev(dev) ; =20 + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + sync_buffers(dev, 0); =20 lock_kernel(); @@ -451,7 +457,13 @@ sync_supers_lockfs(dev) ; unlock_kernel(); =20 - return sync_buffers(dev, 1) ; + ret =3D sync_buffers(dev, 1) ; + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + + return ret; } =20 asmlinkage long sys_sync(void) @@ -1171,13 +1183,23 @@ void balance_dirty(void) { int state =3D balance_dirty_state(); + unsigned long flags; =20 if (state < 0) return; =20 /* If we're getting into imbalance, start write-out */ spin_lock(&lru_list_lock); + + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + write_some_buffers(NODEV); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + =20 /* * And if we're _really_ out of balance, wait for --- linux/fs/xfs/xfs_fsops.c.old Fri Apr 26 18:10:29 2002 +++ linux/fs/xfs/xfs_fsops.c Fri Apr 26 18:13:16 2002 @@ -551,6 +551,7 @@ vfs_t *vfsp; /*REFERENCED*/ int error; + unsigned long flags; =20 vfsp =3D XFS_MTOVFS(mp); =20 @@ -565,6 +566,10 @@ =20 /* Pause transaction subsystem */ xfs_start_freeze(mp, XFS_FREEZE_TRANS); +=09 + /* don't freeze the freeze */ + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; =20 /* Flush any remaining inodes into buffers */ VFS_SYNC(vfsp, SYNC_ATTR|SYNC_WAIT, sys_cred, error); @@ -579,6 +584,10 @@ xfs_log_unmount_write(mp); xfs_unmountfs_writesb(mp); =20 + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + return 0; } =20 @@ -587,7 +596,17 @@ xfs_fs_thaw( xfs_mount_t *mp) { + unsigned long flags; + + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + xfs_unmountfs_writesb(mp); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + xfs_finish_freeze(mp); return 0; } ------_=_NextPart_000_01C1F2BF.F3565040-- From owner-linux-xfs@oss.sgi.com Fri May 3 14:44:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43LiDwJ031720 for ; Fri, 3 May 2002 14:44:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43LiDKr031719 for linux-xfs-outgoing; Fri, 3 May 2002 14:44:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43Li6wJ031693 for ; Fri, 3 May 2002 14:44:07 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx01.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GVK00EQ21RBF0@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Fri, 03 May 2002 16:45:12 -0500 (CDT) Date: Fri, 03 May 2002 17:41:23 -0400 (EDT) From: jtrostel@snapserver.com Subject: Difficulties with large ACL/DACL counts To: acl-devel@bestbits.at, Andreas Gruenbacher , XFS list , Timothy Shimmin , Nathan Scott Cc: Marc Kaplan Cc: Marc Kaplan , "Burrows, Dan" Reply-to: jtrostel@snapserver.com Message-id: Organization: Quantum Corp. / NASD MIME-version: 1.0 X-Mailer: XFMail 1.5.2 on Linux Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are seeing strange behavior with the current versions of XFS when using a large number of ACEs in a combination of Access and Default ACEs. When one creates enough entries so that you have exactly 21 ACEs in an ACL and then you try to create 21 or more ACEs in the 'other' ACL on a directory, the operation will fail. It often panics the system. Any subsequent access attempt to that directory will also panic the system. Note the number of ACEs counted includes the u,g,m,o entries if they are present. Another very interesting note is that, if you create enough entries so that you have a total number of ACEs greater than 21 (or less than 21), there is no problem creating the 'other' ACL entries until you reach the XFS limit of 25 entrys. It may be a problem caused by trying to fit the ACL into the inode... but I'm much too confused right now to be sure ;-> Andreas: As a side note: there seems to be a difficulty using the current userspace tools to make any ACEs when you have more than 16 already created. The 17th will seem to be created fine (with setfacl -d -m u:a17:rw ./test_dir) but a subsequent getfacl call will return 'argument too long'. If you _don't_ check the ACL with getfacl, the next use of setfacl will yield the same error, 'argument too long'. XFS _should_ allow a total of 25 ACEs in the Access ACL and 25 ACEs in the Default ACL. (And older versions of the tools (2.0.4) seem to work) -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Fri May 3 14:56:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43Lu0wJ032043 for ; Fri, 3 May 2002 14:56:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43Lu0qp032042 for linux-xfs-outgoing; Fri, 3 May 2002 14:56:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43LtuwJ032013 for ; Fri, 3 May 2002 14:55:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA3192299 for ; Fri, 3 May 2002 14:57:01 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA00241; Sat, 4 May 2002 07:55:40 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA10819; Sat, 4 May 2002 07:55:38 +1000 (AEST) Date: Sat, 4 May 2002 07:55:38 +1000 From: Nathan Scott To: jtrostel@snapserver.com Cc: acl-devel@bestbits.at, Andreas Gruenbacher , XFS list , Timothy Shimmin , Marc Kaplan , "Burrows, Dan" Subject: Re: Difficulties with large ACL/DACL counts Message-ID: <20020504075538.T100154@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jtrostel@snapserver.com on Fri, May 03, 2002 at 05:41:23PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi John, Tim and I came across this during the week -- we believe it to be a problem in our XFS code, returning E2BIG instead of ERANGE in some places where the user tools are expecting ERANGE (which we documented in the man pages when doing the unified syscalls). Ultimately, this prevents the tools from re-doing the request with a larger buffer, and we get an error instead of a retry. Should be fixed early next week, along with Ethan's other errno related problem (EPERM vs EACCESS), though I haven't had a chance to look into that in detail. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat May 4 03:54:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g44AsEwJ004755 for ; Sat, 4 May 2002 03:54:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g44AsEOs004754 for linux-xfs-outgoing; Sat, 4 May 2002 03:54:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g44As8wJ004728 for ; Sat, 4 May 2002 03:54:09 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 173xC7-00029h-00 for linux-xfs@oss.sgi.com; Sat, 04 May 2002 11:55:15 +0100 Date: Sat, 4 May 2002 11:55:15 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: [PATCH] fix data bug in device-mapping invalidation Message-ID: <20020504115515.A8210@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Currently pagebuf_lock_disable() calls destroy_buffers() and truncate_inode_pages() unconditionally. For the post 2.4.13 case where the pagebuf modules sits ontop of the blockdevice mapping this could cause incore data corruption for other openers of that device (xfsdump?). The fix is to completly remove the calls, blkdev_put does them when the last opener finished. Keep the code for the pre 2.4.13 case as those use their own mapping. Patch is ontop of my last patch, but the bug is present even without it. --- linux/fs/xfs/pagebuf/page_buf_locking.c.~hch~ Sat May 4 13:46:55 2002 +++ linux/fs/xfs/pagebuf/page_buf_locking.c Sat May 4 13:48:33 2002 @@ -324,8 +324,10 @@ pagebuf_lock_disable( /* disable buffer locking */ pb_target_t *target) /* inode for buffers */ { +#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,4,13)) destroy_buffers(target->pbr_device); truncate_inode_pages(PBT_ADDR_SPACE(target), 0LL); +#endif bdput(target->pbr_bdev); kmem_cache_free(pagebuf_target_cache, target); From owner-linux-xfs@oss.sgi.com Sat May 4 04:14:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g44BECwJ005431 for ; Sat, 4 May 2002 04:14:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g44BEBIE005430 for linux-xfs-outgoing; Sat, 4 May 2002 04:14:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g44BE3wJ005404 for ; Sat, 4 May 2002 04:14:05 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 173xVQ-0002ET-00 for linux-xfs@oss.sgi.com; Sat, 04 May 2002 12:15:12 +0100 Date: Sat, 4 May 2002 12:15:12 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: [PATCH] fix qsort breakage Message-ID: <20020504121512.A8534@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Qsort in the XFS tree has two problems: o allocates memory using GFP_KERNEL although called from under i_sem (possible deadlock) o doesn't check kmalloc return value (possible NULL-ptr dereference) The below patch tries to address both issues, but without a return value singnalling ENOMEM is rather difficult.. Andi Kleen suggested getting the pivot from stack, someone with enough time might check the callers for sane ßize arguments. Index: linux/fs/xfs_support/qsort.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs_support/qsort.c,v retrieving revision 1.4 diff -u -u -r1.4 qsort.c --- linux/fs/xfs_support/qsort.c 2002/03/12 06:25:01 1.4 +++ linux/fs/xfs_support/qsort.c 2002/05/04 11:08:26 @@ -88,9 +88,13 @@ /* Allocating SIZE bytes for a pivot buffer facilitates a better algorithm below since we can do comparisons directly on the pivot. */ - char *pivot_buffer = (char *) kmalloc (size, GFP_KERNEL); + char *pivot_buffer = (char *) kmalloc (size, GFP_NOFS); const size_t max_thresh = MAX_THRESH * size; + if (pivot_buffer == NULL) + /* any way to return failure from qsort? */ + return; + if (total_elems == 0) /* Avoid lossage with unsigned arithmetic below. */ return; From owner-linux-xfs@oss.sgi.com Sat May 4 07:13:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g44EDWwJ012234 for ; Sat, 4 May 2002 07:13:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g44EDWJA012233 for linux-xfs-outgoing; Sat, 4 May 2002 07:13:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g44EDMwJ012205 for ; Sat, 4 May 2002 07:13:23 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 1740Ix-0003ac-00 for linux-xfs@oss.sgi.com; Sat, 04 May 2002 15:14:31 +0100 Date: Sat, 4 May 2002 15:14:31 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix qsort breakage Message-ID: <20020504151431.A12980@infradead.org> References: <20020504121512.A8534@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020504121512.A8534@infradead.org>; from hch@infradead.org on Sat, May 04, 2002 at 12:15:12PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, May 04, 2002 at 12:15:12PM +0100, Christoph Hellwig wrote: > Qsort in the XFS tree has two problems: > > o allocates memory using GFP_KERNEL although called from under i_sem > (possible deadlock) > o doesn't check kmalloc return value (possible NULL-ptr dereference) > > The below patch tries to address both issues, but without a return value > singnalling ENOMEM is rather difficult.. > > Andi Kleen suggested getting the pivot from stack, someone with enough > time might check the callers for sane ßize arguments. Wessel Dankers found another bug in the qsort implementation, a memory leak is possible if total_elems is zero. Updated patch is below. The alternative would be to replace this masterpiece of GNU bloatware with a simpler qsort implementation that doesn't use dynamic memory allocation like the one in 4BSD's libc or the public domain one from: http://www.snippets.org/snippets/portable/RG_QSORT+C.php3 Of course you could take the IRIX kernel one as well - it should fully match the assupmtions XFS makes, I guess.. Christoph Index: linux/fs/xfs_support/qsort.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs_support/qsort.c,v retrieving revision 1.4 diff -u -u -r1.4 qsort.c --- linux/fs/xfs_support/qsort.c 2002/03/12 06:25:01 1.4 +++ linux/fs/xfs_support/qsort.c 2002/05/04 13:28:18 @@ -85,14 +85,18 @@ int (*cmp)(const void *, const void *)) { register char *base_ptr = (char *) pbase; - - /* Allocating SIZE bytes for a pivot buffer facilitates a better - algorithm below since we can do comparisons directly on the pivot. */ - char *pivot_buffer = (char *) kmalloc (size, GFP_KERNEL); const size_t max_thresh = MAX_THRESH * size; - + char *pivot_buffer; + if (total_elems == 0) /* Avoid lossage with unsigned arithmetic below. */ + return; + + /* Allocating SIZE bytes for a pivot buffer facilitates a better + algorithm below since we can do comparisons directly on the pivot. */ + pivot_buffer = kmalloc (size, GFP_NOFS); + if (pivot_buffer == NULL) + /* any way to return failure from qsort? */ return; if (total_elems > MAX_THRESH) From owner-linux-xfs@oss.sgi.com Sat May 4 13:27:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g44KRnwJ014503 for ; Sat, 4 May 2002 13:27:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g44KRnJf014501 for linux-xfs-outgoing; Sat, 4 May 2002 13:27:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g44KR5wJ014468 for ; Sat, 4 May 2002 13:27:05 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00782 for ; Sat, 4 May 2002 13:27:54 -0700 (PDT) mail_from (wlang@wu-wien.ac.at) Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g44KAET19419; Sat, 4 May 2002 22:10:14 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15572.16422.411109.679220@slime.wu-wien.ac.at> Date: Sat, 4 May 2002 22:10:14 +0200 To: linux-xfs@oss.sgi.com Subject: xfs_repair changes are not permanent (was: corrupt xfs filesystem -- xfs_repair dumps core) In-Reply-To: <20020426105445.F80513@wobbly.melbourne.sgi.com> References: <15557.36194.760672.792045@slime.wu-wien.ac.at> <20020424082748.L63455@wobbly.melbourne.sgi.com> <15558.37214.558780.264419@slime.wu-wien.ac.at> <20020426105445.F80513@wobbly.melbourne.sgi.com> X-Mailer: VM 7.03 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Sorry for going on about this -- i'm still trying to get my data back... According to Nathan Scott: > > Unfortunatly the '-L' makes no difference: > > Oh, I see -- that check only comes into play later... hmmm, will have > to try plan C. Thank you Nathan! Now i was able to run xfs_repair to the end (the output is attached to this Mail). But: the changes arn't written back to the filesystem. The next run of xfs_repair gives exactly the same output. Any idea what could be wrong, or what i can try next? Thanks for your patience! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria -----snip-snip------------------------ # xfs_repair -L /dev/sdb Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad magic number 0x0 on inode 128 bad version number 0x0 on inode 128 bad magic number 0x0 on inode 129 bad version number 0x0 on inode 129 bad magic number 0x0 on inode 130 bad version number 0x0 on inode 130 bad magic number 0x0 on inode 131 bad version number 0x0 on inode 131 bad magic number 0x0 on inode 132 bad version number 0x0 on inode 132 bad magic number 0x0 on inode 133 bad version number 0x0 on inode 133 bad magic number 0x0 on inode 134 bad version number 0x0 on inode 134 bad magic number 0x0 on inode 135 bad version number 0x0 on inode 135 bad magic number 0x0 on inode 136 bad version number 0x0 on inode 136 bad magic number 0x0 on inode 137 bad version number 0x0 on inode 137 bad magic number 0x0 on inode 138 bad version number 0x0 on inode 138 bad magic number 0x0 on inode 139 bad version number 0x0 on inode 139 bad magic number 0x0 on inode 140 bad version number 0x0 on inode 140 bad magic number 0x0 on inode 141 bad version number 0x0 on inode 141 bad magic number 0x0 on inode 142 bad version number 0x0 on inode 142 bad magic number 0x0 on inode 143 bad version number 0x0 on inode 143 bad magic number 0x0 on inode 144 bad version number 0x0 on inode 144 bad magic number 0x0 on inode 145 bad version number 0x0 on inode 145 bad magic number 0x0 on inode 146 bad version number 0x0 on inode 146 bad magic number 0x0 on inode 147 bad version number 0x0 on inode 147 bad magic number 0x0 on inode 148 bad version number 0x0 on inode 148 bad magic number 0x0 on inode 149 bad version number 0x0 on inode 149 bad magic number 0x0 on inode 150 bad version number 0x0 on inode 150 bad magic number 0x0 on inode 151 bad version number 0x0 on inode 151 bad magic number 0x0 on inode 152 bad version number 0x0 on inode 152 bad magic number 0x0 on inode 153 bad version number 0x0 on inode 153 bad magic number 0x0 on inode 154 bad version number 0x0 on inode 154 bad magic number 0x0 on inode 155 bad version number 0x0 on inode 155 bad magic number 0x0 on inode 156 bad version number 0x0 on inode 156 bad magic number 0x0 on inode 157 bad version number 0x0 on inode 157 bad magic number 0x0 on inode 158 bad version number 0x0 on inode 158 bad magic number 0x0 on inode 159 bad version number 0x0 on inode 159 bad magic number 0x0 on inode 160 bad version number 0x0 on inode 160 bad magic number 0x0 on inode 161 bad version number 0x0 on inode 161 bad magic number 0x0 on inode 162 bad version number 0x0 on inode 162 bad magic number 0x0 on inode 163 bad version number 0x0 on inode 163 bad magic number 0x0 on inode 164 bad version number 0x0 on inode 164 bad magic number 0x0 on inode 165 bad version number 0x0 on inode 165 bad magic number 0x0 on inode 166 bad version number 0x0 on inode 166 bad magic number 0x0 on inode 167 bad version number 0x0 on inode 167 bad magic number 0x0 on inode 168 bad version number 0x0 on inode 168 bad magic number 0x0 on inode 169 bad version number 0x0 on inode 169 bad magic number 0x0 on inode 170 bad version number 0x0 on inode 170 bad magic number 0x0 on inode 171 bad version number 0x0 on inode 171 bad magic number 0x0 on inode 172 bad version number 0x0 on inode 172 bad magic number 0x0 on inode 173 bad version number 0x0 on inode 173 bad magic number 0x0 on inode 174 bad version number 0x0 on inode 174 bad magic number 0x0 on inode 175 bad version number 0x0 on inode 175 bad magic number 0x0 on inode 176 bad version number 0x0 on inode 176 bad magic number 0x0 on inode 177 bad version number 0x0 on inode 177 bad magic number 0x0 on inode 178 bad version number 0x0 on inode 178 bad magic number 0x0 on inode 179 bad version number 0x0 on inode 179 bad magic number 0x0 on inode 180 bad version number 0x0 on inode 180 bad magic number 0x0 on inode 181 bad version number 0x0 on inode 181 bad magic number 0x0 on inode 182 bad version number 0x0 on inode 182 bad magic number 0x0 on inode 183 bad version number 0x0 on inode 183 bad magic number 0x0 on inode 184 bad version number 0x0 on inode 184 bad magic number 0x0 on inode 185 bad version number 0x0 on inode 185 bad magic number 0x0 on inode 186 bad version number 0x0 on inode 186 bad magic number 0x0 on inode 187 bad version number 0x0 on inode 187 bad magic number 0x0 on inode 188 bad version number 0x0 on inode 188 bad magic number 0x0 on inode 189 bad version number 0x0 on inode 189 bad magic number 0x0 on inode 190 bad version number 0x0 on inode 190 bad magic number 0x0 on inode 191 bad version number 0x0 on inode 191 bad magic number 0x0 on inode 128, resetting magic number bad version number 0x0 on inode 128, resetting version number imap claims a free inode 128 is in use, correcting imap and clearing inode cleared root inode 128 bad magic number 0x0 on inode 129, resetting magic number bad version number 0x0 on inode 129, resetting version number imap claims a free inode 129 is in use, correcting imap and clearing inode cleared realtime bitmap inode 129 bad magic number 0x0 on inode 130, resetting magic number bad version number 0x0 on inode 130, resetting version number imap claims a free inode 130 is in use, correcting imap and clearing inode cleared realtime summary inode 130 bad magic number 0x0 on inode 131, resetting magic number bad version number 0x0 on inode 131, resetting version number imap claims a free inode 131 is in use, correcting imap and clearing inode cleared inode 131 bad magic number 0x0 on inode 132, resetting magic number bad version number 0x0 on inode 132, resetting version number bad magic number 0x0 on inode 133, resetting magic number bad version number 0x0 on inode 133, resetting version number bad magic number 0x0 on inode 134, resetting magic number bad version number 0x0 on inode 134, resetting version number bad magic number 0x0 on inode 135, resetting magic number bad version number 0x0 on inode 135, resetting version number bad magic number 0x0 on inode 136, resetting magic number bad version number 0x0 on inode 136, resetting version number bad magic number 0x0 on inode 137, resetting magic number bad version number 0x0 on inode 137, resetting version number bad magic number 0x0 on inode 138, resetting magic number bad version number 0x0 on inode 138, resetting version number bad magic number 0x0 on inode 139, resetting magic number bad version number 0x0 on inode 139, resetting version number bad magic number 0x0 on inode 140, resetting magic number bad version number 0x0 on inode 140, resetting version number bad magic number 0x0 on inode 141, resetting magic number bad version number 0x0 on inode 141, resetting version number bad magic number 0x0 on inode 142, resetting magic number bad version number 0x0 on inode 142, resetting version number bad magic number 0x0 on inode 143, resetting magic number bad version number 0x0 on inode 143, resetting version number bad magic number 0x0 on inode 144, resetting magic number bad version number 0x0 on inode 144, resetting version number bad magic number 0x0 on inode 145, resetting magic number bad version number 0x0 on inode 145, resetting version number bad magic number 0x0 on inode 146, resetting magic number bad version number 0x0 on inode 146, resetting version number bad magic number 0x0 on inode 147, resetting magic number bad version number 0x0 on inode 147, resetting version number bad magic number 0x0 on inode 148, resetting magic number bad version number 0x0 on inode 148, resetting version number bad magic number 0x0 on inode 149, resetting magic number bad version number 0x0 on inode 149, resetting version number bad magic number 0x0 on inode 150, resetting magic number bad version number 0x0 on inode 150, resetting version number bad magic number 0x0 on inode 151, resetting magic number bad version number 0x0 on inode 151, resetting version number bad magic number 0x0 on inode 152, resetting magic number bad version number 0x0 on inode 152, resetting version number bad magic number 0x0 on inode 153, resetting magic number bad version number 0x0 on inode 153, resetting version number bad magic number 0x0 on inode 154, resetting magic number bad version number 0x0 on inode 154, resetting version number bad magic number 0x0 on inode 155, resetting magic number bad version number 0x0 on inode 155, resetting version number bad magic number 0x0 on inode 156, resetting magic number bad version number 0x0 on inode 156, resetting version number bad magic number 0x0 on inode 157, resetting magic number bad version number 0x0 on inode 157, resetting version number bad magic number 0x0 on inode 158, resetting magic number bad version number 0x0 on inode 158, resetting version number bad magic number 0x0 on inode 159, resetting magic number bad version number 0x0 on inode 159, resetting version number bad magic number 0x0 on inode 160, resetting magic number bad version number 0x0 on inode 160, resetting version number bad magic number 0x0 on inode 161, resetting magic number bad version number 0x0 on inode 161, resetting version number bad magic number 0x0 on inode 162, resetting magic number bad version number 0x0 on inode 162, resetting version number bad magic number 0x0 on inode 163, resetting magic number bad version number 0x0 on inode 163, resetting version number bad magic number 0x0 on inode 164, resetting magic number bad version number 0x0 on inode 164, resetting version number bad magic number 0x0 on inode 165, resetting magic number bad version number 0x0 on inode 165, resetting version number bad magic number 0x0 on inode 166, resetting magic number bad version number 0x0 on inode 166, resetting version number bad magic number 0x0 on inode 167, resetting magic number bad version number 0x0 on inode 167, resetting version number bad magic number 0x0 on inode 168, resetting magic number bad version number 0x0 on inode 168, resetting version number bad magic number 0x0 on inode 169, resetting magic number bad version number 0x0 on inode 169, resetting version number bad magic number 0x0 on inode 170, resetting magic number bad version number 0x0 on inode 170, resetting version number bad magic number 0x0 on inode 171, resetting magic number bad version number 0x0 on inode 171, resetting version number bad magic number 0x0 on inode 172, resetting magic number bad version number 0x0 on inode 172, resetting version number bad magic number 0x0 on inode 173, resetting magic number bad version number 0x0 on inode 173, resetting version number bad magic number 0x0 on inode 174, resetting magic number bad version number 0x0 on inode 174, resetting version number bad magic number 0x0 on inode 175, resetting magic number bad version number 0x0 on inode 175, resetting version number bad magic number 0x0 on inode 176, resetting magic number bad version number 0x0 on inode 176, resetting version number bad magic number 0x0 on inode 177, resetting magic number bad version number 0x0 on inode 177, resetting version number bad magic number 0x0 on inode 178, resetting magic number bad version number 0x0 on inode 178, resetting version number bad magic number 0x0 on inode 179, resetting magic number bad version number 0x0 on inode 179, resetting version number bad magic number 0x0 on inode 180, resetting magic number bad version number 0x0 on inode 180, resetting version number bad magic number 0x0 on inode 181, resetting magic number bad version number 0x0 on inode 181, resetting version number bad magic number 0x0 on inode 182, resetting magic number bad version number 0x0 on inode 182, resetting version number bad magic number 0x0 on inode 183, resetting magic number bad version number 0x0 on inode 183, resetting version number bad magic number 0x0 on inode 184, resetting magic number bad version number 0x0 on inode 184, resetting version number bad magic number 0x0 on inode 185, resetting magic number bad version number 0x0 on inode 185, resetting version number bad magic number 0x0 on inode 186, resetting magic number bad version number 0x0 on inode 186, resetting version number bad magic number 0x0 on inode 187, resetting magic number bad version number 0x0 on inode 187, resetting version number bad magic number 0x0 on inode 188, resetting magic number bad version number 0x0 on inode 188, resetting version number bad magic number 0x0 on inode 189, resetting magic number bad version number 0x0 on inode 189, resetting version number bad magic number 0x0 on inode 190, resetting magic number bad version number 0x0 on inode 190, resetting version number bad magic number 0x0 on inode 191, resetting magic number bad version number 0x0 on inode 191, resetting version number - agno = 1 - agno = 2 [...] - agno = 1999 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... root inode lost - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 inode block 8 multiply claimed, state was 4 inode block 9 multiply claimed, state was 4 inode block 10 multiply claimed, state was 4 inode block 11 multiply claimed, state was 4 entry ".." at block 0 offset 568 in directory inode 8320 references free inode 131 clearing inode number in entry at offset 568... no .. entry for directory 8320 - agno = 1 - agno = 2 [...] - agno = 1997 - agno = 1998 - agno = 1999 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... reinitializing root directory reinitializing realtime bitmap inode reinitializing realtime summary inode - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... rebuilding directory inode 8320 - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 8320, moving to lost+found disconnected inode 8321, moving to lost+found disconnected inode 8322, moving to lost+found disconnected inode 35179, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 128 nlinks from 2 to 3 resetting inode 8320 nlinks from 29 to 28 done From owner-linux-xfs@oss.sgi.com Sat May 4 17:48:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g450m0wJ021435 for ; Sat, 4 May 2002 17:48:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g450lxSe021434 for linux-xfs-outgoing; Sat, 4 May 2002 17:47:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g450lpwJ021408 for ; Sat, 4 May 2002 17:47:51 -0700 Received: from hillbilly ([64.168.27.198]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVM00KJK4XP5Q@mta6.snfc21.pbi.net> for linux-xfs@oss.sgi.com; Sat, 04 May 2002 17:49:03 -0700 (PDT) Date: Sat, 04 May 2002 17:48:56 -0700 From: Kevin Giguere Subject: XFS v 1.02 800GB Filesystem problem To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Folks, I have a filesystem that was acting strangely and I have not been able to pin point the true cause. The system was a 1ghz P3, 1 gb ram with external 800GB ide to scsi raid. The scsi HBA is an adaptec 29160 using the aic78xx driver. The filesystem (/dev/sdb1) at its best point would allow me to mount it and I could view files, however this is all that I could do. Any attempt to write a file would freeze the mount and the machine would have to be reset to free the mount point. Another raid (/dev/sdc1)in the scsi chain remained fully usable. I was able to do an xfs_check /dev/sdb1 and it went straight back to prompt. No apparent problems. Restart. Remount. Same behavior; couldn't write anything... So I made sure the fs was unmounted and ran xfs_repair -n /dev/sdb1 and a whole bunch of errors came up, but it didn't do anything b/c -n option. Spoke to my Irix guy asking what some of them meant. We decided to run xfs_repair and try to fix some of these things. This produced a message saying that the log is messed up and I would have to mount to rerun the log. The new problem was that I could not mount it anymore. Shutdown checked the cables, everything was ok. Other Raid was still fine. Doesn't look like a HW problem ( Though I am convinced it is--- SCSI bios looks good, /proc/scsi/scsi sees everything, /proc/partitions sees everything..but HMMM). After wanting to break the thing, I tried again. Same as results as above. Can't mount if I wanted to, can't run xfs_repair or check. The only option to run xfs_repair (and where I am going with this) is xfs_repair -L /dev/sdb1. I understood that this is a potentially dangerous option. But I didn't have another 800GB volume free to dd onto as b/u. So I ran this. And it apparently did a lot. After this was run, I ran xfs_repair again to rebuild the log and then mounted. The great thing is I could mount, read and write. The terrible thing is that I couldn't see any data. All that was there was an empty lost and found....., but xfs_check finds a ton of mismatches and lost inodes. As a last ditch I hooked it up to a SGI to see if it could do anything. >From what I can tell all Irix sees is a raw disk. I didn't do any fx stuff fearing ruining any other chances for recovery. I think that there is very very small chance to get something back, Any one have any Ideas???? Thanks a million in advance, Kevin From owner-linux-xfs@oss.sgi.com Sun May 5 03:18:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45AIRwJ024754 for ; Sun, 5 May 2002 03:18:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45AIQns024753 for linux-xfs-outgoing; Sun, 5 May 2002 03:18:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45AIGwJ024727 for ; Sun, 5 May 2002 03:18:17 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g45AJSaG035512; Sun, 5 May 2002 12:19:28 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA15103; Sun, 5 May 2002 12:19:25 +0200 (CEST) Date: Sun, 5 May 2002 12:19:22 +0200 (CEST) From: Seth Mos To: Kevin Giguere cc: Subject: Re: XFS v 1.02 800GB Filesystem problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 4 May 2002, Kevin Giguere wrote: > Hello Folks, > > I have a filesystem that was acting strangely and I have not been able to > pin point the true cause. > The system was a 1ghz P3, 1 gb ram with external 800GB ide to scsi raid. > The scsi HBA is an adaptec 29160 using the aic78xx driver. > > The filesystem (/dev/sdb1) at its best point would allow me to mount it and > I could view files, however this is all that I could do. Any attempt to > write a file would freeze the mount and the machine would have to be reset > to free the mount point. Another raid (/dev/sdc1)in the scsi chain remained > fully usable. Do you have any idea if some changed in the machine configuration during that time or if you noticed other strange behaviour. Did you have a systemcrash? > I was able to do an xfs_check /dev/sdb1 and it went straight back to prompt. > No apparent problems. Restart. Remount. Same behavior; couldn't write > anything... > > So I made sure the fs was unmounted and ran xfs_repair -n /dev/sdb1 and a > whole bunch of errors came up, but it didn't do anything b/c -n option. > Spoke to my Irix guy asking what some of them meant. We decided to run > xfs_repair and try to fix some of these things. This produced a message > saying that the log is messed up and I would have to mount to rerun the log. > The new problem was that I could not mount it anymore. Shutdown checked the > cables, everything was ok. Other Raid was still fine. Doesn't look like a > HW problem ( Though I am convinced it is--- SCSI bios looks good, > /proc/scsi/scsi sees everything, /proc/partitions sees everything..but > HMMM). Have you saved some of the xfs_repair output? The SGI people would probably be able to tell what was wrong with the filesystem. > After wanting to break the thing, I tried again. Same as results as above. > Can't mount if I wanted to, can't run xfs_repair or check. The only option > to run xfs_repair (and where I am going with this) is xfs_repair -L > /dev/sdb1. I understood that this is a potentially dangerous option. But I > didn't have another 800GB volume free to dd onto as b/u. So I ran this. And > it apparently did a lot. After this was run, I ran xfs_repair again to > rebuild the log and then mounted. The great thing is I could mount, read > and write. The terrible thing is that I couldn't see any data. All that > was there was an empty lost and found....., but xfs_check finds a ton of > mismatches and lost inodes. It sounds like it is toast. Maybe a newer xfs_repair will find some data left to repair although I think there is not much left. > As a last ditch I hooked it up to a SGI to see if it could do anything. > From what I can tell all Irix sees is a raw disk. I didn't do any fx stuff > fearing ruining any other chances for recovery. The linux XFS port can currently only read disks with blocksize == pagesize == 4K on ia32. So I am afraid that won't work easily. The FAQ has better description of the caveats, it is possible though. > I think that there is very very small chance to get something back, Any one > have any Ideas???? I'm afraid not, maybe one of the developers has an idea to get something back. The odds are against you. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun May 5 07:42:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45Eg8wJ032273 for ; Sun, 5 May 2002 07:42:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45Eg8IG032272 for linux-xfs-outgoing; Sun, 5 May 2002 07:42:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45Eg3wJ032246 for ; Sun, 5 May 2002 07:42:04 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (Exim 3.34 #1) id 174NCE-0007mq-00 for linux-xfs@oss.sgi.com; Sun, 05 May 2002 08:41:06 -0600 Message-ID: <3CD544D8.3020507@emergence.com> Date: Sun, 05 May 2002 08:42:32 -0600 From: Michael Best User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Latest Redhat is due out soon Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Redhat 7.3 directory quietly hitting various mirrors There is a Redhat 7.3 directory quietly hitting some of the biggest mirrors, so I expect a Redhat announcement very soon, and I heard that some developers have been notified already. I am going to try and find the time to quickly patch skipjack and XFS together in preparation. Rsync can do the binary difference between two files using it's algorithm, is there a similar program to the diff/patch combination that will allow for the generation of a binary diff file that can be distributed? -Mike From owner-linux-xfs@oss.sgi.com Sun May 5 08:22:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45FMRwJ032600 for ; Sun, 5 May 2002 08:22:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45FMRDU032599 for linux-xfs-outgoing; Sun, 5 May 2002 08:22:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ns1.srv.hcvlny.cv.net (ns1.srv.hcvlny.cv.net [167.206.1.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45FMLwJ032572 for ; Sun, 5 May 2002 08:22:21 -0700 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by ns1.srv.hcvlny.cv.net (8.9.3/8.9.1) with ESMTP id LAA05844 for ; Sun, 5 May 2002 11:23:33 -0400 (EDT) Message-ID: <3CD5490D.6EF72D8B@nic.com> Date: Sun, 05 May 2002 11:00:29 -0400 From: John W Reply-To: jwest@nic.com Organization: Long Pond Ind X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Irix and Linux 2.4.18-XFS1.1 strangeness Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Folks, On my Linux client, I see and Irix Server, running 6.5.15m. in Home Dir, I see this happening: zippy1 2% touch abcabc zippy1 3% ls -la abc* ls: No match. zippy1 4% ls -al abcabc -rw-r--r-- 1 westerj users 0 May 4 2002 abcabc zippy1 5%ls -la | grep abc -rw-r--r-- 1 westerj users 0 May 4 16:36 abcabc zippy1 6% Quite puzziing ! Thanks! John Westerdale PS: Zippy runs 2.4.18 with XFS-1.1 patch and is mounted : -------- zippy1 6% more /etc/fstab | grep home crank:/home/westerj /home/westerj nfs rw,bg,vers=3 0 0 -------- crank 1% more /etc/exports | grep home /home crank 2% -- # Inspire Growth # From owner-linux-xfs@oss.sgi.com Sun May 5 08:38:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45Fc2wJ000331 for ; Sun, 5 May 2002 08:38:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45Fc2Mj000330 for linux-xfs-outgoing; Sun, 5 May 2002 08:38:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45FbswJ032767 for ; Sun, 5 May 2002 08:37:54 -0700 Received: from mystery.carb.nist.gov ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GVNA6S00.PE0; Sun, 5 May 2002 11:40:04 -0400 Subject: Re: Irix and Linux 2.4.18-XFS1.1 strangeness From: "Jonathan F. Dill" To: jwest@nic.com Cc: Linux XFS Mailing List In-Reply-To: <3CD5490D.6EF72D8B@nic.com> References: <3CD5490D.6EF72D8B@nic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4.99 Date: 05 May 2002 11:40:44 -0400 Message-Id: <1020613246.5676.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi John, I have seen this problem due to the tcsh RPM that shipped with RH 7.2 and RH 7.1 compiled without O_LARGEFILE and some other flags. I downloaded tcsh-6.11-3mdk.src.rpm from Mandrake Cooker, built and installed it and globs work fine now. I think the link I used to download was: ftp://mirror.phy.bnl.gov/pub/Mandrake-pub/Mandrake-devel/cooker/SRPMS/tcsh-6.11-3mdk.src.rpm On Sun, 2002-05-05 at 11:00, John W wrote: > Folks, > > On my Linux client, I see and Irix Server, running 6.5.15m. > > in Home Dir, I see this happening: > > zippy1 2% touch abcabc > zippy1 3% ls -la abc* > ls: No match. > zippy1 4% ls -al abcabc > -rw-r--r-- 1 westerj users 0 May 4 2002 abcabc > zippy1 5%ls -la | grep abc > -rw-r--r-- 1 westerj users 0 May 4 16:36 abcabc > zippy1 6% > > > Quite puzziing ! > > Thanks! > > John Westerdale > > PS: > Zippy runs 2.4.18 with XFS-1.1 patch and is mounted : > -------- > zippy1 6% more /etc/fstab | grep home > crank:/home/westerj /home/westerj nfs rw,bg,vers=3 0 0 > -------- > crank 1% more /etc/exports | grep home > /home > crank 2% > > -- > # Inspire Growth # > > > -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Sun May 5 08:42:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45Fg5wJ000524 for ; Sun, 5 May 2002 08:42:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45Fg53g000523 for linux-xfs-outgoing; Sun, 5 May 2002 08:42:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from curlew.cs.man.ac.uk (noplay@curlew.cs.man.ac.uk [130.88.13.7]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45Fg1wJ000497 for ; Sun, 5 May 2002 08:42:01 -0700 Received: from sarah.stg.man.ac.uk ([130.88.186.116] helo=xiao) by curlew.cs.man.ac.uk with esmtp (Exim 2.05 #6) id 174OAL-0002cS-00; Sun, 5 May 2002 16:43:13 +0100 Received: from rhowe by xiao with local (Exim 3.35 #1 (Debian)) id 174OAN-0001op-00; Sun, 05 May 2002 16:43:15 +0100 Date: Sun, 5 May 2002 16:43:15 +0100 To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: Latest Redhat is due out soon Message-ID: <20020505154315.GA6867@xiao> References: <3CD544D8.3020507@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD544D8.3020507@emergence.com> From: Russell Howe Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, May 05, 2002 at 08:42:32AM -0600, Michael Best wrote: > is there a similar program to the diff/patch combination that will allow > for the generation of a binary diff file that can be distributed? Debian (woody) has: Package: xdelta Size: 26678 Description: a diff utility which works with binary files XDELTA is a diff utility which works with binary files. That looks like what you want I can't tell if it's the same thing as sourceforge.net/projects/xdelta -- Russell Howe rhowe@wiss.co.uk From owner-linux-xfs@oss.sgi.com Sun May 5 13:59:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45KxSwJ002567 for ; Sun, 5 May 2002 13:59:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45KxS4T002566 for linux-xfs-outgoing; Sun, 5 May 2002 13:59:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45KxLwJ002538 for ; Sun, 5 May 2002 13:59:22 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g45L0VrQ089585; Sun, 5 May 2002 23:00:32 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA01413; Sun, 5 May 2002 23:00:31 +0200 (CEST) Date: Sun, 5 May 2002 23:00:31 +0200 (CEST) From: Seth Mos To: Michael Best cc: Subject: Re: Latest Redhat is due out soon In-Reply-To: <3CD544D8.3020507@emergence.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 5 May 2002, Michael Best wrote: > Redhat 7.3 directory quietly hitting various mirrors > > There is a Redhat 7.3 directory quietly hitting some of the biggest > mirrors, so I expect a Redhat announcement very soon, and I heard that some > developers have been notified already. Official announcemnts first. 7.2 was released with an updated kernel already on the site which introduced some double work. > I am going to try and find the time to quickly patch skipjack and XFS > together in preparation. I think that the kernel parts might be the easier part to do if they have not replaced the VM in this one. Integrating them with the iso might be challenging. Eric Sandeen can help you with this. > Rsync can do the binary difference between two files using it's algorithm, > is there a similar program to the diff/patch combination that will allow > for the generation of a binary diff file that can be distributed? The diff would grow quite large. There are a lot of newer pacakges on the SGI installer discs which are not on the Red Hat Linux discs. Programs like xfsprogs, xfsdump/xfsrestore and the acl utilities. And the big parts are the kernels on the discs which are all different from the Red Hat discs. I think that it's safe to say there is not a lot to save. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun May 5 17:50:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g460oMwJ008208 for ; Sun, 5 May 2002 17:50:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g460oMvO008207 for linux-xfs-outgoing; Sun, 5 May 2002 17:50:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g460oBwJ008179 for ; Sun, 5 May 2002 17:50:11 -0700 Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA3414259 for ; Sun, 5 May 2002 17:51:22 -0700 (PDT) mail_from (t.landschoff@gmx.net) Received: from fwd11.sul.t-online.de by mailout08.sul.t-online.com with smtp id 174PND-0001LY-0P; Sun, 05 May 2002 19:00:35 +0200 Received: from stargate.galaxy (320026820486-0001@[80.134.188.205]) by fmrl11.sul.t-online.com with esmtp id 174PN9-1Eiv32C; Sun, 5 May 2002 19:00:31 +0200 Received: (from torsten@localhost) by stargate.galaxy (8.9.3/8.9.3/Debian 8.9.3-21) id SAA08357; Sun, 5 May 2002 18:46:35 +0200 Date: Sun, 5 May 2002 18:46:35 +0200 From: Torsten Landschoff To: Russell Howe Cc: Michael Best , linux-xfs@oss.sgi.com Subject: Re: Latest Redhat is due out soon Message-ID: <20020505184635.A8250@stargate.galaxy> References: <3CD544D8.3020507@emergence.com> <20020505154315.GA6867@xiao> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020505154315.GA6867@xiao>; from rhowe@wiss.co.uk on Sun, May 05, 2002 at 04:43:15PM +0100 X-Sender: 320026820486-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Russell,=20 On Sun, May 05, 2002 at 04:43:15PM +0100, Russell Howe wrote: > Debian (woody) has: >=20 > Package: xdelta > Size: 26678 > Description: a diff utility which works with binary files > XDELTA is a diff utility which works with binary files. >=20 > That looks like what you want >=20 > I can't tell if it's the same thing as sourceforge.net/projects/xdelta torsten@pulsar:~$ grep http /usr/share/doc/xdelta/copyright=20 It was downloaded from http://sourceforge.net/projects/xdelta=20 That should answer your question ;-)) Greetings Torsten --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE81WHrdQgHtVUb5EcRAkwmAJ0V+qVT/ELmnJ0Ej07srv8NtZ/ixACfQqVX A3U2W/TRVsU7uBMD91+CKRE= =ZRet -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-linux-xfs@oss.sgi.com Sun May 5 20:44:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g463ifwJ009833 for ; Sun, 5 May 2002 20:44:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g463ifu1009832 for linux-xfs-outgoing; Sun, 5 May 2002 20:44:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g463ibwJ009806 for ; Sun, 5 May 2002 20:44:38 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 174ZPb-00085c-00; Sun, 05 May 2002 21:43:43 -0600 Message-ID: <3CD5FC43.1050004@emergence.com> Date: Sun, 05 May 2002 21:45:07 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Torsten Landschoff CC: linux-xfs@oss.sgi.com Subject: XDelta for binary diffs Re: Latest Redhat is due out soon References: <3CD544D8.3020507@emergence.com> <20020505154315.GA6867@xiao> <20020505184635.A8250@stargate.galaxy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes XDelta appears to be the perfect tool. I read part of the author's thesis about it and it appears to be more or less an rsync style diff for arbitrary files including binaries. And XDelta comes with Skipjack/7.3 as well. -Mike From owner-linux-xfs@oss.sgi.com Sun May 5 21:03:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46439wJ010075 for ; Sun, 5 May 2002 21:03:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46439VK010074 for linux-xfs-outgoing; Sun, 5 May 2002 21:03:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from visualfx.dyndns.org (CPE006097a16e12.cpe.net.cable.rogers.com [24.100.158.232]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4642xwJ010048 for ; Sun, 5 May 2002 21:03:01 -0700 Received: from visualfx.dyndns.org (picasso.visualfx.org [192.168.68.5]) by visualfx.dyndns.org (8.11.6/8.11.2) with ESMTP id g464h7P15845; Mon, 6 May 2002 00:43:08 -0400 Message-ID: <3CD6018E.165736E7@visualfx.dyndns.org> Date: Mon, 06 May 2002 00:07:42 -0400 From: Andrew Ho X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-xfs i686) X-Accept-Language: en, zh-TW MIME-Version: 1.0 To: jwest@nic.com CC: linux-xfs@oss.sgi.com Subject: Re: Irix and Linux 2.4.18-XFS1.1 strangeness References: <3CD5490D.6EF72D8B@nic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please try to put the following line to the fstab in zippy. This is for linux. crank:/home/westerj /home/westerj nfs rexec,dev,suid,rw 0 0 Try it, John W wrote: > Folks, > > On my Linux client, I see and Irix Server, running 6.5.15m. > > in Home Dir, I see this happening: > > zippy1 2% touch abcabc > zippy1 3% ls -la abc* > ls: No match. > zippy1 4% ls -al abcabc > -rw-r--r-- 1 westerj users 0 May 4 2002 abcabc > zippy1 5%ls -la | grep abc > -rw-r--r-- 1 westerj users 0 May 4 16:36 abcabc > zippy1 6% > > Quite puzziing ! > > Thanks! > > John Westerdale > > PS: > Zippy runs 2.4.18 with XFS-1.1 patch and is mounted : > -------- > zippy1 6% more /etc/fstab | grep home > crank:/home/westerj /home/westerj nfs rw,bg,vers=3 0 0 > -------- > crank 1% more /etc/exports | grep home > /home > crank 2% > > -- > # Inspire Growth # From owner-linux-xfs@oss.sgi.com Mon May 6 00:45:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g467j8wJ011703 for ; Mon, 6 May 2002 00:45:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g467j8pe011702 for linux-xfs-outgoing; Mon, 6 May 2002 00:45:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g467j1wJ011672 for ; Mon, 6 May 2002 00:45:01 -0700 Received: from bruce.melbourne.sgi.com (root@bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA3614503 for ; Mon, 6 May 2002 00:46:16 -0700 (PDT) mail_from (fsgqa@bruce.melbourne.sgi.com) Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id RAA01237 for linux-xfs@oss.sgi.com; Mon, 6 May 2002 17:46:14 +1000 Date: Mon, 6 May 2002 17:46:14 +1000 From: FSG QA Message-Id: <200205060746.RAA01237@bruce.melbourne.sgi.com> Subject: TAKE - xfstests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 00:44:22 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118292a cmd/xfstests/common.rc - 1.13 - ensure logdev is unmounted, someone may have been using it for manual tests before being auto-qa runs. cmd/xfstests/004 - 1.3 cmd/xfstests/009 - 1.4 cmd/xfstests/015 - 1.4 cmd/xfstests/016 - 1.5 cmd/xfstests/017 - 1.5 cmd/xfstests/018 - 1.8 cmd/xfstests/019 - 1.3 cmd/xfstests/021 - 1.7 cmd/xfstests/029 - 1.3 cmd/xfstests/030 - 1.4 cmd/xfstests/031 - 1.4 cmd/xfstests/032 - 1.3 cmd/xfstests/033 - 1.4 cmd/xfstests/034 - 1.3 cmd/xfstests/041 - 1.8 cmd/xfstests/042 - 1.7 cmd/xfstests/044 - 1.5 cmd/xfstests/045 - 1.3 cmd/xfstests/049 - 1.3 cmd/xfstests/050 - 1.10 cmd/xfstests/052 - 1.4 cmd/xfstests/053 - 1.4 cmd/xfstests/054 - 1.5 cmd/xfstests/062 - 1.13 - tidy mkfs parameterisation, -f option pulled into common.rc. cmd/xfstests/common.dump - 1.35 - fix buglet where .full files are created in / because of a "cd /" in one part of this script. cmd/xfstests/019.out - 1.2 - additional filtering for blocksize!=pagesize. cmd/xfstests/tools/README.auto-qa - 1.7 - minor correction to match current reality. cmd/xfstests/tools/auto-qa - 1.25 - we always set MKFS_OPTIONS and MOUNT_OPTIONS now, if not coming from the environment initially. From owner-linux-xfs@oss.sgi.com Mon May 6 01:11:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g468BbwJ012068 for ; Mon, 6 May 2002 01:11:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g468Bb3T012067 for linux-xfs-outgoing; Mon, 6 May 2002 01:11:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g468BUwJ012039 for ; Mon, 6 May 2002 01:11:31 -0700 Received: from isis.telemach.net (isis.telemach.net [213.143.65.10]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA06908 for ; Mon, 6 May 2002 01:12:33 -0700 (PDT) mail_from (pegasus@telemach.net) Received: from open (TM-68-212.cable.telemach.net [213.143.68.212]) by isis.telemach.net (Postfix) with SMTP id D03A67A11D; Sun, 5 May 2002 23:08:28 +0200 (CEST) Date: Sun, 5 May 2002 23:08:25 +0200 From: Jure Pecar To: Seth Mos Cc: mbest@emergence.com, linux-xfs@oss.sgi.com Subject: Re: Latest Redhat is due out soon Message-Id: <20020505230825.79e24e59.pegasus@telemach.net> In-Reply-To: References: <3CD544D8.3020507@emergence.com> Organization: Select Technology X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-redhat-linux) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.7Ylf1RgHR6:g4?" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=.7Ylf1RgHR6:g4? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 5 May 2002 23:00:31 +0200 (CEST) Seth Mos wrote: > I think that the kernel parts might be the easier part to do if they > have not replaced the VM in this one. Integrating them with > the iso might be challenging. Eric Sandeen can help you with this. > Last i saw the kernels in the rawhide were patched with rmap and o(1) scheduler. -- Jure Pecar --=.7Ylf1RgHR6:g4? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE81Z9OOHUMrcOSg+8RAqwfAJ0cIEtc87Am/pfQJLrS82rF5fUKNgCeKx8a QTCCSySjpO/lM5UFZ+AsqqE= =/fLn -----END PGP SIGNATURE----- --=.7Ylf1RgHR6:g4?-- From owner-linux-xfs@oss.sgi.com Mon May 6 03:08:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46A8bwJ013158 for ; Mon, 6 May 2002 03:08:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46A8bEa013157 for linux-xfs-outgoing; Mon, 6 May 2002 03:08:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46A8UwJ013131 for ; Mon, 6 May 2002 03:08:32 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g46A9hk08549 for linux-xfs@oss.sgi.com.KAV; Mon, 6 May 2002 12:09:43 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g46A9gF08506 for ; Mon, 6 May 2002 12:09:42 +0200 (CEST) Received: from venus.local.navi.pl (localhost.localdomain [127.0.0.1]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g469VRc04782 for ; Mon, 6 May 2002 11:31:28 +0200 Date: Mon, 6 May 2002 11:31:27 +0200 From: Olaf Fr±czyk To: linux-xfs@oss.sgi.com Subject: XFS + preemptible kernel + lock breaking? Message-ID: <20020506093127.GA4615@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Disposition: inline X-Mailer: Balsa 1.3.3 Lines: 10 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, Some time ago I've heard that preemption doesn't work with kernel with XFS. Can somebody confirm it, or is it working now? (kernel 2.4.18). And I would like to know if it is safe to add lock breaking patch. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon May 6 06:13:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46DD0wJ016657 for ; Mon, 6 May 2002 06:13:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46DD0VP016656 for linux-xfs-outgoing; Mon, 6 May 2002 06:13:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46DCvwJ016629 for ; Mon, 6 May 2002 06:12:57 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (Exim 3.34 #1) id 174iHd-0008Kr-00 for linux-xfs@oss.sgi.com; Mon, 06 May 2002 07:12:05 -0600 Message-ID: <3CD6817A.4000604@emergence.com> Date: Mon, 06 May 2002 07:13:30 -0600 From: Michael Best User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Redhat 7.3/Valhalla ISOs appear to be available Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd suggest that if you want Redhat 7.3 ISOs that you get out there and download them now before word leaks out to Slashdot or something. -Mike From owner-linux-xfs@oss.sgi.com Mon May 6 07:00:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46E0EwJ017262 for ; Mon, 6 May 2002 07:00:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46E0EBw017261 for linux-xfs-outgoing; Mon, 6 May 2002 07:00:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46E08wJ017234 for ; Mon, 6 May 2002 07:00:09 -0700 Received: from pclab.cc.kuleuven.ac.be (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id QAA52138 for ; Mon, 6 May 2002 16:01:19 +0200 Message-Id: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 May 2002 16:01:15 +0200 To: linux-xfs@oss.sgi.com From: werner maes Subject: RedHat 7.3 released: installer for XFS 1.1 available? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, It seems that today RedHat released a new version of its operating system: version 7.3 codename Valhalla. I know this question has been asked many times, but will there be an ISO installer for this new, official version? If not, how can you make RedHat 7.3 XFS enabled? Werner From owner-linux-xfs@oss.sgi.com Mon May 6 07:01:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46E1pwJ017343 for ; Mon, 6 May 2002 07:01:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46E1pYs017342 for linux-xfs-outgoing; Mon, 6 May 2002 07:01:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46E1lwJ017310 for ; Mon, 6 May 2002 07:01:47 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 174j4z-0007M3-00; Mon, 06 May 2002 07:03:05 -0700 To: Linux XFS Subject: Re: Redhat 7.3/Valhalla ISOs appear to be available References: <3CD6817A.4000604@emergence.com> From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Message-Flag: Message text advisory: BRAZEN SELF-DECEIT, PROMOTION OF SELF X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Mon, 06 May 2002 15:03:05 +0100 In-Reply-To: <3CD6817A.4000604@emergence.com> (Michael Best's message of "Mon, 06 May 2002 07:13:30 -0600") Message-ID: <6uadrd4bmu.fsf@zork.zork.net> Lines: 11 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence Michael Best quotation: > I'd suggest that if you want Redhat 7.3 ISOs that you get out there > and download them now before word leaks out to Slashdot or something. Too late. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Mon May 6 07:15:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46EFdwJ017792 for ; Mon, 6 May 2002 07:15:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46EFdBS017791 for linux-xfs-outgoing; Mon, 6 May 2002 07:15:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46EFYwJ017765 for ; Mon, 6 May 2002 07:15:35 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 84198401A40; Mon, 6 May 2002 10:16:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 6985BC00EC6; Mon, 6 May 2002 10:16:55 -0400 (EDT) Date: Mon, 6 May 2002 10:16:55 -0400 (EDT) From: Mike Burger To: werner maes Cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.3 released: installer for XFS 1.1 available? In-Reply-To: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The general theme has been that it will be released, once 7.3 was released, and the folks at SGI had time to work it all out. Patience is the watchword. On Mon, 6 May 2002, werner maes wrote: > Hello, > > It seems that today RedHat released a new version of its operating system: > version 7.3 codename Valhalla. > I know this question has been asked many times, but will there be an ISO > installer for this new, official version? > > If not, how can you make RedHat 7.3 XFS enabled? > > Werner > > From owner-linux-xfs@oss.sgi.com Mon May 6 07:17:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46EHqwJ017908 for ; Mon, 6 May 2002 07:17:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46EHqwV017907 for linux-xfs-outgoing; Mon, 6 May 2002 07:17:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46EHkwJ017879 for ; Mon, 6 May 2002 07:17:46 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (Exim 3.34 #1) id 174jIM-0008N2-00; Mon, 06 May 2002 08:16:54 -0600 Message-ID: <3CD690A9.2040506@emergence.com> Date: Mon, 06 May 2002 08:18:17 -0600 From: Michael Best User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en, pdf MIME-Version: 1.0 To: werner maes , linux-xfs@oss.sgi.com Subject: Re: RedHat 7.3 released: installer for XFS 1.1 available? References: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some comments were made regarding integrating XFS 1.1 into 7.3/Skipjack/Valhalla The basic steps appear to be: 1) Update the kernel on the boot image to be an XFS kernel 2) Update the packages on the discs to be XFS kernels and add xfsprogs and acls 3) Update the package lists for the installer The kernel appears to be the hardest one if you want the kernel to have the same features as the Redhat kernel. I'm hoping that the whole process is simple enough that major modification will not be required. The version of anaconda that ships with 7.3 does know about XFS filesystems (according to messages I read on this list). It's just that the installer doesn't use an XFS capable kernel (as far as I know). The skipjack beta contained a Reiser-fs option that was unofficial something like running "linux reiserfs" at the boot prompt. So maybe just adding something like that will be the way to go. Redhat 7.3 now also supports an alternatives system too. Once ISO images including the updated kernel and packages are made, it's likely that XDelta will be used to distribute a patch for the official ISOs. XDelta is a binary/arbitrary patch/diff utility that ships with Redhat 7.3 -Mike werner maes wrote: > Hello, > > It seems that today RedHat released a new version of its operating > system: version 7.3 codename Valhalla. > I know this question has been asked many times, but will there be an ISO > installer for this new, official version? > > If not, how can you make RedHat 7.3 XFS enabled? > > Werner From owner-linux-xfs@oss.sgi.com Mon May 6 07:41:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46EfKwJ018909 for ; Mon, 6 May 2002 07:41:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46EfKtS018908 for linux-xfs-outgoing; Mon, 6 May 2002 07:41:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46EfCwJ018882 for ; Mon, 6 May 2002 07:41:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA16342; Mon, 6 May 2002 09:42:25 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA07720; Mon, 6 May 2002 09:42:25 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id JAA02464; Mon, 6 May 2002 09:42:24 -0500 (CDT) Message-Id: <200205061442.JAA02464@fsgi158.americas.sgi.com> Subject: Re: Irix and Linux 2.4.18-XFS1.1 strangeness To: jwest@nic.com Date: Mon, 6 May 2002 09:42:24 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <3CD5490D.6EF72D8B@nic.com> from "John W" at May 05, 2002 11:00:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've seen this behavior when NOT exporting with the 32bitclients option on the IRIX server and using a linux client. Tad > Folks, > > On my Linux client, I see and Irix Server, running 6.5.15m. > > in Home Dir, I see this happening: > > zippy1 2% touch abcabc > zippy1 3% ls -la abc* > ls: No match. > zippy1 4% ls -al abcabc > -rw-r--r-- 1 westerj users 0 May 4 2002 abcabc > zippy1 5%ls -la | grep abc > -rw-r--r-- 1 westerj users 0 May 4 16:36 abcabc > zippy1 6% > > > Quite puzziing ! > > Thanks! > > John Westerdale > > PS: > Zippy runs 2.4.18 with XFS-1.1 patch and is mounted : > -------- > zippy1 6% more /etc/fstab | grep home > crank:/home/westerj /home/westerj nfs rw,bg,vers=3 0 0 > -------- > crank 1% more /etc/exports | grep home > /home > crank 2% > > -- > # Inspire Growth # > > > From owner-linux-xfs@oss.sgi.com Mon May 6 08:51:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46FppwJ019931 for ; Mon, 6 May 2002 08:51:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46Fppm8019930 for linux-xfs-outgoing; Mon, 6 May 2002 08:51:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46FpkwJ019901 for ; Mon, 6 May 2002 08:51:47 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA04287 for ; Mon, 6 May 2002 10:52:59 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA48350 for ; Mon, 6 May 2002 10:52:59 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id KAA46242 for linux-xfs@oss.sgi.com; Mon, 6 May 2002 10:52:59 -0500 (CDT) Date: Mon, 6 May 2002 10:52:59 -0500 (CDT) From: Dean Roehrich Message-Id: <200205061552.KAA46242@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi test print_event set managed regions Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 08:52:40 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:118320a src/suite1/cmd/print_event.c - 1.5 - set MR bits on newly-created files. swap MR bits on file after a R-W-T event (after a read, the read event is cleared and the write/truncate bits are set; after a write, the write bit is clear and the read bit is set). From owner-linux-xfs@oss.sgi.com Mon May 6 09:34:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46GYSwJ024308 for ; Mon, 6 May 2002 09:34:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46GYSex024307 for linux-xfs-outgoing; Mon, 6 May 2002 09:34:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gate.jobsoft.com (IDENT:Zp1+UctLSQMTTeXsSL8NVcUqjvZXpPjN@gate.jobsoft.com [66.83.54.62]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46GYPwJ024281 for ; Mon, 6 May 2002 09:34:25 -0700 Received: from wrigley.jobsoft.int (wrigley.jobsoft.int [192.168.1.6]) by gate.jobsoft.com (Postfix) with ESMTP id 5B6AF299 for ; Mon, 6 May 2002 11:35:43 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by wrigley.jobsoft.int (Postfix) with ESMTP id DF1F6E538 for ; Mon, 6 May 2002 10:34:57 -0500 (CDT) Received: from balsam.ad.jobsoft.int (unknown [192.168.1.10]) by wrigley.jobsoft.int (Postfix) with ESMTP id 92FDDE533 for ; Mon, 6 May 2002 10:34:57 -0500 (CDT) Subject: XFS Status in the 2.5 series kernel Date: Mon, 6 May 2002 11:32:16 -0500 Message-ID: <212E735D77FCFF4D811D5A8FF999399B0E6A60@balsam.ad.jobsoft.int> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS Status in the 2.5 series kernel X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcH1G9MrwgB4tHxmRTKji7FLxiUYrg== content-class: urn:content-classes:message From: "Vernon A. Fort" To: X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g46GYQwJ024282 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does any one know when the 2.5 kernel will include the xfs file system? Vernon Fort From owner-linux-xfs@oss.sgi.com Mon May 6 09:33:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46GXTwJ024234 for ; Mon, 6 May 2002 09:33:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46GXTXi024231 for linux-xfs-outgoing; Mon, 6 May 2002 09:33:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46GXNwJ024204 for ; Mon, 6 May 2002 09:33:23 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA3563851 for ; Mon, 6 May 2002 09:34:41 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA37136 for ; Mon, 6 May 2002 09:34:10 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id E205213641F for ; Mon, 6 May 2002 09:34:09 -0700 (PDT) Subject: Re: RedHat 7.3 released: installer for XFS 1.1 available? From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 06 May 2002 09:34:09 -0700 Message-Id: <1020702849.417.10.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-06 at 07:16, Mike Burger wrote: > The general theme has been that it will be released, once 7.3 was > released, and the folks at SGI had time to work it all out. For the SGI team: i'm working now at getting 7.3 on the SGI "internal" all-purpose Linux mirror: linux-dist.corp.sgi.com (HTTP, FTP, NFS) Once it's there, it's going to be much easier for you to download it, because it's on SGI's LAN (or WAN, if you're not in Mountain View). > Patience is the watchword. naah!... :-) -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Mon May 6 09:35:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46GZbwJ024393 for ; Mon, 6 May 2002 09:35:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46GZb9Z024392 for linux-xfs-outgoing; Mon, 6 May 2002 09:35:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46GZXwJ024364 for ; Mon, 6 May 2002 09:35:33 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04375 for ; Mon, 6 May 2002 09:36:38 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA52138 for ; Mon, 6 May 2002 09:36:20 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 9BB0B13641F for ; Mon, 6 May 2002 09:36:19 -0700 (PDT) Subject: Re: Irix and Linux 2.4.18-XFS1.1 strangeness From: Florin Andrei To: Linux XFS Mailing List In-Reply-To: <1020613246.5676.6.camel@localhost.localdomain> References: <3CD5490D.6EF72D8B@nic.com> <1020613246.5676.6.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 06 May 2002 09:36:19 -0700 Message-Id: <1020702979.417.12.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-05-05 at 08:40, Jonathan F. Dill wrote: > > I have seen this problem due to the tcsh RPM that shipped with RH 7.2 > and RH 7.1 compiled without O_LARGEFILE and some other flags. Jonathan, Did you filled out a bug report with Red Hat? http://bugzilla.redhat.com/ If not, please do. -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Mon May 6 09:39:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46GdVwJ024753 for ; Mon, 6 May 2002 09:39:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46GdVl6024752 for linux-xfs-outgoing; Mon, 6 May 2002 09:39:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46GdRwJ024725 for ; Mon, 6 May 2002 09:39:28 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA96934 for ; Mon, 6 May 2002 11:40:40 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA77969 for ; Mon, 6 May 2002 11:40:40 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA23493 for linux-xfs@oss.sgi.com; Mon, 6 May 2002 11:40:40 -0500 (CDT) Date: Mon, 6 May 2002 11:40:40 -0500 (CDT) From: Dean Roehrich Message-Id: <200205061640.LAA23493@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi test print_event mimick a minimal hsm Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 09:40:30 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:118329a src/suite1/cmd/print_event.c - 1.6 - Allow print_event to mimick minimal hsm. From owner-linux-xfs@oss.sgi.com Mon May 6 10:03:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46H3PwJ025153 for ; Mon, 6 May 2002 10:03:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46H3P0c025152 for linux-xfs-outgoing; Mon, 6 May 2002 10:03:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from appsales.net ([65.168.244.19]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46H2lwJ025110 for ; Mon, 6 May 2002 10:02:48 -0700 Message-Id: <200205061702.g46H2lwJ025110@oss.sgi.com> Received: (qmail 22978 invoked from network); 6 May 2002 15:13:44 -0000 Received: from unknown (HELO appsales.net) (65.168.244.13) by 0 with SMTP; 6 May 2002 15:13:44 -0000 From: sendout@appsales.net To: Manufacturers@oss.sgi.com Subject: Last Chance! Free links & seats Manuf Prod/Cntl Software $1,495! Reply-To: info@appsales.net Date: 06 May 2002 08:26:03 -0700 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (JMP05502)The Manufacturing/Job Shop Market has never seen an offer like this, and it won't again. We have now set up national distributors, and will not be able to discount Job Master in the future. For the next week only, Job Master, normally $2,495.00, is not only on sale for $1,495.00, but if you order by May 15th, you'll also receive two user licenses and a link to either Peach Tree, QuickBooks or Excel at no charge, an additional thousand dollars savings. (To be removed from our list, Please click on or send an email to: remove@appsales.net. Please put REMOVE as the subject. Our remove system is automated If you do not click on or send an email to:remove@appsales.net and have REMOVE as your subject you will be overlooked for removal by the system) Job Master is designed specifically for small to medium sized manufacturers, and even at our regular price of $2,495.00 costs many thousands of dollars less than any other even remotely comparable software package. Now, if you order by May 15th, you can save over $2,000.00. For our $1, 495.00 special price, you receive not only Job Master at a thousand dollar discount, network ready, but two user licenses and a link to either Peach Tree, QuickBooks or Excel, which normally would be an additional charge of over a thousand dollars. If you've been waiting to upgrade your production control and tracking software or to computerize your operation, now is the time. For the next week, $1,495.00 gets you everything-Job Master network version, two user licenses, and a link to your accounting program or to Excel. Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041. By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of the original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by May 15th, your total price will be $1,495.00 INCLUDING a free link to either Peach Tree, QuickBooks or Excel (a $750.00 value) and two free seats (a $300.00 value). Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne McFarland Link It Software Corp. --------------------------------------------------------------------------- - (To be removed from our list, Please click on or send an email to: remove@appsales.net. Please put REMOVE as the subject. Our remove system is automated If you do not click on or send an email to:remove@appsales.net and have REMOVE as your subject you will be overlooked for removal by the system) --------------------------------------------------------------------------- - From owner-linux-xfs@oss.sgi.com Mon May 6 10:18:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46HImwJ025806 for ; Mon, 6 May 2002 10:18:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46HImtv025805 for linux-xfs-outgoing; Mon, 6 May 2002 10:18:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46HIhwJ025779 for ; Mon, 6 May 2002 10:18:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA19729 for ; Mon, 6 May 2002 12:19:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA49136 for ; Mon, 6 May 2002 12:19:56 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g46HJud20093; Mon, 6 May 2002 12:19:56 -0500 Message-Id: <200205061719.g46HJud20093@stout.americas.sgi.com> Date: Mon, 6 May 2002 12:19:56 -0500 Subject: TAKE - Merge another mkfs mod Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 10:19:32 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118317a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.24 - Merge irix6.5f:irix:118221a Fix the way mkfs round downs the device when the last AG is maller than the minimum AG size. From owner-linux-xfs@oss.sgi.com Mon May 6 10:23:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46HNmwJ026149 for ; Mon, 6 May 2002 10:23:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46HNmAG026148 for linux-xfs-outgoing; Mon, 6 May 2002 10:23:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46HNiwJ026122 for ; Mon, 6 May 2002 10:23:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA14334 for ; Mon, 6 May 2002 12:24:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA56820 for ; Mon, 6 May 2002 12:24:57 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g46HOvQ20734; Mon, 6 May 2002 12:24:57 -0500 Message-Id: <200205061724.g46HOvQ20734@stout.americas.sgi.com> Date: Mon, 6 May 2002 12:24:57 -0500 Subject: TAKE - Modify nfs-related superblock ops Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (This is Steve's change, just checking it in for him). fh_to_dentry and dentry_to_fh are still #ifdef'd out, but this change restricts the inode numbers to 32 bits, since that's all that we have on Linux at this point. We'll try to get some more testing with this change. Date: Mon May 6 10:22:32 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-nfs-fh The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118335a linux/fs/xfs/linux/xfs_super.c - 1.167 - Change fh_to_dentry/dentry_to_fh methods to only use 32 bits of inode number From owner-linux-xfs@oss.sgi.com Mon May 6 11:25:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46IPkwJ027136 for ; Mon, 6 May 2002 11:25:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46IPkpm027135 for linux-xfs-outgoing; Mon, 6 May 2002 11:25:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46IPdwJ027109 for ; Mon, 6 May 2002 11:25:39 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA20307 for ; Mon, 6 May 2002 13:26:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA46460 for ; Mon, 6 May 2002 13:26:52 -0500 (CDT) Subject: Some nfs testing help needed From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 May 2002 13:26:52 -0500 Message-Id: <1020709612.13140.61.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - As has been apparent from previous posts, our users are often able to discover nfs-related bugs before we do, due to the wide variety of environments in which the testing can happen. A change was made a while back to add the fh_to_dentry / dentry_to_fh superblock operations to XFS, which are used for knfsd. The change was quickly #ifdef'd out again when problems cropped up. Some changes have been made since then, and if some brave NFS users could do a bit of testing with this patch (which re-enables the methods), we'd greatly appreciate reports of success or failure. (Please test this against a fresh CVS checkout from today.) Thanks, -Eric --- /linux/fs/xfs/linux/xfs_super.c_1.167 Mon May 6 13:09:29 2002 +++ linux/fs/xfs/linux/xfs_super.c Mon May 6 13:09:23 2002 @@ -826,7 +826,7 @@ return 0; } -#if 0 +#if 1 STATIC int linvfs_dentry_to_fh( struct dentry *dentry, __u32 *data, @@ -935,7 +935,7 @@ statfs: linvfs_statfs, remount_fs: linvfs_remount, -#if 0 +#if 1 fh_to_dentry: linvfs_fh_to_dentry, dentry_to_fh: linvfs_dentry_to_fh, #endif -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 6 12:48:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46JmbwJ028584 for ; Mon, 6 May 2002 12:48:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46JmaRZ028583 for linux-xfs-outgoing; Mon, 6 May 2002 12:48:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46JmUwJ028557 for ; Mon, 6 May 2002 12:48:31 -0700 Received: from modem-73.new-hampshire.dialup.pol.co.uk ([62.137.80.73] helo=moving-picture.com) by cmailg4.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 174oUQ-000672-00; Mon, 06 May 2002 20:49:43 +0100 Message-ID: <3CD6DE81.B7EB9F6E@moving-picture.com> Date: Mon, 06 May 2002 20:50:25 +0100 From: James Pearson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: Linux XFS Mailing List Subject: Re: Irix and Linux 2.4.18-XFS1.1 strangeness References: <3CD5490D.6EF72D8B@nic.com> <1020613246.5676.6.camel@localhost.localdomain> <1020702979.417.12.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I think it already has - see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55095 James Pearson Florin Andrei wrote: > > On Sun, 2002-05-05 at 08:40, Jonathan F. Dill wrote: > > > > I have seen this problem due to the tcsh RPM that shipped with RH 7.2 > > and RH 7.1 compiled without O_LARGEFILE and some other flags. > > Jonathan, > > Did you filled out a bug report with Red Hat? > > http://bugzilla.redhat.com/ > > If not, please do. > > -- > Florin Andrei > > There's nothing to be ashamed of in coming up with the obvious, > especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Mon May 6 15:14:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46MEcwJ029986 for ; Mon, 6 May 2002 15:14:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46MEclk029985 for linux-xfs-outgoing; Mon, 6 May 2002 15:14:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46MEUwJ029959 for ; Mon, 6 May 2002 15:14:31 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g46MFkU03564; Tue, 7 May 2002 00:15:46 +0200 Date: Tue, 7 May 2002 00:15:45 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: lord@sgi.com, linux-xfs@oss.sgi.com Cc: kevin@bigstorage.com Subject: xfs_repair trouble Message-ID: <20020507001545.G18743@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g46MFkU03564 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g46MEWwJ029960 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi We're having some problems with xfs_repair: When using the utilities from Release-1.0.2 we got the following message: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. I've upgraded to the CVS version, and now the error-message is gone, but there is no more output. I've looked briefly on the source, and AFAICT it is working in libxfs_log_clear(); First of all - is this the way it is supposed to work? It has taken a very long time (a couple of hours) with no output (I specified "-v"). Also I think it's strange that it's reading all over the disk (reading invidivual 512 byte blocks starting at the end of the disk and then moving backwards) for clearing the log. Second - is there something that can be done to speed it up? Reading individual 512-byte blocks in the "backwards" order is probably the least effective way to get data of the device! Maybe it would be better to work with bigger chunks of data - or best of all; start at the beginning of the device rather than the end? Thanks. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Mon May 6 19:17:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g472HjwJ031944 for ; Mon, 6 May 2002 19:17:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g472HjEr031943 for linux-xfs-outgoing; Mon, 6 May 2002 19:17:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.linuxone.co.kr ([210.108.91.129]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g472HbwJ031910 for ; Mon, 6 May 2002 19:17:37 -0700 Received: from diylinuxwin2k (unknown [210.108.91.131]) by mail.linuxone.co.kr (Postfix) with SMTP id B28AD5406C for ; Tue, 7 May 2002 11:18:53 +0900 (KST) Message-ID: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> From: "Yu-Chan Park" To: Subject: SAMBA compile errors at XFS kernel.. Date: Tue, 7 May 2002 11:15:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g472HcwJ031911 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello xfs.. I have compiled samba 2.2.4(new release version) with gcc 2.95 or gcc 2.96 version based RedHat 7.2 and kernel 2.4.18 version which patched xfs(release 1.0) But during compiling samba occure compile errors at quota If using kernel not patched xfs samba is compiled as well. How can i escape hell :) ? Thanks.. The errors are.... Compiling smbd/quotas.c smbd/quotas.c:66: warning: `LINUX_QUOTAS_2' redefined include/config.h:238: warning: this is the location of the previous definition In file included from smbd/quotas.c:45: /usr/include/asm/types.h:18: warning: redefinition of `__u32' /usr/include/sys/capability.h:32: warning: `__u32' previously declared here In file included from smbd/quotas.c:57: /usr/include/linux/quota.h:45: parse error before `qid_t' /usr/include/linux/quota.h:45: warning: data definition has no type or storage class /usr/include/linux/quota.h:137: parse error before `__kernel_time_t' /usr/include/linux/quota.h:137: warning: no semicolon at end of struct or union /usr/include/linux/quota.h:138: warning: data definition has no type or storage class /usr/include/linux/quota.h:274: parse error before `qid_t' smbd/quotas.c: In function `get_smb_linux_vfs_quota': smbd/quotas.c:115: storage size of `D' isn't known make: *** [smbd/quotas.o] Error 1 From owner-linux-xfs@oss.sgi.com Mon May 6 19:49:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g472nCwJ032362 for ; Mon, 6 May 2002 19:49:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g472nCNw032361 for linux-xfs-outgoing; Mon, 6 May 2002 19:49:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g472n4wJ032335 for ; Mon, 6 May 2002 19:49:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA2853518 for ; Mon, 6 May 2002 19:50:23 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA18410; Tue, 7 May 2002 12:49:06 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA28375; Tue, 7 May 2002 12:49:05 +1000 (AEST) Date: Tue, 7 May 2002 12:49:04 +1000 From: Nathan Scott To: Jan Kara Cc: Yu-Chan Park , linux-xfs@oss.sgi.com Subject: Re: SAMBA compile errors at XFS kernel.. Message-ID: <20020507124904.M110403@wobbly.melbourne.sgi.com> References: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k>; from super@linuxone.co.kr on Tue, May 07, 2002 at 11:15:45AM +0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Jan, Some more people are hitting this problem with the new VFS quota patches which we have in XFS CVS. Any idea on how we should go about fixing this? Maybe we should fix Samba so as to not include kernel headers (as we do in the quota user tools already), creating a local header for them instead with only the structures/macros they need? thanks. On Tue, May 07, 2002 at 11:15:45AM +0900, Yu-Chan Park wrote: > Hello xfs.. > > I have compiled samba 2.2.4(new release version) with gcc 2.95 or gcc 2.96 version based > RedHat 7.2 and kernel 2.4.18 version which patched xfs(release 1.0) > > But during compiling samba occure compile errors at quota > > If using kernel not patched xfs samba is compiled as well. > > How can i escape hell :) ? > > Thanks.. > > The errors are.... > > Compiling smbd/quotas.c > smbd/quotas.c:66: warning: `LINUX_QUOTAS_2' redefined > include/config.h:238: warning: this is the location of the previous definition > In file included from smbd/quotas.c:45: > /usr/include/asm/types.h:18: warning: redefinition of `__u32' > /usr/include/sys/capability.h:32: warning: `__u32' previously declared here > In file included from smbd/quotas.c:57: > /usr/include/linux/quota.h:45: parse error before `qid_t' > /usr/include/linux/quota.h:45: warning: data definition has no type or storage class > /usr/include/linux/quota.h:137: parse error before `__kernel_time_t' > /usr/include/linux/quota.h:137: warning: no semicolon at end of struct or union > /usr/include/linux/quota.h:138: warning: data definition has no type or storage class > /usr/include/linux/quota.h:274: parse error before `qid_t' > smbd/quotas.c: In function `get_smb_linux_vfs_quota': > smbd/quotas.c:115: storage size of `D' isn't known > make: *** [smbd/quotas.o] Error 1 > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 6 21:33:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g474XQwJ001219 for ; Mon, 6 May 2002 21:33:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g474XQne001218 for linux-xfs-outgoing; Mon, 6 May 2002 21:33:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g474XMwJ001192 for ; Mon, 6 May 2002 21:33:22 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA3440085 for ; Mon, 6 May 2002 21:34:41 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA15184; Tue, 7 May 2002 14:33:22 +1000 (AEST) Date: Tue, 7 May 2002 14:33:22 +1000 From: Timothy Shimmin To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: errno return for setting acls Message-ID: <20020507143322.A1012161@boing.melbourne.sgi.com> References: <20020501045522.T21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020501045522.T21791@plato.local.lan>; from erbenson@alaska.net on Wed, May 01, 2002 at 04:55:22AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ethan, On Wed, May 01, 2002 at 04:55:22AM -0800, Ethan Benson wrote: > > XFS seems to return EACCES instead of EPERM when a user tries to > set/alter an acl on a file they don't own. from looking at the > withdrawn posix spec i believe it should be EPERM, and that is more > consistent with the equivilent; chmod. > Looking at the 1003.1e std. sections 23.4.8.4, 23.4.22.4, ... I would agree with you that EPERM should be returned ih this case. I'll check in the change shortly. Thanks for pointing this out. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Mon May 6 21:38:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g474cMwJ001375 for ; Mon, 6 May 2002 21:38:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g474cMMu001374 for linux-xfs-outgoing; Mon, 6 May 2002 21:38:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g474cJwJ001348 for ; Mon, 6 May 2002 21:38:19 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA08997 for ; Mon, 6 May 2002 21:39:27 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA58282 for linux-xfs@oss.sgi.com; Tue, 7 May 2002 14:38:20 +1000 (EST) Date: Tue, 7 May 2002 14:38:20 +1000 (EST) From: Timothy Shimmin Message-Id: <200205070438.OAA58282@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_acl.c & EPERM Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 21:37:26 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118422a linux/fs/xfs/xfs_acl.c - 1.16 - Return EPERM instead of EACCES if one is not permitted to set or remove an ACL (not owner or no capability). Motivated by email from Ethan Benson and 1003.1e sections 23.4.8.4 & 23.4.22.4 etc. --Tim From owner-linux-xfs@oss.sgi.com Mon May 6 23:52:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g476qawJ002544 for ; Mon, 6 May 2002 23:52:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g476qa2v002543 for linux-xfs-outgoing; Mon, 6 May 2002 23:52:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e159.dsl.mediaWays.net [213.20.225.89]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g476pkwJ002502 for ; Mon, 6 May 2002 23:51:46 -0700 Received: from apollo.berdmann.de ([192.168.1.2]) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 174yqL-0002h9-00 for linux-xfs@oss.sgi.com; Tue, 07 May 2002 08:53:01 +0200 Received: from be by apollo.berdmann.de with local (Exim 3.22 #1) id 174yqL-0000N8-00 for linux-xfs@oss.sgi.com; Tue, 07 May 2002 08:53:01 +0200 X-Sieve: cmu-sieve 2.0 Received: from james.berdmann.de ([192.168.1.1]) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 174pyW-00060o-00 for be@berdmann.de; Mon, 06 May 2002 23:24:52 +0200 Received: from mout01.kundenserver.de ([195.20.224.132]) by james.berdmann.de with esmtp (Exim 3.22 #1) id 174pyW-00044U-00 for be@berdmann.de; Mon, 06 May 2002 23:24:52 +0200 Received: from [212.227.126.147] (helo=mxng04.kundenserver.de) by mout01.kundenserver.de with esmtp (Exim 2.12 #2) id 174pyP-0001Df-00 for be@berdmann.dyndns.org; Mon, 6 May 2002 23:24:45 +0200 Received: from [66.187.233.211] (helo=listman.redhat.com) by mxng04.kundenserver.de with esmtp (Exim 3.22 #2) id 174pyN-00028o-00 for be@berdmann.de; Mon, 06 May 2002 23:24:43 +0200 Received: from listman.redhat.com (localhost.localdomain [127.0.0.1]) by listman.redhat.com (Postfix) with ESMTP id AFC9B3F640; Mon, 6 May 2002 17:22:28 -0400 (EDT) Delivered-To: redhat-announce-list@listman.redhat.com Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by listman.redhat.com (Postfix) with ESMTP id E81B53EB3A for ; Mon, 6 May 2002 17:01:18 -0400 (EDT) Received: from lacrosse.corp.redhat.com (IDENT:root@lacrosse.corp.redhat.com [172.16.52.154]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g46L1H924179 for ; Mon, 6 May 2002 17:01:17 -0400 Received: (from mail@localhost) by lacrosse.corp.redhat.com (8.11.6/8.9.3) id g46L1GS05361 for redhat-announce-list@listman.redhat.com; Mon, 6 May 2002 17:01:16 -0400 Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g46L1Gf05354 for ; Mon, 6 May 2002 17:01:16 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g46L1G924175 for ; Mon, 6 May 2002 17:01:16 -0400 Received: from listman.redhat.com (IDENT:postfix@listman.redhat.com [172.16.48.211]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g46KtuM18865 for ; Mon, 6 May 2002 16:55:56 -0400 Received: from listman.redhat.com (localhost.localdomain [127.0.0.1]) by listman.redhat.com (Postfix) with ESMTP id E07633F59F; Mon, 6 May 2002 16:53:17 -0400 (EDT) Delivered-To: redhat-watch-list@listman.redhat.com Received: from localhost.localdomain (int-mx1.corp.redhat.com [172.16.52.254]) by listman.redhat.com (Postfix) with ESMTP id 4411D3F3D0 for ; Mon, 6 May 2002 16:51:36 -0400 (EDT) Received: from lacrosse.corp.redhat.com (IDENT:root@lacrosse.corp.redhat.com [172.16.52.154]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g46KpY918272 for ; Mon, 6 May 2002 16:51:34 -0400 Received: (from mail@localhost) by lacrosse.corp.redhat.com (8.11.6/8.9.3) id g46KpYL31579 for redhat-watch-list@listman.redhat.com; Mon, 6 May 2002 16:51:34 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g46KpXf31543; Mon, 6 May 2002 16:51:33 -0400 Received: (from notting@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g46KpX219859; Mon, 6 May 2002 16:51:33 -0400 To: redhat-watch-list@redhat.com Subject: Red Hat Unveils Red Hat Linux 7.3 Message-ID: <20020506165133.A16394@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Old-X-Loop: redhat-watch-list@redhat.com X-BeenThere: redhat-watch-list@redhat.com X-Mailman-Version: 2.0.1 X-Loop: redhat-announce-list@redhat.com From: redhat-announce-list-admin@redhat.com Reply-To: redhat-announce-list@redhat.com X-BeenThere: redhat-announce-list@redhat.com List-Help: List-Post: List-Subscribe: , List-Id: Announcements about Red Hat Software List-Unsubscribe: , List-Archive: Date: Mon, 6 May 2002 16:51:33 -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline RALEIGH, NC--May 6, 2002--Red Hat, Inc. (Nasdaq:RHAT) today released Red Hat Linux version 7.3, a highly configurable operating system (OS) designed for deployments ranging from games and personal productivity to file, print and web serving. Red Hat Linux 7.3 adds new productivity tools, personal firewall configuration at installation, and video conferencing software to deliver everything individual users, educational institutions and small businesses need for flexible Internet-based computing. The new version also includes the Linux industry's best support offerings, including Web and telephone access to experts and Red Hat Network, an automated Internet solution for managing Red Hat Linux systems. Nearly five hundred thousand users already leverage Red Hat Network to keep their systems updated and secure. "Small businesses and enthusiasts are looking for a combination of performance, ease-of-use and value in their technology infrastructure, which is hard to find with today's proprietary operating systems," said Paul Cormier, Executive VP Of Engineering, Red Hat. "Red Hat Linux 7.3 delivers this through a combination of open source software, support and automated remote services for confident Internet-based computing." New Features Increase Productivity and Flexibility Red Hat Linux 7.3 delivers cutting-edge open source technologies, new features and updated core components that increase productivity and provide the flexibility and usability users demand. Key features include: * Evolution e-mail client and contact manager; * MrProject project management software, * Mozilla Web browser; * GNOME Meeting video conferencing software; * Apache Web server 1.3; * Firewall configuration; * PostgreSQL relational database management system; and KDE 3.0 and GNOME 1.4 desktops. For complete overview of all Red Hat Linux 7.3 features and benefits, please visit us on the Web at http://www.redhat.com/software/linux/rhl_new_features.html. Rebates, Pricing and Availability Red Hat Linux 7.3 is available at retail on May 15, and orders are currently being taken online at www.redhat.com. Red Hat Linux 7.3 Personal for individual users has a MSRP of $59.95, which includes 30 days of Red Hat Network Basic Service and Web-based support. Red Hat Linux 7.3 Professional for small businesses has an MSRP of $199.95, which adds a systems administrator's CD, 90 days of Red Hat Network Basic Service, 60-day Web-based support and telephone support. Red Hat is also offering competitive and customer upgrade rebates, including $20 off Red Hat Linux 7.3 Professional and $10 off Red Hat Linux 7.3 Personal. ---------------------------------------------------------------------- For download availability, please try the mirror closest to you. The following mirrors have Red Hat Linux 7.3 available (list courtesy Matthias Saou): North America : - ftp://redhat.dulug.duke.edu/pub/redhat/linux/7.3/ (also http and rsync access) - ftp://carroll.cac.psu.edu/pub/linux/distributions/redhat/redhat/linux/7.3/ (also http and rsync access) - ftp://helios.dii.utk.edu/pub/linux/redhat/redhat/linux/7.3/ - ftp://mirror.hiwaay.net/redhat/redhat/linux/7.3/ - ftp://mirror.cs.princeton.edu/pub/mirrors/redhat/linux/7.3/ - ftp://ftp.freshrpms.net/pub/redhat/linux/7.3/ - ftp://uselinux.org/pub/redhat/7.3/ - ftp://ftp.ussg.iu.edu/pub/linux/redhat/redhat/linux/7.3/ - ftp://ftp.shuttleamerica.com/pub/mirrors/redhat/linux/7.3/ (also rsync access) - ftp://mirrors.hpcf.upr.edu/pub/Mirrors/redhat/ftp.redhat.com/linux/7.3/ (also http access) - ftp://acs-mirror.ucsd.edu/linux/redhat/7.3/ - ftp://ftp.cse.buffalo.edu/pub/Linux/redhat/redhat/linux/7.3/ - ftp://mirror.atlantic.net/pub/linux/redhat/ftp.redhat.com/linux/7.3/ - ftp://csociety-ftp.ecn.purdue.edu/pub/redhat/linux/7.3/ (also http and rsync access) - ftp://ftp.webtrek.com/pub/mirrors/redhat/linux/7.3/ - ftp://ftp.crc.ca/ftp/systems/linux/redhat/ftp.redhat.com/linux/7.3/ - ftp://redhat.eyetap.org/linux/7.3/ - ftp://limestone.uoregon.edu/redhat/7.3/ - ftp://ftp.unet.brandeis.edu/pub/redhat/linux/7.3/ - ftp://mirror.atlantic.net/pub/Linux/redhat/ftp.redhat.com/linux/7.3/ - ftp://mirror.cs.wisc.edu/pub/mirrors/linux/redhat/7.3/ - ftp://ftp.dc.aleron.net/pub/linux/redhat/ftp.redhat.com/linux/7.3/ (also http access) Europe : - ftp://ftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/7.3/ - ftp://ftp.uvsq.fr/pub/redhat/redhat/linux/7.3/ - ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.redhat.com/redhat/linux/7.3/ - ftp://ftp.fi.muni.cz/pub/linux/redhat/linux/7.3/ - ftp://gd.tuwien.ac.at/pub/linux/redhat.com/dist/linux/7.3/ (also http and rsync access) - ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.redhat.com/redhat/linux/7.3/ (also http access) - ftp://ftp.rhnet.is/pub/redhat/linux/7.3/ (also http and rsync access) - ftp://tux.cprm.net/pub/ftp.redhat.com/7.3/ - ftp://redhat.tu-bs.de/ftp/pub/linux/redhat/7.3/ (valid reverse DNS record required) - ftp://fr2.rpmfind.net/linux/redhat/7.3/ - ftp://alviss.et.tudelft.nl/pub/redhat/7.3/ - ftp://ftp.di.fct.unl.pt/pub/linux/ftp.redhat.com/redhat/linux/7.3/ - ftp://ftp.puug.pt/linux/ftp.redhat.com/pub/redhat/linux/7.3/ - ftp://ftp.uninett.no/pub/linux/RedHat/redhat/7.3/ - ftp://ftp.linux.is/redhat/linux/7.3/ - ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/redhat/linux/7.3/ (also http) - ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/redhat/linux/7.3 (IPv6-only) - ftp://ftp.strasbourg.linuxfr.org/redhat/7.3/ - ftp://ftp.nluug.nl/pub/os/Linux/distr/RedHat/ftp/redhat/linux/7.3/ - ftp://ftp.cs.huji.ac.il/mirror/linux/redhat/ftp/redhat/linux/7.3/ - ftp://ftp.free.fr/mirrors/ftp.redhat.com/redhat/linux/7.3/ - ftp://sunsite.icm.edu.pl/pub/linux/redhat/linux/7.3/ (also http and rsync access) - ftp://ftp.uni-bayreuth.de/pub/redhat/linux/7.3/ - ftp://ftp.fi.udc.es/mirrors/ftp.redhat.com/linux/7.3/ (also http access) - ftp://ftp.chg.ru/pub/Linux/redhat/linux/7.3/ - ftp://ftp.sunet.se/pub/Linux/distributions/redhat/redhat/linux/7.3/ - ftp://download.xs4all.nl/pub/mirror/redhat/linux/7.3/ South America : - ftp://ftp.sajinet.com.pe/pub/linux/redhat/linux/7.3/ - ftp://mirror.netglobalis.net/pub/redhat/linux/7.3/ (also http access) Australia : - ftp://ftp.planetmirror.com/pub/redhat/linux/7.3/ (also http access) - ftp://mirror.aarnet.edu.au/pub/redhat/linux/7.3/ (also http access, both only from AU/NZ) - ftp://ftp.isl.net.nz/pub/linux/dist/redhat/redhat-7.3/ (only from AU/NZ) - ftp://ftp.netcraft.com.au/pub/redhat/linux/7.3/ Asia : - ftp://ftp.hjc.edu.sg/opensource/linux/redhat/linux/7.3/ - ftp://ftp.singnet.com.sg/opensource/linux/redhat/linux/7.3/ --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=RELEASE-NOTES Content-Transfer-Encoding: 8bit Red Hat Linux 7.3 Release Notes Copyright © 2002 by Red Hat, Inc. _________________________________________________________ Table of Contents - Anaconda/Installer Notes - Kernel Notes - Distribution General Notes - Package Reorganization Anaconda/Installer Notes Boot Loader * On an upgrade, anaconda now defaults to upgrading your current boot loader configuration without creating a new one. If you are still using LILO and wish to migrate to using GRUB, you will need to select the creation of a new boot loader configuration when asked during the upgrade process. _________________________________________________________________ Kickstart * There is a new directive named %include which can be used with kickstart. This allows you to include the contents of other files as a part of your kickstart configuration. These files should either exist in the installer's initial ramdisk (initrd) or be generated dynamically in the %pre section of the kickstart configuration. For more information about anaconda and kickstart configuration, refer to the documentation located at /usr/share/doc/anaconda-7.3/. _________________________________________________________________ Miscellaneous * The standalone upgrade mode (typing linux upgrade at the boot prompt) is no longer supported. * Installation from an NFS directory that contains all of the required ISO files is now supported. Additionally, if a file called updates.img exists in the directory from which you install, then it will be used for Anaconda updates. Refer to the file install-methods.txt in the Anaconda RPM package for detailed information on the various ways to install Red Hat Linux, as well as how to apply Anaconda updates. * ISO images now have an md5sum embedded in them. To test the checksum integrity of an ISO image, type linux mediacheck at the installation boot prompt. The installation program will prompt you to insert a CD and select OK to perform the checksum operation. This checksum operation can be performed on any Red Hat Linux CD and in any order. It is strongly recommended to perform this operation on any Red Hat Linux CD that were created from downloaded ISO images. This procedure only works with CD-based installations. * The log file summarizing your installation is now located in /root as /root/install.log instead of /tmp/install.log. Upgrade logs have also been relocated to /root/upgrade.log. _________________________________________________________________ Kernel Notes Red Hat Linux 7.3 includes the 2.4.18 kernel as well as the following additions and modifications: * Improved scheduler for lower latency and better SMP performance * Support for 802.11Q (VLAN) * Support for S.M.A.R.T. (TM) and other hard disk drive monitoring technologies; in certain cases, hard disk drives employing these technologies will be able to report failure to users ahead of time * LVM (Logical Volume Management) support * USB 2.0 support * LBA48/ATA133 support for drives > 137GB * Support for Cenatek Rocket Drive solid state disks * Older (pre-IDE era) CD-ROM drives are no longer supported. _________________________________________________________________ Distribution General Notes * There are observed issues upgrading Red Hat Linux 6.x, 7.0, 7.1, 7.2, and 7.3 systems running Ximian GNOME. The issue is caused by version overlap between the official Red Hat Linux RPMs and the Ximian RPMs. Please be aware that this is a configuration unsupported by Red Hat. You have several choices in resolving this issue: 1) You may remove Ximian GNOME from your Red Hat Linux system prior to upgrading Red Hat Linux. 2) You may upgrade Red Hat Linux, and then immediately reinstall Ximian GNOME. 3) You may upgrade Red Hat Linux, and then immediately remove all remaining Ximian RPMs, and replace them with the corresponding Red Hat Linux RPMs. You must resolve the version overlap using one of the above methods. Failure to do so will result in an unstable GNOME configuration. * KDE has been updated to 3.0.0 and includes usability enhancements as well as some new applications and features. Anti-aliased fonts may appear to be non-functioning after the upgrade to KDE 3.0.0. This issue is related to a feature addition: Due to the Qt 3.0 update, it is now possible to use anti-aliased and non-antialiased fonts at the same time in Qt applications. Since the default fonts for the KDE desktop environment are bitmap fonts and therefore can not be anti-aliased, just turning on the enable anti-aliased fonts button in KDE will not modify the look of all applications. To get anti-aliased fonts in menus, window titles, etc., change the fonts for these elements (for example, by replacing Helvetica with Helmet and Courier with Lucidatypewriter). * Red Hat Linux now includes a port of the Debian alternatives system, as a way to support multiple packages providing a particular service. Every binary/file that would be in common between the multiple packages is replaced with a symlink to /etc; this then resolves to the version of that file for the alternative in question. For example: /usr/sbin/sendmail -> /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail These symlinks are added and managed by /usr/sbin/alternatives. See man 8 alternatives for more details Currently, Red Hat Linux offers Sendmail and Postfix as two Mail Transport Agent (MTA) alternatives. For print daemon alternatives, the choices are LPRng and CUPS. Note that the configurations for LPRng and CUPS are completely separate. If you switch from one printing system to another, you will have to reconfigure your printers. Similarly, postfix and sendmail have separate configuration files. * XFree86 has been updated to version 4.2.0. Included in this version is new support for the following graphics chipsets: ATI Radeon 7500 (2D/3D), Radeon 8500 (2D) ATI Radeon Mobility M6/M7 (2D/3D) Intel i830 (2D/3D) Matrox G550 nVidia nForce 3DLabs Permedia 4 Older S3 (non-Savage, non-ViRGE) chipsets NOTE: The nVidia GeForce 4 chipset is not supported by the "nv" driver in XFree86 4.2.0. The XFree86 "vesa" driver, which uses a video card's VESA BIOS to initialize video modes, may work as a temporary workaround until official support is available in a future release. * Mozilla has been updated to 0.9.9. This release includes MathML support, javascript profiling, S/MIME support in mail and news, tabbed browsing, LDAP support in the address book, and a large number of bug fixes. * The Evolution mailer/calendar/contact manager has been added. Evolution includes POP, IMAP, and local mail support, iCalendar support for calendaring and scheduling, and integrated contact management and online tasklists. * MrProject, a project management tool, has been added. MrProject supports planning and tracking projects, including Gantt charts, dependencies, and resource allocations. * The GnomeMeeting video conferencing application has been added. GnomeMeeting is an H.323 compliant videoconferencing tool, which supports H.245 tunneling and also an audio-only mode. * Red Hat Linux now supports both Traditional and Simplified Chinese in addition to support for American English, French, German, Italian, Japanese, Korean, and Spanish. * Support for DVD-R, DVD+RW, and DVD-RW drives has been included and is available in the dvdrtools package. * Formatting DocBook XML documents using the XSL stylesheet language is now possible. For more information, refer to the xmlto(1) manual page. * The DocBook document type definitions (DTDs) have been merged into one RPM package called docbook-dtds. * The gPhoto2 package has been added to the distribution. gPhoto2 is a software application and interface library for digital cameras. The gPhoto2 package also includes gtKam, a graphical digital camera interface that uses gPhoto2. Kamera, a Konqueror plugin for digital cameras, has been added, as well. The older gphoto application (0.4.3) is deprecated and may be removed in a future release. * The initscripts now disable DMA on IDE CD-ROMs by default. To enable it, make a /etc/sysconfig/harddisk file that contains USE_DMA=1, where is the device of your disk or CD-ROM (such as hdc). * /sbin/service now changes to the root directory before starting or stopping services. There are also changes in the way /sbin/service handles environment variables. For example, if an init script relies on special environment variables (PATH, etc.), the script needs to explicitly set these variables rather than expecting to inherit them. * The bcm5820 package has been replaced with the hwcrypto package. The hwcrypto package also includes support for the AEP 1000 cryptographic accelerator. * The xscanimage program has been deprecated and may be removed in a future release of Red Hat Linux. The xsane program should be used instead. * The rp3 package has been removed; to configure dial-up access use the redhat-config-network package. * The ircii package has been replaced with the epic package. epic is mostly compatible with ircii scripts and includes more features than ircii. * The mkkickstart package has been removed. The ksconfig program should be used instead; you can also edit the /root/anaconda-ks.cfg generated by the installer. * The patchutils package of utilities for manipulating patch files is now included. Patch files are often used in software development. * The autoconf253 and automake15 packages are included, which updates autoconf to version 2.53 and automake to version 1.5 for those who need updated development environments. * The glibc-kernheaders package has been added and will replace the kernel-headers package. * The postgresql package has been updated. To preserve your data, dump the data using the pg_dumpall command before upgrading, then restore the data after the upgrade is complete. Refer to the pg_dumpall(1) man page for more information. * The Red Hat Network Panel Applet is included on GNOME desktop panels by default. This applet allows you to receive Red Hat Network notices and download updates for your Red Hat Linux system. Note that the Red Hat Network Panel Applet does not appear on your GNOME desktop panel if you have upgraded from a previous version of Red Hat Linux. To add this to your panel, choose the following: Main Menu => Applets => Monitors => Red Hat Network Alert Notification Tool _________________________________________________________________ Package Reorganization The following applications and packages not previously mentioned have been removed from Red Hat Linux 7.3: * enlightenment * ext2ed * fnlib * gnome-pim * isapnptools * kaffe * libodbc++ * linuxconf * lout * mawk * p2c * ttfm * xmorph * xmailbox * xrn * xsysinfo The following applications and packages are deprecated and may be removed from a future version of Red Hat Linux: * Netscape Communicator 4.7 * XFree86 3.3.x * junkbuster --Q68bSM7Ycu6FN28Q-- _______________________________________________ Redhat-watch-list mailing list To unsubscribe, visit: https://listman.redhat.com/mailman/listinfo/redhat-watch-list _______________________________________________ redhat-announce-list mailing list redhat-announce-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-announce-list From owner-linux-xfs@oss.sgi.com Tue May 7 00:36:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g477aHwJ003783 for ; Tue, 7 May 2002 00:36:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g477aHoQ003782 for linux-xfs-outgoing; Tue, 7 May 2002 00:36:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g477aEwJ003756 for ; Tue, 7 May 2002 00:36:14 -0700 Received: from misie.k.pl (exim@arm.t19.ds.pwr.wroc.pl [156.17.236.105]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA05721 for ; Tue, 7 May 2002 00:37:18 -0700 (PDT) mail_from (misiek@pld.ORG.PL) Received: from amavis by misie.k.pl with scanned-ok (Exim 4.04) id 174zNM-00081h-00 for linux-xfs@oss.sgi.com; Tue, 07 May 2002 09:27:08 +0200 Received: from misiek by misie.k.pl with local (Exim 4.04) id 174zNI-000814-00; Tue, 07 May 2002 09:27:04 +0200 To: "Yu-Chan Park" Cc: Subject: Re: SAMBA compile errors at XFS kernel.. References: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> X-Attribution: arekm X-URL: http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ Organization: PLD Linux Distribution Team From: Arkadiusz Miskiewicz Date: 07 May 2002 09:27:04 +0200 In-Reply-To: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> Message-ID: <87g0145sfr.fsf@arm.t19.ds.pwr.wroc.pl> Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 X-Virus-Scanned: by AMaViS (PLD) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g477aEwJ003757 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Yu-Chan Park" writes: > But during compiling samba occure compile errors at quota Maybe try this one (against samba 2.2.3): http://cvs.pld.org.pl/SOURCES/samba-quota.patch?rev=1.1 -- Arkadiusz Mi¶kiewicz IPv6 ready PLD Linux at http://www.pld.org.pl misiek(at)pld.org.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr From owner-linux-xfs@oss.sgi.com Tue May 7 03:16:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47AGOwJ005654 for ; Tue, 7 May 2002 03:16:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47AGOUO005653 for linux-xfs-outgoing; Tue, 7 May 2002 03:16:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47AG8wJ005626 for ; Tue, 7 May 2002 03:16:09 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 79B89401A40; Tue, 7 May 2002 05:40:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7801EC00EC6; Tue, 7 May 2002 05:40:32 -0400 (EDT) Date: Tue, 7 May 2002 05:40:32 -0400 (EDT) From: Mike Burger To: Florin Andrei Cc: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.3 released: installer for XFS 1.1 available? In-Reply-To: <1020702849.417.10.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Of course, since it'll be on an internal server, we'll be kinda hosed out here. On 6 May 2002, Florin Andrei wrote: > On Mon, 2002-05-06 at 07:16, Mike Burger wrote: > > The general theme has been that it will be released, once 7.3 was > > released, and the folks at SGI had time to work it all out. > > For the SGI team: i'm working now at getting 7.3 on the SGI "internal" > all-purpose Linux mirror: > > linux-dist.corp.sgi.com (HTTP, FTP, NFS) > > Once it's there, it's going to be much easier for you to download it, > because it's on SGI's LAN (or WAN, if you're not in Mountain View). > > > Patience is the watchword. > > naah!... :-) > > From owner-linux-xfs@oss.sgi.com Tue May 7 03:25:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47APTwJ005863 for ; Tue, 7 May 2002 03:25:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47APTZ0005862 for linux-xfs-outgoing; Tue, 7 May 2002 03:25:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from atlantel.fr (geo.atlantel.fr [194.206.120.243]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47APOwJ005835 for ; Tue, 7 May 2002 03:25:24 -0700 Received: from geo (unverified [194.206.120.243]) by atlantel.org (Rockliffe SMTPRA 5.2.3) with SMTP id for ; Tue, 7 May 2002 12:15:02 +0200 Received: FROM marguerite.atlantel.fr BY geo ; Tue May 07 12:15:01 2002 +0200 Received: from admhugo (adm-hugo.atl.net [10.1.2.193]) by marguerite.atlantel.fr (Postfix) with SMTP id 9AC36B6ED6 for ; Tue, 7 May 2002 12:15:01 +0200 (CEST) Message-ID: <004601c1f5b0$0c9bc970$c102010a@atl.net> From: "Hugo Lafargue" To: References: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> <3CD690A9.2040506@emergence.com> Subject: Exporting xfs over nfs Date: Tue, 7 May 2002 12:15:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just installed a cluster of 2 nodes to provide High Availability NFS/Samba service with Hearbeat (0.4.9.1). The exported filesystem is XFS. The kernel is 2.4.18 patched with xfs-1.1 When I stop Heartbeat daemon on the nodeA, the shared ip swithes to the nodeB, and samba clients still access the files. But, I'm now observing that after failover, nfs clients are unable to use the filesystem exported by the backup server until I unmount it and mount it again. Otherwise, I get "stale NFS file handle" messages. Is this a known issue? Is there a way to fix it ? I find on google that there was a known issue with exporting ReiserFS over NFS, but it seems to be please let me know. regards, Hugo. From owner-linux-xfs@oss.sgi.com Tue May 7 03:46:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47AkMwJ015157 for ; Tue, 7 May 2002 03:46:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47AkM3N015156 for linux-xfs-outgoing; Tue, 7 May 2002 03:46:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47AkFwJ015130 for ; Tue, 7 May 2002 03:46:16 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g47AlU726759; Tue, 7 May 2002 12:47:30 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdX1UyoD; Tue May 7 12:47:22 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g47AlLJ02734; Tue, 7 May 2002 12:47:21 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g47AlL814407; Tue, 7 May 2002 12:47:21 +0200 Date: Tue, 7 May 2002 12:47:21 +0200 From: Utz Lehmann To: Olaf Fr?czyk Cc: linux-xfs@oss.sgi.com Subject: Re: XFS + preemptible kernel + lock breaking? Message-ID: <20020507124721.D10218@de.tecosim.com> References: <20020506093127.GA4615@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20020506093127.GA4615@venus.local.navi.pl>; from olaf@cbk.poznan.pl on Mon, May 06, 2002 at 11:31:27AM +0200 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I'm using the preempt patch since 2.4.9 with linux-xfs, and the lockbreak patch since 2.4.16. Mostly without problems. Some weeks ago there were 2.4.18 xfs kernel which had "exit with preempt_count" errors. Newer CVS kernels are fine. Using the preempt (and lockbreak) patch and nice the X server to -10 give a great interactive performance. utz Olaf Fr?czyk [olaf@cbk.poznan.pl] wrote: > Hi All, > > Some time ago I've heard that preemption doesn't work with kernel with > XFS. > Can somebody confirm it, or is it working now? (kernel 2.4.18). > And I would like to know if it is safe to add lock breaking patch. > > Regards, > > Olaf Fraczyk > From owner-linux-xfs@oss.sgi.com Tue May 7 04:16:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47BGEwJ016027 for ; Tue, 7 May 2002 04:16:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47BGDCr016026 for linux-xfs-outgoing; Tue, 7 May 2002 04:16:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47BG4wJ015999 for ; Tue, 7 May 2002 04:16:05 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g47BHCI26884; Tue, 7 May 2002 13:17:12 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdrjebXn; Tue May 7 13:17:09 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g47BH7J04440; Tue, 7 May 2002 13:17:08 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g47BH7R01621; Tue, 7 May 2002 13:17:07 +0200 Date: Tue, 7 May 2002 13:17:07 +0200 From: Utz Lehmann To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Some nfs testing help needed Message-ID: <20020507131707.A1340@de.tecosim.com> References: <1020709612.13140.61.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <1020709612.13140.61.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Mon, May 06, 2002 at 01:26:52PM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric I have compiled a today CVs kernel with this patch for my workstation. I can test it with linux 2.2, 2.4, HP-UX 10.20, 11.0 and older IRIX 6.5 clients. For what errors should i look? utz Eric Sandeen [sandeen@sgi.com] wrote: > Hi all - > > As has been apparent from previous posts, our users are often able to > discover nfs-related bugs before we do, due to the wide variety of > environments in which the testing can happen. > > A change was made a while back to add the fh_to_dentry / dentry_to_fh > superblock operations to XFS, which are used for knfsd. The change was > quickly #ifdef'd out again when problems cropped up. > > Some changes have been made since then, and if some brave NFS users > could do a bit of testing with this patch (which re-enables the > methods), we'd greatly appreciate reports of success or failure. > > (Please test this against a fresh CVS checkout from today.) > > Thanks, > > -Eric > > --- /linux/fs/xfs/linux/xfs_super.c_1.167 Mon May 6 13:09:29 2002 > +++ linux/fs/xfs/linux/xfs_super.c Mon May 6 13:09:23 2002 > @@ -826,7 +826,7 @@ > return 0; > } > > -#if 0 > +#if 1 > STATIC int linvfs_dentry_to_fh( > struct dentry *dentry, > __u32 *data, > @@ -935,7 +935,7 @@ > statfs: linvfs_statfs, > remount_fs: linvfs_remount, > > -#if 0 > +#if 1 > fh_to_dentry: linvfs_fh_to_dentry, > dentry_to_fh: linvfs_dentry_to_fh, > #endif > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 04:22:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47BM5wJ016228 for ; Tue, 7 May 2002 04:22:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47BM5hi016227 for linux-xfs-outgoing; Tue, 7 May 2002 04:22:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47BLmwJ016198 for ; Tue, 7 May 2002 04:21:49 -0700 Received: from warp9.koschikode.com (pD9E0E731.dip.t-dialin.net [217.224.231.49]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id B5F72F516; Tue, 7 May 2002 13:22:52 +0200 (CEST) Received: from localhost (localhost.koschikode.com [127.0.0.1]) by warp9.koschikode.com (Postfix) with SMTP id 15761B8; Tue, 7 May 2002 13:22:41 +0200 (CEST) Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id AA685A9; Tue, 7 May 2002 13:22:39 +0200 (CEST) Message-ID: <3CD7B8FF.3000604@koschikode.com> Date: Tue, 07 May 2002 13:22:39 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugo Lafargue Cc: linux-xfs@oss.sgi.com Subject: Re: Exporting xfs over nfs References: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> <3CD690A9.2040506@emergence.com> <004601c1f5b0$0c9bc970$c102010a@atl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hugo Lafargue wrote: > Hi, > > I just installed a cluster of 2 nodes to provide High Availability NFS/Samba > service with Hearbeat (0.4.9.1). > The exported filesystem is XFS. > The kernel is 2.4.18 patched with xfs-1.1 > > When I stop Heartbeat daemon on the nodeA, the shared ip swithes to the > nodeB, and samba clients still access the files. > > But, I'm now observing that after failover, nfs clients are unable to use > the filesystem exported by the backup server until I unmount it and mount > it again. Otherwise, I get "stale NFS file handle" messages. > > Is this a known issue? Is there a way to fix it ? > > I find on google that there was a known issue with exporting ReiserFS over > NFS, but it seems to be There are some things that you need to care about to make this work: The exported file systems must have the same major/minor device number on both nodes. Also /var/lib/nfs should be on a shared file system used by both nodes. And you might need to run the latest nfs-utils (or maybe even the cvs version) to be able to tell the nfsd that it should use the cluster name (the DNS name corresponding to the shared IP) instead of the node name. Search the archives of the linux-ha and linux-ha-dev lists at http://marc.theaimsgroup.com/?l=linux-ha and http://marc.theaimsgroup.com/?l=linux-ha-dev for more details. [any comments, Ragnar?] Cheers, Juri From owner-linux-xfs@oss.sgi.com Tue May 7 04:56:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47BupwJ016652 for ; Tue, 7 May 2002 04:56:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47BupKB016651 for linux-xfs-outgoing; Tue, 7 May 2002 04:56:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47BuewJ016623 for ; Tue, 7 May 2002 04:56:41 -0700 Received: from starfleet.attglobal.net (slip-32-101-12-229.wi.us.prserv.net[32.101.12.229]) by prserv.net (out2) with ESMTP id <2002050711334420201om6ide>; Tue, 7 May 2002 11:33:45 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g472a4O29793 for linux-xfs@oss.sgi.com; Mon, 6 May 2002 21:36:04 -0500 X-Authentication-Warning: starfleet.attglobal.net: skylar set sender to skylar@attglobal.net using -f Date: Mon, 6 May 2002 21:36:04 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: SAMBA compile errors at XFS kernel.. Message-ID: <20020507023604.GA25983@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> User-Agent: Mutt/1.3.99i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 25 2002 16:11:05) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2002 at 11:15:45AM +0900, Yu-Chan Park wrote: > ?????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ???????????????????????????????????????????????????????????????????????????= ?????????????????????????????? You might want to try posting with an ISO-8859 character set; most Western Hemisphere denizens do not have support for this (I am assuming it is an Asian script). --=20 -- Skylar Thompson (skylar@attglobal.net) --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE81z2TnMU1m27tfjARAok6AJ9NPc9lBsC5e4oP6ikkhaJo6lSCqgCfSDS2 YT6U6bQIYr8+xWqfGvqLLUo= =Iili -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-linux-xfs@oss.sgi.com Tue May 7 05:13:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47CDOwJ017159 for ; Tue, 7 May 2002 05:13:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47CDOaa017158 for linux-xfs-outgoing; Tue, 7 May 2002 05:13:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47CDEwJ017132 for ; Tue, 7 May 2002 05:13:15 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 1753rY-00048j-00; Tue, 07 May 2002 05:14:36 -0700 To: Linux XFS Subject: Re: SAMBA compile errors at XFS kernel.. References: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> <20020507023604.GA25983@starfleet.attglobal.net> From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Message-Flag: Message text advisory: MISMATCHED PARENTHESES, NON-SEQUITUR X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Tue, 07 May 2002 13:14:35 +0100 In-Reply-To: <20020507023604.GA25983@starfleet.attglobal.net> (Skylar Thompson's message of "Mon, 6 May 2002 21:36:04 -0500") Message-ID: <6uk7qgw3x0.fsf@zork.zork.net> Lines: 50 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence Skylar Thompson quotation: > On Tue, May 07, 2002 at 11:15:45AM +0900, Yu-Chan Park wrote: > You might want to try posting with an ISO-8859 character set; most > Western Hemisphere denizens do not have support for this (I am > assuming it is an Asian script). Gnus seemed to decode it okay. Here is the text: commence Yu-Chan Park quotation: > Hello xfs.. > > I have compiled samba 2.2.4(new release version) with gcc 2.95 or > gcc 2.96 version based RedHat 7.2 and kernel 2.4.18 version which > patched xfs(release 1.0) > > But during compiling samba occure compile errors at quota > > If using kernel not patched xfs samba is compiled as well. > > How can i escape hell :) ? > > Thanks.. > > The errors are.... > > Compiling smbd/quotas.c > smbd/quotas.c:66: warning: `LINUX_QUOTAS_2' redefined > include/config.h:238: warning: this is the location of the previous definition > In file included from smbd/quotas.c:45: > /usr/include/asm/types.h:18: warning: redefinition of `__u32' > /usr/include/sys/capability.h:32: warning: `__u32' previously declared here > In file included from smbd/quotas.c:57: > /usr/include/linux/quota.h:45: parse error before `qid_t' > /usr/include/linux/quota.h:45: warning: data definition has no type or storage class > /usr/include/linux/quota.h:137: parse error before `__kernel_time_t' > /usr/include/linux/quota.h:137: warning: no semicolon at end of struct or union > /usr/include/linux/quota.h:138: warning: data definition has no type or storage class > /usr/include/linux/quota.h:274: parse error before `qid_t' > smbd/quotas.c: In function `get_smb_linux_vfs_quota': > smbd/quotas.c:115: storage size of `D' isn't known > make: *** [smbd/quotas.o] Error 1 > -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Tue May 7 06:39:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47DdOwJ026535 for ; Tue, 7 May 2002 06:39:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47DdNNQ026534 for linux-xfs-outgoing; Tue, 7 May 2002 06:39:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47DdDwJ026429 for ; Tue, 7 May 2002 06:39:19 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA93421; Tue, 7 May 2002 08:40:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA20548; Tue, 7 May 2002 08:40:30 -0500 (CDT) Date: Tue, 7 May 2002 08:40:29 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Utz Lehmann cc: linux-xfs@oss.sgi.com Subject: Re: Some nfs testing help needed In-Reply-To: <20020507131707.A1340@de.tecosim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Utz - When this was enabled before, there were a couple reports of oopses, null pointer dereferences, and the like. I'm guessing it happened under load. Thanks, -Eric On Tue, 7 May 2002, Utz Lehmann wrote: > Hi Eric > > I have compiled a today CVs kernel with this patch for my workstation. I > can test it with linux 2.2, 2.4, HP-UX 10.20, 11.0 and older IRIX 6.5 > clients. For what errors should i look? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 07:00:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47E0lwJ031168 for ; Tue, 7 May 2002 07:00:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47E0lHG031167 for linux-xfs-outgoing; Tue, 7 May 2002 07:00:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47E0cwJ031141 for ; Tue, 7 May 2002 07:00:39 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47E1vg24944; Tue, 7 May 2002 16:01:57 +0200 Date: Tue, 7 May 2002 16:01:57 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: lord@sgi.com, linux-xfs@oss.sgi.com Cc: kevin@bigstorage.com Subject: Re: xfs_repair trouble Message-ID: <20020507160157.M18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020507001545.G18743@vestdata.no>; from ragnar@bigstorage.com on Tue, May 07, 2002 at 12:15:45AM +0200 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47E1vg24944 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47E0ewJ031142 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 12:15:45AM +0200, Ragnar Kjørstad wrote: > I've upgraded to the CVS version, and now the error-message is gone, but > there is no more output. I've looked briefly on the source, and AFAICT > it is working in libxfs_log_clear(); Actually it didn't even get that far. The backtrace is: #0 0x40120264 in __llseek (fd=4, offset=952422534144, whence=0) at ../sysdeps/unix/sysv/linux/llseek.c:37 #1 0x0807551c in libxfs_readbufr (dev=2065, blkno=1860200262, buf=0x80ed528, len=1, die=1) at rdwr.c:195 #2 0x080a0a52 in xlog_find_tail (log=0xbffff3f0, head_blk=0xbffff3e0, tail_blk=0xbffff3e8, readonly=0) at xfs_log_recover.c:548 #3 0x0805fdee in zero_log (mp=0xbffff4c0) at phase2.c:67 #4 0x0805ffa3 in phase2 (mp=0xbffff4c0) at phase2.c:138 #5 0x08073405 in main (argc=3, argv=0xbffff744) at xfs_repair.c:478 #6 0x4004f507 in __libc_start_main (main=0x8073238
, argc=3, ubp_av=0xbffff744, init=0x8048bd0 <_init>, fini=0x80a24a0 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff73c) at ../sysdeps/generic/libc-start.c:129 And the variables in xlog_find_tail: (this is not the initial values, but the data after running a while) 2: *log = {l_tail_lsn = 1555200034, l_last_sync_lsn = 8869107466752, l_mp = 0x0, l_dev = 0, l_logBBstart = 580635924371603456, l_logsize = -1303633567, l_logBBsize = 1683758742, l_curr_cycle = 658578423, l_prev_cycle = 1930723645, l_curr_block = -1629678499, l_prev_block = 1488263099, l_iclog_size = 859122733, l_iclog_size_log = -1462469193, l_iclog_bufs = 827354497, l_grant_reserve_cycle = 1914757874, l_grant_reserve_bytes = -1837674487, l_grant_write_cycle = 499151154, l_grant_write_bytes = 903190826} 3: *head_blk = 970809832858919324 4: *tail_blk = 4612568755539746816 Now, that doesn't really tell me anything, but hopefully someone that know xfs better will be able to tell if this looks right or not? The filesystem is ~ 0.8 TB, btw. And it's still going.... (now it has been running for 15 hours) -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Tue May 7 07:25:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47EP8wJ031564 for ; Tue, 7 May 2002 07:25:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47EP8lj031563 for linux-xfs-outgoing; Tue, 7 May 2002 07:25:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47EOwwJ031531 for ; Tue, 7 May 2002 07:24:58 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA95807; Tue, 7 May 2002 09:26:14 -0500 (CDT) Received: from sgi.com (2HqwEcIVbP6U08agzu337x5504BOGebW@cf-vpn-sw-corp-64-8.corp.sgi.com [134.15.64.8]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA56785; Tue, 7 May 2002 09:26:13 -0500 (CDT) Message-ID: <3CD7E4E5.2070008@sgi.com> Date: Tue, 07 May 2002 09:29:57 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= CC: linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble References: <20020507001545.G18743@vestdata.no> <20020507160157.M18743@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ragnar Kjxrstad wrote: >On Tue, May 07, 2002 at 12:15:45AM +0200, Ragnar Kjxrstad wrote: > >>I've upgraded to the CVS version, and now the error-message is gone, but >>there is no more output. I've looked briefly on the source, and AFAICT >>it is working in libxfs_log_clear(); >> > >Actually it didn't even get that far. The backtrace is: >#0 0x40120264 in __llseek (fd=4, offset=952422534144, whence=0) > at ../sysdeps/unix/sysv/linux/llseek.c:37 >#1 0x0807551c in libxfs_readbufr (dev=2065, blkno=1860200262, >buf=0x80ed528, > len=1, die=1) at rdwr.c:195 >#2 0x080a0a52 in xlog_find_tail (log=0xbffff3f0, head_blk=0xbffff3e0, > tail_blk=0xbffff3e8, readonly=0) at xfs_log_recover.c:548 >#3 0x0805fdee in zero_log (mp=0xbffff4c0) at phase2.c:67 >#4 0x0805ffa3 in phase2 (mp=0xbffff4c0) at phase2.c:138 >#5 0x08073405 in main (argc=3, argv=0xbffff744) at xfs_repair.c:478 >#6 0x4004f507 in __libc_start_main (main=0x8073238
, argc=3, > ubp_av=0xbffff744, init=0x8048bd0 <_init>, fini=0x80a24a0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff73c) > at ../sysdeps/generic/libc-start.c:129 > >And the variables in xlog_find_tail: (this is not the initial values, >but the data after running a while) >2: *log = {l_tail_lsn = 1555200034, l_last_sync_lsn = 8869107466752, > l_mp = 0x0, l_dev = 0, l_logBBstart = 580635924371603456, > l_logsize = -1303633567, l_logBBsize = 1683758742, l_curr_cycle = 658578423, > l_prev_cycle = 1930723645, l_curr_block = -1629678499, > l_prev_block = 1488263099, l_iclog_size = 859122733, > l_iclog_size_log = -1462469193, l_iclog_bufs = 827354497, > l_grant_reserve_cycle = 1914757874, l_grant_reserve_bytes = -1837674487, > l_grant_write_cycle = 499151154, l_grant_write_bytes = 903190826} > >3: *head_blk = 970809832858919324 > >4: *tail_blk = 4612568755539746816 > >Now, that doesn't really tell me anything, but hopefully someone that >know xfs better will be able to tell if this looks right or not? The >filesystem is ~ 0.8 TB, btw. > >And it's still going.... (now it has been running for 15 hours) > > > > Put it out of it's misery, it must be in some form of endless loop, there also appears to be data corruption, that l_mp value is not supposed to be NULL, it is supposed to be the first argument of zero_log. Once this was gone, all bets are off. I would say the problem originates higher up the process somewhere. can you print out the contents of the mp argument of zero_log, and dump the super block from the disk using xfs_db: xfs_db -r /dev/xxxx sb 0 p quit Thanks Steve From owner-linux-xfs@oss.sgi.com Tue May 7 07:28:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47ES6wJ031762 for ; Tue, 7 May 2002 07:28:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47ES60e031761 for linux-xfs-outgoing; Tue, 7 May 2002 07:28:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47ERowJ031728 for ; Tue, 7 May 2002 07:27:50 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA04609 for ; Tue, 7 May 2002 07:29:00 -0700 (PDT) mail_from (wlang@wu-wien.ac.at) Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g47E3gt06503; Tue, 7 May 2002 16:03:42 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15575.57022.571520.335291@slime.wu-wien.ac.at> Date: Tue, 7 May 2002 16:03:42 +0200 To: linux-xfs@oss.sgi.com Subject: Re: xfs_repair trouble In-Reply-To: <20020507001545.G18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> X-Mailer: VM 7.03 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id HAA04609 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47ERowJ031730 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Ragnar Kjørstad: > When using the utilities from Release-1.0.2 we got the following > message: > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: > Assertion `start_blk != 0 || *last_blk != start_blk' failed. > > I've upgraded to the CVS version, and now the error-message is gone, but Cool, these are _exactly_ the same phenomena, we observed the last two weeks... What we found out so far: The problem begins, as xfs_repair tries the find the head- and tail block of the log, specifically in "xlog_find_zeroed" Here is the call stack: main phase2 zero_log xlog_find_tail xlog_find_head xlog_find_zeroed If i understand correctly, xlog_find_zeroed should return the first block with cycle number 0. Unfortunatily, under some circumstances[1], it doesnt set "blk_no", and leaves it to the value it has from the auto declaration. In our case, this is: (gdb) p *blk_no $1 = 970809832858808788 (which is rather large...) Later on, back in "xlog_find_tail", when *blk_no has become head_blk, we have this for loop: /* * Search backwards looking for log record header block */ ASSERT(*head_blk < INT_MAX); for (i=(int)(*head_blk)-1; i>=0; i--) { if ((error = xlog_bread(log, i, 1, bp))) goto bread_err; if (INT_GET(*(uint *)(XFS_BUF_PTR(bp)), ARCH_CONVERT) == XLOG_HEADEC_NUM) { found = 1; break; } } Now, with the above value in *head_blk (truncated to 4 byte), this loop runs several hours (as Ragnar Kjørstad observed), reading blocks from the filesystem. [1] now for the "some circumstances" in "xlog_find_zeroed" These are the last lines of this function: if ((error = xlog_find_verify_log_record(log, start_blk, &last_blk, 0))) goto bp_err; *blk_no = last_blk; bp_err: xlog_put_bp(bp); if (error) return error; return -1; } /* xlog_find_zeroed */ If "xlog_find_verify_log_record" returns -1, it jumps over the assignment "*blk_no = last_blk" and returns "error" (which, in this case is -1). So we have the case that "xlog_find_zeroed" returns -1, in spite of the fact that *blk_no is _not_ set. But, according to the comment of the function: * Return: * 0 => the log is completely written to * -1 => use *blk_no as the first block of the log * >0 => error has occurred */ My conclusion was, that the log is corrupt in such a way, that xfs_repair can't handle it. I decided to forget the data in the log, and tried to deleted it: (gdb) p *log $5 = {l_tail_lsn = 0, l_last_sync_lsn = 0, l_mp = 0xbfffdf50, l_dev = 2064, l_logBBstart = 32, l_logsize = 2097152, l_logBBsize = 4096, ...} I closed the xfs_repair session and called # cat /dev/zero | dd of=/dev/sdb bs=512 seek=32 count=1 And then the really strange thing happened: The next run of xfs_repair seemed to repair the filesystem. If anyone is interessted, it can be downloaded at: http://slime.wu-wien.ac.at/xfs/repair.003.out But: after that, the log was corrupted again! I got the same effect as described above. It seems, that running xfs_repair destroys the log! Now, i have no idea, what to try next.... If i can do anything, to bring some light into this issue, please let mit know! Thanks, \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue May 7 07:31:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47EVbwJ031989 for ; Tue, 7 May 2002 07:31:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47EVbnk031988 for linux-xfs-outgoing; Tue, 7 May 2002 07:31:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47EVUwJ031960 for ; Tue, 7 May 2002 07:31:31 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g47EWjh27825; Tue, 7 May 2002 16:32:45 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdtI7bX5; Tue May 7 16:32:44 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g47EWhJ12681; Tue, 7 May 2002 16:32:43 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g47EWh704759; Tue, 7 May 2002 16:32:43 +0200 Date: Tue, 7 May 2002 16:32:43 +0200 From: Utz Lehmann To: Eric Sandeen Cc: Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: Some nfs testing help needed Message-ID: <20020507163243.C1177@de.tecosim.com> References: <20020507131707.A1340@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from sandeen@sgi.com on Tue, May 07, 2002 at 08:40:29AM -0500 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, i will do stresstests overnight/ over the weekend. btw: should i do xfsdumps, xfs_fsr while the stesstests? utz Eric Sandeen [sandeen@sgi.com] wrote: > Hi Utz - > > When this was enabled before, there were a couple reports of oopses, > null pointer dereferences, and the like. I'm guessing it happened > under load. > > Thanks, > > -Eric > > On Tue, 7 May 2002, Utz Lehmann wrote: > > > Hi Eric > > > > I have compiled a today CVs kernel with this patch for my workstation. I > > can test it with linux 2.2, 2.4, HP-UX 10.20, 11.0 and older IRIX 6.5 > > clients. For what errors should i look? > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 08:02:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47F2hwJ032488 for ; Tue, 7 May 2002 08:02:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47F2hfk032487 for linux-xfs-outgoing; Tue, 7 May 2002 08:02:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47F2RwJ032441 for ; Tue, 7 May 2002 08:02:28 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47F3lW27831; Tue, 7 May 2002 17:03:47 +0200 Date: Tue, 7 May 2002 17:03:47 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Stephen Lord Cc: linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble Message-ID: <20020507170347.O18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> <20020507160157.M18743@vestdata.no> <3CD7E4E5.2070008@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD7E4E5.2070008@sgi.com>; from lord@sgi.com on Tue, May 07, 2002 at 09:29:57AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47F3lW27831 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47F2SwJ032442 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 09:29:57AM -0500, Stephen Lord wrote: > Put it out of it's misery, it must be in some form of endless loop, there > also appears to be data corruption, that l_mp value is not supposed to > be NULL, it is supposed to be the first argument of zero_log. Once > this was gone, all bets are off. It's not _endless_ as it's actually working it's way over the disk.... Is the xfs-log located at the beginning or the end of the filesystem? > I would say the problem originates higher up the process somewhere. > can you print out the contents of the mp argument of zero_log, > and dump the super block from the disk using xfs_db: 1: *mp = {m_sb = {sb_magicnum = 1481003842, sb_blocksize = 4096, sb_dblocks = 210098062, sb_rblocks = 0, sb_rextents = 0, sb_uuid = "$yOF?nNÆ\216>&8\212\021äz", sb_logstart = 104857604, sb_rootino = 128, sb_rbmino = 129, sb_rsumino = 130, sb_rextsize = 16, sb_agblocks = 1048576, sb_agcount = 201, sb_rbmblocks = 0, sb_logblocks = 25646, sb_versionnum = 8324, sb_sectsize = 512, sb_inodesize = 256, sb_inopblock = 16, sb_fname = '\000' , sb_blocklog = 12 '\f', sb_sectlog = 9 '\t', sb_inodelog = 8 '\b', sb_inopblog = 4 '\004', sb_agblklog = 20 '\024', sb_rextslog = 0 '\000', sb_inprogress = 0 '\000', sb_imax_pct = 25 '\031', sb_icount = 64, sb_ifree = 60, sb_fdblocks = 210071608, sb_frextents = 0, sb_uquotino = 0, sb_gquotino = 0, sb_qflags = 0, sb_flags = 0 '\000', sb_shared_vn = 0 '\000', sb_inoalignmt = 2, sb_unit = 0, sb_width = 0, sb_dirblklog = 0 '\000', sb_dummy = "\000\000\000\000\000\000"}, m_bsize = 8, m_agfrotor = 0, m_agirotor = 0, m_maxagi = 201, m_rsumlevels = 0, m_rsumsize = 0, m_rbmip = 0x0, m_rsumip = 0x0, m_rootip = 0x0, m_dev = 2065, m_logdev = 0, m_rtdev = 0, m_dircook_elog = 0 '\000', m_blkbit_log = 15 '\017', m_blkbb_log = 3 '\003', m_agno_log = 8 '\b', m_agino_log = 24 '\030', m_inode_cluster_size = 8192, m_blockmask = 4095, m_blockwsize = 1024, m_blockwmask = 1023, m_alloc_mxr = { 510, 340}, m_alloc_mnr = {255, 170}, m_bmap_dmxr = {254, 254}, m_bmap_dmnr = {127, 127}, m_inobt_mxr = {255, 510}, m_inobt_mnr = {127, 255}, m_ag_maxlevels = 3, m_bm_maxlevels = {5, 3}, m_in_maxlevels = 3, m_perag = 0x80e49c0, m_flags = 0, m_qflags = 0, m_attroffset = 120, m_da_node_ents = 510, m_ialloc_inos = 64, m_ialloc_blks = 4, m_litino = 156, m_inoalign_mask = 1, m_reservations = {tr_write = 108216, tr_itruncate = 175032, tr_rename = 305976, tr_link = 152832, tr_remove = 153144, tr_symlink = 158520, tr_create = 157880, tr_mkdir = 157880, tr_ifree = 14520, tr_ichange = 1592, tr_growdata = 44160, tr_swrite = 384, tr_addafork = 69560, tr_writeid = 384, tr_attrinval = 174720, tr_attrset = 22456, tr_attrrm = 87992, tr_clearagi = 640, tr_growrtalloc = 65024, tr_growrtzero = 4224, tr_growrtfree = 5760}, m_maxicount = 840392192, m_dalign = 0, m_swidth = 0, m_sinoalign = 0, m_dir_magicpct = 1515, m_dirversion = 2 '\002', m_dirblksize = 4096, m_dirblkfsbs = 1, m_dirdatablk = 0, m_dirleafblk = 8388608, m_dirfreeblk = 16777216} > xfs_db -r /dev/xxxx > sb 0 > p > quit magicnum = 0x58465342 blocksize = 4096 dblocks = 210098062 rblocks = 0 rextents = 0 uuid = 24794f46-3f6e-4ec6-8e3e-26388a11e47a logstart = 104857604 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 1048576 agcount = 201 rbmblocks = 0 logblocks = 25646 versionnum = 0x2084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 20 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 64 ifree = 60 fdblocks = 210071608 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 Is logstart the block-number of the first block used for the log, and logblocks the size of the log? -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Tue May 7 08:14:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FElwJ000450 for ; Tue, 7 May 2002 08:14:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FElPl000449 for linux-xfs-outgoing; Tue, 7 May 2002 08:14:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FEewJ000423 for ; Tue, 7 May 2002 08:14:41 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47FG1e28401; Tue, 7 May 2002 17:16:01 +0200 Date: Tue, 7 May 2002 17:16:00 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair trouble Message-ID: <20020507171600.P18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> <15575.57022.571520.335291@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15575.57022.571520.335291@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, May 07, 2002 at 04:03:42PM +0200 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47FG1e28401 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47FEgwJ000424 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 04:03:42PM +0200, Willi Langenberger wrote: > If "xlog_find_verify_log_record" returns -1, it jumps over the > assignment "*blk_no = last_blk" and returns "error" (which, in this > case is -1). So we have the case that "xlog_find_zeroed" returns -1, > in spite of the fact that *blk_no is _not_ set. But, according to the > comment of the function: > > * Return: > * 0 => the log is completely written to > * -1 => use *blk_no as the first block of the log > * >0 => error has occurred > */ Yes, xlog_find_verify_log_record return negative numbers for errors (at least in some cases), and xlog_find_zeroed is supposed to return possitive numbers for errors, but passes on the value from xlog_find_verify_log_record. Clearly something fishy is going on :) -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Tue May 7 08:19:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FJdwJ000639 for ; Tue, 7 May 2002 08:19:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FJdJk000638 for linux-xfs-outgoing; Tue, 7 May 2002 08:19:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FJZwJ000609 for ; Tue, 7 May 2002 08:19:35 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA17510; Tue, 7 May 2002 10:20:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA75721; Tue, 7 May 2002 10:20:52 -0500 (CDT) Subject: Re: Some nfs testing help needed From: Eric Sandeen To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020507163243.C1177@de.tecosim.com> References: <20020507131707.A1340@de.tecosim.com> <20020507163243.C1177@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 May 2002 10:20:51 -0500 Message-Id: <1020784852.24761.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sure, whatever you want to throw at it. -Eric On Tue, 2002-05-07 at 09:32, Utz Lehmann wrote: > Ok, i will do stresstests overnight/ over the weekend. > btw: should i do xfsdumps, xfs_fsr while the stesstests? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 08:25:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FPlwJ000849 for ; Tue, 7 May 2002 08:25:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FPkXf000847 for linux-xfs-outgoing; Tue, 7 May 2002 08:25:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FPfwJ000811 for ; Tue, 7 May 2002 08:25:42 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA35432; Tue, 7 May 2002 10:26:58 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA16458; Tue, 7 May 2002 10:26:58 -0500 (CDT) Subject: Re: Exporting xfs over nfs From: Eric Sandeen To: Hugo Lafargue Cc: linux-xfs@oss.sgi.com In-Reply-To: <004601c1f5b0$0c9bc970$c102010a@atl.net> References: <5.1.0.14.2.20020506155833.00a9e540@pb429905.kuleuven.be> <3CD690A9.2040506@emergence.com> <004601c1f5b0$0c9bc970$c102010a@atl.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 May 2002 10:26:58 -0500 Message-Id: <1020785218.24761.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Hugo - Is there a chance that you could try the most recent CVS code? There have been some changes in the way errors return out of xfs_lookup, which has affected NFS in a few ways. If CVS behaves better, but you'd prefer to run XFS 1.1, we can probably come up with a patch for 1.1 for you. -Eric On Tue, 2002-05-07 at 05:15, Hugo Lafargue wrote: ... > But, I'm now observing that after failover, nfs clients are unable to use > the filesystem exported by the backup server until I unmount it and mount > it again. Otherwise, I get "stale NFS file handle" messages. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 08:26:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FQXwJ000924 for ; Tue, 7 May 2002 08:26:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FQX8r000923 for linux-xfs-outgoing; Tue, 7 May 2002 08:26:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FQHwJ000891 for ; Tue, 7 May 2002 08:26:17 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA32027; Tue, 7 May 2002 10:27:34 -0500 (CDT) Received: from sgi.com (vD37IJY77fT3q5efe5Dm3UtkS3wjBDMn@cf-vpn-sw-corp-64-8.corp.sgi.com [134.15.64.8]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA00979; Tue, 7 May 2002 10:27:32 -0500 (CDT) Message-ID: <3CD7F343.2090404@sgi.com> Date: Tue, 07 May 2002 10:31:15 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= CC: linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble References: <20020507001545.G18743@vestdata.no> <20020507160157.M18743@vestdata.no> <3CD7E4E5.2070008@sgi.com> <20020507170347.O18743@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ragnar Kjxrstad wrote: >On Tue, May 07, 2002 at 09:29:57AM -0500, Stephen Lord wrote: > >>Put it out of it's misery, it must be in some form of endless loop, there >>also appears to be data corruption, that l_mp value is not supposed to >>be NULL, it is supposed to be the first argument of zero_log. Once >>this was gone, all bets are off. >> > >It's not _endless_ as it's actually working it's way over the disk.... > >Is the xfs-log located at the beginning or the end of the filesystem? > The middle ;-) > > >>I would say the problem originates higher up the process somewhere. >>can you print out the contents of the mp argument of zero_log, >>and dump the super block from the disk using xfs_db: >> > >1: *mp = {m_sb = {sb_magicnum = 1481003842, sb_blocksize = 4096, > sb_dblocks = 210098062, sb_rblocks = 0, sb_rextents = 0, > sb_uuid = "$yOF?nNF\216>&8\212\021dz", sb_logstart = 104857604, > sb_rootino = 128, sb_rbmino = 129, sb_rsumino = 130, sb_rextsize = 16, > sb_agblocks = 1048576, sb_agcount = 201, sb_rbmblocks = 0, > sb_logblocks = 25646, sb_versionnum = 8324, sb_sectsize = 512, > sb_inodesize = 256, sb_inopblock = 16, > sb_fname = '\000' , sb_blocklog = 12 '\f', > sb_sectlog = 9 '\t', sb_inodelog = 8 '\b', sb_inopblog = 4 '\004', > sb_agblklog = 20 '\024', sb_rextslog = 0 '\000', sb_inprogress = 0 '\000', > sb_imax_pct = 25 '\031', sb_icount = 64, sb_ifree = 60, > sb_fdblocks = 210071608, sb_frextents = 0, sb_uquotino = 0, > sb_gquotino = 0, sb_qflags = 0, sb_flags = 0 '\000', > sb_shared_vn = 0 '\000', sb_inoalignmt = 2, sb_unit = 0, sb_width = 0, > sb_dirblklog = 0 '\000', sb_dummy = "\000\000\000\000\000\000"}, > m_bsize = 8, m_agfrotor = 0, m_agirotor = 0, m_maxagi = 201, > m_rsumlevels = 0, m_rsumsize = 0, m_rbmip = 0x0, m_rsumip = 0x0, > m_rootip = 0x0, m_dev = 2065, m_logdev = 0, m_rtdev = 0, > m_dircook_elog = 0 '\000', m_blkbit_log = 15 '\017', m_blkbb_log = 3 '\003', > m_agno_log = 8 '\b', m_agino_log = 24 '\030', m_inode_cluster_size = 8192, > m_blockmask = 4095, m_blockwsize = 1024, m_blockwmask = 1023, m_alloc_mxr = { > 510, 340}, m_alloc_mnr = {255, 170}, m_bmap_dmxr = {254, 254}, > m_bmap_dmnr = {127, 127}, m_inobt_mxr = {255, 510}, m_inobt_mnr = {127, > 255}, m_ag_maxlevels = 3, m_bm_maxlevels = {5, 3}, m_in_maxlevels = 3, > m_perag = 0x80e49c0, m_flags = 0, m_qflags = 0, m_attroffset = 120, > m_da_node_ents = 510, m_ialloc_inos = 64, m_ialloc_blks = 4, m_litino = 156, > m_inoalign_mask = 1, m_reservations = {tr_write = 108216, > tr_itruncate = 175032, tr_rename = 305976, tr_link = 152832, > tr_remove = 153144, tr_symlink = 158520, tr_create = 157880, > tr_mkdir = 157880, tr_ifree = 14520, tr_ichange = 1592, > tr_growdata = 44160, tr_swrite = 384, tr_addafork = 69560, > tr_writeid = 384, tr_attrinval = 174720, tr_attrset = 22456, > tr_attrrm = 87992, tr_clearagi = 640, tr_growrtalloc = 65024, > tr_growrtzero = 4224, tr_growrtfree = 5760}, m_maxicount = 840392192, > m_dalign = 0, m_swidth = 0, m_sinoalign = 0, m_dir_magicpct = 1515, > m_dirversion = 2 '\002', m_dirblksize = 4096, m_dirblkfsbs = 1, > m_dirdatablk = 0, m_dirleafblk = 8388608, m_dirfreeblk = 16777216} > >>xfs_db -r /dev/xxxx >>sb 0 >>p >>quit >> > >magicnum = 0x58465342 >blocksize = 4096 >dblocks = 210098062 >rblocks = 0 >rextents = 0 >uuid = 24794f46-3f6e-4ec6-8e3e-26388a11e47a >logstart = 104857604 >rootino = 128 >rbmino = 129 >rsumino = 130 >rextsize = 16 >agblocks = 1048576 >agcount = 201 >rbmblocks = 0 >logblocks = 25646 >versionnum = 0x2084 >sectsize = 512 >inodesize = 256 >inopblock = 16 >fname = "\000\000\000\000\000\000\000\000\000\000\000\000" >blocklog = 12 >sectlog = 9 >inodelog = 8 >inopblog = 4 >agblklog = 20 >rextslog = 0 >inprogress = 0 >imax_pct = 25 >icount = 64 >ifree = 60 >fdblocks = 210071608 >frextents = 0 >uquotino = 0 >gquotino = 0 >qflags = 0 >flags = 0 >shared_vn = 0 >inoalignmt = 2 >unit = 0 >width = 0 >dirblklog = 0 > > >Is logstart the block-number of the first block used for the log, and >logblocks the size of the log? > > > Yes, and those are the only blocks this code should look at, it seems to have wandered off into never never land. Your mount structure looks reasonable. We will look into your other message about error return values being wrong. Steve From owner-linux-xfs@oss.sgi.com Tue May 7 08:46:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FkNwJ001463 for ; Tue, 7 May 2002 08:46:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FkNRL001462 for linux-xfs-outgoing; Tue, 7 May 2002 08:46:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FkFwJ001435 for ; Tue, 7 May 2002 08:46:15 -0700 Received: from taz ([12.91.253.162]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020507154732.HHEI7485.mtiwmhc26.worldnet.att.net@taz>; Tue, 7 May 2002 15:47:32 +0000 Date: Tue, 7 May 2002 11:43:46 -0400 From: Greg Freemyer Subject: re[2]: Exporting xfs over nfs To: Eric Sandeen , Hugo Lafargue cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020507154732.HHEI7485.mtiwmhc26.worldnet.att.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47FkGwJ001436 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, His problems are likely more generic than just XFS / NFS integration. NFS (on any filesystem) has not historically been very compatible with fail-over clustering and gives the stale handle message after a fail-over. As Horms said, there has been a lot of discussion and development related to this recently. The heartbeat mailing lists archives should cover this topic in detail. (80+ messages at last count) FYI: It requires a fair bit of effort, but it can be accomplished. To my knowledge there is not a out-of-the-box solution, and neither is there a nice clearly written how-to. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> hi Hugo - >> Is there a chance that you could try the most recent CVS code? There >> have been some changes in the way errors return out of xfs_lookup, which >> has affected NFS in a few ways. >> If CVS behaves better, but you'd prefer to run XFS 1.1, we can probably >> come up with a patch for 1.1 for you. >> -Eric >> On Tue, 2002-05-07 at 05:15, Hugo Lafargue wrote: >> ... >> > But, I'm now observing that after failover, nfs clients are unable to >> use >> > the filesystem exported by the backup server until I unmount it and >> mount >> > it again. Otherwise, I get "stale NFS file handle" messages. >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 08:57:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47Fv1wJ001755 for ; Tue, 7 May 2002 08:57:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47Fv0rf001754 for linux-xfs-outgoing; Tue, 7 May 2002 08:57:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47FurwJ001728 for ; Tue, 7 May 2002 08:56:54 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA36741; Tue, 7 May 2002 10:58:11 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA54946; Tue, 7 May 2002 10:58:10 -0500 (CDT) Subject: Re: xfs_repair trouble From: Eric Sandeen To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= Cc: Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com In-Reply-To: <20020507171600.P18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> <15575.57022.571520.335291@slime.wu-wien.ac.at> <20020507171600.P18743@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 07 May 2002 10:58:10 -0500 Message-Id: <1020787090.24935.45.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47FuswJ001729 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hm, looks like log code error handling in general still needs some scrutiny... I have to work my way out from under some internal deadlines, and then I can start to look at this. At first glance, it seems that we should not be returning -ENOMEM anywhere in xfs_log_recover.c, XFS always expects to deal with + errors internally. On the other hand, (again after just a quick glance) it seems like some functions return block numbers and/or positive error messages, not sure how the caller can distinguish between the two. -Eric On Tue, 2002-05-07 at 10:16, Ragnar Kjørstad wrote: > On Tue, May 07, 2002 at 04:03:42PM +0200, Willi Langenberger wrote: > > If "xlog_find_verify_log_record" returns -1, it jumps over the > > assignment "*blk_no = last_blk" and returns "error" (which, in this > > case is -1). So we have the case that "xlog_find_zeroed" returns -1, > > in spite of the fact that *blk_no is _not_ set. But, according to the > > comment of the function: > > > > * Return: > > * 0 => the log is completely written to > > * -1 => use *blk_no as the first block of the log > > * >0 => error has occurred > > */ > > Yes, xlog_find_verify_log_record return negative numbers for errors (at > least in some cases), and xlog_find_zeroed is supposed to return > possitive numbers for errors, but passes on the value from > xlog_find_verify_log_record. Clearly something fishy is going on :) > > > > -- > Ragnar Kjørstad > Big Storage -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 08:59:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47FxFwJ001898 for ; Tue, 7 May 2002 08:59:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47FxFvD001897 for linux-xfs-outgoing; Tue, 7 May 2002 08:59:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47Fx7wJ001862 for ; Tue, 7 May 2002 08:59:07 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA04817; Tue, 7 May 2002 11:00:25 -0500 (CDT) Received: from sgi.com (Huuqvhp+NNk6VWAHfv1BXmxJ0KCjnNNt@cf-vpn-sw-corp-64-8.corp.sgi.com [134.15.64.8]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA03996; Tue, 7 May 2002 11:00:22 -0500 (CDT) Message-ID: <3CD7FAF2.5040601@sgi.com> Date: Tue, 07 May 2002 11:04:02 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hugo Lafargue CC: linux-xfs@oss.sgi.com Subject: Re: Exporting xfs over nfs References: <20020507154732.HHEI7485.mtiwmhc26.worldnet.att.net@taz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg Freemyer wrote: >Eric, > >His problems are likely more generic than just XFS / NFS integration. > >NFS (on any filesystem) has not historically been very compatible with fail-over clustering and gives the stale handle message after a fail-over. > >As Horms said, there has been a lot of discussion and development related to this recently. > >The heartbeat mailing lists archives should cover this topic in detail. (80+ messages at last count) > >FYI: >It requires a fair bit of effort, but it can be accomplished. > >To my knowledge there is not a out-of-the-box solution, and neither is there a nice clearly written how-to. > >Greg Freemyer >Internet Engineer >Deployment and Integration Specialist >Compaq ASE - Tru64 >Compaq Master ASE - SAN Architect >The Norcross Group >www.NorcrossGroup.com > First of all, I presume when you fail over to the second node, you unmount the xfs filesystem on one box and mount it on the second one before the IP address takeover happens? If not then there is a good chance of corruption. That aside, I think that without code changes, the only way to make this work is to ensure that the /dev entry used to mount the filesystem on both boxes has the same major/minor number. If not then I think the stale handles will result. Note this is just a guess on my part right now, I have not looked at this code in a while. For Irix failsafe I think this has tended to not come up because the two nodes are usually an identical configuration, also the linux nfs client does checking on fields of the handle which other clients do not. Work is now ongoing to add export options to Irix NFS to let this sort of configuration pass in its own device handle to use for nfs clients. Steve From owner-linux-xfs@oss.sgi.com Tue May 7 09:03:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47G3ZwJ002144 for ; Tue, 7 May 2002 09:03:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47G3YZ8002143 for linux-xfs-outgoing; Tue, 7 May 2002 09:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47G3SwJ002116 for ; Tue, 7 May 2002 09:03:28 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA95371; Tue, 7 May 2002 11:04:45 -0500 (CDT) Received: from sgi.com (cBcR9YzPZZER7L3lrvQuKTKBzZJ1PjhD@cf-vpn-sw-corp-64-8.corp.sgi.com [134.15.64.8]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA95496; Tue, 7 May 2002 11:04:43 -0500 (CDT) Message-ID: <3CD7FBF8.3090007@sgi.com> Date: Tue, 07 May 2002 11:08:24 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix data bug in device-mapping invalidation References: <20020504115515.A8210@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: >Currently pagebuf_lock_disable() calls destroy_buffers() and >truncate_inode_pages() unconditionally. For the post 2.4.13 case >where the pagebuf modules sits ontop of the blockdevice mapping >this could cause incore data corruption for other openers of that >device (xfsdump?). The fix is to completly remove the calls, >blkdev_put does them when the last opener finished. > >Keep the code for the pre 2.4.13 case as those use their own mapping. >Patch is ontop of my last patch, but the bug is present even without it. > >--- linux/fs/xfs/pagebuf/page_buf_locking.c.~hch~ Sat May 4 13:46:55 2002 >+++ linux/fs/xfs/pagebuf/page_buf_locking.c Sat May 4 13:48:33 2002 >@@ -324,8 +324,10 @@ > pagebuf_lock_disable( /* disable buffer locking */ > pb_target_t *target) /* inode for buffers */ > { >+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,4,13)) > destroy_buffers(target->pbr_device); > truncate_inode_pages(PBT_ADDR_SPACE(target), 0LL); >+#endif > bdput(target->pbr_bdev); > kmem_cache_free(pagebuf_target_cache, target); > > Thanks Christoph, this and your other patches are in my queue - I am bogged down in an I/O path rewrite at the moment, amongst other things. Steve From owner-linux-xfs@oss.sgi.com Tue May 7 09:25:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47GP1wJ002567 for ; Tue, 7 May 2002 09:25:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47GP1HK002566 for linux-xfs-outgoing; Tue, 7 May 2002 09:25:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47GOrwJ002536 for ; Tue, 7 May 2002 09:24:54 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47GL8730892; Tue, 7 May 2002 18:21:08 +0200 Date: Tue, 7 May 2002 18:21:08 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Stephen Lord Cc: Hugo Lafargue , linux-xfs@oss.sgi.com Subject: Re: Exporting xfs over nfs Message-ID: <20020507182108.S18743@vestdata.no> References: <20020507154732.HHEI7485.mtiwmhc26.worldnet.att.net@taz> <3CD7FAF2.5040601@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD7FAF2.5040601@sgi.com>; from lord@sgi.com on Tue, May 07, 2002 at 11:04:02AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47GL8730892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47GOswJ002537 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 11:04:02AM -0500, Stephen Lord wrote: > First of all, I presume when you fail over to the second node, you > unmount the xfs filesystem on one > box and mount it on the second one before the IP address takeover > happens? If not then there is > a good chance of corruption. Yes, that's the way it's done. Most cluster-implementations also implement some kind of fencing to make sure the original server doesn't continue accessing the disk after the second server takes over. > That aside, I think that without code changes, the only way to make this > work is to ensure that the > /dev entry used to mount the filesystem on both boxes has the same > major/minor number. If not > then I think the stale handles will result. Note this is just a guess on > my part right now, I have > not looked at this code in a while. Recently a patch was accepted to allow the user to specify the device-id to use for nfs exports - that should take care of the problem with different major/minor numbers on the two servers. But of course, having to identical servers are the easiest way. You also need to put /var/lib/nfs on shared storage, and to use the same "servicename" on both servers (-n flag in newest version of nfs-utils) for locks to work properly. There are other cavecats as well, but basicly it's possible to get it to work with a little effort. And for out-of-the-box solutions there are ofcourse NAS devices that you can buy that implement this :-) -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Tue May 7 11:39:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47IdKwJ004691 for ; Tue, 7 May 2002 11:39:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47IdJ7k004690 for linux-xfs-outgoing; Tue, 7 May 2002 11:39:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47Id5wJ004656 for ; Tue, 7 May 2002 11:39:06 -0700 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03206 for ; Tue, 7 May 2002 11:40:05 -0700 (PDT) mail_from (jce0@Lehigh.EDU) Received: from Lehigh.EDU (hooch.CC.lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g47HStur012117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 May 2002 13:28:55 -0400 Message-ID: <3CD80ED7.1080309@Lehigh.EDU> Date: Tue, 07 May 2002 13:28:55 -0400 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: GBanschbach@sandata.com CC: linux-xfs@oss.sgi.com Subject: Re: Did you ever get that memory situation straightened out? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Dear Jim, > > I read your posting from last Nov about the 64GB patch on > 2.4.13 and .14. Does it all work now ? I am interested in knowing > more about your experiences.... > Sincerely, > > Greg Greg (cc: linux-xfs) Wow, that seems like a long time ago. Sorry for not posting an update. Since then I've run 2.4.1[678] with xfs from split patches and CVS. The last was 2.4.18+split patches+an nfs patch that Steve? posted to the list. That resulted in ~35 days uptime before hanging with the oops appended below. I'm now running 2.4.19-pre6aa1 (which includes xfs of around Mar 30 timeframe I think) and a patched ips (IBM serveraid) driver which does highmem io, and have been up for 10 days. Note this is a very busy 8-way 8G campus mail server. The 2.4 kernel and xfs have been steadily improving. I think I can say now that yes, it does all work. I don't know how soon I'll get to see triple-digit uptime but I'm optimistic. Jim Apr 27 09:44:16 xxxx kernel: invalid operand: 0000 Apr 27 09:44:16 xxxx kernel: CPU: 5 Apr 27 09:44:16 xxxx kernel: EIP: 0010:[ll_rw_block+138/504] Not tainted Apr 27 09:44:16 xxxx kernel: EIP: 0010:[] Not tainted Apr 27 09:44:16 xxxx kernel: EFLAGS: 00010287 Apr 27 09:44:16 xxxx kernel: eax: 00000000 ebx: 00003a04 ecx: df6b4ba0 edx: 00000000 Apr 27 09:44:16 xxxx kernel: esi: 00000000 edi: e4e6fd28 ebp: 00000200 esp: e4e6fce0 Apr 27 09:44:16 xxxx kernel: ds: 0018 es: 0018 ss: 0018 Apr 27 09:44:16 xxxx kernel: Process procmail (pid: 14699, stackpage=e4e6f000) Apr 27 09:44:16 xxxx kernel: Stack: e9f051e0 df6b4ba0 e4e6fd4c 00000000 df6b4ba0 00000000 00001000 00000200 Apr 27 09:44:16 xxxx kernel: df6b4ba0 c0139685 00000001 00000001 e4e6fd28 e9f051c0 c9d873e0 c9d873c8 Apr 27 09:44:16 xxxx kernel: 00000001 e4e6fd4c df6b4ba0 f7192e80 00000001 f6d00000 00000000 00000292 Apr 27 09:44:16 xxxx kernel: Call Trace: [fsync_inode_data_buffers+165/384] [xfs_mod_incore_sb_batch+71/160] [xfs_trans_unreserve_and_mod_sb+348/360] [xfs_log_notify+54/84] [__refile_buffer+84/92] Apr 27 09:44:16 xxxx kernel: Call Trace: [] [] [] [] [] Apr 27 09:44:16 xxxx kernel: [refile_buffer+23/36] [set_buffer_dirty_uptodate+51/68] [__pb_block_commit_write_async+46/80] [pagebuf_commit_write+66/144] [pagebuf_commit_write+115/144] [pagebuf_generic_file_write+677/792] Apr 27 09:44:16 xxxx kernel: [] [] [] [] [] [] Apr 27 09:44:16 xxxx kernel: [pagebuf_generic_file_write+727/792] [xfs_trans_unlocked_item+34/60] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+75/84] [xfs_rwunlock+48/100] [xfs_write+1276/1292] Apr 27 09:44:16 xxxx kernel: [] [] [] [] [] [] Apr 27 09:44:16 xxxx kernel: [pagebuf_flush+23/40] [fs_flush_pages+41/48] [xfs_fsync+239/748] [linvfs_fsync+65/76] [sys_fsync+98/172] [system_call+51/56] Apr 27 09:44:16 xxxx kernel: [] [] [] [] [] [] Apr 27 09:44:16 xxxx kernel: Apr 27 09:44:16 xxxx kernel: Code: 0f 0b 83 c7 04 46 3b 74 24 2c 7c c8 8b 4c 24 28 f6 c1 01 74 Apr 27 09:44:48 xxxx kernel: invalid operand: 0000 Apr 27 09:44:48 xxxx kernel: CPU: 3 Apr 27 09:44:48 xxxx kernel: EIP: 0010:[__make_request+141/1652] Not tainted Apr 27 09:44:48 xxxx kernel: EIP: 0010:[] Not tainted Apr 27 09:44:48 xxxx kernel: EFLAGS: 00010246 Apr 27 09:44:48 xxxx kernel: eax: 00000008 ebx: 00000841 ecx: 00000001 edx: 00000004 Apr 27 09:44:48 xxxx kernel: esi: ed969480 edi: 00004000 ebp: 00000000 esp: c9897eac Apr 27 09:44:48 xxxx kernel: ds: 0018 es: 0018 ss: 0018 Apr 27 09:44:48 xxxx kernel: Process kupdated (pid: 13, stackpage=c9897000) Apr 27 09:44:48 xxxx kernel: Stack: 00000841 ed969480 c03e66c0 00000000 f7159b70 f7159a00 00004000 c9978498 Apr 27 09:44:48 xxxx kernel: c9978490 00000400 00000000 00000000 00000008 002007d0 00000001 c022cc12 Apr 27 09:44:48 xxxx kernel: c9978478 00000001 ed969480 00000008 00000001 eb770ec0 00000051 c022ccd8 Apr 27 09:44:48 xxxx kernel: Call Trace: [generic_make_request+158/292] [submit_bh+64/92] [write_locked_buffers+32/44] [write_some_buffers+204/280] [sync_old_buffers+91/148] Apr 27 09:44:48 xxxx kernel: Call Trace: [] [] [] [] [] Apr 27 09:44:48 xxxx kernel: [kupdate+317/324] [stext+0/68] [kernel_thread+26/48] [kernel_thread+35/48] Apr 27 09:44:48 xxxx kernel: [] [] [] [] Apr 27 09:44:48 xxxx kernel: Apr 27 09:44:48 xxxx kernel: Code: 0f 0b 56 8b 7c 24 48 57 e8 d2 92 f0 ff 89 c6 83 c4 08 0f b6 From owner-linux-xfs@oss.sgi.com Tue May 7 12:26:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47JQswJ005428 for ; Tue, 7 May 2002 12:26:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47JQs3i005427 for linux-xfs-outgoing; Tue, 7 May 2002 12:26:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dispatch.tco.census.gov (dispatch.tco.census.gov [148.129.129.22]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47JQmwJ005400 for ; Tue, 7 May 2002 12:26:49 -0700 Received: from dispatch.tco.census.gov (localhost.localdomain [127.0.0.1]) by dispatch.tco.census.gov (8.11.6/8.11.6/v3.5) with ESMTP id g47JS5611324 for ; Tue, 7 May 2002 15:28:05 -0400 Received: from deliver.tco.census.gov ([148.129.126.70]) by dispatch.tco.census.gov (8.11.6/8.11.6/v3.6) with ESMTP id g47JS5h11318 for ; Tue, 7 May 2002 15:28:05 -0400 Received: from grendel.dpd.census.gov (grendel.dpd.census.gov [148.129.119.235]) by deliver.tco.census.gov (8.11.6/8.11.6/v3.19) with ESMTP id g47JS5420720 for ; Tue, 7 May 2002 15:28:05 -0400 Received: from npc.census.gov (tasha.npc.census.gov [148.129.63.63]) by grendel.dpd.census.gov (8.9.3/8.9.3/v3.2) with ESMTP id PAA23865 for ; Tue, 7 May 2002 15:28:06 -0400 Message-ID: <3CD82AA1.62F7AC69@npc.census.gov> Date: Tue, 07 May 2002 15:27:29 -0400 From: Jeff Cooper X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-9ck i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Maximum Volume size for XFS on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a large Linux SAN with 8 - 1.8TB volumes for a large data capture operation. I am able to format the drives with mkfs.xfs, and until a certain point, around 800GB, things are fine. At this point however, the file system freezes, and we are unable to create any more files on the volume. I am running kernel 2.4.18 with the XFS1.1 patch. The image files on the volume are all between 20-40K. We had hoped to put over 10,000,000 images per volume, spread evenly over 80 root directories, with 400 sub directories. Each low level directory would hold approx 1300 images. Can this be achieved with XFS? As long as I stayed under the 2TB block device limit, I thought things would be fine. Any help or ideas would be appreciated. Thank you, Jeff Cooper US Census Bureau From owner-linux-xfs@oss.sgi.com Tue May 7 12:28:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47JSRwJ005538 for ; Tue, 7 May 2002 12:28:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47JSM8u005537 for linux-xfs-outgoing; Tue, 7 May 2002 12:28:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47JS7wJ005498 for ; Tue, 7 May 2002 12:28:08 -0700 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id g47JTUT05426 for ; Tue, 7 May 2002 15:29:30 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #40646) id <0GVR00I018WEVN@lmco.com> for linux-xfs@oss.sgi.com; Tue, 7 May 2002 15:29:29 -0400 (EDT) Received: from lmco.com ([134.5.193.209]) by lmco.com (PMDF V5.2-33 #40646) with ESMTP id <0GVR00HRO9VGXX@lmco.com> for linux-xfs@oss.sgi.com; Tue, 07 May 2002 15:23:40 -0400 (EDT) Date: Tue, 07 May 2002 15:38:07 -0400 From: Jeff Layton Subject: [Fwd: opinion on XFS] To: linux-xfs@oss.sgi.com Reply-to: jeffrey.b.layton@lmco.com Message-id: <3CD82D1F.E8013131@lmco.com> Organization: Lockheed-Martin Aeronautics Company MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16smp i686) Content-type: multipart/mixed; boundary="Boundary_(ID_WbrCRyDBcM+QR9M0HmZfyg)" X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_WbrCRyDBcM+QR9M0HmZfyg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT There is a discussion on the Beowulf mailing list about XFS. I saw this post and I thought I would forward it to this list. Enjoy! Jeff --Boundary_(ID_WbrCRyDBcM+QR9M0HmZfyg) Content-type: message/rfc822 Received: from emss03g01.ems.lmco.com (emss03g01.orl.lmco.com [141.240.4.144]) by emss06m01.ems.lmco.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KJTQ8CAG; Tue, 7 May 2002 15:21:13 -0400 Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #40646) id <0GVR00I018TU2J@lmco.com> for jeffrey.b.layton@imc6.ems.lmco.com (ORCPT rfc822;jeffrey.b.layton@lmco.com); Tue, 7 May 2002 15:21:09 -0400 (EDT) Received: from mailgw2.lmco.com ([192.91.147.3]) by lmco.com (PMDF V5.2-33 #40646) with ESMTP id <0GVR00H669JIXX@lmco.com>; Tue, 07 May 2002 15:16:32 -0400 (EDT) Received: from blueraja.scyld.com (dsl093-058-083.blt1.dsl.speakeasy.net [66.93.58.83]) by mailgw2.lmco.com (8.11.6/8.11.6) with ESMTP id g47JGRd05235; Tue, 07 May 2002 15:16:28 -0400 (EDT) Received: from dsl093-058-083.blt1.dsl.speakeasy.net (localhost.localdomain [127.0.0.1]) by blueraja.scyld.com (8.11.6/8.11.6) with ESMTP id g47IqsO29142; Tue, 07 May 2002 14:52:54 -0400 Received: from mail.interaktif.net.tr ([62.248.102.120]) by blueraja.scyld.com (8.11.6/8.11.6) with ESMTP id g47InRO29023 for ; Tue, 07 May 2002 14:49:27 -0400 Received: from abn160-102.ank-avrupa-ports.kablonet.net.tr (abn160-102.ank-ports.kablonet.net.tr [195.174.160.102]) by mail.interaktif.net.tr (Postfix) with ESMTP id B9CB23BAD3; Tue, 07 May 2002 21:48:43 +0300 (EEST) Date: Tue, 07 May 2002 21:51:43 +0300 From: Eray Ozkural Subject: Re: opinion on XFS In-reply-to: Sender: beowulf-admin@beowulf.org To: Yudong Tian , "Beowulf (E-mail)" Errors-to: beowulf-admin@beowulf.org Message-id: <200205072151.43365.erayo@cs.bilkent.edu.tr> Organization: Bilkent University CS Dept. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: KMail/1.4.5 X-BeenThere: beowulf@beowulf.org X-Mailman-Version: 2.0.6 X-Mozilla-Status2: 00000000 References: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: Discussion of topics related to Beowulf clusters Hi Yudong, On Tuesday 07 May 2002 18:28, Yudong Tian wrote: > Hello, > Has anyone tested the water of using SGI's XFS on a Linux cluster Can > you kindly share any experience and insights? I haven't made an analysis of what needs to be done to merge XFS into the kernel mainline but I have a feeling it is not prohitibive. I have been running the 32 node Beowulf at bilkent cs dept. and my personal computers with XFS for the last 6-7 months. It has operated perfectly, I have not observed a single reliability or performance bug that will influence the parallel system. On the contrary, the uptime and reliability of our system has improved significantly. We used to suffer crashed nodes due to the extremely poorly written EXT2 filesystem. That was the only system level bug that interrupted our work. Since I modified our installation scripts to format local drives with XFS, everything has changed. I think the required maintenance time has decreased considerably. They haven't called me for the last couple of months :) -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo Malfunction: http://mp3.com/ariza GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf --Boundary_(ID_WbrCRyDBcM+QR9M0HmZfyg)-- From owner-linux-xfs@oss.sgi.com Tue May 7 12:33:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47JX6wJ005812 for ; Tue, 7 May 2002 12:33:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47JX6NH005811 for linux-xfs-outgoing; Tue, 7 May 2002 12:33:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47JWxwJ005784 for ; Tue, 7 May 2002 12:33:01 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g47JY7t08033; Tue, 7 May 2002 21:34:07 +0200 Date: Tue, 7 May 2002 21:34:07 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Eric Sandeen Cc: Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble Message-ID: <20020507213407.Z18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> <15575.57022.571520.335291@slime.wu-wien.ac.at> <20020507171600.P18743@vestdata.no> <1020787090.24935.45.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1020787090.24935.45.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Tue, May 07, 2002 at 10:58:10AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g47JY7t08033 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g47JX2wJ005786 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 10:58:10AM -0500, Eric Sandeen wrote: > Hm, looks like log code error handling in general still needs some > scrutiny... I have to work my way out from under some internal > deadlines, and then I can start to look at this. Thanks. Is there something we can test in the meantime to get our filesystem back? I was thinking of commenting out the zero_log() part of xfs_repair to get it to run the rest of the process. Is that safe? Will the filesystem mount afterwards? Or is there a different (better) way to get the repair going? Also; if we can work-around this problem, is there some data we should extract from the filesystem first if you wish to debug the problem later? We already sent the superblock, but if there are other data that might be useful we'll copy that off before doing anything to the filesystem. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Tue May 7 12:55:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47JtBwJ006490 for ; Tue, 7 May 2002 12:55:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47JtBnd006489 for linux-xfs-outgoing; Tue, 7 May 2002 12:55:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47Jt3wJ006462 for ; Tue, 7 May 2002 12:55:03 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g47JtsLL006172; Tue, 7 May 2002 21:55:54 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA17213; Tue, 7 May 2002 21:55:53 +0200 (CEST) Date: Tue, 7 May 2002 21:55:53 +0200 (CEST) From: Seth Mos To: Jeff Cooper cc: Subject: Re: Maximum Volume size for XFS on Linux In-Reply-To: <3CD82AA1.62F7AC69@npc.census.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 7 May 2002, Jeff Cooper wrote: > Hi, > > I have a large Linux SAN with 8 - 1.8TB volumes > for a large data capture operation. > > I am able to format the drives with mkfs.xfs, > and until a certain point, around 800GB, things > are fine. At this point however, the file system > freezes, and we are unable to create any more files > on the volume. The box freezes, is that what you mean? Or is it just impossible to create extra files. > I am running kernel 2.4.18 with the XFS1.1 patch. > > The image files on the volume are all between 20-40K. > We had hoped to put over 10,000,000 images per volume, > spread evenly over 80 root directories, with 400 sub > directories. Each low level directory would hold approx > 1300 images. How many images did you actually get onto the volume? It might have run out of inodes. The default is to allow a maximum of 25 percent of the diskspace. if you could run xfs_info that would be helpful. (provided in the xfsprogs rpm or in the cmd branch of the CVS tree) > Can this be achieved with XFS? As long as I stayed > under the 2TB block device limit, I thought things > would be fine. It should work. You can adjust the maximum amount of inode space using xfs_growfs I think. Otherwise you can always specify it at mkfs.xfs time how much percent is the limit. Cheers Seth From owner-linux-xfs@oss.sgi.com Tue May 7 13:03:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47K3EwJ006903 for ; Tue, 7 May 2002 13:03:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47K3EkQ006902 for linux-xfs-outgoing; Tue, 7 May 2002 13:03:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47K38wJ006876 for ; Tue, 7 May 2002 13:03:09 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g47K40I7011104; Tue, 7 May 2002 22:04:00 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA17834; Tue, 7 May 2002 22:04:00 +0200 (CEST) Date: Tue, 7 May 2002 22:04:00 +0200 (CEST) From: Seth Mos To: Jeff Cooper cc: Subject: Re: Maximum Volume size for XFS on Linux In-Reply-To: <3CD82AA1.62F7AC69@npc.census.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 7 May 2002, Jeff Cooper wrote: > Hi, > > I have a large Linux SAN with 8 - 1.8TB volumes > for a large data capture operation. > > I am able to format the drives with mkfs.xfs, > and until a certain point, around 800GB, things > are fine. At this point however, the file system > freezes, and we are unable to create any more files > on the volume. I forgot, which version of mkfs.xfs did you use. Some older mkfs.xfs version incorrectly sized the inodeseize which results in the exact behaviour you are describing. This was fixed a few months ago and was only introduced during a short time. You might have been unlucky. Can you try recreating one of the filesystems with a recent mkfs.xfs or better yet the latest CVS to be sure. (although 1.1 release xfsprogs will do fine). Cheers Seth From owner-linux-xfs@oss.sgi.com Tue May 7 13:08:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47K8QwJ007181 for ; Tue, 7 May 2002 13:08:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47K8Qoq007180 for linux-xfs-outgoing; Tue, 7 May 2002 13:08:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47K8HwJ007129 for ; Tue, 7 May 2002 13:08:17 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA38121; Tue, 7 May 2002 15:09:34 -0500 (CDT) Received: from sgi.com (OVVHyksZEdOX81RPlZJFvqJloW5s/iCg@cf-vpn-sw-corp-64-8.corp.sgi.com [134.15.64.8]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA24765; Tue, 7 May 2002 15:09:32 -0500 (CDT) Message-ID: <3CD83558.5020601@sgi.com> Date: Tue, 07 May 2002 15:13:12 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= CC: Eric Sandeen , Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble References: <20020507001545.G18743@vestdata.no> <15575.57022.571520.335291@slime.wu-wien.ac.at> <20020507171600.P18743@vestdata.no> <1020787090.24935.45.camel@stout.americas.sgi.com> <20020507213407.Z18743@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ragnar Kjxrstad wrote: >On Tue, May 07, 2002 at 10:58:10AM -0500, Eric Sandeen wrote: > >>Hm, looks like log code error handling in general still needs some >>scrutiny... I have to work my way out from under some internal >>deadlines, and then I can start to look at this. >> > >Thanks. > >Is there something we can test in the meantime to get our filesystem >back? I was thinking of commenting out the zero_log() part of xfs_repair >to get it to run the rest of the process. Is that safe? Will the >filesystem mount afterwards? > >Or is there a different (better) way to get the repair going? > >Also; if we can work-around this problem, is there some data we should >extract from the filesystem first if you wish to debug the problem >later? We already sent the superblock, but if there are other data that >might be useful we'll copy that off before doing anything to the >filesystem. > > Can you run xfs_check on the filesystem and see what that reports? It ignores the log, so there is no problem there. Careful use of dd into the block device can do this. Using the superblock info which is in filesystem blocks. You need to do this: xfs_db -r /dev/xxx sb 0 p and find the logstart field. Then convert it to a disk address using xfs_db convert fsblock xxxxx daddr where xxxx is the value for logstart This will put it in 512 byte blocks, note that a regular divide operation will not help as this is not such a simple mapping. You can then use dd to write some zeros into this location, you probably want to do it for logblocks blocks, this value is in 4K units, just multiply by 8 to get 512 byte units. To be doubly safe, dd this portion of the device out to a file before zeroing it. You can then use xfs_repair on the filesystem to hopefully fix it up, it usually does a good job. Steve From owner-linux-xfs@oss.sgi.com Tue May 7 15:06:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47M6kwJ009820 for ; Tue, 7 May 2002 15:06:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47M6ko8009819 for linux-xfs-outgoing; Tue, 7 May 2002 15:06:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47M6fwJ009793 for ; Tue, 7 May 2002 15:06:41 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 18:07:59 -0400 Message-ID: From: Murthy Kambhampaty To: "'linux-xfs@oss.sgi.com'" Subject: XFS optimization question Date: Tue, 7 May 2002 18:07:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am having a little trouble decoding the documentation on "sunit" and "swidth" w.t.t. my raid controller. Some background: I have a Mylex Acceleraid352 controller running a system drive in raid-5 and a data drive in raid-0. The default stripe width on the controller is 64K, and a segment size of 8k, and this is what the driver's documentation says about configuring ext2 filesystems: "For maximum performance and the most efficient E2FSCK performance, it is recommended that EXT2 file systems be built with a 4KB block size and 16 block stride to match the DAC960 controller's 64KB default stripe size. The command "mke2fs -b 4096 -R stride=16 " is appropriate." For XFS, I haven't been able to find sufficient information to figure out whether it is sunit or swidth that is analagous to the "stride" or "stripe width" of 64K? It sounds to me like swidth, in which case would sunit be set to the segment size of 8k? I'm probably going over ground that's been covered previously on this list, but didn't have much luck finding it in the archive or the documentation. Thanks for the help, Murthy From owner-linux-xfs@oss.sgi.com Tue May 7 15:10:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47MATwJ010079 for ; Tue, 7 May 2002 15:10:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47MAT5O010077 for linux-xfs-outgoing; Tue, 7 May 2002 15:10:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47MANwJ010048 for ; Tue, 7 May 2002 15:10:24 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id HAA20836 for ; Wed, 8 May 2002 07:17:31 +0930 Message-ID: <3CD8550C.BF48CA15@rebel.net.au> Date: Wed, 08 May 2002 07:58:28 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.18-XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmm... I have a particularly broken system, a RedHat 7.1 system (default) but the RPM database is dead (1). Nonetheless, rpm -ivh kernel-2.4.18 (XFS) absolutely kills /var. Bugger knows why... Any ideas? (When I run xfs_repair over /dev/hda3 [aka /var] it picks up problems with directories and such] DSL -- 2337: Chastity means the successful integration of sexuality within the person and thus the inner unity of man in his bodily and spiritual being...[First sentence of item 2337 of the Catechism of the Catholic Church revised in accordance with the official Latin Text] From owner-linux-xfs@oss.sgi.com Tue May 7 15:42:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47MgQwJ011478 for ; Tue, 7 May 2002 15:42:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47MgQX1011477 for linux-xfs-outgoing; Tue, 7 May 2002 15:42:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47MgLwJ011449 for ; Tue, 7 May 2002 15:42:21 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 65A351D805 for ; Wed, 8 May 2002 00:43:36 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002050800433451:4818 ; Wed, 8 May 2002 00:43:34 +0200 Message-ID: <3CD858A1.2070208@propack-data.com> Date: Wed, 08 May 2002 00:43:45 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Problems compiling acl-2.0.9 X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 08.05.2002 00:43:34, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 08.05.2002 00:43:36, Serialize complete at 08.05.2002 00:43:36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On my newly build LFS-system I can not build the acl-2.0.9 package. #make stopps with this message: [...snipp...] gcc -o .libs/getfacl getfacl.o user_group.o /lib/libattr.so ../libacl/.libs/libacl.so gcc: /lib/libattr.so: No such file or directory make[1]: *** [getfacl] Error 1 make: *** [default] Error 2 But the file is there: root:/usr/src/acl-2.0.9# ls -l /lib/libattr.so lrwxrwxrwx 1 root root 12 May 8 02:16 /lib/libattr.so -> libattr.so.1 So what's wrong?? regards micha From owner-linux-xfs@oss.sgi.com Tue May 7 15:52:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47MqXwJ011768 for ; Tue, 7 May 2002 15:52:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47MqXIG011767 for linux-xfs-outgoing; Tue, 7 May 2002 15:52:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47MqRwJ011740 for ; Tue, 7 May 2002 15:52:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA2877976 for ; Tue, 7 May 2002 15:53:49 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06507; Wed, 8 May 2002 08:52:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA30564; Wed, 8 May 2002 08:52:31 +1000 (AEST) Date: Wed, 8 May 2002 08:52:31 +1000 From: Nathan Scott To: Michael Wahlbrink Cc: linux-xfs Subject: Re: Problems compiling acl-2.0.9 Message-ID: <20020508085231.E108700@wobbly.melbourne.sgi.com> References: <3CD858A1.2070208@propack-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CD858A1.2070208@propack-data.com>; from x_miw@propack-data.com on Wed, May 08, 2002 at 12:43:45AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 08, 2002 at 12:43:45AM +0200, Michael Wahlbrink wrote: > Hi, > On my newly build LFS-system I can not build the acl-2.0.9 package. > #make stopps with this message: > [...snipp...] > gcc -o .libs/getfacl getfacl.o user_group.o /lib/libattr.so > ../libacl/.libs/libacl.so > gcc: /lib/libattr.so: No such file or directory > make[1]: *** [getfacl] Error 1 > make: *** [default] Error 2 > > But the file is there: > root:/usr/src/acl-2.0.9# ls -l /lib/libattr.so > lrwxrwxrwx 1 root root 12 May 8 02:16 /lib/libattr.so -> libattr.so.1 > > So what's wrong?? Is the file its pointing to there? It should look like this... # ls -l /lib/libattr.so /lib/libattr.so.1 /lib/libattr.so.1.0.0 lrwxr-xr-x 1 root root 12 May 8 07:24 /lib/libattr.so -> libattr.so.1 lrwxr-xr-x 1 root root 16 May 3 16:59 /lib/libattr.so.1 -> libattr.so.1.0.0 -rw-r--r-- 1 root root 31743 May 3 16:59 /lib/libattr.so.1.0.0 If any are missing, then your "attr" binaries aren't installed correctly - try "make install install-dev install-lib" in attr source directory. BTW, you may as well use acl-2.0.11 if building from source, there have been a couple of bugs fixed since acl-2.0.9. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 7 16:21:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47NLDwJ012310 for ; Tue, 7 May 2002 16:21:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47NLD3O012309 for linux-xfs-outgoing; Tue, 7 May 2002 16:21:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47NL5wJ012283 for ; Tue, 7 May 2002 16:21:06 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA4066388 for ; Tue, 7 May 2002 16:22:28 -0700 (PDT) mail_from (fsgqa@bruce.melbourne.sgi.com) Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id JAA31455 for linux-xfs@oss.sgi.com; Wed, 8 May 2002 09:22:23 +1000 Date: Wed, 8 May 2002 09:22:23 +1000 From: FSG QA Message-Id: <200205072322.JAA31455@bruce.melbourne.sgi.com> Subject: TAKE - xfstests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon May 6 22:58:13 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118427a cmd/xfstests/check - 1.4 - get some default MKFS_OPTIONS and MOUNT_OPTIONS happening so its more obvious on how to use these variables. Date: Tue May 7 14:33:35 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118519a cmd/xfstests/src/feature.c - 1.4 - check whether libc rlimit/ftruncate handling works correctly. cmd/xfstests/066 - 1.3 - don't unilaterally notrun this test -- check whether libc is busted, and run the test if not. Date: Tue May 7 16:11:58 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118528a cmd/xfstests/057 - 1.6 - clarify the notrun message a little. Date: Tue May 7 16:21:16 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118529a cmd/xfstests/066 - 1.4 - fix typo, bozo -- TEST_MNT -> TEST_DIR; extra notrun checks now work. From owner-linux-xfs@oss.sgi.com Tue May 7 16:47:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47Nl2wJ014458 for ; Tue, 7 May 2002 16:47:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47Nl2qv014457 for linux-xfs-outgoing; Tue, 7 May 2002 16:47:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [210.86.15.138]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47NktwJ014429 for ; Tue, 7 May 2002 16:46:56 -0700 Received: from localhost.localdomain ([210.86.76.145]) by mta5-rme.xtra.co.nz with ESMTP id <20020507234813.XXIM15450.mta5-rme.xtra.co.nz@localhost.localdomain> for ; Wed, 8 May 2002 11:48:13 +1200 Subject: 2.4.13 Merge coming? From: mdew To: xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uimjqqciRPRqoBnIZPaU" X-Mailer: Ximian Evolution 1.0.3 Date: 08 May 2002 11:48:00 +1200 Message-Id: <1020815281.6941.32.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-uimjqqciRPRqoBnIZPaU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable yes there are some of us waiting for it :) --=20 ph33r! Linux mdew 2.4.19-pre8-xfs-aa #2 Sat May 4 23:16:25 NZST 2002 i686 unknown GPG Key: http://mdew.orcon.net.nz/gpg --=-uimjqqciRPRqoBnIZPaU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA82GewH5J/xul0J+4RAkJHAJ9Q/QeESOh9sgobzFOivU2hYGp/ygCeNbh1 k3xVV00GvCqSDHvWbh1M6v0= =gpPn -----END PGP SIGNATURE----- --=-uimjqqciRPRqoBnIZPaU-- From owner-linux-xfs@oss.sgi.com Tue May 7 16:58:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47NwbwJ014937 for ; Tue, 7 May 2002 16:58:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47NwbWi014936 for linux-xfs-outgoing; Tue, 7 May 2002 16:58:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta2-rme.xtra.co.nz (mta2-rme.xtra.co.nz [210.86.15.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47NwUwJ014899 for ; Tue, 7 May 2002 16:58:30 -0700 Received: from localhost.localdomain ([210.86.76.145]) by mta2-rme.xtra.co.nz with ESMTP id <20020507235948.YJJL9409.mta2-rme.xtra.co.nz@localhost.localdomain> for ; Wed, 8 May 2002 11:59:48 +1200 Subject: ahem 2.5.13 From: mdew To: xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Wvucr7z5LUJbdDP+MKcH" X-Mailer: Ximian Evolution 1.0.3 Date: 08 May 2002 11:59:32 +1200 Message-Id: <1020815976.6941.34.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Wvucr7z5LUJbdDP+MKcH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ok ...that was a typo... --=20 ph33r! Linux mdew 2.4.19-pre8-xfs-aa #2 Sat May 4 23:16:25 NZST 2002 i686 unknown GPG Key: http://mdew.orcon.net.nz/gpg --=-Wvucr7z5LUJbdDP+MKcH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA82GpkH5J/xul0J+4RAlxWAJwPHT0uWZpVHtISlDnoYaEPaAafGwCeJutE b2+r/pKrSSOl60p9yfAeWTc= =Fm0g -----END PGP SIGNATURE----- --=-Wvucr7z5LUJbdDP+MKcH-- From owner-linux-xfs@oss.sgi.com Tue May 7 17:05:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4805nwJ015328 for ; Tue, 7 May 2002 17:05:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4805nnX015327 for linux-xfs-outgoing; Tue, 7 May 2002 17:05:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4805gwJ015299 for ; Tue, 7 May 2002 17:05:43 -0700 Received: from starfleet.attglobal.net (slip-32-101-12-177.wi.us.prserv.net[32.101.12.177]) by prserv.net (out2) with ESMTP id <2002050723424920200fs6jfe>; Tue, 7 May 2002 23:42:50 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g47NfdB29078 for linux-xfs@oss.sgi.com; Tue, 7 May 2002 18:41:39 -0500 X-Authentication-Warning: starfleet.attglobal.net: skylar set sender to skylar@attglobal.net using -f Date: Tue, 7 May 2002 18:41:39 -0500 From: Skylar Thompson To: Linux XFS Subject: Re: SAMBA compile errors at XFS kernel.. Message-ID: <20020507234139.GA29054@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: Linux XFS References: <009101c1f56d$192f86b0$3701a8c0@diylinuxwin2k> <20020507023604.GA25983@starfleet.attglobal.net> <6uk7qgw3x0.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <6uk7qgw3x0.fsf@zork.zork.net> User-Agent: Mutt/1.3.99i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 25 2002 16:11:05) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2002 at 01:14:35PM +0100, Sean Neakums wrote: > commence Skylar Thompson quotation: >=20 > > On Tue, May 07, 2002 at 11:15:45AM +0900, Yu-Chan Park wrote: > > You might want to try posting with an ISO-8859 character set; most > > Western Hemisphere denizens do not have support for this (I am > > assuming it is an Asian script). >=20 > Gnus seemed to decode it okay. Here is the text: Thanks. Mutt didn't seem to want to decode it. --=20 -- Skylar Thompson (skylar@attglobal.net) --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE82GYznMU1m27tfjARAhXWAJ0dlV/cpwjcfPgcCmVQYaswcpmRyQCfVECL lmwUWKsEEXFixAsi2dxsskk= =c180 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-linux-xfs@oss.sgi.com Tue May 7 17:06:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4806wwJ015475 for ; Tue, 7 May 2002 17:06:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4806wGX015474 for linux-xfs-outgoing; Tue, 7 May 2002 17:06:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4806swJ015439 for ; Tue, 7 May 2002 17:06:55 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 526354B7EB7; Tue, 7 May 2002 20:08:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 452F9C00EC6; Tue, 7 May 2002 20:08:26 -0400 (EDT) Date: Tue, 7 May 2002 20:08:26 -0400 (EDT) From: Mike Burger To: mdew Cc: xfs Subject: Re: ahem 2.5.13 In-Reply-To: <1020815976.6941.34.camel@mdew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oh...oops. Sorry. On 8 May 2002, mdew wrote: > ok ...that was a typo... > > From owner-linux-xfs@oss.sgi.com Tue May 7 17:06:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4806mwJ015421 for ; Tue, 7 May 2002 17:06:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4806mDd015420 for linux-xfs-outgoing; Tue, 7 May 2002 17:06:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4806jwJ015394 for ; Tue, 7 May 2002 17:06:45 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 0EAA4401A40; Tue, 7 May 2002 20:08:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id EB806C00EC6; Tue, 7 May 2002 20:08:15 -0400 (EDT) Date: Tue, 7 May 2002 20:08:15 -0400 (EDT) From: Mike Burger To: mdew Cc: xfs Subject: Re: 2.4.13 Merge coming? In-Reply-To: <1020815281.6941.32.camel@mdew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 2.4.13? That was yesterday's news...they've got 2.4.14 and 2.4.18 trees. On 8 May 2002, mdew wrote: > yes there are some of us waiting for it :) > > > From owner-linux-xfs@oss.sgi.com Tue May 7 18:06:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4816jwJ016876 for ; Tue, 7 May 2002 18:06:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4816jfI016875 for linux-xfs-outgoing; Tue, 7 May 2002 18:06:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4816ewJ016848 for ; Tue, 7 May 2002 18:06:40 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA41162; Tue, 7 May 2002 20:07:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA14227; Tue, 7 May 2002 20:07:58 -0500 (CDT) Date: Tue, 7 May 2002 20:07:58 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.18-XFS In-Reply-To: <3CD8550C.BF48CA15@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So, /var is fine, until you run rpm, and then it goes south? And you're xfs_repair-ing it after a clean unmount of the filesystem? Which directories does it complain about, things related to the rpm db, or is it unrelated parts of /var? (I have a dead RPM db as well, but as far as I know the underlying filesystem is fine...) -Eric On Wed, 8 May 2002, David Lloyd wrote: > I have a particularly broken system, a RedHat 7.1 system (default) but > the RPM database is dead (1). Nonetheless, rpm -ivh kernel-2.4.18 (XFS) > absolutely kills /var. Bugger knows why... > > Any ideas? > > (When I run xfs_repair over /dev/hda3 [aka /var] it picks up problems > with directories and such] -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 7 18:11:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g481BrwJ017101 for ; Tue, 7 May 2002 18:11:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g481BriH017100 for linux-xfs-outgoing; Tue, 7 May 2002 18:11:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g481BowJ017074 for ; Tue, 7 May 2002 18:11:50 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA4202972 for ; Tue, 7 May 2002 18:13:14 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA50296 for ; Tue, 7 May 2002 18:12:43 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id F29A113641F for ; Tue, 7 May 2002 18:12:42 -0700 (PDT) Subject: Re: Kernel 2.4.18-XFS From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <3CD8550C.BF48CA15@rebel.net.au> References: <3CD8550C.BF48CA15@rebel.net.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 07 May 2002 18:12:42 -0700 Message-Id: <1020820362.14055.177.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-07 at 15:28, David Lloyd wrote: > > I have a particularly broken system, a RedHat 7.1 system (default) but > the RPM database is dead (1). Nonetheless, rpm -ivh kernel-2.4.18 (XFS) > absolutely kills /var. Bugger knows why... > > Any ideas? rpm --rebuilddb But if you have problems with the filesystem, then you're not going to have too much luck. -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Tue May 7 18:13:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g481DdwJ017197 for ; Tue, 7 May 2002 18:13:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g481DdAe017196 for linux-xfs-outgoing; Tue, 7 May 2002 18:13:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g481DZwJ017166 for ; Tue, 7 May 2002 18:13:36 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA41762; Tue, 7 May 2002 20:14:54 -0500 (CDT) Received: from [192.168.1.101] (mtv-vpn-sw-corp-0-28.corp.sgi.com [134.15.0.28]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA41716; Tue, 7 May 2002 20:14:53 -0500 (CDT) Subject: Re: ahem 2.5.13 From: Stephen Lord To: mdew Cc: xfs In-Reply-To: <1020815976.6941.34.camel@mdew> References: <1020815976.6941.34.camel@mdew> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 07 May 2002 20:06:17 -0500 Message-Id: <1020819979.1177.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-07 at 18:59, mdew wrote: > ok ...that was a typo... You will have to wait a while, first 2.5.14 is already out there, but secondly, I have other more pressing things for the next few days, and this is a non-trivial merge since the way pages are flushed to disk was rewritten. Steve > > -- > ph33r! > Linux mdew 2.4.19-pre8-xfs-aa #2 Sat May 4 23:16:25 NZST 2002 i686 > unknown > GPG Key: http://mdew.orcon.net.nz/gpg From owner-linux-xfs@oss.sgi.com Tue May 7 21:21:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g484LYwJ020891 for ; Tue, 7 May 2002 21:21:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g484LX6q020890 for linux-xfs-outgoing; Tue, 7 May 2002 21:21:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g484LTwJ020864 for ; Tue, 7 May 2002 21:21:29 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA2918443 for ; Tue, 7 May 2002 21:22:53 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA52473 for linux-xfs@oss.sgi.com; Wed, 8 May 2002 14:21:36 +1000 (EST) Date: Wed, 8 May 2002 14:21:36 +1000 (EST) From: Nathan Scott Message-Id: <200205080421.OAA52473@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue May 7 21:19:54 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118557a linux/fs/xfs/linux/xfs_super.h - 1.17 linux/fs/xfs/linux/xfs_iops.h - 1.12 - linvfs_set_inode_ops is actually in xfs_super.c, so declare in xfs_super.h; fixes xfs_inode.c compiler warning along the way. linux/fs/xfs/pagebuf/page_buf.c - 1.20 - boost performance for metadata of small blocksize filesystems by being smarter about handling cached blocks. From owner-linux-xfs@oss.sgi.com Tue May 7 21:43:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g484hrwJ021187 for ; Tue, 7 May 2002 21:43:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g484hrVK021186 for linux-xfs-outgoing; Tue, 7 May 2002 21:43:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g484hjwJ021159 for ; Tue, 7 May 2002 21:43:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA4385956 for ; Tue, 7 May 2002 21:45:08 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA51976 for linux-xfs@oss.sgi.com; Wed, 8 May 2002 14:43:44 +1000 (EST) Date: Wed, 8 May 2002 14:43:44 +1000 (EST) From: Timothy Shimmin Message-Id: <200205080443.OAA51976@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - EA E2BIG -> ERANGE change Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This change should allow one to set and get an ACL with up to 25 entries (the XFS limit). As John Trostel noticed, this bug would cause getting an ACL to fail when retrieving an ACL with more than 16 ACEs ("argument too long"). HEADS UP: This XFS kernel change will break "xfsdump -e", i.e. the checking of the SGI_XFSDUMP_SKIP_FILE EA. You'll need xfsdump-2.0.2 in order to use the -e option with this XFS change. John, we've yet to look into the panic you reported - on the TODO list. --Tim Date: Tue May 7 21:29:55 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118558a cmd/xfsdump/VERSION - 1.30 - Bump to 2.0.2 for xfsdump ERANGE checking. cmd/xfsdump/doc/CHANGES - 1.37 - 2.0.2 change for xfsdump -e change where we now need to test for ERANGE for skip EA. cmd/xfsdump/dump/inomap.c - 1.13 - 2.0.2 change for xfsdump -e change where we now need to test for ERANGE for skip EA. cmd/xfstests/051 - 1.14 - Test for handling of large ACLs with the limit and beyond number of ACEs. cmd/xfstests/051.out - 1.14 - Test for handling of large ACLs with the limit and beyond number of ACEs. Modid: 2.4.x-xfs:slinx:118558b linux/fs/xfs/xfs_dmapi.c - 1.51 - Map ERANGE error returns from VOP_ATTR_* calls to E2BIG in order to comply with dmapi standard. linux/fs/xfs/xfs_attr_leaf.c - 1.60 linux/fs/xfs/xfs_acl.c - 1.17 - E2BIG --to--> ERANGE From owner-linux-xfs@oss.sgi.com Tue May 7 21:47:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g484lOwJ021359 for ; Tue, 7 May 2002 21:47:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g484lOKB021358 for linux-xfs-outgoing; Tue, 7 May 2002 21:47:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g484kawJ021313 for ; Tue, 7 May 2002 21:46:36 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA4111181 for ; Tue, 7 May 2002 21:47:58 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09393; Wed, 8 May 2002 14:46:37 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA11275; Wed, 8 May 2002 14:46:36 +1000 (AEST) Date: Wed, 8 May 2002 14:46:36 +1000 From: Nathan Scott To: Jan Kara , Yu-Chan Park Cc: linux-xfs@oss.sgi.com, samba@lists.samba.org Subject: Re: SAMBA compile errors at XFS kernel.. (fwd) Message-ID: <20020508144636.J108700@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi Jan, I've attached Yu-Chan's quota.h -- does this look familiar to you? It is clearly not the quota.h from the XFS CVS as I had originally thought. It may be the one from the XFS 1.1 CDs, which is a Redhat-based, XFS-enabled distro, so would have an earlier version of your VFS quota patches (via -ac kernel). Either way, it doesn't really matter. We need to fix Samba, and a local header for those folks similar to the ones in the quota tools, I guess, seems like the best option to me too. The configure script and quota.c could then be tidied up a bit here too - long time since I looked at that code though. cheers. -- Nathan ----- Forwarded message from Yu-Chan Park ----- Date: Wed, 8 May 2002 13:20:04 +0900 To: "Nathan Scott" X-Mailer: Microsoft Outlook Express 5.50.4807.1700 From: "Yu-Chan Park" Subject: Re: SAMBA compile errors at XFS kernel.. Thanks your help I attach my quota.h file regards.. Yu-Chan Park ----- Original Message ----- From: "Nathan Scott" To: "Yu-Chan Park" Sent: Wednesday, May 08, 2002 7:55 AM Subject: Re: SAMBA compile errors at XFS kernel.. > hi Yu-Chan, > > Can you send me a copy of your /usr/include/linux/quota.h > file please? We're just trying to understand where it came > from originally and whats causing these errors exactly. > > thanks. > > > On Wed, May 08, 2002 at 12:40:55AM +0200, Jan Kara wrote: > > Hello, > > > > Umm.. I can understand complaints of compiler about __kernel_uid32_t > > in the definition of qid_t. But I can't understand those problem with > > __kernel_time_t. I can't see it anywhere in the quota.h - even time_t > > is in #ifdef __KERNEL__. Anyway creating userspace version of header > > is probably the right way out of problems... I'll try to create some > > userspace header file... > > > > Honza > > > > > Some more people are hitting this problem with the new VFS > > > quota patches which we have in XFS CVS. Any idea on how we > > > should go about fixing this? Maybe we should fix Samba so > > > as to not include kernel headers (as we do in the quota user > > > tools already), creating a local header for them instead > > > with only the structures/macros they need? > > > > > > thanks. > > > > > > > > > On Tue, May 07, 2002 at 11:15:45AM +0900, Yu-Chan Park wrote: > > > > Hello xfs.. > > > > > > > > I have compiled samba 2.2.4(new release version) with gcc 2.95 or gcc 2.96 version based > > > > RedHat 7.2 and kernel 2.4.18 version which patched xfs(release 1.0) > > > > > > > > But during compiling samba occure compile errors at quota > > > > > > > > If using kernel not patched xfs samba is compiled as well. > > > > > > > > How can i escape hell :) ? > > > > > > > > Thanks.. > > > > > > > > The errors are.... > > > > > > > > Compiling smbd/quotas.c > > > > smbd/quotas.c:66: warning: `LINUX_QUOTAS_2' redefined > > > > include/config.h:238: warning: this is the location of the previous definition > > > > In file included from smbd/quotas.c:45: > > > > /usr/include/asm/types.h:18: warning: redefinition of `__u32' > > > > /usr/include/sys/capability.h:32: warning: `__u32' previously declared here > > > > In file included from smbd/quotas.c:57: > > > > /usr/include/linux/quota.h:45: parse error before `qid_t' > > > > /usr/include/linux/quota.h:45: warning: data definition has no type or storage class > > > > /usr/include/linux/quota.h:137: parse error before `__kernel_time_t' > > > > /usr/include/linux/quota.h:137: warning: no semicolon at end of struct or union > > > > /usr/include/linux/quota.h:138: warning: data definition has no type or storage class > > > > /usr/include/linux/quota.h:274: parse error before `qid_t' > > > > smbd/quotas.c: In function `get_smb_linux_vfs_quota': > > > > smbd/quotas.c:115: storage size of `D' isn't known > > > > make: *** [smbd/quotas.o] Error 1 > > > > > > > > > > > > > > -- > > > Nathan > > -- > Nathan ----- End forwarded message ----- --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="quota.h" /* * Copyright (c) 1982, 1986 Regents of the University of California. * All rights reserved. * * This code is derived from software contributed to Berkeley by * Robert Elz at The University of Melbourne. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * Version: $Id: quota.h,v 2.0 1996/11/17 16:48:14 mvw Exp mvw $ */ #ifndef _LINUX_QUOTA_ #define _LINUX_QUOTA_ #include #include typedef __kernel_uid32_t qid_t; /* Type in which we store ids in memory */ typedef __u64 qsize_t; /* Type in which we store size limitations */ #define MAXQUOTAS 2 #define USRQUOTA 0 /* element used for user quotas */ #define GRPQUOTA 1 /* element used for group quotas */ /* * Definitions for the default names of the quotas files. */ #define INITQFNAMES { \ "user", /* USRQUOTA */ \ "group", /* GRPQUOTA */ \ "undefined", \ } /* * Definitions of magics and versions of current quota files */ #define INITQMAGICS {\ 0xd9c01f11, /* USRQUOTA */\ 0xd9c01927 /* GRPQUOTA */\ } #define INITQVERSIONS {\ 0, /* USRQUOTA */\ 0 /* GRPQUOTA */\ } #define QUOTAFILENAME "aquota" #define QUOTAGROUP "staff" /* Size of blocks in which are counted size limits */ #define QUOTABLOCK_BITS 10 #define QUOTABLOCK_SIZE (1 << QUOTABLOCK_BITS) /* Conversion routines from and to quota blocks */ #define qb2kb(x) ((x) << (QUOTABLOCK_BITS-10)) #define kb2qb(x) ((x) >> (QUOTABLOCK_BITS-10)) #define toqb(x) (((x) + QUOTABLOCK_SIZE - 1) >> QUOTABLOCK_BITS) /* * Command definitions for the 'quotactl' system call. * The commands are broken into a main command defined below * and a subcommand that is used to convey the type of * quota that is being manipulated (see above). */ #define SUBCMDMASK 0x00ff #define SUBCMDSHIFT 8 #define QCMD(cmd, type) (((cmd) << SUBCMDSHIFT) | ((type) & SUBCMDMASK)) #define Q_QUOTAON 0x0100 /* enable quotas */ #define Q_QUOTAOFF 0x0200 /* disable quotas */ /* GETQUOTA, SETQUOTA and SETUSE which were at 0x0300-0x0500 has now other parameteres */ #define Q_SYNC 0x0600 /* sync disk copy of a filesystems quotas */ #define Q_SETQLIM 0x0700 /* set limits */ /* GETSTATS at 0x0800 is now longer... */ #define Q_GETINFO 0x0900 /* get info about quotas - graces, flags... */ #define Q_SETINFO 0x0A00 /* set info about quotas */ #define Q_SETGRACE 0x0B00 /* set inode and block grace */ #define Q_SETFLAGS 0x0C00 /* set flags for quota */ #define Q_GETQUOTA 0x0D00 /* get limits and usage */ #define Q_SETQUOTA 0x0E00 /* set limits and usage */ #define Q_SETUSE 0x0F00 /* set usage */ /* 0x1000 used by old RSQUASH */ /* 0x1100 used by GETSTATS v2, since replaced by procfs entry */ /* * The following structure defines the format of the disk quota file * (as it appears on disk) - the file is a hash table whose entries points * to blocks of these structures. */ struct disk_dqblk { __u32 dqb_id; /* id this quota applies to */ __u32 dqb_ihardlimit; /* absolute limit on allocated inodes */ __u32 dqb_isoftlimit; /* preferred inode limit */ __u32 dqb_curinodes; /* current # allocated inodes */ __u32 dqb_bhardlimit; /* absolute limit on disk space (in QUOTABLOCK_SIZE) */ __u32 dqb_bsoftlimit; /* preferred limit on disk space (in QUOTABLOCK_SIZE) */ __u64 dqb_curspace; /* current space occupied (in bytes) */ __u64 dqb_btime; /* time limit for excessive disk use */ __u64 dqb_itime; /* time limit for excessive inode use */ }; /* This is in-memory copy of quota block. See meaning of entries above */ struct mem_dqblk { unsigned int dqb_ihardlimit; unsigned int dqb_isoftlimit; unsigned int dqb_curinodes; unsigned int dqb_bhardlimit; unsigned int dqb_bsoftlimit; qsize_t dqb_curspace; __kernel_time_t dqb_btime; __kernel_time_t dqb_itime; }; /* * Here are header structures as written on disk and their in-memory copies */ /* First generic header */ struct disk_dqheader { __u32 dqh_magic; /* Magic number identifying file */ __u32 dqh_version; /* File version */ }; /* Header with type and version specific information */ struct disk_dqinfo { __u32 dqi_bgrace; /* Time before block soft limit becomes hard limit */ __u32 dqi_igrace; /* Time before inode soft limit becomes hard limit */ __u32 dqi_flags; /* Flags for quotafile (DQF_*) */ __u32 dqi_blocks; /* Number of blocks in file */ __u32 dqi_free_blk; /* Number of first free block in the list */ __u32 dqi_free_entry; /* Number of block with at least one free entry */ }; /* Inmemory copy of version specific information */ struct mem_dqinfo { unsigned int dqi_bgrace; unsigned int dqi_igrace; unsigned int dqi_flags; unsigned int dqi_blocks; unsigned int dqi_free_blk; unsigned int dqi_free_entry; }; /* Flags for version specific files */ #define DQF_MASK 0x0000 /* Mask for all valid ondisk flags */ #ifdef __KERNEL__ #define DQF_DIRTY 0x0010 /* Is info dirty? */ extern inline void mark_info_dirty(struct mem_dqinfo *info) { info->dqi_flags |= DQF_DIRTY; } #define info_dirty(info) ((info)->dqi_flags & DQF_DIRTY) #endif /* * Structure of header of block with quota structures. It is padded to 16 bytes so * there will be space for exactly 18 quota-entries in a block */ struct disk_dqdbheader { __u32 dqdh_next_free; /* Number of next block with free entry */ __u32 dqdh_prev_free; /* Number of previous block with free entry */ __u16 dqdh_entries; /* Number of valid entries in block */ __u16 dqdh_pad1; __u32 dqdh_pad2; }; #define DQINFOOFF sizeof(struct disk_dqheader) /* Offset of info header in file */ #define DQBLKSIZE_BITS 10 #define DQBLKSIZE (1 << DQBLKSIZE_BITS) /* Size of block with quota structures */ #define DQTREEOFF 1 /* Offset of tree in file in blocks */ #define DQTREEDEPTH 4 /* Depth of quota tree */ #define DQSTRINBLK ((DQBLKSIZE - sizeof(struct disk_dqdbheader)) / sizeof(struct disk_dqblk)) /* Number of entries in one blocks */ struct dqstats { __u32 lookups; __u32 drops; __u32 reads; __u32 writes; __u32 cache_hits; __u32 allocated_dquots; __u32 free_dquots; __u32 syncs; __u32 version; }; #ifdef __KERNEL__ extern int nr_dquots, nr_free_dquots; #define NR_DQHASH 43 /* Just an arbitrary number */ #define DQ_LOCKED 0x01 /* dquot under IO */ #define DQ_MOD 0x02 /* dquot modified since read */ #define DQ_BLKS 0x10 /* uid/gid has been warned about blk limit */ #define DQ_INODES 0x20 /* uid/gid has been warned about inode limit */ #define DQ_FAKE 0x40 /* no limits only usage */ #define DQ_INVAL 0x80 /* dquot is going to be invalidated */ struct dquot { struct list_head dq_hash; /* Hash list in memory */ struct list_head dq_inuse; /* List of all quotas */ struct list_head dq_free; /* Free list element */ wait_queue_head_t dq_wait_lock; /* Pointer to waitqueue on dquot lock */ wait_queue_head_t dq_wait_free; /* Pointer to waitqueue for quota to be unused */ int dq_count; /* Use count */ int dq_dup_ref; /* Number of duplicated refences */ /* fields after this point are cleared when invalidating */ struct super_block *dq_sb; /* superblock this applies to */ qid_t dq_id; /* ID this applies to (uid, gid) */ kdev_t dq_dev; /* Device this applies to */ short dq_type; /* Type of quota */ short dq_flags; /* See DQ_* */ loff_t dq_off; /* Offset of structure in file (0 for not allocated) */ unsigned long dq_referenced; /* Number of times this dquot was referenced during its lifetime */ struct mem_dqblk dq_dqb; /* Diskquota usage */ }; #define NODQUOT (struct dquot *)NULL #define dq_curspace dq_dqb.dqb_curspace #define dq_curinodes dq_dqb.dqb_curinodes #define dq_isoftlimit dq_dqb.dqb_isoftlimit #define dq_ihardlimit dq_dqb.dqb_ihardlimit #define dq_bsoftlimit dq_dqb.dqb_bsoftlimit #define dq_bhardlimit dq_dqb.dqb_bhardlimit #define dq_itime dq_dqb.dqb_itime #define dq_btime dq_dqb.dqb_btime /* * Flags used for set_info */ #define ISET_GRACE 0x01 #define ISET_FLAGS 0x02 #define ISET_ALL 0x03 #define QUOTA_OK 0 #define NO_QUOTA 1 typedef char *dqbuf_t; #else # /* nodep */ include __BEGIN_DECLS long quotactl __P ((int, const char *, qid_t, __kernel_caddr_t)); __END_DECLS #endif /* __KERNEL__ */ #endif /* _QUOTA_ */ --tThc/1wpZn/ma/RB-- From owner-linux-xfs@oss.sgi.com Tue May 7 22:41:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g485fDwJ022056 for ; Tue, 7 May 2002 22:41:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g485fDAe022055 for linux-xfs-outgoing; Tue, 7 May 2002 22:41:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g485f9wJ022029 for ; Tue, 7 May 2002 22:41:09 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA4352592 for ; Tue, 7 May 2002 22:42:33 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA76916 for linux-xfs@oss.sgi.com; Wed, 8 May 2002 15:41:16 +1000 (EST) Date: Wed, 8 May 2002 15:41:16 +1000 (EST) From: Nathan Scott Message-Id: <200205080541.PAA76916@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue May 7 22:40:48 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118560a cmd/xfsdump/doc/CHANGES - 1.38 cmd/xfsdump/debian/changelog - 1.20 - update for 2.0.2. cmd/xfsdump/common/drive.c - 1.3 - trivial fix for -v silent to really be silent. From owner-linux-xfs@oss.sgi.com Wed May 8 00:44:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g487icwJ024141 for ; Wed, 8 May 2002 00:44:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g487ic6Z024140 for linux-xfs-outgoing; Wed, 8 May 2002 00:44:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g487iWwJ024105 for ; Wed, 8 May 2002 00:44:33 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id EB0091D805 for ; Wed, 8 May 2002 01:07:49 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002050801074895:4820 ; Wed, 8 May 2002 01:07:48 +0200 Message-ID: <3CD85E4F.7060707@propack-data.com> Date: Wed, 08 May 2002 01:07:59 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Re: Problems compiling acl-2.0.9 References: <3CD858A1.2070208@propack-data.com> <20020508085231.E108700@wobbly.melbourne.sgi.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 08.05.2002 01:07:49, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 08.05.2002 01:07:50, Serialize complete at 08.05.2002 01:07:50 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott wrote: > On Wed, May 08, 2002 at 12:43:45AM +0200, Michael Wahlbrink wrote: [...] > > > If any are missing, then your "attr" binaries aren't installed > correctly - try "make install install-dev install-lib" in attr > source directory. Thanks, that was the solution!!! (I should read the INSTALL file correctly ;-) I remembered only on the "make install-dev" command). > > BTW, you may as well use acl-2.0.11 if building from source, there > have been a couple of bugs fixed since acl-2.0.9. > I haven't found this Version on ftp:/oss.sgi.com and cvs is not possible for me (proxy/firewall.....) ;-( thankx for the fast help! regards micha From owner-linux-xfs@oss.sgi.com Wed May 8 07:31:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EVlwJ029742 for ; Wed, 8 May 2002 07:31:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EVlq0029741 for linux-xfs-outgoing; Wed, 8 May 2002 07:31:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48EVcwJ029715 for ; Wed, 8 May 2002 07:31:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91673; Wed, 8 May 2002 09:32:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA16425; Wed, 8 May 2002 09:32:58 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g48EUp031463; Wed, 8 May 2002 09:30:51 -0500 Subject: Re: XFS optimization question From: Steve Lord To: Murthy Kambhampaty Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 08 May 2002 09:30:51 -0500 Message-Id: <1020868251.29836.69.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-07 at 17:07, Murthy Kambhampaty wrote: > I am having a little trouble decoding the documentation on "sunit" and > "swidth" w.t.t. my raid controller. > > Some background: > I have a Mylex Acceleraid352 controller running a system drive in raid-5 and > a data drive in raid-0. The default stripe width on the controller is 64K, > and a segment size of 8k, and this is what the driver's documentation says > about configuring ext2 filesystems: > > "For maximum performance and the most efficient E2FSCK performance, it is > recommended that EXT2 file systems be built with a 4KB block size and 16 > block stride to match the DAC960 controller's 64KB default stripe size. The > command "mke2fs -b 4096 -R stride=16 " is appropriate." > > For XFS, I haven't been able to find sufficient information to figure out > whether it is sunit or swidth that is analagous to the "stride" or "stripe > width" of 64K? It sounds to me like swidth, in which case would sunit be set > to the segment size of 8k? > > I'm probably going over ground that's been covered previously on this list, > but didn't have much luck finding it in the archive or the documentation. > > Thanks for the help, > Murthy I would guess from your description of the DAC960 that in xfs terms, the stripe width is 64K and the stripe unit is 8K. To quote from the mkfs.xfs man page: The sw suboption is an alternative to using swidth. The sw suboption is used to specify the stripe width for a RAID device or striped logical volume. The suboption value is expressed as a multiplier of the stripe unit, usually the same as the number of stripe members in the logical volume configuration, or data disks in a RAID device. However, the stripe width is truly more closely related to how many disks you have in a striped volume. Who knows what the DAC960 is really doing with that number. Most things though are based on stripe unit, and 8K does sound correct for that. I would get the latest mkfs from cvs, some changes just went in which relate to how striped filesystems are aligned. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 8 08:06:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48F6wwJ030408 for ; Wed, 8 May 2002 08:06:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48F6wb9030407 for linux-xfs-outgoing; Wed, 8 May 2002 08:06:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp1.globalintech.pl (helios.globalintech.pl [62.89.81.98]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48F6qwJ030381 for ; Wed, 8 May 2002 08:06:54 -0700 Received: from globalintech.pl ([172.26.25.211]) by smtp1.globalintech.pl with Microsoft SMTPSVC(5.0.2195.4453); Wed, 8 May 2002 17:08:17 +0200 Message-ID: <3CD93F61.9080702@globalintech.pl> Date: Wed, 08 May 2002 17:08:17 +0200 From: Tomasz Baranowski Organization: GlobalInTech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Some advisory needed (mysql, xfs, rjfs and hangups) Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2002 15:08:17.0358 (UTC) FILETIME=[2ECFA6E0:01C1F6A2] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Afriend of mine has installed MySql on Quad processor 2GB RAM machine. Until upgrade all was working fine. He changed kernel to 2.2.x and fs to reiserfs and MySQL start hangup. I suggested her to change kernel to 2.4 and fs to XFS but this doesn't help. Due I see some similarity (change to journaled fs) I have question: did someone have any ideas why this happens ? What is so different so MySQL hangs ? It seems like it is waiting for something, during that MySql causes 100% load of each CPU. Regards, Blizbor From owner-linux-xfs@oss.sgi.com Wed May 8 08:27:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48FRMwJ030930 for ; Wed, 8 May 2002 08:27:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48FRMRV030929 for linux-xfs-outgoing; Wed, 8 May 2002 08:27:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48FRBwJ030901 for ; Wed, 8 May 2002 08:27:12 -0700 Received: (qmail 19603 invoked by uid 500); 8 May 2002 15:28:31 -0000 Subject: Re: TAKE - pagebuf From: Austin Gonyou To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <200205080421.OAA52473@snort.melbourne.sgi.com> References: <200205080421.OAA52473@snort.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Edkn58FagTtJTHBV38TH" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 08 May 2002 10:28:30 -0500 Message-Id: <1020871711.19190.18.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Edkn58FagTtJTHBV38TH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Curious to know what is being considered *small block*? (2k 1k?) On Tue, 2002-05-07 at 23:21, Nathan Scott wrote: > Date: Tue May 7 21:19:54 PDT 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs >=20 > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs >=20 >=20 > Modid: 2.4.x-xfs:slinx:118557a > linux/fs/xfs/linux/xfs_super.h - 1.17 > linux/fs/xfs/linux/xfs_iops.h - 1.12 > - linvfs_set_inode_ops is actually in xfs_super.c, so declare in > xfs_super.h; fixes xfs_inode.c compiler warning along the way. >=20 > linux/fs/xfs/pagebuf/page_buf.c - 1.20 > - boost performance for metadata of small blocksize filesystems > by > being smarter about handling cached blocks. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-Edkn58FagTtJTHBV38TH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA82UQe94g6ZVmFMoIRArHuAKCYbt5rBx+Up6drwgh8IzKniKf3QgCfWiNo S1vq3nl270bogvVTDBgSckY= =VFM/ -----END PGP SIGNATURE----- --=-Edkn58FagTtJTHBV38TH-- From owner-linux-xfs@oss.sgi.com Wed May 8 09:10:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48GAtwJ001580 for ; Wed, 8 May 2002 09:10:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48GAs5N001579 for linux-xfs-outgoing; Wed, 8 May 2002 09:10:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48GAnwJ001552 for ; Wed, 8 May 2002 09:10:50 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA53016; Wed, 8 May 2002 11:12:10 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA54806; Wed, 8 May 2002 11:12:09 -0500 (CDT) Subject: Re: TAKE - pagebuf From: Eric Sandeen To: Austin Gonyou Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <1020871711.19190.18.camel@UberGeek> References: <200205080421.OAA52473@snort.melbourne.sgi.com> <1020871711.19190.18.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 May 2002 11:12:09 -0500 Message-Id: <1020874330.30053.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-08 at 10:28, Austin Gonyou wrote: > Curious to know what is being considered *small block*? (2k 1k?) Anything less than page size. And "boost performance" does not mean that reducing your block size is a performance enhancer; the mod you mentioned was more along the lines of "less slow," not "super fast." Note that none of this stuff is ready for prime-time yet, either... You should assume that the block size == page size restriction is still in place, for now. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 8 09:29:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48GTZwJ001935 for ; Wed, 8 May 2002 09:29:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48GTYVE001934 for linux-xfs-outgoing; Wed, 8 May 2002 09:29:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48GTPwJ001905 for ; Wed, 8 May 2002 09:29:25 -0700 Received: (qmail 23994 invoked by uid 500); 8 May 2002 16:30:45 -0000 Subject: Re: TAKE - pagebuf From: Austin Gonyou To: Eric Sandeen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <1020874330.30053.2.camel@stout.americas.sgi.com> References: <1020874330.30053.2.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LmahqkIv8QjL6MtuQVoq" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 08 May 2002 11:30:45 -0500 Message-Id: <1020875445.23942.4.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-LmahqkIv8QjL6MtuQVoq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Great info. Thanks for answering! On Wed, 2002-05-08 at 11:12, Eric Sandeen wrote: > On Wed, 2002-05-08 at 10:28, Austin Gonyou wrote: > > Curious to know what is being considered *small block*? (2k 1k?) >=20 > Anything less than page size. >=20 >=20 > And "boost performance" does not mean that reducing your block size > is a > performance enhancer; the mod you mentioned was more along the lines > of > "less slow," not "super fast." >=20 > Note that none of this stuff is ready for prime-time yet, either... > You > should assume that the block size =3D=3D page size restriction is still > in > place, for now. >=20 > -Eric >=20 > --=20 > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-LmahqkIv8QjL6MtuQVoq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA82VK194g6ZVmFMoIRAmPXAKCe3jPpPXqgBeEaKtdUtqOf5FX9OACfYYZ9 1okywiGolsYZBeWjlLcbIrc= =dGkg -----END PGP SIGNATURE----- --=-LmahqkIv8QjL6MtuQVoq-- From owner-linux-xfs@oss.sgi.com Wed May 8 09:30:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48GUwwJ002044 for ; Wed, 8 May 2002 09:30:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48GUwOF002043 for linux-xfs-outgoing; Wed, 8 May 2002 09:30:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48GUowJ001989 for ; Wed, 8 May 2002 09:30:50 -0700 Received: (qmail 22727 invoked by uid 1000); 8 May 2002 16:41:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 May 2002 16:41:25 -0000 Date: Wed, 8 May 2002 19:41:25 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Tomasz Baranowski cc: Subject: Re: Some advisory needed (mysql, xfs, rjfs and hangups) In-Reply-To: <3CD93F61.9080702@globalintech.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I dont know if the kernel/fs change triggers this bug but I did hit a similar bug with MySQL (a recent version too). It hangs up and starts spawning lots of threads and the CPU load arround 100%. Since then I have used the binary versions from mysql.com. I VERY MUCH recommend them (I did benchamarks and they are faster than any other compiled version I have made, even statically linked etc...). So try to get the last MySQL stable version, binary tar.gz (or RPM) and install it, and see if that crasshes. PS: The MySQL server I am talking about now has 70 days uptime, 800 millions queries and an average of 130 queries per second, its on XFS + software RAID 1, kernel 2.4.9-13, XFS 1.0.2 release On Wed, 8 May 2002, Tomasz Baranowski wrote: > Hi, > > Afriend of mine has installed MySql on Quad processor 2GB RAM machine. > > Until upgrade all was working fine. He changed kernel to 2.2.x and > fs to reiserfs and MySQL start hangup. I suggested her to change > kernel to 2.4 and fs to XFS but this doesn't help. > > Due I see some similarity (change to journaled fs) I have question: > did someone have any ideas why this happens ? What is so different > so MySQL hangs ? > > It seems like it is waiting for something, during that MySql causes > 100% load of each CPU. > > Regards, > Blizbor > > ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Wed May 8 09:49:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48GncwJ002554 for ; Wed, 8 May 2002 09:49:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48GncXv002551 for linux-xfs-outgoing; Wed, 8 May 2002 09:49:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48GnMwJ002520 for ; Wed, 8 May 2002 09:49:22 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id BCC87401A40; Wed, 8 May 2002 12:21:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 9F9E5C00EC6; Wed, 8 May 2002 12:21:20 -0400 (EDT) Date: Wed, 8 May 2002 12:21:20 -0400 (EDT) From: Mike Burger To: Tomasz Baranowski Cc: linux-xfs@oss.sgi.com Subject: Re: Some advisory needed (mysql, xfs, rjfs and hangups) In-Reply-To: <3CD93F61.9080702@globalintech.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I tend to doubt it's the journaled FS, in particular. I say this because I, personally, am running an XFS based system, with MySQL running on it...the only filesystem on the box that's not XFS is the /boot mount, which is ext2. Everything else is XFS, and I've not had any problems. On Wed, 8 May 2002, Tomasz Baranowski wrote: > Hi, > > Afriend of mine has installed MySql on Quad processor 2GB RAM machine. > > Until upgrade all was working fine. He changed kernel to 2.2.x and > fs to reiserfs and MySQL start hangup. I suggested her to change > kernel to 2.4 and fs to XFS but this doesn't help. > > Due I see some similarity (change to journaled fs) I have question: > did someone have any ideas why this happens ? What is so different > so MySQL hangs ? > > It seems like it is waiting for something, during that MySql causes > 100% load of each CPU. > > Regards, > Blizbor > From owner-linux-xfs@oss.sgi.com Wed May 8 10:39:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48HdHwJ003754 for ; Wed, 8 May 2002 10:39:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48HdHYb003753 for linux-xfs-outgoing; Wed, 8 May 2002 10:39:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48Hd9wJ003726 for ; Wed, 8 May 2002 10:39:11 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Wed, 8 May 2002 13:40:27 -0400 Message-ID: From: Murthy Kambhampaty To: "'Steve Lord'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: XFS optimization question Date: Wed, 8 May 2002 13:40:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wednesday, May 08, 2002 10:31, Steve Lord [mailto:lord@sgi.com] wrote: > However, the stripe width is truly more closely related to > how many disks > you have in a striped volume. Who knows what the DAC960 is > really doing with > that number. Most things though are based on stripe unit, and 8K does > sound correct for that. > Thanks, Steve, for the info. FYI, the manual for the controller defines the relevant terms as follows: Segment Size (aka Cache Line Size) The cache line size is defined as the size, in kilobytes (1024 bytes) of a single I/O operation. The Cache Line Size function is set in conjuction with stripe size and represents the size of the data "chunk" that will be read or written at one time. Stripe Size The size of a logically contiguous data block mapped to a single disk. A stripe of data (data residing in actual physical disk sectors, which are logically ordered first to last) is divided over all disks in the drive group. Stripe Width The number of striped SCSI drives within a drive group. All of this confirms your recommendation. So, is there an optimal size for the stripe width given a "cache line size" and a number of disks. (On my data drive, I have two disks, but since it is used for databases of 30Gb or larger, I have set the stripe width to 1024k (the controller has a cache of 64M). Thanks again for the help, Murthy From owner-linux-xfs@oss.sgi.com Wed May 8 10:49:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48HnmwJ003956 for ; Wed, 8 May 2002 10:49:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48Hnmt6003955 for linux-xfs-outgoing; Wed, 8 May 2002 10:49:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48HlWwJ003917 for ; Wed, 8 May 2002 10:47:32 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 19BE41E967 for ; Wed, 8 May 2002 19:48:54 +0200 (MEST) Date: Wed, 8 May 2002 19:48:53 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: x86-64 patchkit for XFS 1.1 Message-ID: <20020508194853.A1370@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk With this patch the XFS 1.1 release compiles on x86-64. All changes were only interrupt flags int -> long. This may benefit some other architectures too. Some of these changes may be already in XFS CVS. -Andi diff -burp linux-no64/fs/xfs/linux/xfs_vfs.c linux-x86_64/fs/xfs/linux/xfs_vfs.c --- linux-no64/fs/xfs/linux/xfs_vfs.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/linux/xfs_vfs.c Tue May 7 21:15:25 2002 @@ -86,7 +86,7 @@ STATIC int vfs_lock_flags(struct vfs *vfsp, int flags) { register int error; - long s; + unsigned long s; spin_lock_irqsave(&vfslock, s); if (vfsp->vfs_flag & (VFS_MLOCK|VFS_MWANT)) { @@ -153,7 +153,7 @@ vfs_lock_offline(struct vfs *vfsp) void vfs_unlock(register struct vfs *vfsp) { - long s; + unsigned long s; spin_lock_irqsave(&vfslock, s); ASSERT((vfsp->vfs_flag & (VFS_MWANT|VFS_MLOCK)) == VFS_MLOCK); @@ -176,7 +176,7 @@ vfs_unlock(register struct vfs *vfsp) int vfs_busy(struct vfs *vfsp) { - long s; + unsigned long s; spin_lock_irqsave(&vfslock, s); ASSERT((vfsp->vfs_flag & (VFS_MLOCK|VFS_OFFLINE)) != VFS_OFFLINE); @@ -209,7 +209,7 @@ vfs_busy(struct vfs *vfsp) struct vfs * vfs_busydev(dev_t dev, int type) { - long s; + unsigned long s; struct vfs *vfsp; kdev_t kdev = MKDEV(MAJOR(dev), MINOR(dev)); struct super_block *sb; @@ -296,7 +296,7 @@ vfs_devsearch_nolock(dev_t dev, int fsty void vfs_unbusy(struct vfs *vfsp) { - long s; + unsigned long s; spin_lock_irqsave(&vfslock, s); ASSERT(!(vfsp->vfs_flag & (VFS_MLOCK|VFS_OFFLINE))); @@ -321,7 +321,7 @@ struct vfs * vfs_devsearch(dev_t dev, int fstype) { register struct vfs *vfsp; - long s; + unsigned long s; spin_lock_irqsave(&vfslock, s); vfsp = vfs_devsearch_nolock(dev, fstype); @@ -366,7 +366,7 @@ vfs_insertbhv( void vfs_setflag(vfs_t *vfsp, unsigned long f) { - long s = mp_mutex_spinlock(&vfslock); + unsigned long s = mp_mutex_spinlock(&vfslock); vfsp->vfs_flag |= f; mp_mutex_spinunlock(&vfslock, s); } diff -burp linux-no64/fs/xfs/linux/xfs_vnode.c linux-x86_64/fs/xfs/linux/xfs_vnode.c --- linux-no64/fs/xfs/linux/xfs_vnode.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/linux/xfs_vnode.c Tue May 7 20:08:30 2002 @@ -84,7 +84,8 @@ vn_init(void) int vn_reclaim(struct vnode *vp, int flag) { - int error, s; + int error; + unsigned long s; XFS_STATS_INC(xfsstats.vn_reclaim); @@ -121,7 +122,7 @@ vn_reclaim(struct vnode *vp, int flag) STATIC void vn_wakeup(struct vnode *vp) { - int s = VN_LOCK(vp); + unsigned long s = VN_LOCK(vp); if (vp->v_flag & VWAIT) { sv_broadcast(vptosync(vp)); } @@ -135,7 +136,7 @@ vn_wait(struct vnode *vp) NESTED_VN_LOCK(vp); if (vp->v_flag & (VINACT | VRECLM)) { - int s; + unsigned long s; local_irq_save(s); vp->v_flag |= VWAIT; @@ -170,7 +171,7 @@ struct vnode * vn_initialize(vfs_t *vfsp, struct inode *inode, int from_readinode) { struct vnode *vp; - int s = 0; + unsigned long s = 0; XFS_STATS_INC(xfsstats.vn_active); @@ -422,7 +423,7 @@ again: struct vnode * vn_hold(struct vnode *vp) { - register int s = VN_LOCK(vp); + unsigned long s = VN_LOCK(vp); struct inode *inode; XFS_STATS_INC(xfsstats.vn_hold); @@ -453,7 +454,7 @@ vn_rele(struct vnode *vp) void vn_put(struct vnode *vp) { - int s; + unsigned long s; int vcnt; /* REFERENCED */ int cache; diff -burp linux-no64/fs/xfs/linux/xfs_vnode.h linux-x86_64/fs/xfs/linux/xfs_vnode.h --- linux-no64/fs/xfs/linux/xfs_vnode.h Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/linux/xfs_vnode.h Tue May 7 19:19:36 2002 @@ -794,7 +794,7 @@ extern void vn_put(struct vnode *); static __inline__ void vn_flagset(struct vnode *vp, uint flag) { - long flags; + unsigned long flags; spin_lock_irqsave(&vp->v_lock, flags); vp->v_flag |= flag; spin_unlock_irqrestore(&vp->v_lock, flags); @@ -802,7 +802,7 @@ static __inline__ void vn_flagset(struct static __inline__ void vn_flagclr(struct vnode *vp, uint flag) { - long flags; + unsigned long flags; spin_lock_irqsave(&vp->v_lock, flags); vp->v_flag &= ~flag; spin_unlock_irqrestore(&vp->v_lock, flags); diff -burp linux-no64/fs/xfs/xfs_alloc.c linux-x86_64/fs/xfs/xfs_alloc.c --- linux-no64/fs/xfs/xfs_alloc.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/xfs_alloc.c Tue May 7 19:34:25 2002 @@ -2504,7 +2504,7 @@ xfs_alloc_mark_busy(xfs_trans_t *tp, xfs_mount_t *mp; xfs_perag_busy_t *bsy; int n; - int s; + unsigned long s; mp = tp->t_mountp; s = mutex_spinlock(&mp->m_perag[agno].pagb_lock); @@ -2547,7 +2547,7 @@ xfs_alloc_clear_busy(xfs_trans_t *tp, { xfs_mount_t *mp; xfs_perag_busy_t *list; - int s; + unsigned long s; mp = tp->t_mountp; @@ -2581,7 +2581,8 @@ xfs_alloc_search_busy(xfs_trans_t *tp, int n; xfs_agblock_t uend, bend; xfs_lsn_t lsn; - int cnt, s; + int cnt; + unsigned long s; mp = tp->t_mountp; diff -burp linux-no64/fs/xfs/xfs_bmap.c linux-x86_64/fs/xfs/xfs_bmap.c --- linux-no64/fs/xfs/xfs_bmap.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/xfs_bmap.c Tue May 7 19:19:36 2002 @@ -3782,7 +3782,7 @@ xfs_bmap_add_attrfork( xfs_bmap_free_t flist; /* freed extent list */ int logflags; /* logging flags */ xfs_mount_t *mp; /* mount structure */ - int s; /* spinlock spl value */ + unsigned long s; /* spinlock spl value */ xfs_trans_t *tp; /* transaction pointer */ ASSERT(ip->i_df.if_ext_max == diff -burp linux-no64/fs/xfs/xfs_dquot_item.c linux-x86_64/fs/xfs/xfs_dquot_item.c --- linux-no64/fs/xfs/xfs_dquot_item.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/xfs_dquot_item.c Tue May 7 19:27:27 2002 @@ -78,7 +78,7 @@ STATIC void xfs_qm_dquot_logitem_pin( xfs_dq_logitem_t *logitem) { - int s; + unsigned long s; xfs_dquot_t *dqp; dqp = logitem->qli_dquot; @@ -97,7 +97,7 @@ STATIC void xfs_qm_dquot_logitem_unpin( xfs_dq_logitem_t *logitem) { - int s; + unsigned long s; xfs_dquot_t *dqp; dqp = logitem->qli_dquot; @@ -171,7 +171,7 @@ void xfs_qm_dqunpin_wait( xfs_dquot_t *dqp) { - int s; + unsigned long s; ASSERT(XFS_DQ_IS_LOCKED(dqp)); if (dqp->q_pincount == 0) { diff -burp linux-no64/fs/xfs/xfs_fsops.c linux-x86_64/fs/xfs/xfs_fsops.c --- linux-no64/fs/xfs/xfs_fsops.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/xfs_fsops.c Tue May 7 19:19:36 2002 @@ -438,7 +438,7 @@ xfs_fs_counts( xfs_mount_t *mp, xfs_fsop_counts_t *cnt) { - int s; + unsigned long s; s = XFS_SB_LOCK(mp); cnt->freedata = mp->m_sb.sb_fdblocks; @@ -472,7 +472,7 @@ xfs_reserve_blocks( { __uint64_t lcounter, delta; __uint64_t request; - int s; + unsigned long s; /* If inval is null, report current values and return */ diff -burp linux-no64/fs/xfs/xfs_inode.c linux-x86_64/fs/xfs/xfs_inode.c --- linux-no64/fs/xfs/xfs_inode.c Wed May 8 16:52:29 2002 +++ linux-x86_64/fs/xfs/xfs_inode.c Tue May 7 19:37:10 2002 @@ -2560,7 +2560,7 @@ void xfs_ipin( xfs_inode_t *ip) { - int s; + unsigned long s; ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); @@ -2578,7 +2578,7 @@ void xfs_iunpin( xfs_inode_t *ip) { - int s; + unsigned long s; ASSERT(ip->i_pincount > 0); @@ -2598,7 +2598,7 @@ unsigned int xfs_ipincount( xfs_inode_t *ip) { - int s; + unsigned long s; unsigned int cnt; s = mutex_spinlock(&ip->i_ipinlock); @@ -2623,7 +2623,7 @@ void xfs_iunpin_wait( xfs_inode_t *ip) { - int s; + unsigned long s; xfs_inode_log_item_t *iip; xfs_lsn_t lsn; diff -burp linux-no64/fs/xfs/xfs_log.c linux-x86_64/fs/xfs/xfs_log.c --- linux-no64/fs/xfs/xfs_log.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_log.c Tue May 7 19:44:08 2002 @@ -561,7 +561,7 @@ xfs_log_unmount_write(xfs_mount_t *mp) xfs_log_ticket_t tic = 0; xfs_lsn_t lsn; int error; - int spl; + unsigned long spl; /* the data section must be 32 bit size aligned */ struct { @@ -722,7 +722,8 @@ xfs_log_move_tail(xfs_mount_t *mp, { xlog_ticket_t *tic; xlog_t *log = mp->m_log; - int need_bytes, free_bytes, cycle, bytes, spl; + int need_bytes, free_bytes, cycle, bytes; + unsigned long spl; #if defined(DEBUG) || defined(XLOG_NOLOG) if (!xlog_debug && xlog_devt == log->l_dev) @@ -798,7 +799,8 @@ xfs_log_move_tail(xfs_mount_t *mp, int xfs_log_need_covered(xfs_mount_t *mp) { - int spl, needed = 0, gen; + int needed = 0, gen; + unsigned long spl; xlog_t *log = mp->m_log; if (mp->m_frozen || XFS_FORCED_SHUTDOWN(mp)) @@ -842,7 +844,7 @@ xfs_lsn_t xlog_assign_tail_lsn(xfs_mount_t *mp, xlog_in_core_t *iclog) { xfs_lsn_t tail_lsn; - int spl; + unsigned long spl; xlog_t *log = mp->m_log; tail_lsn = xfs_trans_tail_ail(mp); @@ -1260,7 +1262,7 @@ xlog_grant_push_ail(xfs_mount_t *mp, int free_bytes; /* free bytes left to write to */ int threshold_block; /* block in lsn we'd like to be at */ int threshold_cycle; /* lsn cycle we'd like to be at */ - int spl; + unsigned long spl; int free_threshold; ASSERT(BTOBB(need_bytes) < log->l_logBBsize); @@ -1859,7 +1861,7 @@ xlog_state_do_callback( xlog_in_core_t *first_iclog; /* used to know when we've * processed all iclogs once */ xfs_log_callback_t *cb, *cb_next; - int spl; + unsigned long spl; int flushcnt = 0; xfs_lsn_t lowest_lsn; int ioerrors; /* counter: iclogs with errors */ @@ -2074,7 +2076,7 @@ xlog_state_done_syncing( xlog_in_core_t *iclog, int aborted) { - int spl; + unsigned long spl; xlog_t *log = iclog->ic_log; spl = LOG_LOCK(log); @@ -2121,7 +2123,7 @@ xlog_state_finish_copy(xlog_t *log, int first_write, int copy_bytes) { - int spl; + unsigned long spl; spl = LOG_LOCK(log); @@ -2163,7 +2165,7 @@ xlog_state_get_iclog_space(xlog_t *log int *continued_write, int *logoffsetp) { - int spl; + unsigned long spl; int log_offset; xlog_rec_header_t *head; xlog_in_core_t *iclog; @@ -2269,7 +2271,7 @@ xlog_grant_log_space(xlog_t *log, { int free_bytes; int need_bytes; - int spl; + unsigned long spl; #ifdef DEBUG xfs_lsn_t tail_lsn; #endif @@ -2384,7 +2386,7 @@ STATIC int xlog_regrant_write_log_space(xlog_t *log, xlog_ticket_t *tic) { - int spl; + unsigned long spl; int free_bytes, need_bytes; xlog_ticket_t *ntic; #ifdef DEBUG @@ -2521,7 +2523,7 @@ STATIC void xlog_regrant_reserve_log_space(xlog_t *log, xlog_ticket_t *ticket) { - int spl; + unsigned long spl; xlog_trace_loggrant(log, ticket, "xlog_regrant_reserve_log_space: enter"); @@ -2569,7 +2571,7 @@ STATIC void xlog_ungrant_log_space(xlog_t *log, xlog_ticket_t *ticket) { - int spl; + unsigned long spl; if (ticket->t_cnt > 0) ticket->t_cnt--; @@ -2611,7 +2613,7 @@ xlog_state_lsn_is_synced(xlog_t *lo int *abortflg) { xlog_in_core_t *iclog; - int spl; + unsigned long spl; int lsn_is_synced = 1; *abortflg = 0; @@ -2651,7 +2653,7 @@ void xlog_state_put_ticket(xlog_t *log, xlog_ticket_t *tic) { - int spl; + unsigned long spl; spl = LOG_LOCK(log); xlog_ticket_put(log, tic); @@ -2672,7 +2674,7 @@ int xlog_state_release_iclog(xlog_t *log, xlog_in_core_t *iclog) { - int spl; + unsigned long spl; int sync = 0; /* do we sync? */ xlog_assign_tail_lsn(log->l_mp, 0); @@ -2780,7 +2782,7 @@ xlog_state_sync_all(xlog_t *log, uint fl { xlog_in_core_t *iclog; xfs_lsn_t lsn; - int spl; + unsigned long spl; spl = LOG_LOCK(log); @@ -2897,7 +2899,7 @@ xlog_state_sync(xlog_t *log, uint flags) { xlog_in_core_t *iclog; - int spl; + unsigned long spl; int already_slept = 0; @@ -2996,7 +2998,7 @@ try_again: void xlog_state_want_sync(xlog_t *log, xlog_in_core_t *iclog) { - int spl; + unsigned long spl; spl = LOG_LOCK(log); @@ -3028,7 +3030,7 @@ xlog_state_ticket_alloc(xlog_t *log) xlog_ticket_t *t_list; xlog_ticket_t *next; xfs_caddr_t buf; - int spl; + unsigned long spl; uint i = (NBPP / sizeof(xlog_ticket_t)) - 2; /* @@ -3116,7 +3118,7 @@ xlog_ticket_get(xlog_t *log, uint xflags) { xlog_ticket_t *tic; - int spl; + unsigned long spl; alloc: if (log->l_freelist == NULL) @@ -3289,7 +3291,8 @@ xlog_verify_iclog(xlog_t *log, xfs_caddr_t base_ptr; __psint_t field_offset; __uint8_t clientid; - int len, i, op_len, spl; + int len, i, op_len; + unsigned long spl; int idx; /* check validity of iclog pointers */ @@ -3400,7 +3403,7 @@ xfs_log_force_umount( int logerror) { xlog_ticket_t *tic; - int spl, spl2; + unsigned long spl, spl2; xlog_t *log; int retval; diff -burp linux-no64/fs/xfs/xfs_mount.c linux-x86_64/fs/xfs/xfs_mount.c --- linux-no64/fs/xfs/xfs_mount.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_mount.c Tue May 7 19:46:23 2002 @@ -1433,7 +1433,7 @@ xfs_mod_incore_sb_unlocked(xfs_mount_t * int xfs_mod_incore_sb(xfs_mount_t *mp, xfs_sb_field_t field, int delta, int rsvd) { - int s; + unsigned long s; int status; s = XFS_SB_LOCK(mp); @@ -1456,7 +1456,7 @@ xfs_mod_incore_sb(xfs_mount_t *mp, xfs_s int xfs_mod_incore_sb_batch(xfs_mount_t *mp, xfs_mod_sb_t *msb, uint nmsb, int rsvd) { - int s; + unsigned long s; int status=0; xfs_mod_sb_t *msbp; @@ -1623,7 +1623,7 @@ xfs_mount_reset_sbqflags( xfs_mount_t *mp) { xfs_trans_t *tp; - int s; + unsigned long s; mp->m_qflags = 0; /* @@ -1687,7 +1687,7 @@ xfs_start_freeze( xfs_mount_t *mp, int level) { - int s = mutex_spinlock(&mp->m_freeze_lock); + unsigned long s = mutex_spinlock(&mp->m_freeze_lock); mp->m_frozen = level; mutex_spinunlock(&mp->m_freeze_lock, s); @@ -1702,7 +1702,7 @@ void xfs_finish_freeze( xfs_mount_t *mp) { - int s = mutex_spinlock(&mp->m_freeze_lock); + unsigned long s = mutex_spinlock(&mp->m_freeze_lock); if (mp->m_frozen) { mp->m_frozen = 0; @@ -1719,7 +1719,7 @@ xfs_check_frozen( int ioflag, int level) { - int s; + unsigned long s; int do_lock = 0; if (!mp->m_frozen) { diff -burp linux-no64/fs/xfs/xfs_mount.h linux-x86_64/fs/xfs/xfs_mount.h --- linux-no64/fs/xfs/xfs_mount.h Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_mount.h Tue May 7 19:24:50 2002 @@ -82,7 +82,7 @@ struct xfs_dio; struct xfs_bmbt_irec; struct xfs_bmap_free; -#define SPLDECL(s) int s +#define SPLDECL(s) unsigned long s #define AIL_LOCK_T lock_t #define AIL_LOCKINIT(x,y) spinlock_init(x,y) #define AIL_LOCK_DESTROY(x) spinlock_destroy(x) Only in linux-x86_64/fs/xfs: xfs_mount.h-o diff -burp linux-no64/fs/xfs/xfs_qm.c linux-x86_64/fs/xfs/xfs_qm.c --- linux-no64/fs/xfs/xfs_qm.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_qm.c Tue May 7 19:19:36 2002 @@ -323,7 +323,7 @@ int xfs_qm_mount_quotas( xfs_mount_t *mp) { - int s; + unsigned long s; int error; uint sbf; @@ -1438,7 +1438,8 @@ xfs_qm_qino_alloc( uint flags) { xfs_trans_t *tp; - int error, s; + int error; + unsigned long s; cred_t zerocr; int committed; Only in linux-x86_64/fs/xfs: xfs_qm.c-XFS64 diff -burp linux-no64/fs/xfs/xfs_qm_syscalls.c linux-x86_64/fs/xfs/xfs_qm_syscalls.c --- linux-no64/fs/xfs/xfs_qm_syscalls.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_qm_syscalls.c Tue May 7 19:19:36 2002 @@ -162,7 +162,7 @@ xfs_qm_scall_quotaoff( boolean_t force) { uint dqtype; - int s; + unsigned long s; int error; uint inactivate_flags; xfs_qoff_logitem_t *qoffstart; @@ -410,7 +410,8 @@ xfs_qm_scall_quotaon( xfs_mount_t *mp, uint flags) { - int error, s; + int error; + unsigned long s; uint qf; uint accflags; __int64_t sbflags; @@ -813,7 +814,8 @@ xfs_qm_log_quotaoff( uint flags) { xfs_trans_t *tp; - int error, s; + int error; + unsigned long s; xfs_qoff_logitem_t *qoffi=NULL; uint oldsbqflag=0; Only in linux-x86_64/fs/xfs: xfs_qm_syscalls.c-XFS64 diff -burp linux-no64/fs/xfs/xfs_trans_ail.c linux-x86_64/fs/xfs/xfs_trans_ail.c --- linux-no64/fs/xfs/xfs_trans_ail.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_trans_ail.c Tue May 7 20:01:17 2002 @@ -281,7 +281,7 @@ xfs_trans_update_ail( xfs_mount_t *mp, xfs_log_item_t *lip, xfs_lsn_t lsn, - int s) + unsigned long s) { xfs_ail_entry_t *ailp; xfs_log_item_t *dlip=NULL; @@ -333,7 +333,7 @@ void xfs_trans_delete_ail( xfs_mount_t *mp, xfs_log_item_t *lip, - int s) + unsigned long s) { xfs_ail_entry_t *ailp; xfs_log_item_t *dlip; diff -burp linux-no64/fs/xfs/xfs_trans_priv.h linux-x86_64/fs/xfs/xfs_trans_priv.h --- linux-no64/fs/xfs/xfs_trans_priv.h Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_trans_priv.h Tue May 7 20:02:36 2002 @@ -61,9 +61,10 @@ xfs_log_busy_slot_t *xfs_trans_add_busy * From xfs_trans_ail.c */ void xfs_trans_update_ail(struct xfs_mount *, - struct xfs_log_item *, xfs_lsn_t, int); + struct xfs_log_item *, xfs_lsn_t, + unsigned long); void xfs_trans_delete_ail(struct xfs_mount *, - struct xfs_log_item *, int); + struct xfs_log_item *, unsigned long); struct xfs_log_item *xfs_trans_first_ail(struct xfs_mount *, int *); struct xfs_log_item *xfs_trans_next_ail(struct xfs_mount *, struct xfs_log_item *, int *, int *); diff -burp linux-no64/fs/xfs/xfs_utils.c linux-x86_64/fs/xfs/xfs_utils.c --- linux-no64/fs/xfs/xfs_utils.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_utils.c Tue May 7 19:19:36 2002 @@ -480,7 +480,7 @@ xfs_bump_ino_vers2( xfs_inode_t *ip) { xfs_mount_t *mp; - int s; + unsigned long s; ASSERT(ismrlocked (&ip->i_lock, MR_UPDATE)); ASSERT(ip->i_d.di_version == XFS_DINODE_VERSION_1); Only in linux-x86_64/fs/xfs: xfs_utils.c-XFS64 diff -burp linux-no64/fs/xfs/xfs_vfsops.c linux-x86_64/fs/xfs/xfs_vfsops.c --- linux-no64/fs/xfs/xfs_vfsops.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs/xfs_vfsops.c Tue May 7 19:19:36 2002 @@ -855,7 +855,7 @@ xfs_statvfs( xfs_extlen_t lsize; xfs_mount_t *mp; xfs_sb_t *sbp; - int s; + unsigned long s; mp = XFS_BHVTOM(bdp); sbp = &(mp->m_sb); Only in linux-x86_64/fs/xfs: xfs_vfsops.c-XFS64 diff -burp linux-no64/fs/xfs_dmapi/dmapi_private.h linux-x86_64/fs/xfs_dmapi/dmapi_private.h --- linux-no64/fs/xfs_dmapi/dmapi_private.h Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_dmapi/dmapi_private.h Tue May 7 20:19:43 2002 @@ -299,13 +299,13 @@ extern lock_t dm_reg_lock; /* lock for int dm_find_session_and_lock( dm_sessid_t sid, dm_session_t **sessionpp, - int *lcp); + unsigned long *lcp); int dm_find_msg_and_lock( dm_sessid_t sid, dm_token_t token, dm_tokevent_t **tevpp, - int *lcp); + unsigned long *lcp); dm_tokevent_t * dm_evt_create_tevp( dm_eventtype_t event, @@ -461,7 +461,7 @@ int dm_waitfor_disp_session( vfs_t *vfsp, dm_tokevent_t *tevp, dm_session_t **sessionpp, - int *lcp); + unsigned long *lcp); vnode_t * dm_handle_to_vp ( xfs_handle_t *handlep, @@ -472,7 +472,7 @@ int dm_check_dmapi_vp( dm_tokevent_t * dm_find_mount_tevp_and_lock( fsid_t *fsidp, - int *lcp); + unsigned long *lcp); int dm_path_to_hdl( char *path, Only in linux-x86_64/fs/xfs_dmapi: dmapi_private.h-o diff -burp linux-no64/fs/xfs_dmapi/dmapi_register.c linux-x86_64/fs/xfs_dmapi/dmapi_register.c --- linux-no64/fs/xfs_dmapi/dmapi_register.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_dmapi/dmapi_register.c Tue May 7 20:21:28 2002 @@ -151,7 +151,7 @@ dm_find_fsreg( static dm_fsreg_t * dm_find_fsreg_and_lock( fsid_t *fsidp, - int *lcp) /* address of returned lock cookie */ + unsigned long *lcp) /* address of returned lock cookie */ { dm_fsreg_t *fsrp; @@ -192,7 +192,7 @@ dm_add_fsys_entry( dm_fsreg_t *fsrp; int msgsize; void *msg; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Allocate and initialize a dm_fsreg_t structure for the filesystem. */ @@ -266,7 +266,7 @@ dm_change_fsys_entry( { dm_fsreg_t *fsrp; int seq_error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Find the filesystem referenced by the vfsp's fsid_t. This should always succeed. @@ -357,7 +357,7 @@ dm_remove_fsys_entry( { dm_fsreg_t **fsrpp; dm_fsreg_t *fsrp; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Find the filesystem referenced by the vfsp's fsid_t and dequeue it after verifying that the fr_state shows a filesystem that is @@ -459,7 +459,7 @@ dm_handle_to_vp( dm_fsreg_t *fsrp; vnode_t *vp; short type; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ int error; fid_t *fidp; @@ -566,7 +566,7 @@ dm_check_dmapi_vp( /* REFERENCED */ dm_fsreg_t *fsrp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if ((error = dm_vp_to_handle(vp, &handle)) != 0) return(error); @@ -587,7 +587,7 @@ dm_check_dmapi_vp( dm_tokevent_t * dm_find_mount_tevp_and_lock( fsid_t *fsidp, - int *lcp) /* address of returned lock cookie */ + unsigned long *lcp) /* address of returned lock cookie */ { dm_fsreg_t *fsrp; @@ -620,9 +620,9 @@ dm_waitfor_disp( vfs_t *vfsp, dm_tokevent_t *tevp, dm_fsreg_t **fsrpp, - int *lc1p, /* addr of first returned lock cookie */ + unsigned long *lc1p, /* addr of first returned lock cookie */ dm_session_t **sessionpp, - int *lc2p) /* addr of 2nd returned lock cookie */ + unsigned long *lc2p) /* addr of 2nd returned lock cookie */ { dm_eventtype_t event = tevp->te_msg.ev_type; dm_session_t *s; @@ -695,7 +695,7 @@ dm_waitfor_disp_session( vfs_t *vfsp, dm_tokevent_t *tevp, dm_session_t **sessionpp, - int *lcp) + unsigned long *lcp) { dm_fsreg_t *fsrp; int lc2; @@ -726,8 +726,8 @@ dm_waitfor_destroy_attrname( dm_session_t *s; dm_fsreg_t *fsrp; int error; - int lc1; /* first lock cookie */ - int lc2; /* second lock cookie */ + unsigned long lc1; /* first lock cookie */ + unsigned long lc2; /* second lock cookie */ void *msgp; tevp = dm_evt_create_tevp(DM_EVENT_DESTROY, 1, (void**)&msgp); @@ -757,7 +757,7 @@ dm_clear_fsreg( { dm_fsreg_t *fsrp; int event; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ lc = mutex_spinlock(&dm_reg_lock); @@ -793,7 +793,7 @@ dm_path_to_hdl( vnode_t *vp; size_t hlen; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ struct nameidata nd; struct inode *inode; size_t len; @@ -858,7 +858,7 @@ dm_path_to_fshdl( vnode_t *vp; size_t hlen; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ struct nameidata nd; struct inode *inode; size_t len; @@ -919,7 +919,7 @@ dm_fd_to_hdl( xfs_handle_t handle; size_t hlen; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ struct file *filep = fget(fd); if (!filep) @@ -1047,8 +1047,8 @@ dm_set_disp( dm_tokdata_t *tdp; dm_eventset_t eventset; int error; - int lc1; /* first lock cookie */ - int lc2; /* second lock cookie */ + unsigned long lc1; /* first lock cookie */ + unsigned long lc2; /* second lock cookie */ u_int i; /* Copy in and validate the event mask. Only the lower maxevent bits @@ -1176,8 +1176,8 @@ dm_set_return_on_destroy( dm_fsreg_t *fsrp; dm_session_t *s; int error; - int lc1; /* first lock cookie */ - int lc2; /* second lock cookie */ + unsigned long lc1; /* first lock cookie */ + unsigned long lc2; /* second lock cookie */ /* If a dm_attrname_t is provided, copy it in and validate it. */ @@ -1247,7 +1247,7 @@ dm_get_mountinfo( dm_fsreg_t *fsrp; dm_tokdata_t *tdp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Make sure that the caller's buffer is 8-byte aligned. */ @@ -1301,8 +1301,8 @@ dm_getall_disp( size_t *rlenp) { dm_session_t *s; /* pointer to session given by sid */ - int lc1; /* first lock cookie */ - int lc2; /* second lock cookie */ + unsigned long lc1; /* first lock cookie */ + unsigned long lc2; /* second lock cookie */ int totalsize; int msgsize; int fsyscnt; Only in linux-x86_64/fs/xfs_dmapi: dmapi_register.c-o diff -burp linux-no64/fs/xfs_dmapi/dmapi_right.c linux-x86_64/fs/xfs_dmapi/dmapi_right.c --- linux-no64/fs/xfs_dmapi/dmapi_right.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_dmapi/dmapi_right.c Tue May 7 20:28:47 2002 @@ -205,7 +205,7 @@ static int dm_app_lookup_tdp( xfs_handle_t *handlep, /* the handle we are looking for */ dm_tokevent_t *tevp, /* the event to search for the handle */ - int *lcp, /* address of active lock cookie */ + unsigned long *lcp, /* address of active lock cookie */ short types, /* acceptable object types */ dm_right_t right, /* minimum right the object must have */ u_int flags, @@ -426,7 +426,7 @@ dm_app_get_tdp_by_token( dm_tokevent_t *tevp; xfs_handle_t handle; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if (right < DM_RIGHT_NULL || right > DM_RIGHT_EXCL) return(EINVAL); @@ -477,7 +477,7 @@ dm_app_get_tdp( xfs_handle_t handle; dm_tokevent_t *tevp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ ASSERT(right >= DM_RIGHT_SHARED); @@ -531,7 +531,7 @@ dm_get_config_tdp( xfs_handle_t handle; dm_tokevent_t *tevp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if ((error = dm_copyin_handle(hanp, hlen, &handle)) != 0) return(error); @@ -637,7 +637,7 @@ dm_put_tevp( dm_tokdata_t *tdp) { int free_tdp = 0; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ lc = mutex_spinlock(&tevp->te_lock); @@ -865,7 +865,7 @@ dm_evt_rele_tevp( int droprights) /* non-zero, evt thread loses rights */ { dm_tokdata_t *tdp; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ lc = mutex_spinlock(&tevp->te_lock); Only in linux-x86_64/fs/xfs_dmapi: dmapi_right.c-o diff -burp linux-no64/fs/xfs_dmapi/dmapi_session.c linux-x86_64/fs/xfs_dmapi/dmapi_session.c --- linux-no64/fs/xfs_dmapi/dmapi_session.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_dmapi/dmapi_session.c Tue May 7 20:53:29 2002 @@ -446,7 +446,7 @@ int dm_find_session_and_lock( dm_sessid_t sid, dm_session_t **sessionpp, - int *lcp) /* addr of returned lock cookie */ + unsigned long *lcp) /* addr of returned lock cookie */ { int error; @@ -511,7 +511,7 @@ dm_find_msg_and_lock( dm_sessid_t sid, dm_token_t token, dm_tokevent_t **tevpp, - int *lcp) /* address of returned lock cookie */ + unsigned long *lcp) /* address of returned lock cookie */ { dm_session_t *s; int error; @@ -542,7 +542,7 @@ dm_create_session( char sessinfo[DM_SESSION_INFO_LEN]; size_t len; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ len = strnlen_user(info, DM_SESSION_INFO_LEN-1); if (copy_from_user(sessinfo, info, len)) @@ -599,7 +599,7 @@ dm_destroy_session( { dm_session_t *s; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* The dm_session_lock must be held until the session is unlinked. */ @@ -668,7 +668,7 @@ dm_getall_sessions( dm_session_t *s; u_int sesscnt; dm_sessid_t *sesslist; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ int error; int i; @@ -731,7 +731,7 @@ dm_query_session( int len; /* length of session info string */ int error; char sessinfo[DM_SESSION_INFO_LEN]; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if ((error = dm_find_session_and_lock(sid, &s, &lc)) != 0) return(error); @@ -770,7 +770,7 @@ dm_getall_tokens( { dm_session_t *s; /* pointer to session given by sid */ dm_tokevent_t *tevp; /* event message queue traversal */ - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ int tokcnt; dm_token_t *toklist; int error; @@ -846,7 +846,7 @@ dm_find_eventmsg( int msgsize; /* size of message to copy out */ void *msg; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Because some of the events (dm_data_event_t in particular) contain __u64 fields, we need to make sure that the buffer provided by the @@ -904,7 +904,7 @@ dm_move_event( dm_session_t *s2; dm_tokevent_t *tevp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ #ifdef __sgi int hash_it; #endif @@ -946,7 +946,7 @@ dm_pending( { dm_tokevent_t *tevp; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if ((error = dm_find_msg_and_lock(sid, token, &tevp, &lc)) != 0) return(error); @@ -972,8 +972,8 @@ dm_get_events( dm_session_t *s; /* pointer to session given by sid */ dm_tokevent_t *tevp; /* next event message on queue */ int error; - int lc1; /* first lock cookie */ - int lc2 = 0; /* second lock cookie */ + unsigned long lc1; /* first lock cookie */ + unsigned long lc2 = 0; /* second lock cookie */ int totalsize; int msgsize; dm_eventmsg_t *prevmsg; @@ -1180,7 +1180,7 @@ dm_respond_event( dm_session_t *s; /* pointer to session given by sid */ dm_tokevent_t *tevp; /* event message queue traversal */ int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Sanity check the input parameters. */ @@ -1252,7 +1252,7 @@ dm_respond_event( static int dm_enqueue( dm_session_t *s, - int lc, /* input lock cookie */ + unsigned long lc, /* input lock cookie */ dm_tokevent_t *tevp, /* in/out parameter */ int sync, int flags, @@ -1400,7 +1400,7 @@ dm_enqueue_normal_event( dm_session_t *s; int error; int sync; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ switch (tevp->te_msg.ev_type) { case DM_EVENT_READ: @@ -1469,7 +1469,7 @@ dm_enqueue_mount_event( dm_session_t *s; dm_sessid_t sid; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Make the mounting filesystem visible to other DMAPI calls. */ @@ -1520,7 +1520,7 @@ dm_enqueue_sendmsg_event( { dm_session_t *s; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ if ((error = dm_find_session_and_lock(targetsid, &s, &lc)) != 0) return(error); @@ -1537,7 +1537,7 @@ dm_enqueue_user_event( { dm_session_t *s; int error; - int lc; /* lock cookie */ + unsigned long lc; /* lock cookie */ /* Atomically find and lock the session whose session id is 'sid'. */ diff -burp linux-no64/fs/xfs_dmapi/xfsjunk.c linux-x86_64/fs/xfs_dmapi/xfsjunk.c --- linux-no64/fs/xfs_dmapi/xfsjunk.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_dmapi/xfsjunk.c Tue May 7 20:10:44 2002 @@ -6,7 +6,7 @@ struct vnode * vn_hold(struct vnode *vp) { - register int s = VN_LOCK(vp); + unsigned long s = VN_LOCK(vp); struct inode *inode; /* XFS_STATS_INC(xfsstats.vn_hold);*/ diff -burp linux-no64/fs/xfs_support/mrlock.c linux-x86_64/fs/xfs_support/mrlock.c --- linux-no64/fs/xfs_support/mrlock.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_support/mrlock.c Tue May 7 20:54:39 2002 @@ -170,7 +170,7 @@ mrupdatef(mrlock_t *mrp, int flags) int mrtryaccess(mrlock_t *mrp) { - long s; + unsigned long s; MRLOCK_INT(mrp, s); /* @@ -189,7 +189,7 @@ mrtryaccess(mrlock_t *mrp) int mrtrypromote(mrlock_t *mrp) { - long s; + unsigned long s; MRLOCK_INT(mrp, s); @@ -206,7 +206,7 @@ mrtrypromote(mrlock_t *mrp) int mrtryupdate(mrlock_t *mrp) { - long s; + unsigned long s; MRLOCK_INT(mrp, s); @@ -248,7 +248,7 @@ mraccunlock(mrlock_t *mrp) void mrunlock(mrlock_t *mrp) { - long s; + unsigned long s; MRLOCK_INT(mrp, s); if (mrp->mr_count < 0) { Only in linux-x86_64/fs/xfs_support: mrlock.c-o diff -burp linux-no64/fs/xfs_support/sv.c linux-x86_64/fs/xfs_support/sv.c --- linux-no64/fs/xfs_support/sv.c Wed May 8 16:52:30 2002 +++ linux-x86_64/fs/xfs_support/sv.c Tue May 7 19:27:59 2002 @@ -47,7 +47,7 @@ void _sv_init( sv_t *sv) spin_lock_init(&sv->lock); } -void _sv_wait( sv_t *sv, spinlock_t *lock, int spl, int intr, struct timespec *timeout) +void _sv_wait( sv_t *sv, spinlock_t *lock, unsigned long spl, int intr, struct timespec *timeout) { DECLARE_WAITQUEUE( wait, current ); diff -burp linux-no64/include/linux/xfs_support/mutex.h linux-x86_64/include/linux/xfs_support/mutex.h --- linux-no64/include/linux/xfs_support/mutex.h Wed May 8 16:52:30 2002 +++ linux-x86_64/include/linux/xfs_support/mutex.h Tue May 7 19:54:32 2002 @@ -83,7 +83,7 @@ void _mutex_destroy( mutex_t *mutex); static __inline__ int mutex_spinlock(spinlock_t *l) { - long flags; + unsigned long flags; spin_lock_irqsave(l, flags); return(flags); } diff -burp linux-no64/include/linux/xfs_support/sv.h linux-x86_64/include/linux/xfs_support/sv.h --- linux-no64/include/linux/xfs_support/sv.h Wed May 8 16:52:30 2002 +++ linux-x86_64/include/linux/xfs_support/sv.h Tue May 7 19:54:32 2002 @@ -70,7 +70,7 @@ typedef struct sv_s { } sv_t; void _sv_init(sv_t *sv); -void _sv_wait(sv_t *sv, spinlock_t *lock, int spl, int intr, struct timespec *timeout); +void _sv_wait(sv_t *sv, spinlock_t *lock, unsigned long spl, int intr, struct timespec *timeout); void _sv_broadcast(sv_t *sv); void _sv_signal(sv_t *sv); From owner-linux-xfs@oss.sgi.com Wed May 8 11:57:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48IvTwJ004919 for ; Wed, 8 May 2002 11:57:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48IvSpG004918 for linux-xfs-outgoing; Wed, 8 May 2002 11:57:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48IvLwJ004891 for ; Wed, 8 May 2002 11:57:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA34842 for ; Wed, 8 May 2002 13:58:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA24128 for ; Wed, 8 May 2002 13:58:43 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g48Iwhq09399; Wed, 8 May 2002 13:58:43 -0500 Message-Id: <200205081858.g48Iwhq09399@stout.americas.sgi.com> Date: Wed, 8 May 2002 13:58:43 -0500 Subject: TAKE - Fix log recovery error returns Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In general, 2 changes here: 1) many places returned "-ENOMEM" but within XFS, this should be (+)ENOMEM. 2) xlog_find_verify_cycle was modified in 9/2000, and along with the modification came some possible errors that could be returned from the function. Callers don't expect errors, and would interpret them as block numbers :(. This function now returns any error, and the block number is passed in as a pointer, making it easy to distinguish between errors and block numbers. :-) I think the latter case _might_ be where the bigstorage people are having trouble. Date: Wed May 8 11:56:56 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118599a cmd/xfsprogs/doc/CHANGES - 1.64 - Document error return fixes, also an older mkfs fix cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.5 - Return errors from xlog_find_verify_cycle in such a way that we can distinguish them from normal returns. Fix sign of -ENOMEM returns; should be (+) returns. Modid: 2.4.x-xfs:slinx:118599b linux/fs/xfs/xfs_log_recover.c - 1.226 - Return errors from xlog_find_verify_cycle in such a way that we can distinguish them from normal returns. Fix sign of -ENOMEM returns; should be (+) returns. From owner-linux-xfs@oss.sgi.com Wed May 8 13:01:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48K1owJ005644 for ; Wed, 8 May 2002 13:01:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48K1o1K005643 for linux-xfs-outgoing; Wed, 8 May 2002 13:01:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gigex01.guidemail.com (inmail1.guidemail.com [208.32.234.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48K1jwJ005617 for ; Wed, 8 May 2002 13:01:46 -0700 Received: by GIGEX01 with Internet Mail Service (5.5.2655.55) id ; Wed, 8 May 2002 15:03:09 -0500 Message-ID: From: "Konkol, Josh" To: "'linux-xfs@oss.sgi.com'" Subject: xfs for s/390 Date: Wed, 8 May 2002 15:03:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Have the problems with block sizes been resovled so that I can use xfs on the s/390 ?? If so can someone point me in the right direction to find information on doing this? Thanks !! Josh Konkol, CNE MCSE Senior Network Analyst GuideOne Insurance Mail Stop AB-1 515-267-2427 jkonkol@guidemail.com .~. /V\ /( )\ ^^-^^ From owner-linux-xfs@oss.sgi.com Wed May 8 13:10:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48KAbwJ010696 for ; Wed, 8 May 2002 13:10:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48KAbIs010674 for linux-xfs-outgoing; Wed, 8 May 2002 13:10:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48KAWwJ008972 for ; Wed, 8 May 2002 13:10:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA29168; Wed, 8 May 2002 15:11:54 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA86927; Wed, 8 May 2002 15:11:54 -0500 (CDT) Subject: Re: xfs for s/390 From: Eric Sandeen To: "Konkol, Josh" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 May 2002 15:11:54 -0500 Message-Id: <1020888714.10168.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Josh - As far as I know, there has been no work on the issues described in http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721115805&w=2 -Eric On Wed, 2002-05-08 at 15:03, Konkol, Josh wrote: > Have the problems with block sizes been resovled so that I can use xfs on > the s/390 ?? If so can someone point me in the right direction to find > information on doing this? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 8 15:56:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48Mu4wJ017544 for ; Wed, 8 May 2002 15:56:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48Mu4ga017543 for linux-xfs-outgoing; Wed, 8 May 2002 15:56:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48MtwwJ017517 for ; Wed, 8 May 2002 15:55:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA2733767 for ; Wed, 8 May 2002 15:57:25 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17492; Thu, 9 May 2002 08:56:08 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA33522; Thu, 9 May 2002 08:56:07 +1000 (AEST) Date: Thu, 9 May 2002 08:56:07 +1000 From: Nathan Scott To: Eric Sandeen Cc: Austin Gonyou , linux-xfs@oss.sgi.com Subject: Re: TAKE - pagebuf Message-ID: <20020509085607.E131535@wobbly.melbourne.sgi.com> References: <200205080421.OAA52473@snort.melbourne.sgi.com> <1020871711.19190.18.camel@UberGeek> <1020874330.30053.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020874330.30053.2.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, May 08, 2002 at 11:12:09AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 08, 2002 at 11:12:09AM -0500, Eric Sandeen wrote: > On Wed, 2002-05-08 at 10:28, Austin Gonyou wrote: > > Curious to know what is being considered *small block*? (2k 1k?) > > Anything less than page size. > > And "boost performance" does not mean that reducing your block size is a > performance enhancer; the mod you mentioned was more along the lines of > "less slow," not "super fast." This mod gets Note that none of this stuff is ready for prime-time yet, either... You > should assume that the block size == page size restriction is still in > place, for now. It _is_ still in place (the Linux/XFS mount code path doesn't allow fs's with non-pgsize blocks), no assumption about it. There is still plenty to be done before we drop this check I think, but not too far off now. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 8 15:58:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48MwHwJ017708 for ; Wed, 8 May 2002 15:58:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48MwH6V017707 for linux-xfs-outgoing; Wed, 8 May 2002 15:58:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48MwBwJ017681 for ; Wed, 8 May 2002 15:58:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA58030; Wed, 8 May 2002 17:59:34 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA15134; Wed, 8 May 2002 17:59:34 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id RAA18710; Wed, 8 May 2002 17:59:33 -0500 (CDT) Message-ID: <3CD9ADD4.79FC3D8E@sgi.com> Date: Wed, 08 May 2002 17:59:32 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: masano@tnes.nec.co.jp Subject: TAKE - xfsdump Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -------------------------------------------------------- Workarea: dmfnt2.americas.sgi.com:/ptmp/mkulima/NEC The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs (submitted by mkulima on 05/08/02 14:12:41) - xfsdump/VERSION: - xfsdump/doc/CHANGES: - Update for 2.0.3 - xfsdump/inventory/inv_api.c: - Fixed xfsdump so that it does not cause segmentation fault when media object id is specified using -I option ("xfsdump -I mobjid="). - Fixed similar code for filesystem option. --------------------------------------------------------- Asano, thank you for identifying and providing a fix for this bug. Thanks, Kihonge JN From owner-linux-xfs@oss.sgi.com Wed May 8 22:27:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g495RTwJ022652 for ; Wed, 8 May 2002 22:27:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g495RT6U022651 for linux-xfs-outgoing; Wed, 8 May 2002 22:27:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g495ROwJ022624 for ; Wed, 8 May 2002 22:27:24 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA3575575 for ; Wed, 8 May 2002 22:28:53 -0700 (PDT) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA70157 for linux-xfs@oss.sgi.com; Thu, 9 May 2002 15:27:32 +1000 (EST) Date: Thu, 9 May 2002 15:27:32 +1000 (EST) From: Timothy Shimmin Message-Id: <200205090527.PAA70157@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 067 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Write qa test to reproduce John Trostel's bug. --Tim Date: Wed May 8 22:26:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118686a cmd/xfstests/067 - 1.1 - reproduce john trostels bug when going from 20 aces to 21 aces. cmd/xfstests/051 - 1.15 - move some acl funcs into common.attr cmd/xfstests/common.attr - 1.3 - add some handy acl funcs cmd/xfstests/group - 1.22 - add 067 From owner-linux-xfs@oss.sgi.com Thu May 9 00:28:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g497SZwJ023786 for ; Thu, 9 May 2002 00:28:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g497SZum023785 for linux-xfs-outgoing; Thu, 9 May 2002 00:28:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g497SPwJ023759 for ; Thu, 9 May 2002 00:28:25 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA4321625 for ; Thu, 9 May 2002 00:29:53 -0700 (PDT) mail_from (fsgqa@bruce.melbourne.sgi.com) Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id RAA02721 for linux-xfs@oss.sgi.com; Thu, 9 May 2002 17:29:43 +1000 Date: Thu, 9 May 2002 17:29:43 +1000 From: FSG QA Message-Id: <200205090729.RAA02721@bruce.melbourne.sgi.com> Subject: TAKE - xfstests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue May 7 22:45:22 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118561a cmd/xfstests/common.config - 1.15 - fix bruce's remote tape setup, remove couple of old QA machines now used for other duties. cmd/xfstests/tools/auto-qa - 1.26 - spilt the kernel/userspace build component apart to allow use of auto-qa for quicker build/installs. Date: Wed May 8 16:44:54 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118672a cmd/xfstests/066 - 1.5 - Fix a typo. Date: Wed May 8 23:03:32 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118687a cmd/xfstests/016 - 1.6 - fix to work with multiple block sizes - we were running mkfs with a log size which was dependent on block size, and became too small for 1024k filesystems. cmd/xfstests/common.repair - 1.2 cmd/xfstests/030.out - 1.2 - inode numbers will be different for non-pagesize blksize filesystems, fix. Date: Wed May 8 23:09:58 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118688a cmd/xfstests/044 - 1.6 cmd/xfstests/055 - 1.2 cmd/xfstests/056 - 1.2 - fix typo in header comment. Date: Thu May 9 00:24:12 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:118690a cmd/xfstests/check - 1.5 - cosmetic change to script output. cmd/xfstests/018 - 1.9 cmd/xfstests/018.ugquota - 1.3 cmd/xfstests/018.usrquota - 1.5 cmd/xfstests/018.grpquota - 1.3 cmd/xfstests/018.noquota - 1.4 - updates for supporting blocksizes smaller than the pagesize. From owner-linux-xfs@oss.sgi.com Thu May 9 00:41:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g497fDwJ024067 for ; Thu, 9 May 2002 00:41:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g497fDEn024066 for linux-xfs-outgoing; Thu, 9 May 2002 00:41:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g497f6wJ024040 for ; Thu, 9 May 2002 00:41:07 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 1709BC000AA; Thu, 9 May 2002 17:42:30 +1000 (EST) Date: Thu, 9 May 2002 17:42:30 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: default ACL behaviour Message-ID: <20020509074230.GA31809@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, is the following meant to happen? I set a default group mask, and the file also gains a default user mask of rwx. Could someone please explain this to me? ... and hit me with a big stick if this is default ACL behaviour ;) cheers, Ian. ids:/tmp# mkdir test ids:/tmp# setfacl -dm u:www-data:r-x test ids:/tmp# getfacl test # file: test # owner: root # group: root user::rwx group::r-x other::--- default:user::rwx default:user:www-data:r-x default:group::r-x default:mask::r-x default:other::--- -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Thu May 9 04:06:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49B6awJ026706 for ; Thu, 9 May 2002 04:06:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49B6apq026705 for linux-xfs-outgoing; Thu, 9 May 2002 04:06:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moe.rice.edu (moe.rice.edu [128.42.5.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49B6VwJ026679 for ; Thu, 9 May 2002 04:06:31 -0700 Received: from photino.sid.rice.edu (sid-1129.sid.rice.edu [128.42.162.129]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id GAA09244 for ; Thu, 9 May 2002 06:08:01 -0500 (CDT) Received: by photino.sid.rice.edu (Postfix, from userid 1000) id B663068B9; Thu, 9 May 2002 06:08:00 -0500 (CDT) To: linux-xfs@oss.sgi.com Subject: Re: Lockups while X is running References: <20020320165017.GA3454@xiao> <1016644790.24161.35.camel@stout.americas.sgi.com> From: Rahul Jain Date: 09 May 2002 06:08:00 -0500 In-Reply-To: <1016644790.24161.35.camel@stout.americas.sgi.com> Message-ID: <87vg9xmve7.fsf@photino.sid.rice.edu> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen writes: > If the machine locks up while X is running, you really need kdb on a > serial console to use it, unfortunately. A palm pilot will work, if you > have one. :) Can this work with a visor on a USB port, out of curiosity? -- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rjain@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Thu May 9 04:15:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49BFWwJ026922 for ; Thu, 9 May 2002 04:15:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49BFWHV026921 for linux-xfs-outgoing; Thu, 9 May 2002 04:15:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49BFSwJ026866 for ; Thu, 9 May 2002 04:15:28 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA65449; Thu, 9 May 2002 06:16:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA92026; Thu, 9 May 2002 06:16:53 -0500 (CDT) Date: Thu, 9 May 2002 06:16:53 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rahul Jain cc: linux-xfs@oss.sgi.com Subject: Re: Lockups while X is running In-Reply-To: <87vg9xmve7.fsf@photino.sid.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 9 May 2002, Rahul Jain wrote: > Eric Sandeen writes: > > > If the machine locks up while X is running, you really need kdb on a > > serial console to use it, unfortunately. A palm pilot will work, if you > > have one. :) > > Can this work with a visor on a USB port, out of curiosity? Not as far as I know... there is no "CONFIG_USB_CONSOLE" :) although I see that console support for the USB serial drivers is planned for 2.5.... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu May 9 05:11:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49CBawJ027379 for ; Thu, 9 May 2002 05:11:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49CBamr027378 for linux-xfs-outgoing; Thu, 9 May 2002 05:11:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49CBTwJ027352 for ; Thu, 9 May 2002 05:11:30 -0700 Message-Id: <200205091211.g49CBTwJ027352@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GVUF9I00.3YN; Thu, 9 May 2002 22:12:54 +1000 Received: from CPE-144-137-138-147.qld.bigpond.net.au ([144.137.138.147]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0m 125/671229); 09 May 2002 22:12:51 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Nathan Scott , Nigel Kukard Subject: Re: ./configure - niceness Date: Thu, 9 May 2002 22:12:46 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List References: <20020430095422.A100718@wobbly.melbourne.sgi.com> In-Reply-To: <20020430095422.A100718@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan, I understand that you have a very long to-do list at the moment and are busy with internal SGI projects. However, any idea when this patch will be intergrated into CVS? If it is all-ready in there then I apologise; however, I cannot remember seeing a TAKE message for it. This is quite a handy little patch for those of us that like to have the user tool binaries in different places. Thanks On Tue, 30 Apr 2002 09:54, Nathan Scott wrote: > On Mon, Apr 29, 2002 at 08:10:41PM +0200, Nigel Kukard wrote: > > SUMMARY > > ------- > > - Removed ROOT_PREFIX && PREFIX default environment variable usage > > - Fixed all configure *dir variables to properly work > > - Fixed --prefix & --exec-prefix and the like to work as expected > > Thanks Nigel, I'll have a proper look though it as soon as I > get a chance. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Thu May 9 08:20:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49FK1wJ028949 for ; Thu, 9 May 2002 08:20:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49FK0Ne028948 for linux-xfs-outgoing; Thu, 9 May 2002 08:20:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49FJhwJ028915 for ; Thu, 9 May 2002 08:19:44 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g49FG3910677; Thu, 9 May 2002 17:16:03 +0200 Date: Thu, 9 May 2002 17:16:03 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Eric Sandeen Cc: linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: TAKE - Fix log recovery error returns Message-ID: <20020509171603.O18743@vestdata.no> References: <200205081858.g48Iwhq09399@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205081858.g48Iwhq09399@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, May 08, 2002 at 01:58:43PM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g49FG3910677 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g49FJjwJ028917 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 08, 2002 at 01:58:43PM -0500, Eric Sandeen wrote: > I think the latter case _might_ be where the bigstorage people are > having trouble. Unfortenately it doesn't solve our problem. I've run the whole process in the debugger, and: xlog_find_tail get's called with: *log = {l_tail_lsn = 0, l_last_sync_lsn = 0, l_mp = 0xbffff4f0, l_dev = 2065, l_logBBstart = 838860832, l_logsize = 105046016, l_logBBsize = 205168, l_curr_cycle = 0, l_prev_cycle = 0, l_curr_block = 0, l_prev_block = 0, l_iclog_size = 0, l_iclog_size_log = 0, l_iclog_bufs = 0, l_grant_reserve_cycle = 0, l_grant_reserve_bytes = 0, l_grant_write_cycle = 0, l_grant_write_bytes = 0} *head_blk = 4612076345055252480 *tail_blk = 4612568755539746816 I suppose the later two are return-arguments, and it's ok for them to be garbage? Now, on line 690 in zlog_find_zeroed something strange happens: 690 first_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); 16: first_cycle = 0 15: error = 0 (gdb) 691 if (first_cycle == 0) { /* completely zeroed log */ 16: first_cycle = 1 15: error = 1 (gdb) So GET_CYCLE is setting both first_cycle and error = 1 ?? *bp = {b_blkno = 838860832, b_bcount = 512, b_dev = 2065, b_fsprivate = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_addr = 0x80ed5ac "þíº¾"} Also I get: (gdb) display last_cycle No symbol "last_cycle" in current context. but it clearly _should_ be defined in this context!? This was done with gcc 2.96, so I switched to gcc 3.0.2 Now the "last_cycle" symbol was defined correctly, but "error" still chnaged when it was not supposed to: (gdb) 146 return __arch__swab32(x); 3: last_cycle = 16777216 2: first_cycle = 0 1: error = 0 (gdb) 691 if (first_cycle == 0) { /* completely zeroed log */ 3: last_cycle = 16777216 2: first_cycle = 1 1: error = 1 (gdb) I've now removed the "-O1" part from CFLAGS, and this problem went away. I'm unsure if the compiler- / compilerflag-problems affect the actual process or just the debugging. Just to be safe, I'll do all futher testing with gcc3 and no optimization. OK; next problem: xlog_find_zeroed appear to return -1 without setting blk_no first. This happens because xlog_find_verify_log_record returns -1. xlog_find_verify_log_record is called with: *log = {l_tail_lsn = 0, l_last_sync_lsn = 0, l_mp = 0xbffff4d0, l_dev = 2065, l_logBBstart = 838860832, l_logsize = 105046016, l_logBBsize = 205168, l_curr_cycle = 0, l_prev_cycle = 0, l_curr_block = 0, l_prev_block = 0, l_iclog_size = 0, l_iclog_size_log = 0, l_iclog_bufs = 0, l_grant_reserve_cycle = 0, l_grant_reserve_bytes = 0, l_grant_write_cycle = 0, l_grant_write_bytes = 0} start_blk = 0 *last_blk = 0 extra_bblks = 0 The return is done on line 200, from the following code: /* * We hit the beginning of the physical log & still no header. * Return * to caller. If caller can handle a return of -1, then this * routine * will be called again for the end of the physical log. */ if (i == -1) { error = -1; goto out; } Shoud it be changed to "error = 1;" ? Or a different possitive error-code? AFAICT if we set error to a possitive value it will be returned all the way back to zero_log. This will warn that the head/tail is not found, but will zero the log anyway, and repair should go on... -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Thu May 9 08:27:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49FRDwJ029150 for ; Thu, 9 May 2002 08:27:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49FRCax029149 for linux-xfs-outgoing; Thu, 9 May 2002 08:27:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49FR5wJ029121 for ; Thu, 9 May 2002 08:27:06 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g49FSV810966; Thu, 9 May 2002 17:28:31 +0200 Date: Thu, 9 May 2002 17:28:31 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Stephen Lord Cc: Eric Sandeen , Willi.Langenberger@wu-wien.ac.at, linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: xfs_repair trouble Message-ID: <20020509172831.P18743@vestdata.no> References: <20020507001545.G18743@vestdata.no> <15575.57022.571520.335291@slime.wu-wien.ac.at> <20020507171600.P18743@vestdata.no> <1020787090.24935.45.camel@stout.americas.sgi.com> <20020507213407.Z18743@vestdata.no> <3CD83558.5020601@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD83558.5020601@sgi.com>; from lord@sgi.com on Tue, May 07, 2002 at 03:13:12PM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g49FSV810966 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g49FR6wJ029122 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 03:13:12PM -0500, Stephen Lord wrote: > >Is there something we can test in the meantime to get our filesystem > >back? I was thinking of commenting out the zero_log() part of xfs_repair > >to get it to run the rest of the process. Is that safe? Will the > >filesystem mount afterwards? > > Can you run xfs_check on the filesystem and see what that reports? It > ignores the log, > so there is no problem there. It ignores the log, but reports 152558 other errors... That sounds like a lot.... > You can then use dd to write some zeros into this location, you probably > want to do it for logblocks blocks, this value is in 4K units, just multiply > by 8 to get 512 byte units. > > To be doubly safe, dd this portion of the device out to a file before > zeroing it. > > You can then use xfs_repair on the filesystem to hopefully fix it up, > it usually does a good job. Thanks. I will try this if we can not get xfs_repair to fix the problem, but right now I think we're close to locating the problem and then it would be better to fix it so we don't run into this again. I've copied the log into a file; let me know if you want a copy to find out why it got corrupted in the first place... (it used to run 2.4.9-13SGI_XFS_1.0.2 kernel, so it maybe the bug is fixed already?) -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Thu May 9 09:15:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49GFNwJ003577 for ; Thu, 9 May 2002 09:15:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49GFNUT003576 for linux-xfs-outgoing; Thu, 9 May 2002 09:15:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49GFBwJ003549 for ; Thu, 9 May 2002 09:15:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA61848; Thu, 9 May 2002 11:16:36 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA49690; Thu, 9 May 2002 11:16:36 -0500 (CDT) Date: Thu, 9 May 2002 11:16:36 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= cc: linux-xfs@oss.sgi.com, Subject: Re: TAKE - Fix log recovery error returns In-Reply-To: <20020509171603.O18743@vestdata.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by zeus-e8.americas.sgi.com id LAA61848 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g49GFBwJ003551 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 9 May 2002, Ragnar Kjørstad wrote: > Unfortenately it doesn't solve our problem. I've run the whole process > in the debugger, and: Darn... (You've rebuilt & reinstalled all of the relevant userspace, I guess?) > xlog_find_tail get's called with: > *head_blk = 4612076345055252480 > *tail_blk = 4612568755539746816 > > I suppose the later two are return-arguments, and it's ok for them to be > garbage? Yep, they're brand new variables from xlog_recover, they're garbage at this point. > Now, on line 690 in zlog_find_zeroed something strange happens: > 690 first_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); > 16: first_cycle = 0 > 15: error = 0 > (gdb) > 691 if (first_cycle == 0) { /* completely zeroed log */ > 16: first_cycle = 1 > 15: error = 1 > (gdb) > > So GET_CYCLE is setting both first_cycle and error = 1 ?? I don't understand that... > Also I get: > (gdb) display last_cycle > No symbol "last_cycle" in current context. > > but it clearly _should_ be defined in this context!? > > This was done with gcc 2.96, so I switched to gcc 3.0.2 > I'm unsure if the compiler- / compilerflag-problems affect the actual process > or just the debugging. Just to be safe, I'll do all futher testing with > gcc3 and no optimization. Ah... http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC17 states that -O should work, but that things might not behave as expected. > OK; next problem: xlog_find_zeroed appear to return -1 without setting > blk_no first. > > This happens because xlog_find_verify_log_record returns -1. > > xlog_find_verify_log_record is called with: > *log = {l_tail_lsn = 0, l_last_sync_lsn = 0, l_mp = 0xbffff4d0, > l_dev = 2065, l_logBBstart = 838860832, l_logsize = 105046016, > l_logBBsize = 205168, l_curr_cycle = 0, l_prev_cycle = 0, l_curr_block = 0, > l_prev_block = 0, l_iclog_size = 0, l_iclog_size_log = 0, l_iclog_bufs = 0, > l_grant_reserve_cycle = 0, l_grant_reserve_bytes = 0, > l_grant_write_cycle = 0, l_grant_write_bytes = 0} > start_blk = 0 > *last_blk = 0 > extra_bblks = 0 > > The return is done on line 200, from the following code: > /* > * We hit the beginning of the physical log & still no header. > * Return > * to caller. If caller can handle a return of -1, then this > * routine > * will be called again for the end of the physical log. > */ > if (i == -1) { > error = -1; > goto out; > } > > Shoud it be changed to "error = 1;" ? Or a different possitive > error-code? AFAICT if we set error to a possitive value it will be > returned all the way back to zero_log. This will warn that the head/tail > is not found, but will zero the log anyway, and repair should go on... Yep, this does look a bit odd... I'll have to take some time to look at this, I'm not that familiar with the log recovery code... arbitrarily setting it to 1 probably isn't right (that's a specific error code...) Unfortunately there's a lot going on right now, no guarantees about how soon I can try to sort this out - looks like you're getting a pretty good handle on it already, though. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu May 9 11:11:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49IB6wJ011463 for ; Thu, 9 May 2002 11:11:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49IB6oL011462 for linux-xfs-outgoing; Thu, 9 May 2002 11:11:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49IAuwJ011430 for ; Thu, 9 May 2002 11:10:57 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g49ICLE14866; Thu, 9 May 2002 20:12:21 +0200 Date: Thu, 9 May 2002 20:12:21 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Eric Sandeen Cc: linux-xfs@oss.sgi.com, kevin@bigstorage.com Subject: Re: TAKE - Fix log recovery error returns Message-ID: <20020509201221.R18743@vestdata.no> References: <20020509171603.O18743@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from sandeen@sgi.com on Thu, May 09, 2002 at 11:16:36AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g49ICLE14866 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g49IAwwJ011434 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 09, 2002 at 11:16:36AM -0500, Eric Sandeen wrote: > On Thu, 9 May 2002, Ragnar Kjørstad wrote: > > > Unfortenately it doesn't solve our problem. I've run the whole process > > in the debugger, and: > > Darn... > (You've rebuilt & reinstalled all of the relevant userspace, I guess?) I didn't "install" it, but am running it locally from the CVS-dir. And yes, I did a make clean first. > > Shoud it be changed to "error = 1;" ? Or a different possitive > > error-code? AFAICT if we set error to a possitive value it will be > > returned all the way back to zero_log. This will warn that the head/tail > > is not found, but will zero the log anyway, and repair should go on... > > Yep, this does look a bit odd... I'll have to take some time to > look at this, I'm not that familiar with the log recovery code... > arbitrarily setting it to 1 probably isn't right (that's a specific > error code...) > > Unfortunately there's a lot going on right now, no guarantees about how > soon I can try to sort this out - looks like you're getting a pretty > good handle on it already, though. :) When I did the propsed change the xfs_repair was able to continue, but of course the fix is "wrong" as the problem has nothing to do with EPERM. (if the error is supposed to be an errno-type error-code) Also, this just "fixes" the error-handling when the log can not be parsed - it does not address the actual parsing of the log. It should be noted that "xfs_repair -L" was run on the filesystem earlier, because the filesystem could not be mounted. Anyway; the filesystem now mounts, and some data is left. Unfortenately the fs is very damaged (most of the directory-structure and I fear a lot of the data is gone). Is there anything more that can be done, or is what's lost lost? Also I think it's strange that so much data was lost if it was only the log that was corrupted. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Thu May 9 11:49:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49InvwJ013464 for ; Thu, 9 May 2002 11:49:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49Invgp013463 for linux-xfs-outgoing; Thu, 9 May 2002 11:49:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49InowJ013437 for ; Thu, 9 May 2002 11:49:50 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA3749326 for ; Thu, 9 May 2002 11:51:21 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA46179 for ; Thu, 9 May 2002 11:50:50 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id BA61F13641F for ; Thu, 9 May 2002 11:50:50 -0700 (PDT) Subject: [Fwd: RE: XFS support] From: Florin Andrei To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 May 2002 11:50:50 -0700 Message-Id: <1020970250.5074.44.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Red Hat 7.3 was just released, and people are already getting anxious to get XFS support in it. I've seen some requests on redhat-devel-list. :-) And, yeah, from the "self-styled, self-driven XFS Advertising Department" (just kidding), the following answer was sprinkled upon the starving masses: -----Forwarded Message----- From: Florin Andrei To: redhat-devel-list@redhat.com Subject: RE: XFS support Date: 09 May 2002 11:36:58 -0700 On Thu, 2002-05-09 at 11:26, Paul Hamm wrote: > ?????? Hun? > xfs 1672 1 0 Apr26 ? 00:00:23 xfs -droppriv -daemon > > Am I missing something obvious? Or is this not the X font server? Knut was talking about SGI XFS, the high-performance filesystem used on video pumps, multimedia servers, etc.: http://oss.sgi.com/projects/xfs/ Usually, the SGI team provides a slightly modified installer that can be used instead of the default one to install Red Hat directly on XFS partitions. You can download the installer from the address above. Since 7.3 was just released a few days ago, it's going to take a few days/weeks before the SGI 7.3 installer will be provided. But it looks like some people are too anxious to get XFS faster! ;-) -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Thu May 9 12:02:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49J2HwJ013765 for ; Thu, 9 May 2002 12:02:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49J2H9v013764 for linux-xfs-outgoing; Thu, 9 May 2002 12:02:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49J2BwJ013738 for ; Thu, 9 May 2002 12:02:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA73798 for ; Thu, 9 May 2002 14:03:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA10867 for ; Thu, 9 May 2002 14:03:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g49J1Je13576; Thu, 9 May 2002 14:01:19 -0500 Message-Id: <200205091901.g49J1Je13576@jen.americas.sgi.com> Date: Thu, 9 May 2002 14:01:19 -0500 Subject: TAKE - fix space reservation for out of line extended attributes To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We tripped over this on a 1K block filesystem, we seem to have lucked out in the 4K block case in that the numbers came out 'good enough'. So I am not sure there is a practical implication for existing filesystems. Steve Date: Thu May 9 11:42:19 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:118747a linux/fs/xfs/xfs_attr.c - 1.90 - fix space reservation calculation for out of line extended attributes. From owner-linux-xfs@oss.sgi.com Thu May 9 15:19:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49MJTwJ022941 for ; Thu, 9 May 2002 15:19:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49MJTlS022940 for linux-xfs-outgoing; Thu, 9 May 2002 15:19:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49MJNwJ022914 for ; Thu, 9 May 2002 15:19:23 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA4575269 for ; Thu, 9 May 2002 15:20:54 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA27772; Fri, 10 May 2002 08:19:37 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA36727; Fri, 10 May 2002 08:19:36 +1000 (AEST) Date: Fri, 10 May 2002 08:19:36 +1000 From: Nathan Scott To: Adrian Head , Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: ./configure - niceness Message-ID: <20020510081936.N131535@wobbly.melbourne.sgi.com> References: <20020430095422.A100718@wobbly.melbourne.sgi.com> <200205091211.g49CBTwJ027352@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205091211.g49CBTwJ027352@oss.sgi.com>; from ahead@bigpond.net.au on Thu, May 09, 2002 at 10:12:46PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there, On Thu, May 09, 2002 at 10:12:46PM +1000, Adrian Head wrote: > However, any idea when this patch will be intergrated into CVS? If it is > all-ready in there then I apologise; however, I cannot remember seeing a TAKE > message for it. No its not in there yet. This patch needs some changes before it goes in, I've been having some discussions with Nigel about it, he's going to get back to me when he's reworked some bits. > This is quite a handy little patch for those of us that like to have the user > tool binaries in different places. The patch simply changes ROOT_PREFIX and PREFIX from environment variables to configure options, it doesn't add new functionality (ie. you can achieve the above with the existing build system). Unfortunately it has some side-effects on some parts of the build process which were not foreseen; it shouldn't be too difficult to fix though, and Nigel is working on it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 9 15:52:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49MqhwJ023318 for ; Thu, 9 May 2002 15:52:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49MqhhR023317 for linux-xfs-outgoing; Thu, 9 May 2002 15:52:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49MqcwJ023291 for ; Thu, 9 May 2002 15:52:38 -0700 Message-Id: <200205092252.g49MqcwJ023291@oss.sgi.com> Received: from there ([144.135.24.78]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw Feb 26 2002 03:44:21) with SMTP id GVV8Y300.I1R; Fri, 10 May 2002 08:54:03 +1000 Received: from CPE-144-137-138-147.qld.bigpond.net.au ([144.137.138.147]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0m 35/1401872); 10 May 2002 08:54:02 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Nathan Scott , Nigel Kukard Subject: Re: ./configure - niceness Date: Fri, 10 May 2002 08:53:59 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List References: <200205091211.g49CBTwJ027352@oss.sgi.com> <20020510081936.N131535@wobbly.melbourne.sgi.com> In-Reply-To: <20020510081936.N131535@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan, Thanks for taking the time to give an up-date - much appreciated. > No its not in there yet. This patch needs some changes before > it goes in, I've been having some discussions with Nigel about > it, he's going to get back to me when he's reworked some bits. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Thu May 9 22:56:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A5uuwJ001943 for ; Thu, 9 May 2002 22:56:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A5uuaf001942 for linux-xfs-outgoing; Thu, 9 May 2002 22:56:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail2.etransmail2.com ([207.67.131.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A5uOwJ001915 for ; Thu, 9 May 2002 22:56:34 -0700 Message-Id: <200205100556.g4A5uOwJ001915@oss.sgi.com> Received: from PickupDirectory by mail2.etransmail2.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTR0L61P; Thu, 9 May 2002 20:39:11 -0700 From: "Sarah Davis" To: Subject: Invitation to Bid on Excess Inventory! Date: Wed, 8 May 2002 21:14:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4A5ufwJ001916 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Good Afternoon! Please kindly review the below items and excess inventory quantities we can offer for liquidation. All products are available immediately, ready for pick-up on palletes. If you are interested, please enter your bid right below each offering. After evaluation we will call the highest bidder to arrange for pick-up and payment details. Please provide your name, address and telephone number. ///Bids accepted until May 10th, 5pm EST/// Thank you very much! ****************************** 1. eTransForm 2000 http://www.g7ps.com/scripts/etrans.asp Units: 10,200 Condition: Unopened original packaging SRP: $495 BID:....... ******************************* 2. eExpressForms 2000 http://www.g7ps.com/scripts/expforms.asp Units: 3,500 Condition: Unopened original packaging SRP: $129 BID:....... ******************************* 3. WebCommerce Deluxe http://www.g7ps.com/scripts/webdelx.asp Units: 500 Condition: Unopened original packaging SRP: $99 BID:....... ******************************* 4. Fortune http://www.g7ps.com/scripts/fortune.asp Units: 6,000 Condition: Unopened original packaging SRP: $149 BID:....... ******************************* 5. WebCommerce Basic http://www.g7ps.com/scripts/commerce1.asp Units: 2,500 Condition: Unopened original packaging SRP: $49 BID:....... ******************************* 6. VersaCheck 2001 Premium http://www.g7ps.com/scripts/premium.asp Units: 1,000 Condition: Unopened original packaging SRP: $59 BID:....... ******************************* 7. VersaCheck 2001 Professional http://www.g7ps.com/scripts/professional.asp Units: 1,500 Condition: Unopened original packaging SRP: $179 BID:....... ******************************* 8. VersaCheck 2001 Personal http://www.g7ps.com/scripts/personal.asp Units: 500 Condition: Unopened original packaging SRP: $19 BID:....... ******************************* 9. VersaCheck 2001 Home&Business http://www.g7ps.com/scripts/homebus2001.asp Units: 500 Condition: Unopened original packaging SRP: $39 BID:....... ********************************** Terms: F.O.B. G7 Warehouse San Diego Payment: Cash upon Pickup / Wire transfer ********************************* YOUR NAME: YOUR ADDRESS: CITY/STATE/ZIP: TEL: *********************************** About G7 Productivity Systems, Inc. The company specializes in publishing and distribution of its line of productivity software titles for home and business users. Main titles are: VersaCheck™ 2002 family – "Check Creation and Financial Manger", WebCommerce™ – "internet business builder," eTransForm™ – "Electronic form design and publishing on the Internet" and many more. COMPANY MAILING ADDRESS: G7 Productivity Systems, Inc. P.O. Box 27495 San Diego, CA 92198 Sarah Davis Marketing G7 Productivity Systems, Inc. sarah.davis@etransmail2.com 800-303-2620 From owner-linux-xfs@oss.sgi.com Fri May 10 00:29:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A7TewJ002873 for ; Fri, 10 May 2002 00:29:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A7TeJ5002872 for linux-xfs-outgoing; Fri, 10 May 2002 00:29:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A7TTwJ002846 for ; Fri, 10 May 2002 00:29:30 -0700 Received: (qmail 6065 invoked by uid 1000); 10 May 2002 07:30:32 -0000 To: linux-xfs@oss.sgi.com Subject: Oops in xfs_acl_iaccess From: Florian Weimer Date: Fri, 10 May 2002 09:30:32 +0200 Message-ID: <87k7qcbgtj.fsf@CERT.Uni-Stuttgart.DE> Lines: 74 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On our news server (running x86 Linux 2.4.18-xfs.1.1), we have encountered the following oops. Is this a known issue? invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010287 eax: 00000000 ebx: 00000008 ecx: f374af80 edx: f374af80 esi: 00000001 edi: 00000001 ebp: 00000002 esp: e30dbcd4 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 28488, stackpage=e30db000) Stack: f374af80 00000000 c0210c67 00000001 f374af80 efc336a0 f374af80 efc336a0 e30dbd14 00001000 f374af80 c0137914 00000001 00000001 e30dbd1c efc336a0 00000000 c0138712 f374af80 efc336a0 00000001 c032b000 d9cc0ab8 e30dbed4 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b b8 03 00 00 00 f0 0f ab 42 18 0f b7 42 0c 66 89 42 14 >>EIP; c0210ae7 <===== >>ecx; f374af80 >>edx; f374af80 >>esp; e30dbcd4 Trace; c0210c67 Trace; c0137914 Trace; c0138712 Trace; c018fe28 Trace; c018fe28 Trace; c018fe28 Trace; c0113c08 Trace; c0130042 <_alloc_pages+16/18> Trace; c018fe28 Trace; c0138adc <__refile_buffer+54/5c> Trace; c0138afb Trace; c0138a3e <__mark_buffer_dirty+26/2c> Trace; c01e6a9f Trace; c01e6da0 <__pb_block_commit_write_async+2c/4c> Trace; c01e5d70 Trace; c01e7476 Trace; c01e74a8 Trace; c01d81e6 Trace; c01c49e7 Trace; c01e12b4 Trace; c01ecfef Trace; c01e5dd3 Trace; c01e8d7b Trace; c01dd25e Trace; c01e877d Trace; c0137fc8 Trace; c0106e5b Code; c0210ae7 00000000 <_EIP>: Code; c0210ae7 <===== 0: 0f 0b ud2a <===== Code; c0210ae9 2: b8 03 00 00 00 mov $0x3,%eax Code; c0210aee 7: f0 0f ab 42 18 lock bts %eax,0x18(%edx) Code; c0210af3 c: 0f b7 42 0c movzwl 0xc(%edx),%eax Code; c0210af7 10: 66 89 42 14 mov %ax,0x14(%edx) -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Fri May 10 02:04:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A94ewJ004362 for ; Fri, 10 May 2002 02:04:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A94exo004361 for linux-xfs-outgoing; Fri, 10 May 2002 02:04:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from willow (mail@pD952C6E9.dip.t-dialin.net [217.82.198.233]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A94CwJ004312 for ; Fri, 10 May 2002 02:04:29 -0700 Received: from merlin by willow with local (Exim 3.35 #1 (Debian)) id 1766LD-0005wJ-00 for ; Fri, 10 May 2002 11:05:31 +0200 Subject: getfacl reports unknown error 524 on xfs partition From: Sebastian Bertho To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 10 May 2002 11:05:27 +0200 Message-Id: <1021021527.3941.19.camel@willow> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a reiserfs and a xfs partition with Debian/Woody Linux 2.4.18-xfs running. When I try to get or set the ACL of a file or directory on the xfs parition I get a error message "unknown error 524". On the reiserfs partition everything works fine (means: I can use getfacl without any errors). I tried acl-2.0.7 up to acl-2.0.11, with the latest other packages (dmapi, attr, xfsdump, xfsprogs) installed. Any ideas what this error means (and maybe how to fix it ;) )? Thanks a lot ;) cu Sebastian Bertho From owner-linux-xfs@oss.sgi.com Fri May 10 02:19:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A9JewJ004744 for ; Fri, 10 May 2002 02:19:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A9JeIP004743 for linux-xfs-outgoing; Fri, 10 May 2002 02:19:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A9JVwJ004714 for ; Fri, 10 May 2002 02:19:31 -0700 Received: from erbenson.alaska.net (129-pm11.nwc.alaska.net [209.112.140.129]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g4A9L4N94443 for ; Fri, 10 May 2002 01:21:04 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 76A1C3924 for ; Fri, 10 May 2002 01:21:03 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 295C21028C; Fri, 10 May 2002 01:21:03 -0800 (AKDT) Date: Fri, 10 May 2002 01:21:03 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: getfacl reports unknown error 524 on xfs partition Message-ID: <20020510012102.K11075@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1021021527.3941.19.camel@willow> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EdRE1UL8d3mMOE6m" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1021021527.3941.19.camel@willow>; from sebastian@bertho.de on Fri, May 10, 2002 at 11:05:27AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --EdRE1UL8d3mMOE6m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2002 at 11:05:27AM +0200, Sebastian Bertho wrote: > Hi, >=20 > I have a reiserfs and a xfs partition with Debian/Woody Linux 2.4.18-xfs > running. > When I try to get or set the ACL of a file or directory on the xfs > parition I get a error message "unknown error 524". On the reiserfs > partition everything works fine (means: I can use getfacl without any > errors). i didn't know reiserfs supported acls.. > I tried acl-2.0.7 up to acl-2.0.11, with the latest other packages > (dmapi, attr, xfsdump, xfsprogs) installed. >=20 > Any ideas what this error means (and maybe how to fix it ;) )? the problem is you compiled XFS without ACL support, in this case XFS returns the wrong errno so perror reports `Unknown error (524)' instead of Operation not supported.=20=20 glibc only knows about EOPNOTSUPP, ENOTSUP and ENOTSUPP are protected by __KERNEL__ so xfs needs to change its return values when it does not have ACL support. i sent details of this problem to Nathan several weeks ago but he never followed up. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --EdRE1UL8d3mMOE6m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzbkP4ACgkQJKx7GixEevxYLwCeOwUbgwUJu0vXLHuHBD95Oy8s MtYAn1SqvENBkb/adlsIqi2V5r0J0S4X =9xSp -----END PGP SIGNATURE----- --EdRE1UL8d3mMOE6m-- From owner-linux-xfs@oss.sgi.com Fri May 10 02:42:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A9gvwJ005121 for ; Fri, 10 May 2002 02:42:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A9gvQD005120 for linux-xfs-outgoing; Fri, 10 May 2002 02:42:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from 211.21.7.10 (IDENT:squid@dns.happyprint.com.tw [211.21.7.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A9glwJ005094 for ; Fri, 10 May 2002 02:42:51 -0700 Message-Id: <200205100942.g4A9glwJ005094@oss.sgi.com> From: Jeniffer To: Undisclosed.Recipients@oss.sgi.com Cc: Subject: Check This Out!! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 May 2002 05:44:23 -0400 X-Mailer: The Bat! (v1.52f) Business Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello ! My name is Jennifer, and my friends are Stephanie and Sara! We all three host intmate parties and have fun every night and day! We are always looking for new friends that like to party. We all have webcams and show off either individaully or, if the party is hot, we all get together and have FUN, if you know what i mean! This is something new and different, since we do this for fun and pure entertainment. Nobody will ask you for credit cards or crazy stuff like that, really! You have everything in your hands, and you can come see us anytime, fun is always there! Feel free to download the friendly-user software and you will see how easy it is to chat and watch us all the time! And that is FREE! http://liveshowz.by.ru Thank you! We send this email in order to meet new people. It is not SPAM and it has no commercial purpose whatsoever. We thank you for your understanding and we would be pleased if you would come say hi! If by any chance these types of emails bother you, we encourage that you unsubscribe from our list and you will never have to worry about it. plsremoveme@lycos.com From owner-linux-xfs@oss.sgi.com Fri May 10 04:30:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ABUvwJ006757 for ; Fri, 10 May 2002 04:30:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ABUvsh006756 for linux-xfs-outgoing; Fri, 10 May 2002 04:30:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ns1.a-net.ne.jp (ns1.a-net.ne.jp [202.224.241.98]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ABUqwJ006729 for ; Fri, 10 May 2002 04:30:53 -0700 Received: from mail.a-net.ne.jp (unverified [219.96.180.89]) by ns1.a-net.ne.jp (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 10 May 2002 20:28:56 +0900 Date: Fri, 10 May 2002 20:28:56 +0900 Message-ID: Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISpOeCROISElYSE8JWslXiUsJTgbKEI=?= =?ISO-2022-JP?B?GyRCJXMbKEI=?= From: milk@a-net.ne.jp To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: nMail Version 1.14 X-Antirelay: Good relay from milk from 219.96.180.89 PASS **** OK [10/May/2002:20:25:41] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk $B!*9-9p!*=P2q$$%5%$%H$N$40FFb(B $B?7$7$$Nx$G?4$N%j%U%l%C%7%e!*(B $B$-$C$H8+$D$+$k(B $B"-"-"-"-"-"-"-(B <<<$BEPO?L5NA(B>>> http://www.milkpot.net/index.shtml $B?7$?$J=P2q$$$N%+%?%A$+$J(B(^-^) $B"(F10l%"%I%l%9$X$N:FAw?.$O$7$J$$$h$&$K$7$F$*$j$^$9!#(B $BITMW$N>l9g$O(B info@milkpot.net $B$^$G!*(B From owner-linux-xfs@oss.sgi.com Fri May 10 06:16:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ADGiwJ008865 for ; Fri, 10 May 2002 06:16:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ADGiw4008864 for linux-xfs-outgoing; Fri, 10 May 2002 06:16:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ADGdwJ008822 for ; Fri, 10 May 2002 06:16:39 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA82946; Fri, 10 May 2002 08:18:08 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA67322; Fri, 10 May 2002 08:18:08 -0500 (CDT) Date: Fri, 10 May 2002 08:18:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Sebastian Bertho cc: linux-xfs@oss.sgi.com Subject: Re: getfacl reports unknown error 524 on xfs partition In-Reply-To: <1021021527.3941.19.camel@willow> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sebastian - If you're not running it already, could you try this with the 2.4.18 patch from the Release-1.1 directory on the xfs ftp site? Also, the output of "strace " on the failing command might be helpful. Thanks, -Eric On 10 May 2002, Sebastian Bertho wrote: > I have a reiserfs and a xfs partition with Debian/Woody Linux 2.4.18-xfs > running. > When I try to get or set the ACL of a file or directory on the xfs > parition I get a error message "unknown error 524". On the reiserfs > partition everything works fine (means: I can use getfacl without any > errors). -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri May 10 06:24:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ADOlwJ009727 for ; Fri, 10 May 2002 06:24:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ADOlce009726 for linux-xfs-outgoing; Fri, 10 May 2002 06:24:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ADOgwJ009700 for ; Fri, 10 May 2002 06:24:43 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA84412; Fri, 10 May 2002 08:26:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA81695; Fri, 10 May 2002 08:26:12 -0500 (CDT) Date: Fri, 10 May 2002 08:26:11 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: getfacl reports unknown error 524 on xfs partition In-Reply-To: <20020510012102.K11075@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah, thanks Ethan! Should have read your reply before I sent mine. :) Nathan made this change about 4 weeks ago to fs/xfs/linux/xfs_linux.h, I think it should address this problem? > ENOTSUP was defined to be ENOTSUPP. this is a problem because some glibc > versions and some architectures do not grok this code (errno.h in the kernel > only defines this within __KERNEL__). we now define it as EOPNOTSUPP which > will work everywhere and is the same thing we use for extended attributes > not available elsewhere in the kernel (ENOTSUP is the ACL not enabled code). Thanks, -Eric On Fri, 10 May 2002, Ethan Benson wrote: > the problem is you compiled XFS without ACL support, in this case XFS > returns the wrong errno so perror reports `Unknown error (524)' > instead of Operation not supported. > > glibc only knows about EOPNOTSUPP, ENOTSUP and ENOTSUPP are protected > by __KERNEL__ so xfs needs to change its return values when it does > not have ACL support. i sent details of this problem to Nathan > several weeks ago but he never followed up. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri May 10 06:42:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ADgCwJ010048 for ; Fri, 10 May 2002 06:42:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ADgCiP010047 for linux-xfs-outgoing; Fri, 10 May 2002 06:42:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ADg4wJ010019 for ; Fri, 10 May 2002 06:42:04 -0700 Received: from erbenson.alaska.net (129-pm11.nwc.alaska.net [209.112.140.129]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g4ADhcN48623 for ; Fri, 10 May 2002 05:43:38 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 5F95E3924 for ; Fri, 10 May 2002 05:43:37 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 871661028C; Fri, 10 May 2002 05:43:37 -0800 (AKDT) Date: Fri, 10 May 2002 05:43:37 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: getfacl reports unknown error 524 on xfs partition Message-ID: <20020510054337.L11075@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020510012102.K11075@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/0U0QBNx7JIUZLHm" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sandeen@sgi.com on Fri, May 10, 2002 at 08:26:11AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --/0U0QBNx7JIUZLHm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2002 at 08:26:11AM -0500, Eric Sandeen wrote: > Ah, thanks Ethan! Should have read your reply before I sent mine. :) >=20 > Nathan made this change about 4 weeks ago to fs/xfs/linux/xfs_linux.h, > I think it should address this problem? ah i must have missed it, i assume he changed it to return EOPNOTSUPP instead of ENOTSUP (like xattr.c does) ? if so that should do it. but im too lazy to compile a kernel without XFS acl support just to see ;-) > > ENOTSUP was defined to be ENOTSUPP. this is a problem because some gli= bc > > versions and some architectures do not grok this code (errno.h in the k= ernel > > only defines this within __KERNEL__). we now define it as EOPNOTSUPP w= hich > > will work everywhere and is the same thing we use for extended attribut= es > > not available elsewhere in the kernel (ENOTSUP is the ACL not enabled c= ode). yeah sounds about right. *NOTSUP* seems to be quite a inconsistent mess.. at least in linuxland.. > Thanks, no problem. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/0U0QBNx7JIUZLHm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzbzokACgkQJKx7GixEevygMQCff6lNy9/X+Wj3Vdyyb9hN4B04 6koAoJRjSuuNLo9rX2kys24n43cro2k5 =7WAn -----END PGP SIGNATURE----- --/0U0QBNx7JIUZLHm-- From owner-linux-xfs@oss.sgi.com Fri May 10 09:02:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AG24wJ011685 for ; Fri, 10 May 2002 09:02:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AG24e8011684 for linux-xfs-outgoing; Fri, 10 May 2002 09:02:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AG1twJ011658 for ; Fri, 10 May 2002 09:01:56 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g4AG3TM25906; Fri, 10 May 2002 18:03:29 +0200 Date: Fri, 10 May 2002 18:03:29 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Andre Canis cc: , Subject: Re: [Acl-Devel] Naming User Attributes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 10 May 2002, Andre Canis wrote: > Is there any standard or consensus on naming user attributer? The > attr(5) man page has "user.mime_type" as an example, and I guess > "user.charset" should be OK too, but has anyone thought about other > attributes? I think standardizing on attribute names is an attempt in vein. It may work out reasonably well to make existing names known, but I don't think a registry of user EA names or similar would make it. Should we try to build a list of existing names? > For example, NetPositive, a web browser for BeOS, remembers the source > of downloaded files in some attribute (I don't remember the name, I've > since uninstalled BeOS. I thought the filesystem was a great idea, but > sadly there were few programs using it.) > > Wouldn't it be great if browsers and download managers on Linux could do > the same? You could resume downloads without having to remember the > address. And mime type and charset could also be set while saving files. > > Another possible application of user attributes: MP3 (or Ogg etc...) > files. You could put artist, title etc. into attributes, maybe by > converting the tags from the file. Writing a script should be easy, but > I hesitate, because I keep looking for some naming standard to adhere to. I have a modified copy of wget which stores the URL of downloaded files in `user.url'. For a couple of MP3's I use user.album, user.artist, user.title, user.track, user.year, user.genre, analogous to ordinary MP3 tags. --Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Fri May 10 14:57:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ALvvwJ015781 for ; Fri, 10 May 2002 14:57:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ALvv1f015780 for linux-xfs-outgoing; Fri, 10 May 2002 14:57:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mathserv.math.ohio-state.edu (mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ALvrwJ015754 for ; Fri, 10 May 2002 14:57:53 -0700 Received: from math.ohio-state.edu (zaphod.math.ohio-state.edu [128.146.111.36]) by mathserv.math.ohio-state.edu (8.12.3/8.12.3) with ESMTP id g4ALxTaK008917 for ; Fri, 10 May 2002 17:59:29 -0400 Received: by math.ohio-state.edu (Postfix, from userid 500) id EE70F2D8422; Fri, 10 May 2002 17:59:28 -0400 (EDT) Date: Fri, 10 May 2002 17:59:28 -0400 From: Dave Alden To: linux-xfs@oss.sgi.com Subject: Help debugging a hang? Message-ID: <20020510175928.A13815@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I recently replaced an aging Solaris NFS server with a Linux NFS server (running XFS of course :-). After a couple of weeks without any problems the server decided to lockup. I was able to send a break (through a serial console), so I did a Sync followed by a reBoot. Now, in case this happens again, does anyone have any pointers on where to read up on how to figure out where it's locking up? ...thnx, ...dave From owner-linux-xfs@oss.sgi.com Fri May 10 15:08:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AM8ewJ016050 for ; Fri, 10 May 2002 15:08:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AM8egj016049 for linux-xfs-outgoing; Fri, 10 May 2002 15:08:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AM8YwJ016023 for ; Fri, 10 May 2002 15:08:35 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA82523; Fri, 10 May 2002 17:10:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA80436; Fri, 10 May 2002 17:10:06 -0500 (CDT) Subject: Re: Help debugging a hang? From: Eric Sandeen To: Dave Alden Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020510175928.A13815@math.ohio-state.edu> References: <20020510175928.A13815@math.ohio-state.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 10 May 2002 17:10:05 -0500 Message-Id: <1021068606.21745.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dave - If you have KDB enabled, there are a few things you can do to see what's going on. If the whole machine is locked up, just type "bt" to get a backtrace of the current hung process. If it's just one process that's locked up, type "ps" to get the pid of that process, then type "btp " to backtrace that process. After that, it depends on what has gone wrong, to know what to look at next. But those first couple steps can tell us quite a bit, in many cases. -Eric On Fri, 2002-05-10 at 16:59, Dave Alden wrote: > Hi, > I recently replaced an aging Solaris NFS server with a Linux NFS server > (running XFS of course :-). After a couple of weeks without any problems > the server decided to lockup. I was able to send a break (through a serial > console), so I did a Sync followed by a reBoot. Now, in case this happens > again, does anyone have any pointers on where to read up on how to figure > out where it's locking up? > ...thnx, > ...dave -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri May 10 15:54:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AMsRwJ016400 for ; Fri, 10 May 2002 15:54:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AMsRTg016399 for linux-xfs-outgoing; Fri, 10 May 2002 15:54:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AMsIwJ016373 for ; Fri, 10 May 2002 15:54:19 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id IAA15880; Sat, 11 May 2002 08:38:53 +0930 Message-ID: <3CDC53E9.BF7B3432@rebel.net.au> Date: Sat, 11 May 2002 08:42:41 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.18-XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric It says: Fatal error on root filesystem ide0(3,1) /lib/modules/2.4.18-SGI-XFS-1.1/kernel/drivers/modutils...radio cpio: mkdir (?) unknown error 998 /home itself gets butchered (i.e. lots of stuff gets shoved to lost+found) but md5sum still says the RPM checks out ok. DSL (?) I can't read my own writing... > So, /var is fine, until you run rpm, and then it goes south? > And you're xfs_repair-ing it after a clean unmount of the filesystem? > > Which directories does it complain about, things related to > the rpm db, or is it unrelated parts of /var? > > (I have a dead RPM db as well, but as far as I know the underlying > filesystem is fine...) > > -Eric > > On Wed, 8 May 2002, David Lloyd wrote: > > > I have a particularly broken system, a RedHat 7.1 system (default) but > > the RPM database is dead (1). Nonetheless, rpm -ivh kernel-2.4.18 (XFS) > > absolutely kills /var. Bugger knows why... > > > > Any ideas? > > > > (When I run xfs_repair over /dev/hda3 [aka /var] it picks up problems > > with directories and such] > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- 2337: Chastity means the successful integration of sexuality within the person and thus the inner unity of man in his bodily and spiritual being...[First sentence of item 2337 of the Catechism of the Catholic Church revised in accordance with the official Latin Text] From owner-linux-xfs@oss.sgi.com Fri May 10 18:52:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B1qewJ017775 for ; Fri, 10 May 2002 18:52:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B1qdEg017774 for linux-xfs-outgoing; Fri, 10 May 2002 18:52:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B1qIwJ017747 for ; Fri, 10 May 2002 18:52:19 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA70390; Fri, 10 May 2002 20:53:50 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA71593; Fri, 10 May 2002 20:53:49 -0500 (CDT) Date: Fri, 10 May 2002 20:53:49 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.18-XFS In-Reply-To: <3CDC53E9.BF7B3432@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, I'm a little confused... you said /var in your first message, but now you say /home is bad? So let's start over - can you verify that xfs_repair finds _no_ problems on any filesystem before the RPM install, and that one or more is damaged afterwards? You'll need to make sure you cleanly unmount any filesystem that you run xfs_repair on. Are there any messages in the system log? Also the full error message, without the (?) might be helpful. :) -Eric On Sat, 11 May 2002, David Lloyd wrote: > > Eric > > It says: > > Fatal error on root filesystem ide0(3,1) > /lib/modules/2.4.18-SGI-XFS-1.1/kernel/drivers/modutils...radio cpio: > mkdir (?) unknown error 998 > > /home itself gets butchered (i.e. lots of stuff gets shoved to -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat May 11 01:51:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B8p3wJ022019 for ; Sat, 11 May 2002 01:51:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B8p3Lr022018 for linux-xfs-outgoing; Sat, 11 May 2002 01:51:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pooh.lsc.hu (IDENT:postfix@pooh.lsc.hu [195.56.172.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B8okwJ021992 for ; Sat, 11 May 2002 01:50:47 -0700 Received: by pooh.lsc.hu (Postfix, from userid 547) id C8791E0210; Sat, 11 May 2002 10:42:39 +0200 (CEST) Date: Sat, 11 May 2002 10:42:39 +0200 From: GCS To: =?iso-8859-2?Q?Olaf_Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com Subject: Re: XFS + preemptible kernel + lock breaking? Message-ID: <20020511104239.A22109@lsc.hu> References: <20020506093127.GA4615@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020506093127.GA4615@venus.local.navi.pl>; from olaf@cbk.poznan.pl on Mon, May 06, 2002 at 11:31:27AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! On Mon, May 06, 2002 at 11:31:27AM +0200, Olaf Fr±czyk wrote: > Can somebody confirm it, or is it working now? (kernel 2.4.18). > And I would like to know if it is safe to add lock breaking patch. It does not work. I think the bug is not in XFS, nor lock break. It is in the way they play together. I mean if you use them separately, everything are ok. But as soon as you add either(!) XFS or JFS to lock break, you will have problems. I try to fix it with some kernel hackers including Robert M. Love, but until now the bug is still out there. For me it seems that with a journaling filesystem (XFS | JFS) a lock is acquired early in the boot process, and never released. Thus it causes dead lock when you write on a loop mounted filesystem (regardless of it's type). I have not posted the current state of bug hunting here, but do it now: fs/buffer.c in function wait_for_buffers(): if (conditional_schedule_needed() && nr_rescheds < 100) { nr_rescheds++; debug_lock_break(1); spin_unlock(&lru_list_lock); return -EAGAIN; } My test shows that if you write on a loop device then as soon as it would like to sync to the disk, conditional_schedule_needed() will be constant one, and nr_rescheds zero. Thus it will step into the if, and returns -EAGAIN. Thus it tries again, and again etc. Deadlock, but I still does not know why conditional_schedule_needed() is constant one in these cases. (Forgot that I get a line next from the Init version 2.84 loading, which shows that Sxxdevfs exited with preempt_count 1; and after this every process show this at termination.) If anyone has any idea, please share with me, GCS From owner-linux-xfs@oss.sgi.com Sat May 11 02:38:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B9cFwJ022554 for ; Sat, 11 May 2002 02:38:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B9cFHD022553 for linux-xfs-outgoing; Sat, 11 May 2002 02:38:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B9c8wJ022526 for ; Sat, 11 May 2002 02:38:09 -0700 Received: from xs3.xs4all.nl (xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.3/8.12.3) with ESMTP id g4B9dkdR095332; Sat, 11 May 2002 11:39:46 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id LAA25957; Sat, 11 May 2002 11:39:46 +0200 (CEST) Date: Sat, 11 May 2002 11:39:46 +0200 (CEST) From: Seth Mos To: David Lloyd cc: Eric Sandeen , Subject: Re: Kernel 2.4.18-XFS In-Reply-To: <3CDC53E9.BF7B3432@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 11 May 2002, David Lloyd wrote: > > Eric > > It says: > > Fatal error on root filesystem ide0(3,1) > /lib/modules/2.4.18-SGI-XFS-1.1/kernel/drivers/modutils...radio cpio: > mkdir (?) unknown error 998 This error might be related to 990 which is filesystem corruption. If that happens the fs can not be read or written from and appear empty. If you then reboot it should all be there but you will need to run xfs_repair _after_ a clean unmount and see if something is broken. If you repair first and not replay the logs you can lose a lot of data. > /home itself gets butchered (i.e. lots of stuff gets shoved to > lost+found) but md5sum still says the RPM checks out ok. After repair that is? Cheers Seth From owner-linux-xfs@oss.sgi.com Sat May 11 09:19:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4BGJZwJ026118 for ; Sat, 11 May 2002 09:19:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4BGJZY8026117 for linux-xfs-outgoing; Sat, 11 May 2002 09:19:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4BGJSwJ026091 for ; Sat, 11 May 2002 09:19:28 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 11 May 2002 09:21:03 -0700 Received: from qarce-lnx.afara.com ([10.2.4.98]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 11 May 2002 09:21:03 -0700 Subject: Are these errors bad? xfs_repair finding errors. From: Quentin Arce To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 May 2002 09:21:03 -0700 Message-Id: <1021134063.3827.978.camel@qarce-lnx> Mime-Version: 1.0 X-OriginalArrivalTime: 11 May 2002 16:21:03.0373 (UTC) FILETIME=[D865EBD0:01C1F907] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have been using XFS since if first came out... well a little before that :) Anyhow, I have just finished running xfs_repair on a x86 build system and found this error twice: LEAFN node level is 1 inode 104051713 bno = 8388608 Please if you know what this means please let me know... Seem it was not repaired on the first pass with xfs_repair. Also one other question regarding xfs_repair... This system as well as my laptop seem to always rebuild inode 128. Is their a reason why this is rebuilt on some systems but not others? Info: Build system. RH-7.2 base with XFS 1.02a installer Running XFS 2.4.9-21 kernel may be moving to 2.4.9-31 soon Errors on mirror partition Laptop RH-7.2 base with XFS 1.02a installer Running XFS 2.4.9-31 kernel Errors on root partition Both systems have all of the patches up to date from redhat as well as the new xfs tools. Thank you for everyone's help, Q From owner-linux-xfs@oss.sgi.com Sat May 11 14:02:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4BL2PwJ028759 for ; Sat, 11 May 2002 14:02:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4BL2P4S028758 for linux-xfs-outgoing; Sat, 11 May 2002 14:02:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4BL2IwJ028732 for ; Sat, 11 May 2002 14:02:18 -0700 Received: from wilma.widomaker.com (wilma.widomaker.com [204.17.220.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA00952 for ; Sat, 11 May 2002 14:03:50 -0700 (PDT) mail_from (shannon@escape.shannon.net) Received: from [209.96.185.47] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 176dti-000EyJ-00 for linux-xfs@oss.sgi.com; Sat, 11 May 2002 16:55:23 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4BKroN06837 for ; Sat, 11 May 2002 16:53:50 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4BKpQA04609 for linux-xfs@oss.sgi.com; Sat, 11 May 2002 16:51:26 -0400 Date: Sat, 11 May 2002 16:51:26 -0400 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: xfsrestore problems Message-ID: <20020511205125.GD4462@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a problem with xfsrestore, a couple actually. Number one is that it doesn't restore files, only directories. I partially fixed that by removing /var/xfsdump. After doing that, some of the files are restored, but a lot are missing. xfsrestore interactive shows ALL of the files are on the tape, but extract will not get all of them. I'm running XFS 1.1 on the 2.4.18 Linux kernel, and have been using XFS since last fall. My backups used to verify and restore fine, and now I don't know if any of them are good. Any ideas on why xfsrestore will not restore files? Why did removing /var/xfsdump allow some but not all files to restore? The second problem is that xfsrestore doesn't set the permissions on the restored files. Of course, this might be due to whatever causes the first problem. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Sun May 12 21:50:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4D4ocwJ015260 for ; Sun, 12 May 2002 21:50:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4D4ocDk015259 for linux-xfs-outgoing; Sun, 12 May 2002 21:50:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imsp210.netvigator.com (imsp210.netvigator.com [203.198.23.213]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4D4oWwJ015233 for ; Sun, 12 May 2002 21:50:33 -0700 Received: from simonchs (ipvpn100046.netvigator.com [203.198.209.46]) by imsp210.netvigator.com (8.11.6/8.11.6) with SMTP id g4D4ouv14979; Mon, 13 May 2002 12:50:56 +0800 (HKT) Message-ID: <000b01c1fa39$f4f2b070$2ed1c6cb@simonchs> From: "Simons" To: Subject: Invalid argument Date: Mon, 13 May 2002 12:50:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I had just installed the sgi xfs linux with the installer, and updated those rpms updates from redhat.com (except kernel rpms) When I try to enable root filesystem xfs quota support by "quotaon -v /", it said: [root@linux root]# quotaon -v / Enabling group quota on root filesystem (reboot to take effect) quotaon: quotactl on /dev/sda2: Invalid argument Enabling user quota on root filesystem (reboot to take effect) quotaon: quotactl on /dev/sda2: Invalid argument Would anyone help me to solve this issue? Thank you very much. rgds, Simons From owner-linux-xfs@oss.sgi.com Mon May 13 01:40:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4D8evwJ017093 for ; Mon, 13 May 2002 01:40:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4D8evMe017092 for linux-xfs-outgoing; Mon, 13 May 2002 01:40:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4D8eewJ017064 for ; Mon, 13 May 2002 01:40:40 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA04625 for ; Mon, 13 May 2002 01:42:17 -0700 (PDT) mail_from (wlang@slime.wu-wien.ac.at) Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g4D7qRH28006; Mon, 13 May 2002 09:52:27 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15583.28859.844623.488928@slime.wu-wien.ac.at> Date: Mon, 13 May 2002 09:52:27 +0200 To: linux-xfs@oss.sgi.com Cc: Stephen Lord Subject: wrong logstart value (was: xfs_repair trouble) X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: Willi.Langenberger@wu-wien.ac.at X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id BAA04625 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4D8eewJ017065 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Maybe i found the reason for my xfs_repair troubles... The log seems to overlap the root inode: # xfs_db -r /dev/sdb xfs_db: sb 0 xfs_db: p magicnum = 0x58465342 blocksize = 4096 dblocks = 2000000 rblocks = 0 rextents = 0 uuid = 2604c50c-3a11-4d67-a80c-156580239afb logstart = 4 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 1000 agcount = 2000 rbmblocks = 0 logblocks = 512 versionnum = 0x2084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 10 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 154432 ifree = 98649 fdblocks = 1513350 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 ==> logstart=4, logblocks=512, rootino=128 xfs_db: convert fsblock 4 daddr 0x20 (32) xfs_db: convert ino 128 daddr 0x40 (64) Thus: zeroing the log destroys the root inode. Later on, xfs_repair restores the root inode and corrupts the log... # cat /dev/zero | dd of=/dev/sdb bs=512 seek=32 count=1 (needed for xfs_repair to run -- otherwise it will hang in the loop in xlog_find_tail, as described before) # xfs_repair -L /dev/sdb (output of xfs_repair: http://slime.wu-wien.ac.at/xfs/repair.003.out) My questions: * any idea, how this can happen? * (more important) is there a chance that i can correct the log region? how can i find out where the log really should be? * or, can i change my fs to use an external log? that way it would not destroy data... For completeness, the mp structure: (gdb) p *mp $14 = {m_sb = {sb_magicnum = 1481003842, sb_blocksize = 4096, sb_dblocks = 2000000, sb_rblocks = 0, sb_rextents = 0, sb_uuid = "&\004Å\f:\021Mg¨\f\025e\200#\232û", sb_logstart = 4, sb_rootino = 128, sb_rbmino = 129, sb_rsumino = 130, sb_rextsize = 16, sb_agblocks = 1000, sb_agcount = 2000, sb_rbmblocks = 0, sb_logblocks = 512, sb_versionnum = 8324, sb_sectsize = 512, sb_inodesize = 256, sb_inopblock = 16, sb_fname = '\000' , sb_blocklog = 12 '\f', sb_sectlog = 9 '\t', sb_inodelog = 8 '\b', sb_inopblog = 4 '\004', sb_agblklog = 10 '\n', sb_rextslog = 0 '\000', sb_inprogress = 0 '\000', sb_imax_pct = 25 '\031', sb_icount = 154432, sb_ifree = 98649, sb_fdblocks = 1513350, sb_frextents = 0, sb_uquotino = 0, sb_gquotino = 0, sb_qflags = 0, sb_flags = 0 '\000', sb_shared_vn = 0 '\000', sb_inoalignmt = 2, sb_unit = 0, sb_width = 0, sb_dirblklog = 0 '\000', sb_dummy = "\000\000\000\000\000\000"}, m_bsize = 8, m_agfrotor = 0, m_agirotor = 0, m_maxagi = 2000, m_rsumlevels = 0, m_rsumsize = 0, m_rbmip = 0x0, m_rsumip = 0x0, m_rootip = 0x0, m_dev = 2064, m_logdev = 0, m_rtdev = 0, m_dircook_elog = 0 '\000', m_blkbit_log = 15 '\017', m_blkbb_log = 3 '\003', m_agno_log = 11 '\013', m_agino_log = 14 '\016', m_inode_cluster_size = 8192, m_blockmask = 4095, m_blockwsize = 1024, m_blockwmask = 1023, m_alloc_mxr = {510, 340}, m_alloc_mnr = {255, 170}, m_bmap_dmxr = {254, 254}, m_bmap_dmnr = {127, 127}, m_inobt_mxr = {255, 510}, m_inobt_mnr = {127, 255}, m_ag_maxlevels = 2, m_bm_maxlevels = {5, 3}, m_in_maxlevels = 2, m_perag = 0x80e7fc0, m_flags = 0, m_qflags = 0, m_attroffset = 120, m_da_node_ents = 510, m_ialloc_inos = 64, m_ialloc_blks = 4, m_litino = 156, m_inoalign_mask = 1, m_reservations = { tr_write = 74424, tr_itruncate = 107448, tr_rename = 305976, tr_link = 152832, tr_remove = 153144, tr_symlink = 158520, tr_create = 157880, tr_mkdir = 157880, tr_ifree = 14520, tr_ichange = 1592, tr_growdata = 27264, tr_swrite = 384, tr_addafork = 52664, tr_writeid = 384, tr_attrinval = 107136, tr_attrset = 22456, tr_attrrm = 54200, tr_clearagi = 640, tr_growrtalloc = 48128, tr_growrtzero = 4224, tr_growrtfree = 5760}, m_maxicount = 8000000, m_dalign = 0, m_swidth = 0, m_sinoalign = 0, m_dir_magicpct = 1515, m_dirversion = 2 '\002', m_dirblksize = 4096, m_dirblkfsbs = 1, m_dirdatablk = 0, m_dirleafblk = 8388608, m_dirfreeblk = 16777216} Thanks to all! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Mon May 13 03:53:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DArYwJ022435 for ; Mon, 13 May 2002 03:53:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DArY9Z022434 for linux-xfs-outgoing; Mon, 13 May 2002 03:53:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DArUwJ022402 for ; Mon, 13 May 2002 03:53:31 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id F417E4C30F4; Mon, 13 May 2002 06:55:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id EE189C0EE0B for ; Mon, 13 May 2002 06:55:19 -0400 (EDT) Date: Mon, 13 May 2002 06:55:19 -0400 (EDT) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: "badblocks" for XFS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I read on one of the redhat lists, this morning, about "badblocks" which acts as a low-level test utility for detecting physically bad blocks on your hard drive. However, the man page only seems to point to its use with ext2 (at least on my 7.1 system). So...is there a badblocks-type utility for XFS formatted systems? From owner-linux-xfs@oss.sgi.com Mon May 13 05:32:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DCW8wJ024318 for ; Mon, 13 May 2002 05:32:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DCW8Sj024317 for linux-xfs-outgoing; Mon, 13 May 2002 05:32:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from k-7.stesmi.com (IDENT:root@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DCW1wJ024291 for ; Mon, 13 May 2002 05:32:02 -0700 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by k-7.stesmi.com (8.11.2/8.8.7) with ESMTP id g4DCUBf21052; Mon, 13 May 2002 14:30:11 +0200 Message-ID: <3CDFB2A0.9020700@stesmi.com> Date: Mon, 13 May 2002 14:33:36 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Burger CC: linux-xfs@oss.sgi.com Subject: Re: "badblocks" for XFS? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > I read on one of the redhat lists, this morning, about "badblocks" which > acts as a low-level test utility for detecting physically bad blocks on > your hard drive. However, the man page only seems to point to its use > with ext2 (at least on my 7.1 system). > > So...is there a badblocks-type utility for XFS formatted systems? badblocks has no notion of the filesystem. In default mode it doesn't even write to the drive, it only reads it, you can force it to write patterns via the -w switch, and after writing it then reads it back to see if it gets the same data as was written. So, you're safe to use badblocks with any device, as long as you don't write anything to it. Yes, even mounted filesystems work, and why shouldn't they? As I said, as long asyou don't use -w, because if it's mounted you'll mes it up, if it's not mounted, you'll still mess it up :D // Stefan From owner-linux-xfs@oss.sgi.com Mon May 13 06:17:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DDHAwJ024781 for ; Mon, 13 May 2002 06:17:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DDHAtq024780 for linux-xfs-outgoing; Mon, 13 May 2002 06:17:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DDH2wJ024753 for ; Mon, 13 May 2002 06:17:03 -0700 Received: from mystery.carb.nist.gov ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GW1X0Z00.8M5; Mon, 13 May 2002 09:19:47 -0400 Subject: Re: "badblocks" for XFS? From: "Jonathan F. Dill" To: Stefan Smietanowski Cc: Mike Burger , Linux XFS Mailing List In-Reply-To: <3CDFB2A0.9020700@stesmi.com> References: <3CDFB2A0.9020700@stesmi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: UMBI CARB X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 13 May 2002 09:20:33 -0400 Message-Id: <1021296035.1577.9.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there any way to allocate/mark bad the badblocks with XFS so they won't be used by the filesystem? SCSI drives usually have their own way to do this internally in the defects list, but AFAIK EIDE drives do not. Historically, XFS grew up on SCSI drives with the IRIX "fx" utility to help add blocks to the drive's internal defect list, so I don't know if there is a really user-friendly, automated way to add bad blocks to an XFS filesystem on an EIDE drive. The only way I can see to do it is with xfs_db and xfs_bmap, although I'm not clear on the procedure. On Mon, 2002-05-13 at 08:33, Stefan Smietanowski wrote: > Mike Burger wrote: > > I read on one of the redhat lists, this morning, about "badblocks" which > > acts as a low-level test utility for detecting physically bad blocks on > > your hard drive. However, the man page only seems to point to its use > > with ext2 (at least on my 7.1 system). > > > > So...is there a badblocks-type utility for XFS formatted systems? > > > badblocks has no notion of the filesystem. > > In default mode it doesn't even write to the drive, it only reads it, > you can force it to write patterns via the -w switch, and after writing > it then reads it back to see if it gets the same data as was written. > > So, you're safe to use badblocks with any device, as long as you don't > write anything to it. > > Yes, even mounted filesystems work, and why shouldn't they? > > As I said, as long asyou don't use -w, because if it's mounted you'll > mes it up, if it's not mounted, you'll still mess it up :D > > // Stefan > -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon May 13 10:34:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DDXPwJ025143 for ; Mon, 13 May 2002 06:33:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DDXPTF025142 for linux-xfs-outgoing; Mon, 13 May 2002 06:33:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DDXLwJ025116 for ; Mon, 13 May 2002 06:33:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA29416; Mon, 13 May 2002 08:35:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA54948; Mon, 13 May 2002 08:35:02 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4DDW6u08639; Mon, 13 May 2002 08:32:06 -0500 Subject: Re: wrong logstart value (was: xfs_repair trouble) From: Steve Lord To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com In-Reply-To: <15583.28859.844623.488928@slime.wu-wien.ac.at> References: <15583.28859.844623.488928@slime.wu-wien.ac.at> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 May 2002 08:32:05 -0500 Message-Id: <1021296725.8614.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-13 at 02:52, Willi Langenberger wrote: > Hi! > > > Maybe i found the reason for my xfs_repair troubles... > > The log seems to overlap the root inode: Did you possibly make this filesystem with an external log device? If you did, repair needs to be told that too. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon May 13 10:43:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DHhRnC002197 for ; Mon, 13 May 2002 10:43:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DHhREj002196 for linux-xfs-outgoing; Mon, 13 May 2002 10:43:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DHhLnC001156 for ; Mon, 13 May 2002 10:43:22 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA30885; Mon, 13 May 2002 12:43:35 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA44708; Mon, 13 May 2002 12:43:34 -0500 (CDT) Subject: Re: "badblocks" for XFS? From: Eric Sandeen To: "Jonathan F. Dill" Cc: Stefan Smietanowski , Mike Burger , Linux XFS Mailing List In-Reply-To: <1021296035.1577.9.camel@localhost.localdomain> References: <3CDFB2A0.9020700@stesmi.com> <1021296035.1577.9.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 May 2002 12:43:34 -0500 Message-Id: <1021311815.3935.206.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-13 at 08:20, Jonathan F. Dill wrote: > Is there any way to allocate/mark bad the badblocks with XFS so they > won't be used by the filesystem? SCSI drives usually have their own way > to do this internally in the defects list, but AFAIK EIDE drives do not. As I understand it, all modern drives do defect management internally, remapping data blocks as they go bad. If you're actually seeing a bad block from the outside, that probably means that the drive has run out of blocks to remap to, and it's all downhill from there. At least, that's the reason I've always given for why filesystems shouldn't track bad blocks - that's the drive's job. If you want data integrity, and your drive is showing bad blocks, throw it away and get a new one. -Eric > Historically, XFS grew up on SCSI drives with the IRIX "fx" utility to > help add blocks to the drive's internal defect list, so I don't know if > there is a really user-friendly, automated way to add bad blocks to an > XFS filesystem on an EIDE drive. > > The only way I can see to do it is with xfs_db and xfs_bmap, although > I'm not clear on the procedure. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 13 10:57:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DHvrnC002532 for ; Mon, 13 May 2002 10:57:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DHvraZ002531 for linux-xfs-outgoing; Mon, 13 May 2002 10:57:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DHvmnC002505 for ; Mon, 13 May 2002 10:57:49 -0700 Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA01094 for ; Mon, 13 May 2002 09:53:37 -0700 (PDT) mail_from (wlang@slime.wu-wien.ac.at) Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g4DGmf902247; Mon, 13 May 2002 18:48:41 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15583.61033.352240.802191@slime.wu-wien.ac.at> Date: Mon, 13 May 2002 18:48:41 +0200 To: linux-xfs@oss.sgi.com Subject: Re: wrong logstart value (was: xfs_repair trouble) In-Reply-To: <1021296725.8614.0.camel@jen.americas.sgi.com> References: <15583.28859.844623.488928@slime.wu-wien.ac.at> <1021296725.8614.0.camel@jen.americas.sgi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk According to Steve Lord: > > Maybe i found the reason for my xfs_repair troubles... > > > > The log seems to overlap the root inode: > > > Did you possibly make this filesystem with an external log device? No, definitly not. We used the xfs-redhat iso images. I looked into the anaconda source: the option is "-l internal". The question is, can i now change from an internal log to an external log device? Maybe with xfs_db? \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Mon May 13 11:02:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DI2knC002794 for ; Mon, 13 May 2002 11:02:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DI2k92002793 for linux-xfs-outgoing; Mon, 13 May 2002 11:02:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DI2enC002764 for ; Mon, 13 May 2002 11:02:41 -0700 Received: from mystery.carb.nist.gov ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GW2A6K00.KQ6; Mon, 13 May 2002 14:03:56 -0400 Subject: Re: "badblocks" for XFS? From: "Jonathan F. Dill" To: Eric Sandeen Cc: Stefan Smietanowski , Mike Burger , Linux XFS Mailing List In-Reply-To: <1021311815.3935.206.camel@stout.americas.sgi.com> References: <3CDFB2A0.9020700@stesmi.com> <1021296035.1577.9.camel@localhost.localdomain> <1021311815.3935.206.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: UMBI CARB X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 13 May 2002 14:04:42 -0400 Message-Id: <1021313085.2555.95.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You've got a point there. When I start seeing bad blocks on the outside, usually it shows up that whole regions of the disk appear to be "bad" I think because the head is having trouble seeking to that region. The next thing that usually happens is that the drive head fails altogether. On Mon, 2002-05-13 at 13:43, Eric Sandeen wrote: > On Mon, 2002-05-13 at 08:20, Jonathan F. Dill wrote: > > Is there any way to allocate/mark bad the badblocks with XFS so they > > won't be used by the filesystem? SCSI drives usually have their own way > > to do this internally in the defects list, but AFAIK EIDE drives do not. > > As I understand it, all modern drives do defect management internally, > remapping data blocks as they go bad. If you're actually seeing a bad > block from the outside, that probably means that the drive has run out > of blocks to remap to, and it's all downhill from there. > > At least, that's the reason I've always given for why filesystems > shouldn't track bad blocks - that's the drive's job. If you want data > integrity, and your drive is showing bad blocks, throw it away and get a > new one. -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon May 13 11:16:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIG6nC003179 for ; Mon, 13 May 2002 11:16:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIG5Xe003178 for linux-xfs-outgoing; Mon, 13 May 2002 11:16:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DIFsnE003116 for ; Mon, 13 May 2002 11:16:00 -0700 Received: from PCS001C.pcs-telcom.com (masqrd.pcstelcom.com [208.201.11.51] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA05751 for ; Mon, 13 May 2002 07:28:03 -0700 (PDT) mail_from (ted.hazlewood@teampcs.com) Received: by pcs001c.pcs-telcom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 07:22:57 -0700 Message-ID: From: Ted Hazlewood To: "'linux-xfs@oss.sgi.com'" Subject: Changeing permissions and adding accounts to files from Winnt Date: Mon, 13 May 2002 07:22:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am just wondering if with the new version of xfs and the new version of samba. Does changing the permissions of files/directories and adding usernames to files/directories from a Winnt box work. If it does now work can anyone give me pointers and getting it to work. At this time the best I can do is change permissions on files of the primary user/group/everyone. But I can't add users nor do I see any additional users added from the linux side. I am unable to make changes to directories. This is an improvement from 1.02 and samba 2.2.3a. But I was hoping that since it is partially working that maybe I am just missing something. System Clean install of RedHat 7.2 using XFS 1.02 ISO's then upgraded to XFS 1.1 using XFS redhat 1.1 rpm's. Ted Hazlewood Senior Systems Administrator Public Communications Services (310) 954-3024 Phone (310) 954-2139 Fax ted.hazlewood@teampcs.com From owner-linux-xfs@oss.sgi.com Mon May 13 11:16:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIG4nC003170 for ; Mon, 13 May 2002 11:16:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIG463003169 for linux-xfs-outgoing; Mon, 13 May 2002 11:16:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DIFsnC003116 for ; Mon, 13 May 2002 11:15:54 -0700 Received: from creon.profinet.sk (creon.profinet.sk [195.46.64.12]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07931 for ; Mon, 13 May 2002 07:45:47 -0700 (PDT) mail_from (erkac@host.sk) Received: by creon.profinet.sk (Postfix, from userid 201) id 3C42921F097; Mon, 13 May 2002 15:57:59 +0200 (CEST) Date: Mon, 13 May 2002 15:57:59 +0200 From: lubos klokner To: linux-xfs@oss.sgi.com Subject: new mirror in Slovakia Message-ID: <20020513135759.GC12014@creon.profinet.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, i made complete mirror of xfs in Slovakia. it is accessible by ftp at ftp://spirit.profinet.sk/mirrors/xfs or by http at http://spirit.profinet.sk/xfs mirror is updated every hour. bye -- lubos klokner From owner-linux-xfs@oss.sgi.com Mon May 13 11:18:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIIvnC006372 for ; Mon, 13 May 2002 11:18:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIIvQA006371 for linux-xfs-outgoing; Mon, 13 May 2002 11:18:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DIIrnC006339 for ; Mon, 13 May 2002 11:18:53 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA80136; Mon, 13 May 2002 13:19:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA18352; Mon, 13 May 2002 13:19:06 -0500 (CDT) Subject: Re: new mirror in Slovakia From: Eric Sandeen To: lubos klokner Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020513135759.GC12014@creon.profinet.sk> References: <20020513135759.GC12014@creon.profinet.sk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 May 2002 13:19:06 -0500 Message-Id: <1021313946.3744.208.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thank you, I'll add it! -Eric On Mon, 2002-05-13 at 08:57, lubos klokner wrote: > hello, > > i made complete mirror of xfs in Slovakia. > > it is accessible by ftp at ftp://spirit.profinet.sk/mirrors/xfs > or by http at http://spirit.profinet.sk/xfs > > mirror is updated every hour. > > bye > -- > lubos klokner -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 13 12:25:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DJPPnC010187 for ; Mon, 13 May 2002 12:25:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DJPP67010186 for linux-xfs-outgoing; Mon, 13 May 2002 12:25:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf17bis.bellsouth.net (mail217.mail.bellsouth.net [205.152.58.157]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DJPGnC010160 for ; Mon, 13 May 2002 12:25:16 -0700 Received: from taz ([66.156.2.161]) by imf17bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020513192656.NGND7584.imf17bis.bellsouth.net@taz>; Mon, 13 May 2002 15:26:56 -0400 Date: Mon, 13 May 2002 15:21:08 -0400 From: Greg Freemyer Subject: re: Changeing permissions and adding accounts to files from Winnt To: Ted Hazlewood cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020513192656.NGND7584.imf17bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4DJPHnC010161 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ted, I'm in the middle of trying to get this to all work in my lab. I'm using Suse 8.0 but the basic process should be the same. (SuSE 8.0 include XFS support out of the box, so I have it a little easier than you.) Everything is supposed to work now, but there are few things you still have to do. (I understand that the latest Mandrake ships with everything already configured correctly.) 1) Make sure you have a implementation of XFS that supports ACLs. (ACLs are the users and permissions you are taking about.) Note: You can use getfacl and setfacl from the command line to verify the above is working, if you aren't sure. 2) Make sure you have libattr and libacl installed on your server. (You can get them from the XFS site, but they are now being developed at http://acl.bestbits.at/ and are shared by the xfs and bestbits projects) 3) Compile Samba from source with the --with-acl-support argument passed into ./configure. Unfortunately, Samba normally has a bunch of arguments passed into ./configure, so if you want it to compile more or less like Redhat did, then you need to get the spec file out of their SRPM. The easiest may be to just add --with-acl-support to the spec file, then use "rpm -bi samba.spec" to compile and install it. HTH Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> I am just wondering if with the new version of xfs and the new version of >> samba. >> Does changing the permissions of files/directories and adding usernames to >> files/directories from a Winnt box work. >> If it does now work can anyone give me pointers and getting it to work. >> At this time the best I can do is change permissions on files of the >> primary >> user/group/everyone. But I can't add users nor do I see any additional >> users added from the linux side. >> I am unable to make changes to directories. >> This is an improvement from 1.02 and samba 2.2.3a. But I was hoping that >> since it is partially working that maybe I am just missing something. >> System >> Clean install of RedHat 7.2 using XFS 1.02 ISO's then upgraded to XFS 1.1 >> using XFS redhat 1.1 rpm's. >> Ted Hazlewood >> Senior Systems Administrator >> Public Communications Services >> (310) 954-3024 Phone >> (310) 954-2139 Fax >> ted.hazlewood@teampcs.com >> From owner-linux-xfs@oss.sgi.com Mon May 13 15:56:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DMuvnC001381 for ; Mon, 13 May 2002 15:56:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DMuvPh001380 for linux-xfs-outgoing; Mon, 13 May 2002 15:56:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DMuhnC001354 for ; Mon, 13 May 2002 15:56:44 -0700 Received: from taz ([66.156.2.161]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020513225824.OQUK28927.imf03bis.bellsouth.net@taz> for ; Mon, 13 May 2002 18:58:24 -0400 Date: Mon, 13 May 2002 18:52:34 -0400 From: Greg Freemyer Subject: xfsdump/restore confusion about ACLs To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020513225824.OQUK28927.imf03bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4DMuinC001355 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm trying to verify that xfsdump/xfsrestore handle ACLs. When I do: su # ie. set effective ID to root. getfacl gaf/samba/Junk/Test1.txt xfsdump -J -s gaf -L dummy-label -f /tmp/xfs.out /home xfsrestore -J -f /tmp/xfs.out restore_temp getfacl restore_temp/gaf/samba/Junk/Test1.txt I loose the test acl I put on the test file. (Output below my signature) Am I missing an argument, or is something wrong. I did RTM, but I must have missed something. xfsdump and xfsrestore claim to be version 3, so I don't know what version they really are. I'm using a pure SuSE 8.0 release of XFS and the utilities. Also, in my experiments, I had several occasions where I had an interrupted restore I wanted to delete. I just deleted /var/lib/xfsdump/inventory/*. Is there a better way to resolve this complaint. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com # getfacl gaf/samba/Junk/Test1.txt # file: gaf/samba/Junk/Test1.txt # owner: gaf # group: users user::rwx user:rlw:rwx group::r-- mask::rwx other::--- # xfsdump -J -s gaf -L dummy-label -f /tmp/xfs.out /home xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.0 - Running single-threaded xfsdump: level 0 dump of david:/home xfsdump: dump date: Mon May 13 18:40:05 2002 xfsdump: session id: 1b64663c-0158-4844-9f38-e2e1018b6f59 xfsdump: session label: "dummy-session" xfsdump: ino map phase 1: parsing subtree selections xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: pruning unneeded subtrees xfsdump: ino map phase 4: estimating dump size xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 26176 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files xfsdump: ending media file xfsdump: media file size 23080 bytes xfsdump: dump size (non-dir files) : 0 bytes xfsdump: dump complete: 1 seconds elapsed xfsdump: Dump Status: SUCCESS # xfsrestore -J -f /tmp/xfs.out restore_temp xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: david xfsrestore: mount point: /home xfsrestore: volume: /dev/hda2 xfsrestore: session time: Mon May 13 18:40:05 2002 xfsrestore: level: 0 xfsrestore: session label: "dummy-session" xfsrestore: media label: "dummy-label" xfsrestore: file system id: fa0ef892-94c9-4643-beb3-c5b62d07aca9 xfsrestore: session id: 1b64663c-0158-4844-9f38-e2e1018b6f59 xfsrestore: media id: 0026a6c2-1a8d-4ed9-a3e6-16235f5b09fe xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 4 directories and 24 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: restore complete: 0 seconds elapsed xfsrestore: Restore Status: SUCCESS # getfacl restore_temp/gaf/samba/Junk/Test1.txt # file: restore_temp/gaf/samba/Junk/Test1.txt # owner: gaf # group: users user::rwx group::rwx other::--- From owner-linux-xfs@oss.sgi.com Mon May 13 16:53:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DNrunC002169 for ; Mon, 13 May 2002 16:53:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DNruIk002168 for linux-xfs-outgoing; Mon, 13 May 2002 16:53:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DNrnnC002140 for ; Mon, 13 May 2002 16:53:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA37774; Mon, 13 May 2002 18:54:03 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA90500; Mon, 13 May 2002 18:54:02 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id SAA16129; Mon, 13 May 2002 18:54:02 -0500 (CDT) Message-ID: <3CE05219.1DF5A2C3@sgi.com> Date: Mon, 13 May 2002 18:54:01 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles, We are investigating this issue and we will get back to you soon. Kihonge JN Charles Shannon Hendrix wrote: > I have a problem with xfsrestore, a couple actually. Number one is > that it doesn't restore files, only directories. > > I partially fixed that by removing /var/xfsdump. After doing that, > some of the files are restored, but a lot are missing. > > xfsrestore interactive shows ALL of the files are on the tape, but > extract will not get all of them. > > I'm running XFS 1.1 on the 2.4.18 Linux kernel, and have been using > XFS since last fall. > > My backups used to verify and restore fine, and now I don't know if any > of them are good. > > Any ideas on why xfsrestore will not restore files? > > Why did removing /var/xfsdump allow some but not all files to restore? > > The second problem is that xfsrestore doesn't set the permissions on > the restored files. Of course, this might be due to whatever causes the > first problem. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Mon May 13 18:32:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E1WEnC004063 for ; Mon, 13 May 2002 18:32:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E1WENS004062 for linux-xfs-outgoing; Mon, 13 May 2002 18:32:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E1W9nC004035 for ; Mon, 13 May 2002 18:32:09 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA11928; Mon, 13 May 2002 20:32:24 -0500 (CDT) Received: from [192.168.1.101] (mtv-vpn-sw-corp-0-34.corp.sgi.com [134.15.0.34]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA65201; Mon, 13 May 2002 20:32:23 -0500 (CDT) Subject: Re: xfsdump/restore confusion about ACLs From: Stephen Lord To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020513225824.OQUK28927.imf03bis.bellsouth.net@taz> References: <20020513225824.OQUK28927.imf03bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 May 2002 20:31:13 -0500 Message-Id: <1021339874.1169.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-13 at 17:52, Greg Freemyer wrote: > > I'm trying to verify that xfsdump/xfsrestore handle ACLs. > > When I do: > > su # ie. set effective ID to root. > > getfacl gaf/samba/Junk/Test1.txt > xfsdump -J -s gaf -L dummy-label -f /tmp/xfs.out /home > xfsrestore -J -f /tmp/xfs.out restore_temp > getfacl restore_temp/gaf/samba/Junk/Test1.txt I think you need later xfsdump and restore images, up until recently they were not restoring acls. There are current images on oss.sgi.com. Steve From owner-linux-xfs@oss.sgi.com Mon May 13 18:48:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E1mCnC004458 for ; Mon, 13 May 2002 18:48:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E1mBfj004457 for linux-xfs-outgoing; Mon, 13 May 2002 18:48:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E1m0nC004425 for ; Mon, 13 May 2002 18:48:00 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA05550; Mon, 13 May 2002 20:48:15 -0500 (CDT) Received: from [192.168.1.101] (mtv-vpn-sw-corp-0-34.corp.sgi.com [134.15.0.34]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA72565; Mon, 13 May 2002 20:48:13 -0500 (CDT) Subject: [Fwd: Re: xfsdump/restore confusion about ACLs] From: Stephen Lord To: linux-xfs@oss.sgi.com Cc: freemyer@norcrossgroup.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 May 2002 20:46:58 -0500 Message-Id: <1021340820.1169.4.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looks like we are having some internal email difficulties, here is another explanation for xfsrestore losing acls. Steve -----Forwarded Message----- From: Tim Shimmin To: mkulima@sgi.com Cc: slinx-xfs@cthulhu.engr.sgi.com Subject: Re: xfsdump/restore confusion about ACLs Date: 14 May 2002 11:43:45 +1000 Hi, Nathan has responded to the dump/acl question to Greg and the linux-xfs list but our emails to oss.sgi.com are currently bouncing (Arghhh). John, perhaps you (or someone else) can send the info on to the linux-xfs list. Thanks, Tim. On Mon, May 13, 2002 at 06:52:34PM -0400, Greg Freemyer wrote: > > I'm trying to verify that xfsdump/xfsrestore handle ACLs. > > When I do: > > su # ie. set effective ID to root. > > getfacl gaf/samba/Junk/Test1.txt > xfsdump -J -s gaf -L dummy-label -f /tmp/xfs.out /home > xfsrestore -J -f /tmp/xfs.out restore_temp > getfacl restore_temp/gaf/samba/Junk/Test1.txt > > I loose the test acl I put on the test file. (Output below my signature) > > Am I missing an argument, or is something wrong. > I did RTM, but I must have missed something. > > xfsdump and xfsrestore claim to be version 3, > so I don't know what version they really are. This should really be fixed, so that the VERSION info is output by xfsdump and xfsrestore. Will be on the todo list. > > I'm using a pure SuSE 8.0 release of XFS and the utilities. > The problem reported above is likely to be a bug in the xfs-kernel that was fixed around 16/April: http://marc.theaimsgroup.com/?l=linux-xfs&m=101893920409629&w=2 Nathan replied thus: Date: Tue, 14 May 2002 09:37:09 +1000 To: Greg Freemyer Cc: linux-xfs@oss.sgi.com User-Agent: Mutt/1.2.5i From: Nathan Scott Subject: Re: xfsdump/restore confusion about ACLs Try a CVS kernel, there has been fixes in this area since the code the Suse folks had at the time they released 8.0. Not sure what the answer to the second question is, there must surely be a cleaner solution though. ;) cheers. > > Also, in my experiments, I had several occasions where I had an > interrupted restore I wanted to delete. > > I just deleted /var/lib/xfsdump/inventory/*. > Is there a better way to resolve this complaint. For an interrupted restore and cumulative restore, state about the restore session is stored within the xfsrestorehousekeepingdir within the destination directory. So I'd normally rm the destdir/xfsrestorehousekeepingdir if one wanted to cleanup the interrupted state. --Tim From owner-linux-xfs@oss.sgi.com Mon May 13 23:09:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E69BnC008684 for ; Mon, 13 May 2002 23:09:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E69BQU008683 for linux-xfs-outgoing; Mon, 13 May 2002 23:09:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E699nC008656 for ; Mon, 13 May 2002 23:09:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id BAA40393 for ; Tue, 14 May 2002 01:09:25 -0500 (CDT) Received: (from andrewd@localhost) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) id BAA89561 for linux-xfs@oss.sgi.com; Tue, 14 May 2002 01:09:25 -0500 (CDT) Date: Tue, 14 May 2002 01:09:25 -0500 (CDT) From: Andrew Danne Message-Id: <200205140609.BAA89561@daisy-e185.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Please ignore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From owner-linux-xfs@oss.sgi.com Mon May 13 23:08:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E68KnC008639 for ; Mon, 13 May 2002 23:08:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E68KDb008637 for linux-xfs-outgoing; Mon, 13 May 2002 23:08:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E68FnC008604 for ; Mon, 13 May 2002 23:08:15 -0700 Received: from nodin.corp.sgi.com ([198.29.75.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA06787 for ; Mon, 13 May 2002 23:08:30 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E65ZPF6066598 for ; Mon, 13 May 2002 23:05:36 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA5498546 for ; Mon, 13 May 2002 23:05:33 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E64WPF6080620 for ; Mon, 13 May 2002 23:04:32 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA4790309 for ; Mon, 13 May 2002 23:04:31 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E63UPF6091540 for ; Mon, 13 May 2002 23:03:30 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA5228325 for ; Mon, 13 May 2002 23:03:29 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E62SPF4659703 for ; Mon, 13 May 2002 23:02:28 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA4996692 for ; Mon, 13 May 2002 23:02:26 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E61PPF6077413 for ; Mon, 13 May 2002 23:01:25 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA5158320 for ; Mon, 13 May 2002 23:01:24 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4E60MPF6097813 for ; Mon, 13 May 2002 23:00:23 -0700 (PDT) Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA4194776 for ; Mon, 13 May 2002 23:00:20 -0700 (PDT) mail_from (guest@boing.melbourne.sgi.com) Received: (from guest@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA34728 for linux-xfs@oss.sgi.com; Tue, 14 May 2002 15:59:02 +1000 (AEST) Date: Tue, 14 May 2002 15:59:02 +1000 (AEST) From: Guest Account Message-Id: <200205140559.PAA34728@boing.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: Please ignore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From owner-linux-xfs@oss.sgi.com Tue May 14 02:59:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E9xsnC016835 for ; Tue, 14 May 2002 02:59:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E9xspU016834 for linux-xfs-outgoing; Tue, 14 May 2002 02:59:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imspcml001.netvigator.com (imspcml001.netvigator.com [203.198.23.215]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E9xlnC016805 for ; Tue, 14 May 2002 02:59:48 -0700 Received: from simonchs (ipvpn100046.netvigator.com [203.198.209.46]) by imspcml001.netvigator.com (8.11.6/8.11.6) with SMTP id g4EA02119463; Tue, 14 May 2002 18:00:02 +0800 (HKT) Message-ID: <000b01c1fb2e$1d8d2020$2ed1c6cb@simonchs> From: "Simons" To: "Nathan Scott" Cc: References: <000b01c1fa39$f4f2b070$2ed1c6cb@simonchs> <20020513181503.I120284@wobbly.melbourne.sgi.com> Subject: Re: Invalid argument Date: Tue, 14 May 2002 18:00:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I just tried this and don't seem to be able to reproduce the > problem - it works as advertised for me. Are you able to build > your own kernel? If so, I'd suggest putting some printk's into > xfs_qm_syscalls.c::xfs_qm_scall_quotaon(); esp. where EINVAL is > returned and we will get a better picture of where this is going > wrong. > > I'll try it out on a few more machines tomorrow and see if I can > uncover the problem. It smells like an uninitialised or perhaps > only partially inited flags variable, or something like that -- > nothing leaps out at me after reading through the code though. > seems i have just found out the reason, the problem only occured on the machine with scsi hdd. i have setup 3 scsi machines: machine A - adaptec 29160, ibm 18g scsi machine B - adaptec 29160, seagate 9g scsi machine C - adaptec 2940UW, seagate 9g scsi both machines got the "Invalid argument" problem, but i have setup 2 ide hdd machines last night, and don't have such problem. > Also, what does "repquota -vug /" on your machine now say? [root@xfs root]# repquota -vug / repquota: Not all specified mountpoints are using quota. rgds, Simons From owner-linux-xfs@oss.sgi.com Tue May 14 03:24:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EAOXnC017384 for ; Tue, 14 May 2002 03:24:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EAOXUv017383 for linux-xfs-outgoing; Tue, 14 May 2002 03:24:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EAOHnC017356 for ; Tue, 14 May 2002 03:24:18 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 651F3C230; Tue, 14 May 2002 11:57:33 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA22729; Tue, 14 May 2002 11:57:32 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id EB16157306; Tue, 14 May 2002 08:01:11 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2AED925835; Tue, 14 May 2002 07:52:56 +0200 (CEST) Message-ID: <3CE0A638.E5AD1D67@ch.sauter-bc.com> Date: Tue, 14 May 2002 07:52:56 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: wrong logstart value (was: xfs_repair trouble) References: <15583.28859.844623.488928@slime.wu-wien.ac.at> <1021296725.8614.0.camel@jen.americas.sgi.com> <15583.61033.352240.802191@slime.wu-wien.ac.at> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Willi Langenberger schrieb: > > According to Steve Lord: > > > Maybe i found the reason for my xfs_repair troubles... > > > > > > The log seems to overlap the root inode: > > > > > > Did you possibly make this filesystem with an external log device? > > No, definitly not. We used the xfs-redhat iso images. I looked into > the anaconda source: the option is "-l internal". > > The question is, can i now change from an internal log to an external > log device? Maybe with xfs_db? Search the list archives and you'll find some info about how to export an internal log. IIRC it's possible but not very easy. Simon > > \wlang{} > > -- > Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 > Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue May 14 06:03:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ED3nnC022452 for ; Tue, 14 May 2002 06:03:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ED3naq022451 for linux-xfs-outgoing; Tue, 14 May 2002 06:03:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ED3inC022418 for ; Tue, 14 May 2002 06:03:45 -0700 Received: from 21cn.com([10.2.2.4]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm43ce14880; Tue, 14 May 2002 21:03:26 +0800 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-AIMailer: AIMC 2.9.5.1 2001.05.18 X-AIMime: MIME/SMIME Lib 2.9 2.9 2001.05.18 Date: Tue, 14 May 2002 20:58:09 +0800 (CST) From: "hhh" To: linux-xfs@oss.sgi.com Cc: Subject: about xfs :P X-Priority: 3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The cd that I pass you to provide installs the redhat7.3, when the gearing end. Can't manufacture to start the floppy disk, please tell me to how create. :) ---------------------------------------------- ǧ½ðÄÑÂòÐÄÍ·ºÃ ÌØÊâÓÊÏäÓû§Ãû¿ìÇÀ¹º http://mail.21cn.com/business.html ÊÕ·ÑÓÊÏäÖÜÄêÇì ,ÈýÖØ´óÓÅ»Ý,ÀñÆ·Äò»Í£ http://mail.21cn.com/oneyear ¶©ÖÆЦ»°¶ÌÐÅ ÔùËÍ21CNÊÕ·ÑÓÊÏä http://mail.21cn.com/jf/mobile.htm ÓÃÓÊÏ俨£¬Ö§¸¶ÓÊÏ䣬ºñÀñÅÉËÍ http://mail.21cn.com/oneyear/4.html ÍøÂçÓ²ÅÌ È«Ð¿ª·Å Ãâ·ÑÊÔÓà http://mail.21cn.com/21drive.html From owner-linux-xfs@oss.sgi.com Tue May 14 08:35:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EFZfnC002988 for ; Tue, 14 May 2002 08:35:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EFZfvS002987 for linux-xfs-outgoing; Tue, 14 May 2002 08:35:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EFZWnC002960 for ; Tue, 14 May 2002 08:35:32 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA26346 for ; Tue, 14 May 2002 10:35:49 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA43846 for ; Tue, 14 May 2002 10:35:49 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g4EFZna22423; Tue, 14 May 2002 10:35:49 -0500 Message-Id: <200205141535.g4EFZna22423@stout.americas.sgi.com> Date: Tue, 14 May 2002 10:35:49 -0500 Subject: TAKE - xfs userspace build changes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This change is really for an internal project, but it may be helpful in general. It allows the xfs userspace commands to be built from within the source tree, so that dependencies do not have to be installed along the way; i.e. it looks within the source tree for libs and header files (it will also look for installed libs and headers, and use those, if found.) There is a new Makefile in the cmds/ dir with a "cmds" target that builds RPMs and moves them to an RPMS/$ARCH directory, and moves source RPMS to an SRPMS dir. This could easily be extended to do source installs (rather than RPM installs) as well, for now that's left as an exercise for the reader... :) Date: Tue May 14 08:31:38 PDT 2002 Workarea: stout.americas.sgi.com:/home/poppy20/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:119075a Makefile - 1.1 - New Makefile for cmds subdir; really only builds RPMs for now acl/configure.in - 1.16 - Look for libs within source tree first (will use system libs if found) xfsprogs/include/Makefile - 1.8 - Make xfs symlink in include/ dir so we can find xfs/foo.h xfsdump/configure.in - 1.18 - Don't overwrite existing CPPFLAGS Look for libs within source tree first (will use system libs if found) xfsdump/include/builddefs.in - 1.15 - Don't overwrite existing CPPFLAGS dmapi/include/Makefile - 1.3 - Make xfs symlink in include/ dir so we can find xfs/dmapi.h dmapi/include/buildmacros - 1.3 xfsprogs/include/buildmacros - 1.3 acl/include/buildmacros - 1.3 attr/include/buildmacros - 1.3 xfsdump/include/buildmacros - 1.3 - Add CPPFLAGS to compiler flags From owner-linux-xfs@oss.sgi.com Tue May 14 13:10:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EKAlnC010834 for ; Tue, 14 May 2002 13:10:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EKAl9G010833 for linux-xfs-outgoing; Tue, 14 May 2002 13:10:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from net.bluemoon.net (root@net.bluemoon.net [63.237.147.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EKAgnC010800 for ; Tue, 14 May 2002 13:10:43 -0700 Received: from localhost (fantom@localhost) by net.bluemoon.net (8.11.6/8.11.1) with SMTP id g4EKB5B43284 for ; Tue, 14 May 2002 16:11:05 -0400 (EDT) (mail-from fant@pobox.com) X-Authentication-Warning: net.bluemoon.net: fantom owned process doing -bs Date: Tue, 14 May 2002 16:11:05 -0400 (EDT) From: Andrew Fant X-Sender: fantom@net.bluemoon.net To: linux-xfs@oss.sgi.com Subject: XFS and Crusoe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone successfully compiled an XFS-aware kernel on a Transmeta Crusoe chip? I am seriously considering a notebook based on one for my new traveling desktop, and I would like to be sure that I will be able run XFS on it under linux. Thanks, Andy Andrew Fant | This | "If I could walk THAT way... Molecular Geek | Space | I wouldn't need the talcum powder!" fant@pobox.com | For | G. Marx (apropos of Aerosmith) Boston, MA USA | Hire | http://www.pharmawulf.com From owner-linux-xfs@oss.sgi.com Tue May 14 13:20:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EKKVnC011116 for ; Tue, 14 May 2002 13:20:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EKKV5a011115 for linux-xfs-outgoing; Tue, 14 May 2002 13:20:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EKKQnC011088 for ; Tue, 14 May 2002 13:20:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA13912; Tue, 14 May 2002 15:20:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA88914; Tue, 14 May 2002 15:20:44 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4EKKX101789; Tue, 14 May 2002 15:20:33 -0500 Subject: Re: XFS and Crusoe From: Steve Lord To: Andrew Fant Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 May 2002 15:20:33 -0500 Message-Id: <1021407633.19994.338.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-14 at 15:11, Andrew Fant wrote: > Has anyone successfully compiled an XFS-aware kernel on a Transmeta Crusoe > chip? I am seriously considering a notebook based on one for my new > traveling desktop, and I would like to be sure that I will be able run XFS > on it under linux. If you could get Linus to try it ....... ;-) The only issue I can think of is that xfs is pretty heavy on the 64 bit math, it might test the emulation in directions it has not been tested before. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue May 14 14:10:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELASnC026194 for ; Tue, 14 May 2002 14:10:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELASfR026192 for linux-xfs-outgoing; Tue, 14 May 2002 14:10:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELAKnC026156 for ; Tue, 14 May 2002 14:10:20 -0700 Received: (qmail 28470 invoked by uid 500); 14 May 2002 21:10:09 -0000 Subject: what happens if your mountpoint looks like this?: From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YIQ0zKwrmJGnBm2daciY" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 14 May 2002 16:10:09 -0500 Message-Id: <1021410609.27758.7.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-YIQ0zKwrmJGnBm2daciY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I hear *noatime* is good for performance, but what about the double logbufs? Will that screw things up, or *help* performance as well?(potentially?) /dev/sda5 on / type xfs (rw,noatime,logbufs=3D8,logbufs=3D8) --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-YIQ0zKwrmJGnBm2daciY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA84X0x94g6ZVmFMoIRAp0ZAJ4iJ1NgRcAboO05A3NPmKkRJcYOWwCeN2VY +HDOoIzBxkfLvxahAw089pM= =kpEA -----END PGP SIGNATURE----- --=-YIQ0zKwrmJGnBm2daciY-- From owner-linux-xfs@oss.sgi.com Tue May 14 14:15:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELFAnC026399 for ; Tue, 14 May 2002 14:15:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELFAgU026398 for linux-xfs-outgoing; Tue, 14 May 2002 14:15:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELF6nC026372 for ; Tue, 14 May 2002 14:15:06 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA53416; Tue, 14 May 2002 16:15:24 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA30747; Tue, 14 May 2002 16:15:24 -0500 (CDT) Subject: Re: what happens if your mountpoint looks like this?: From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1021410609.27758.7.camel@UberGeek> References: <1021410609.27758.7.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 May 2002 16:15:24 -0500 Message-Id: <1021410924.23888.87.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-14 at 16:10, Austin Gonyou wrote: > I hear *noatime* is good for performance, but what about the double > logbufs? Will that screw things up, or *help* performance as > well?(potentially?) > > > > /dev/sda5 on / type xfs (rw,noatime,logbufs=8,logbufs=8) hi Austin - I think that specifying logbufs=8 twice will simply set that variable to "8" two times during mount... which will infinitesimally slow down your mount performance, and leave subsequent performance unchanged. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 14 14:19:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELJZnC026605 for ; Tue, 14 May 2002 14:19:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELJZ7F026604 for linux-xfs-outgoing; Tue, 14 May 2002 14:19:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELJQnC026564 for ; Tue, 14 May 2002 14:19:26 -0700 Received: (qmail 28628 invoked by uid 500); 14 May 2002 21:19:16 -0000 Subject: Re: what happens if your mountpoint looks like this?: From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1021410924.23888.87.camel@stout.americas.sgi.com> References: <1021410924.23888.87.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bn2Luab+Fo+s1YBuLKEu" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 14 May 2002 16:19:16 -0500 Message-Id: <1021411156.27758.15.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-bn2Luab+Fo+s1YBuLKEu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Without rebooting, is there a way to change that? I did a remount, with the all the options, and the only one duplicated, was logbufs. (so rw and noatime were not). Doing the mount again though, does not append another logbufs, so it continues to look like the below, even when remounting again. TIA. On Tue, 2002-05-14 at 16:15, Eric Sandeen wrote: > On Tue, 2002-05-14 at 16:10, Austin Gonyou wrote: > > I hear *noatime* is good for performance, but what about the > double > > logbufs? Will that screw things up, or *help* performance as > > well?(potentially?) > >=20 > >=20 > >=20 > > /dev/sda5 on / type xfs (rw,noatime,logbufs=3D8,logbufs=3D8) >=20 > hi Austin - I think that specifying logbufs=3D8 twice will simply set > that > variable to "8" two times during mount... which will infinitesimally > slow down your mount performance, and leave subsequent performance > unchanged. :) >=20 > -Eric >=20 > --=20 > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-bn2Luab+Fo+s1YBuLKEu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA84X9U94g6ZVmFMoIRAjnbAKDWPen/4BcBhqMW6j854dZeAJYwtwCglpP7 L1BzwAVJwoqhaxFFHydEVF4= =LHB0 -----END PGP SIGNATURE----- --=-bn2Luab+Fo+s1YBuLKEu-- From owner-linux-xfs@oss.sgi.com Tue May 14 14:22:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELMunC026804 for ; Tue, 14 May 2002 14:22:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELMun0026803 for linux-xfs-outgoing; Tue, 14 May 2002 14:22:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELMmnC026773 for ; Tue, 14 May 2002 14:22:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA49656; Tue, 14 May 2002 16:23:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA61664; Tue, 14 May 2002 16:23:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4ELMtd02455; Tue, 14 May 2002 16:22:55 -0500 Subject: Re: what happens if your mountpoint looks like this?: From: Steve Lord To: Austin Gonyou Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1021411156.27758.15.camel@UberGeek> References: <1021410924.23888.87.camel@stout.americas.sgi.com> <1021411156.27758.15.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 May 2002 16:22:55 -0500 Message-Id: <1021411375.28640.347.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-14 at 16:19, Austin Gonyou wrote: > Without rebooting, is there a way to change that? I did a remount, with > the all the options, and the only one duplicated, was logbufs. (so rw > and noatime were not). Doing the mount again though, does not append > another logbufs, so it continues to look like the below, even when > remounting again. I do not think noatime will have any affect on the filesystem unless you get it in there on the initial mount - difficult on the root I know. As for the logbufs thing, the string of what is in the mount options reported by the kernel has nothing to do with xfs itself, it is all done with smoke and mirrors in the vfs layer. Steve > > TIA. > > On Tue, 2002-05-14 at 16:15, Eric Sandeen wrote: > > On Tue, 2002-05-14 at 16:10, Austin Gonyou wrote: > > > I hear *noatime* is good for performance, but what about the > > double > > > logbufs? Will that screw things up, or *help* performance as > > > well?(potentially?) > > > > > > > > > > > > /dev/sda5 on / type xfs (rw,noatime,logbufs=8,logbufs=8) > > > > hi Austin - I think that specifying logbufs=8 twice will simply set > > that > > variable to "8" two times during mount... which will infinitesimally > > slow down your mount performance, and leave subsequent performance > > unchanged. :) > > > > -Eric > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "One ought never to turn one's back on a threatened danger and > try to run away from it. If you do that, you will double the danger. > But if you meet it promptly and without flinching, you will > reduce the danger by half." > Sir Winston Churchill -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue May 14 14:29:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELT8nC027034 for ; Tue, 14 May 2002 14:29:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELT8Nq027033 for linux-xfs-outgoing; Tue, 14 May 2002 14:29:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELT3nC027004 for ; Tue, 14 May 2002 14:29:04 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA52115; Tue, 14 May 2002 16:29:22 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA50891; Tue, 14 May 2002 16:29:22 -0500 (CDT) Subject: Re: what happens if your mountpoint looks like this?: From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1021411156.27758.15.camel@UberGeek> References: <1021410924.23888.87.camel@stout.americas.sgi.com> <1021411156.27758.15.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 May 2002 16:29:21 -0500 Message-Id: <1021411762.23888.89.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-14 at 16:19, Austin Gonyou wrote: > Without rebooting, is there a way to change that? I did a remount, with > the all the options, and the only one duplicated, was logbufs. (so rw > and noatime were not). Doing the mount again though, does not append > another logbufs, so it continues to look like the below, even when > remounting again. if you have logbufs=8 in your fstab and you specified it on your mount command line, it shows up twice. Dunno why, ext2 does the same thing for the resuid=X option, for example. It's not hurting anything, in any case. -eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 14 14:30:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELUCnC027150 for ; Tue, 14 May 2002 14:30:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELUCbR027149 for linux-xfs-outgoing; Tue, 14 May 2002 14:30:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dumbo.zwecker.de (root@a088227.adsl.hansenet.de [213.191.88.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELU7nC027122 for ; Tue, 14 May 2002 14:30:08 -0700 Received: from localhost.localdomain (doc@localhost.localdomain [127.0.0.1]) by dumbo.zwecker.de (8.11.6/8.11.0) with ESMTP id g4ELULu02167 for ; Tue, 14 May 2002 23:30:22 +0200 Subject: Status on RH7.3 installer ? From: Christophe Zwecker To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 May 2002 23:30:21 +0200 Message-Id: <1021411822.19054.6.camel@dumbo.zwecker.de> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, gotto reinstall a machine, kinda waiting for the XFS installer for RH7.3 to come out. Any ETA ? :-) If you guys tweak it you might wanna make it a lvm aware installer, that can handle upgrades on lvm partitions :-) Not trying to be greedy. thx alot for xfs , keep up the great work! Christophe -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Tue May 14 14:35:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELZ3nC027441 for ; Tue, 14 May 2002 14:35:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELZ3mW027440 for linux-xfs-outgoing; Tue, 14 May 2002 14:35:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELYvnC027410 for ; Tue, 14 May 2002 14:34:57 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA34427; Tue, 14 May 2002 16:35:15 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA36802; Tue, 14 May 2002 16:35:15 -0500 (CDT) Subject: Re: Status on RH7.3 installer ? From: Eric Sandeen To: Christophe Zwecker Cc: linux-xfs@oss.sgi.com In-Reply-To: <1021411822.19054.6.camel@dumbo.zwecker.de> References: <1021411822.19054.6.camel@dumbo.zwecker.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 May 2002 16:35:15 -0500 Message-Id: <1021412115.28834.93.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Christophe - Nobody at SGI has touched it yet... A couple people outside have looked at it, I'm evaluating a contributed 2.4.18-4 kernel patch against the 7.3 RH kernel, and someone else was looking into actually doing an installer... I don't suppose you'd be interested in Debian, Slackware, SuSE, Mandrake, or Gentoo, in the meantime? ;-) -Eric On Tue, 2002-05-14 at 16:30, Christophe Zwecker wrote: > Hi, > > gotto reinstall a machine, kinda waiting for the XFS installer for RH7.3 > to come out. Any ETA ? :-) > If you guys tweak it you might wanna make it a lvm aware installer, that > can handle upgrades on lvm partitions :-) > Not trying to be greedy. > > thx alot for xfs , keep up the great work! > > Christophe > -- > Christophe Zwecker mail: doc@zwecker.de > Hamburg, Germany fon: +49 179 3994867 > http://www.zwecker.de > > "Who is General Failure ? And why is he reading my disk ??" -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 14 14:36:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELaHnC027550 for ; Tue, 14 May 2002 14:36:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELaHNd027549 for linux-xfs-outgoing; Tue, 14 May 2002 14:36:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELa9nC027460 for ; Tue, 14 May 2002 14:36:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA54628; Tue, 14 May 2002 16:36:27 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA61885; Tue, 14 May 2002 16:36:27 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id QAA17616; Tue, 14 May 2002 16:36:26 -0500 (CDT) Message-ID: <3CE1835A.89040F77@sgi.com> Date: Tue, 14 May 2002 16:36:26 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles, It is difficult at the moment to determine why xfsrestore is not working properly without getting more details from you. Here are afew quesions; What is the xfsretore command line that you are using? What version of glibc are you using? Are there changes you have made to the kernel or libraries between the time the xfsrestore was working properly and the time you realized it wasnt? Are there any changes between the time you backed the files and now? What Linux are you running - SuSe, Red Hat, other? Thanks, Kihonge JN Charles Shannon Hendrix wrote: > I have a problem with xfsrestore, a couple actually. Number one is > that it doesn't restore files, only directories. > > I partially fixed that by removing /var/xfsdump. After doing that, > some of the files are restored, but a lot are missing. > > xfsrestore interactive shows ALL of the files are on the tape, but > extract will not get all of them. > > I'm running XFS 1.1 on the 2.4.18 Linux kernel, and have been using > XFS since last fall. > > My backups used to verify and restore fine, and now I don't know if any > of them are good. > > Any ideas on why xfsrestore will not restore files? > > Why did removing /var/xfsdump allow some but not all files to restore? > > The second problem is that xfsrestore doesn't set the permissions on > the restored files. Of course, this might be due to whatever causes the > first problem. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Tue May 14 14:43:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELhGnC027844 for ; Tue, 14 May 2002 14:43:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELhGU5027843 for linux-xfs-outgoing; Tue, 14 May 2002 14:43:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dumbo.zwecker.de (root@a088227.adsl.hansenet.de [213.191.88.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELh9nC027816 for ; Tue, 14 May 2002 14:43:10 -0700 Received: from localhost.localdomain (doc@localhost.localdomain [127.0.0.1]) by dumbo.zwecker.de (8.11.6/8.11.0) with ESMTP id g4ELhCu02386; Tue, 14 May 2002 23:43:12 +0200 Subject: Re: Status on RH7.3 installer ? From: Christophe Zwecker To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1021412115.28834.93.camel@stout.americas.sgi.com> References: <1021411822.19054.6.camel@dumbo.zwecker.de> <1021412115.28834.93.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 May 2002 23:43:11 +0200 Message-Id: <1021412592.19056.11.camel@dumbo.zwecker.de> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-05-14 at 23:35, Eric Sandeen wrote: > I don't suppose you'd be interested in Debian, Slackware, SuSE, > Mandrake, or Gentoo, in the meantime? ;-) well basically I not proud to say no. See all my machines and machines I build for customers are RH. so thats like 30 or so. I constantly have to evaluate new stuff (how do I replace exchange servers with linux, HA stuff, blablabla). What im trying to say is: Id love to another distro, but im afraid it'll cost me too much time to learn howto tweak it :-) Guess Mandrake would come closest, I prolly should look into that. Well ok, so it probably wont be available in the next few weeks, I cant wait so long, so im gonna have to upgrade the machines while running, not booting from a CD. Thx for the amating fast reply ! cheers Christophe -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Tue May 14 14:54:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ELstnC028243 for ; Tue, 14 May 2002 14:54:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ELst0K028242 for linux-xfs-outgoing; Tue, 14 May 2002 14:54:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e159.dsl.mediaWays.net [213.20.225.89]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ELsonC028215 for ; Tue, 14 May 2002 14:54:51 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 177kGD-0005fy-00 for linux-xfs@oss.sgi.com; Tue, 14 May 2002 23:55:09 +0200 Message-ID: <3CE187BD.E41333DC@berdmann.de> Date: Tue, 14 May 2002 23:55:09 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: bought a SGI Workstation Indigo2 for fun Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi SGI developers, just wanted to let you know to have bought a six year old Indigo2 XZ (R4400, 250 MHz, 128 MB, G3-Elan) to see the filesystem XFS on IRIX in its natural environment. This machine is very impressive! The case is purple (indigo?) colored like being displayed by the second URL: http://www.obsolyte.com/sgi_indigo2/ http://www.obsolyte.com/sgi_indigo2/purple.jpg From owner-linux-xfs@oss.sgi.com Tue May 14 15:04:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EM4pnC028580 for ; Tue, 14 May 2002 15:04:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EM4pmR028579 for linux-xfs-outgoing; Tue, 14 May 2002 15:04:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e159.dsl.mediaWays.net [213.20.225.89]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EM4lnC028553 for ; Tue, 14 May 2002 15:04:48 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 177kPq-0005ko-00 for linux-xfs@oss.sgi.com; Wed, 15 May 2002 00:05:06 +0200 Message-ID: <3CE18A12.7D1118F4@berdmann.de> Date: Wed, 15 May 2002 00:05:06 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > If you guys tweak it you might wanna make it a lvm aware installer, that > can handle upgrades on lvm partitions :-) oh yes, please - I have a lot of LVM machines (for production and fun) and I would donate some time to test beta versions of the 7.3 installer From owner-linux-xfs@oss.sgi.com Tue May 14 15:09:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EM9tnC028849 for ; Tue, 14 May 2002 15:09:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EM9tLu028848 for linux-xfs-outgoing; Tue, 14 May 2002 15:09:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EM9nnC028820 for ; Tue, 14 May 2002 15:09:49 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 177kSk-0006da-00; Tue, 14 May 2002 16:08:06 -0600 Message-ID: <3CE18B3F.1060605@emergence.com> Date: Tue, 14 May 2002 16:10:07 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Christophe Zwecker Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Perhaps someone knows how to do the step that I stopped on, which was to generate a disk/disc image for booting from the cdrom. The default Redhat installer uses a 2.8M installer image in the dosutils/autoboot directory of the cd: 2.8M cdboot.img 1.9M initrd.img Which appears to be a 2.8M boot image which contains: 784k of vmlinuz (kernel) and 1.9M of initrd.img plus various bootup files. I need to make one of these and then I can probably make a cd that boots with a different kernel. By simply using mkinitrd it makes a minimalist initrd image. I already did these other steps too: *) Added the xfs utilities to RedHat/base/stage2.img *) Added the xfs utility rpms to Redhat/RPMS on disc1 and disc2 *) modified RedHat/base/comps to include xfs util rpms *) updated hdlist/hdlist2 in Redhat/base/ using genhdlist from the anaconda 7.3 source *) learned about embedding the MD5 into the implantisomd5 and checkisomd5 from the anaconda 7.3 source *) examined the anaconda source code for claimed xfs support (it appears to append XFS to the list of available filesystems if that filesystem choice is available, more work here is needed) -Mike From owner-linux-xfs@oss.sgi.com Tue May 14 15:24:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EMOsnC029286 for ; Tue, 14 May 2002 15:24:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EMOrvW029285 for linux-xfs-outgoing; Tue, 14 May 2002 15:24:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EMOlnC029256 for ; Tue, 14 May 2002 15:24:47 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA53415; Tue, 14 May 2002 17:25:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA30600; Tue, 14 May 2002 17:25:05 -0500 (CDT) Subject: Re: Status on RH7.3 installer ? From: Eric Sandeen To: Michael Best Cc: linux-xfs@oss.sgi.com, Christophe Zwecker In-Reply-To: <3CE18B3F.1060605@emergence.com> References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 May 2002 17:25:05 -0500 Message-Id: <1021415105.23820.104.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Mike - On Tue, 2002-05-14 at 17:10, Michael Best wrote: > Perhaps someone knows how to do the step that I stopped on, which was to > generate a disk/disc image for booting from the cdrom. The default > Redhat installer uses a 2.8M installer image in the dosutils/autoboot > directory of the cd: There are scripts in anaconda, scripts/buildinstall to be exact, that do what you want, I think. You need to have the tree set up correctly, but eventually you get the boot image & a tree to burn to an ISO. There are some configs in there that tell it what should go in stage1, stage2 etc. I think if you look at the anaconda SRPM from the 1.0.2 installer, the patch in the SRPM will show you what we did. > I already did these other steps too: > *) Added the xfs utility rpms to Redhat/RPMS on disc1 and disc2 Oh, do they actually fit? > *) examined the anaconda source code for claimed xfs support > (it appears to append XFS to the list of available filesystems > if that filesystem choice is available, more work here is needed) At a minimum, you'd need to change "self.supported = 0" to "1" in class xfsFileSystem in the fsset.py file... You're going about it a different way, I think, more directly modifying the RH ISOs with a binary diff; we made a stand-alone ISO, so we had to let Anaconda know about a 3rd CD (now would be 4th) to get kernels & utilities for XFS. There may be other things, but that's a start. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 14 15:36:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EMaUnC029629 for ; Tue, 14 May 2002 15:36:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EMaUrq029628 for linux-xfs-outgoing; Tue, 14 May 2002 15:36:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cdc.net (cdc3.cdc.net [207.244.0.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EMaPnC029600 for ; Tue, 14 May 2002 15:36:25 -0700 Received: (qmail 17285 invoked from network); 14 May 2002 22:31:06 -0000 Received: from unknown (HELO cdc.net) (207.244.0.13) by cdc3.cdc.net with SMTP; 14 May 2002 22:31:06 -0000 Received: (qmail 25701 invoked by uid 138); 14 May 2002 22:31:38 -0000 Delivered-To: gharper@cdc.net Received: (qmail 21015 invoked from network); 16 Apr 2002 23:50:49 -0000 Received: from unknown (HELO mx.cdc.net) (207.244.0.30) by server1.cdc.net with SMTP; 16 Apr 2002 23:50:49 -0000 Received: from outgoing.securityfocus.com (unverified [66.38.151.27]) by mx.cdc.net (Vircom SMTPRS 1.2.222) with ESMTP id for ; Tue, 16 Apr 2002 19:49:48 -0700 Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id B4ADCA33C9; Tue, 16 Apr 2002 15:44:14 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 11500 invoked from network); 16 Apr 2002 21:37:35 -0000 Subject: Re: IRIX XFS filesystem denial of service attack From: Eric Sandeen To: H D Moore Cc: agent99@sgi.com, linux-xfs@oss.sgi.com, bugtraq@securityfocus.com In-Reply-To: <200204151832.38497.sflist@digitaloffense.net> References: <10204151449.ZM268355@einstein.csd.sgi.com> <200204151832.38497.sflist@digitaloffense.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Apr 2002 16:40:00 -0500 Message-Id: <1018993200.8789.377.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi HD - I don't believe that Linux is affected. I've been told that the Linux I/O path was written specifically to avoid this problem, and I have run some test cases from our original bug report, and did not see the described behavior. I'll look a bit more and reply when I know for sure. -Eric On Mon, 2002-04-15 at 18:32, H D Moore wrote: > Does this vulnerability affect the Linux XFS port? The XFS page has no > information about this or whether there is a fix available: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue May 14 15:38:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EMc8nC029766 for ; Tue, 14 May 2002 15:38:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EMc8UD029765 for linux-xfs-outgoing; Tue, 14 May 2002 15:38:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cdc.net (cdc3.cdc.net [207.244.0.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EMc3nC029737 for ; Tue, 14 May 2002 15:38:04 -0700 Received: (qmail 17044 invoked from network); 14 May 2002 22:30:56 -0000 Received: from unknown (HELO cdc.net) (207.244.0.13) by cdc3.cdc.net with SMTP; 14 May 2002 22:30:56 -0000 Received: (qmail 25573 invoked by uid 138); 14 May 2002 22:31:27 -0000 Delivered-To: gharper@cdc.net Received: (qmail 28995 invoked from network); 16 Apr 2002 22:18:20 -0000 Received: from unknown (HELO outgoing.securityfocus.com) (66.38.151.27) by server1.cdc.net with SMTP; 16 Apr 2002 22:18:20 -0000 Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id 176EAA3199; Tue, 16 Apr 2002 10:52:43 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 8733 invoked from network); 15 Apr 2002 23:30:13 -0000 Content-Type: text/plain; charset="iso-8859-1" From: H D Moore To: agent99@sgi.com, linux-xfs@oss.sgi.com, bugtraq@securityfocus.com Subject: Re: IRIX XFS filesystem denial of service attack Date: Mon, 15 Apr 2002 18:32:38 -0500 X-Mailer: KMail [version 1.4] References: <10204151449.ZM268355@einstein.csd.sgi.com> In-Reply-To: <10204151449.ZM268355@einstein.csd.sgi.com> X-DigitalOffense: TRUE MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204151832.38497.sflist@digitaloffense.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does this vulnerability affect the Linux XFS port? The XFS page has no information about this or whether there is a fix available: http://oss.sgi.com/projects/xfs/ -HD On Monday 15 April 2002 04:49 pm, SGI Security Coordinator wrote: > > SGI Security Advisory > > Title: IRIX XFS filesystem denial of service attack > Number: 20020402-01-P > Date: April 15, 2002 > Reference: CAN-2002-0042 > ----------------------- > --- Issue Specifics --- > ----------------------- > > It has been reported that there is a vulnerability in IRIX's XFS > filesystem. Under some circumstances, a user can create a file that would > hang any application that would try to access it. This has the potential > to be used to create a Denial of Service attack. From owner-linux-xfs@oss.sgi.com Tue May 14 15:57:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EMv2nC030219 for ; Tue, 14 May 2002 15:57:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EMv2eR030218 for linux-xfs-outgoing; Tue, 14 May 2002 15:57:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EMuwnC030190 for ; Tue, 14 May 2002 15:56:58 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 177lCO-0006fK-00 for linux-xfs@oss.sgi.com; Tue, 14 May 2002 16:55:16 -0600 Message-ID: <3CE1964D.3000605@emergence.com> Date: Tue, 14 May 2002 16:57:17 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> <1021415105.23820.104.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: >>*) Added the xfs utility rpms to Redhat/RPMS on disc1 and disc2 > > Oh, do they actually fit? Addendum: *) Add the 2.4.18 XFS kernel RPMS as well (rpms with Redhat specific patches or even the -aa kernel would be an interesting/useful addition) The sizes of the ISO images were about the same, give or take a megabyte. This is without doing the boot image part of the process yet. 638M May 14 16:52 valhalla-xfs-i386-disc1.iso 637M May 6 21:24 valhalla-i386-disc1.iso -Mike From owner-linux-xfs@oss.sgi.com Tue May 14 17:04:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4F04BnC032392 for ; Tue, 14 May 2002 17:04:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4F04BoY032391 for linux-xfs-outgoing; Tue, 14 May 2002 17:04:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4F041nC032358 for ; Tue, 14 May 2002 17:04:01 -0700 Received: (qmail 1989 invoked by uid 500); 15 May 2002 00:03:57 -0000 Subject: Re: what happens if your mountpoint looks like this?: From: Austin Gonyou To: Steve Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1021411375.28640.347.camel@jen.americas.sgi.com> References: <1021411375.28640.347.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5krV7cin3ADQT5+/jw5U" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 14 May 2002 19:03:57 -0500 Message-Id: <1021421037.29493.45.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-5krV7cin3ADQT5+/jw5U Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks much Steve.=20 On Tue, 2002-05-14 at 16:22, Steve Lord wrote: > On Tue, 2002-05-14 at 16:19, Austin Gonyou wrote: > > Without rebooting, is there a way to change that? I did a remount, > with > > the all the options, and the only one duplicated, was logbufs. (so > rw > > and noatime were not). Doing the mount again though, does not > append > > another logbufs, so it continues to look like the below, even when > > remounting again. >=20 > I do not think noatime will have any affect on the filesystem unless > you get it in there on the initial mount - difficult on the root I > know. > As for the logbufs thing, the string of what is in the mount options > reported by the kernel has nothing to do with xfs itself, it is all > done with smoke and mirrors in the vfs layer. >=20 > Steve >=20 > >=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-5krV7cin3ADQT5+/jw5U Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA84aXt94g6ZVmFMoIRAqA9AJ9OnlY+je9lNRe6If7hEqWJnVVK4QCfccLu /9d+qCVfAAysVYBpUgzj11o= =25tT -----END PGP SIGNATURE----- --=-5krV7cin3ADQT5+/jw5U-- From owner-linux-xfs@oss.sgi.com Tue May 14 20:50:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4F3oDnC003147 for ; Tue, 14 May 2002 20:50:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4F3oCrW003146 for linux-xfs-outgoing; Tue, 14 May 2002 20:50:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4F3o3nC003119 for ; Tue, 14 May 2002 20:50:03 -0700 Received: from [206.246.249.41] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 177po2-0006AF-00; Tue, 14 May 2002 23:50:26 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4F3mAN19317; Tue, 14 May 2002 23:48:10 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4F3m9f00428; Tue, 14 May 2002 23:48:09 -0400 Date: Tue, 14 May 2002 23:48:09 -0400 From: Charles Shannon Hendrix To: John Kihonge Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems Message-ID: <20020515034808.GA349@widomaker.com> References: <20020511205125.GD4462@widomaker.com> <3CE1835A.89040F77@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE1835A.89040F77@sgi.com> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 14, 2002 at 04:36:26PM -0500, John Kihonge wrote: > > Charles, > > It is difficult at the moment to determine why xfsrestore is not working > properly without getting more details from you. Here are afew quesions; > > What is the xfsretore command line that you are using? All of them... :) Seriously, no combination of xfsrestore commands is special with regard to restoring or not restoring files. I have tried incremental, sub-path specification, and full restores. Incremental shows files but won't restore them. xfsrestore -t shows files in the listing. > What version of glibc are you using? 2.2.3 right now. Slackware came with an older version. I do not know when I upgraded. However, I did a successful restore under 2.2.3 about a month ago. > Are there changes you have made to the kernel or libraries between the > time the xfsrestore was working properly and the time you realized it > wasnt? Are there any changes between the time you backed the files and > now? Yes. Starting last fall, I tracked XFS as it was updated, and made kernel upgrades as the 2.4 series had problems and fixes were issued. I have run kernel 2.4.9, 2.4.12, 2.4.16, and 2.4.18 with XFS current at the time. I used whichever XFS was current for the kernel version at the time I upgraded. Unfortunately, I had to save space and remove my old kernels, so I cannot give you an exact roadmap. The other thing I track actively is the nVidia kernel drivers, patching the kernel with each upgrade. When I first started using XFS, I did a lot of testing to make sure it worked, and have done several restores since then and they all worked. I did a successful xfsrestore under kernel 2.4.16 and whatever XFS was current with that release. My best guess is that this problem is recent, but I could not prove that for sure. The problem might simply not have affected my restores under kernel 2.4.16, but I'm sure you know that. I log all my backups. Unfortunately, I do not log my restores, though I plan to start. > What Linux are you running - SuSe, Red Hat, other? Slackware 8.0 with utility upgrades as specified by the 2.4 series of kernels. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Tue May 14 22:34:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4F5YqnC005165 for ; Tue, 14 May 2002 22:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4F5Yqq5005164 for linux-xfs-outgoing; Tue, 14 May 2002 22:34:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4F5YjnC005131 for ; Tue, 14 May 2002 22:34:45 -0700 Received: from starfleet.attglobal.net (slip-32-100-182-126.wi.us.prserv.net[32.100.182.126]) by prserv.net (out2) with ESMTP id <2002051502573120205gceqke>; Wed, 15 May 2002 02:57:33 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g4F2vHU31675 for linux-xfs@oss.sgi.com; Tue, 14 May 2002 21:57:17 -0500 X-Authentication-Warning: starfleet.attglobal.net: skylar set sender to skylar@attglobal.net using -f Date: Tue, 14 May 2002 21:57:17 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: about xfs :P Message-ID: <20020515025717.GA31311@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 25 2002 16:11:05) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2002 at 08:58:09PM +0800, hhh wrote: > The cd that I pass you to provide installs the redhat7.3, when the gearin= g end. Can't manufacture to start the floppy disk, please tell me to how cr= eate. :) cdrecord -v dev=3Dn,o,p speed=3Ds image.iso where n, o, and p are the numbers for the host adapter, the bus (channel), and ID number of the device, and s is the speed (in 150kB/s units) of the writer. --=20 -- Skylar Thompson (skylar@attglobal.net) --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE84c6MnMU1m27tfjARAjE0AJoD/f0B7HoVaPrAHDiDr8vX7NoUSQCgjqNT NXBPeLuigTuYvyo/zpjaUW4= =Wx25 -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-linux-xfs@oss.sgi.com Wed May 15 03:33:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FAXXnC023753 for ; Wed, 15 May 2002 03:33:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FAXXQ3023752 for linux-xfs-outgoing; Wed, 15 May 2002 03:33:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FAXSnC023725 for ; Wed, 15 May 2002 03:33:29 -0700 Received: from azrael.blades.cxm ([62.248.236.72]) by fep02-app.kolumbus.fi with ESMTP id <20020515103350.VVBY4192.fep02-app.kolumbus.fi@azrael.blades.cxm>; Wed, 15 May 2002 13:33:50 +0300 Received: (from blades@localhost) by azrael.blades.cxm (SGI-8.9.3/8.9.3) id NAA19566; Wed, 15 May 2002 13:33:50 +0300 (EEST) X-Authentication-Warning: azrael.blades.cxm: blades set sender to harri.haataja@cs.helsinki.fi using -f Date: Wed, 15 May 2002 13:33:49 +0300 From: Harri Haataja To: Skylar Thompson Cc: linux-xfs@oss.sgi.com Subject: Re: about xfs :P Message-ID: <20020515133349.C18926@azrael.smilehouse.com> References: <20020515025717.GA31311@starfleet.attglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020515025717.GA31311@starfleet.attglobal.net>; from skylar@attglobal.net on Tue, May 14, 2002 at 09:57:17PM -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4FAXTnC023727 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 14, 2002 at 09:57:17PM -0500, Skylar Thompson wrote: > On Tue, May 14, 2002 at 08:58:09PM +0800, hhh wrote: > > The cd that I pass you to provide installs the redhat7.3, when the > > gearing end. Can't manufacture to start the floppy disk, please tell > > me to how create. :) > > cdrecord -v dev=n,o,p speed=s image.iso > > where n, o, and p are the numbers for the host adapter, the bus > (channel), and ID number of the device, and s is the speed (in 150kB/s > units) of the writer. The nop you can figure out with -scanbus. Very easy and there's a nice man page though it does have heaps of options. From owner-linux-xfs@oss.sgi.com Wed May 15 04:29:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBTnnC026183 for ; Wed, 15 May 2002 04:29:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBTnZE026182 for linux-xfs-outgoing; Wed, 15 May 2002 04:29:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.tvol.net ([66.150.46.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBThnC026155 for ; Wed, 15 May 2002 04:29:43 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCR0D0; Wed, 15 May 2002 07:27:25 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4FBU9H19921 for ; Wed, 15 May 2002 07:30:09 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE246C1.7060104@wgate.com> Date: Wed, 15 May 2002 07:30:09 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Strange behavior on the 2.4.18 XFS tree? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have only been able to see this behavior on my system running the kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. The problem is that I started up a number of "rxvt" sessions and they took well over a minute to start up. During that time, the cpu utilization was almost nil. (Less than 1%) There was a background find operation happening, and this seems to be the key item. I could not run top while waiting for the sessions to start. I could not run "ps" either. Both blocked until the sessions finally came up and thus they produced no useful information. Is there some BKL that is being held longer than it should be in the XFS code? The 2.4.18 non-XFS system does not show this behavior. (Well, at least not to this degree. The find in the background does slow things up a bit but only by a second or two, not over 60 seconds) The machine has lots (more than 512Meg) of RAM and a fast (1GHz) PIII Tulatin processor. Is there something I should look at for you or is this a known issue? -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed May 15 04:43:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBhKnC026693 for ; Wed, 15 May 2002 04:43:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBhKxA026692 for linux-xfs-outgoing; Wed, 15 May 2002 04:43:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp1.globalintech.pl (helios.globalintech.pl [62.89.81.98]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBhDnC026665 for ; Wed, 15 May 2002 04:43:16 -0700 Received: from globalintech.pl ([172.26.25.211]) by smtp1.globalintech.pl with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 May 2002 13:43:37 +0200 Message-ID: <3CE249E9.8090803@globalintech.pl> Date: Wed, 15 May 2002 13:43:37 +0200 From: Tomasz Baranowski Organization: GlobalInTech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RH7.3 installer - question Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2002 11:43:38.0027 (UTC) FILETIME=[C0A6AFB0:01C1FC05] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Is it possible to create ISO image with SGI installer as a replacement of the origuinal RH 7.3 disk 1 ? It's very inconvenient to switch 3 disks. With just two (SGI modified "boot" and original RH7.3) its even possible to install system without swaping CD's. Regards, Blizbor From owner-linux-xfs@oss.sgi.com Wed May 15 04:46:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBkfnC026924 for ; Wed, 15 May 2002 04:46:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBkfFc026923 for linux-xfs-outgoing; Wed, 15 May 2002 04:46:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBkXnC026890 for ; Wed, 15 May 2002 04:46:33 -0700 Received: from starfleet.attglobal.net (slip-32-100-182-70.wi.us.prserv.net[32.100.182.70]) by prserv.net (out2) with ESMTP id <2002051511465720200jo8i0e>; Wed, 15 May 2002 11:46:57 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g4FBbcF06098 for linux-xfs@oss.sgi.com; Wed, 15 May 2002 06:37:38 -0500 X-Authentication-Warning: starfleet.attglobal.net: skylar set sender to skylar@attglobal.net using -f Date: Wed, 15 May 2002 06:37:38 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: about xfs :P Message-ID: <20020515113738.GA6073@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020515025717.GA31311@starfleet.attglobal.net> <20020515133349.C18926@azrael.smilehouse.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20020515133349.C18926@azrael.smilehouse.com> User-Agent: Mutt/1.3.99i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 25 2002 16:11:05) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2002 at 01:33:49PM +0300, Harri Haataja wrote: > On Tue, May 14, 2002 at 09:57:17PM -0500, Skylar Thompson wrote: > > On Tue, May 14, 2002 at 08:58:09PM +0800, hhh wrote: > > > The cd that I pass you to provide installs the redhat7.3, when the > > > gearing end. Can't manufacture to start the floppy disk, please tell > > > me to how create. :) > >=20 > > cdrecord -v dev=3Dn,o,p speed=3Ds image.iso > >=20 > > where n, o, and p are the numbers for the host adapter, the bus > > (channel), and ID number of the device, and s is the speed (in 150kB/s > > units) of the writer. >=20 > The nop you can figure out with -scanbus. Very easy and there's a nice > man page though it does have heaps of options. Ooops. Forgot about that. ;) But yes, cdrecord has one of the best man pages I have ever seen. IMHO, every command should have a couple examples demonstrating usage. For the person writing the man page, it wouldn't take too much more time either, as I would hope that that person would have the experience with the command to do many of the examples from memory. --=20 -- Skylar Thompson (skylar@attglobal.net) --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE84kh+nMU1m27tfjARAu7mAJ9pmM3FEiB4wEOY4NpTcalMfrVUHACeI1w4 emRUO0F/lOtw+4wGYROxtiQ= =lK+I -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-linux-xfs@oss.sgi.com Wed May 15 04:47:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBlGnC027094 for ; Wed, 15 May 2002 04:47:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBlGqk027093 for linux-xfs-outgoing; Wed, 15 May 2002 04:47:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBlAnC027034 for ; Wed, 15 May 2002 04:47:11 -0700 Received: from hamburg.fcb.com ([170.200.66.15]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id GW5I4900.SAJ; Wed, 15 May 2002 13:48:09 +0200 Message-ID: <3CE24AD3.7FCA020@hamburg.fcb.com> Date: Wed, 15 May 2002 13:47:31 +0200 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Tomasz Baranowski CC: linux-xfs@oss.sgi.com Subject: Re: RH7.3 installer - question References: <3CE249E9.8090803@globalintech.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tomasz Baranowski wrote: > > Hi, > > Is it possible to create ISO image with SGI installer as > a replacement of the origuinal RH 7.3 disk 1 ? > > It's very inconvenient to switch 3 disks. > With just two (SGI modified "boot" and original RH7.3) > its even possible to install system without swaping CD's. > > Regards, > Blizbor If You want an easy install without disk swapping, go for Mandrake 8.2. You can install a basic system with only the first CD of the download edition. It offers You a choice of journaling file systems and even allows the creation of an auto install floppy, so You can easily install the same setup on a lot of machines. Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Wed May 15 04:56:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBurnC029429 for ; Wed, 15 May 2002 04:56:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBureR029428 for linux-xfs-outgoing; Wed, 15 May 2002 04:56:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp1.globalintech.pl (helios.globalintech.pl [62.89.81.98]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBuinC029387 for ; Wed, 15 May 2002 04:56:46 -0700 Received: from globalintech.pl ([172.26.25.211]) by smtp1.globalintech.pl with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 May 2002 13:57:06 +0200 Message-ID: <3CE24D12.6000606@globalintech.pl> Date: Wed, 15 May 2002 13:57:06 +0200 From: Tomasz Baranowski Organization: GlobalInTech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Wagener CC: linux-xfs@oss.sgi.com Subject: Re: RH7.3 installer - question References: <3CE249E9.8090803@globalintech.pl> <3CE24AD3.7FCA020@hamburg.fcb.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2002 11:57:06.0402 (UTC) FILETIME=[A27AEC20:01C1FC07] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Of course you are right in your opinion on Mandrake. But for some reasons I cant switch my distribution. I'm using RH since 1997, I was evaluating misc others, Mandrake is cool but I must use RH. Regards, Blizbor Harald Wagener wrote: > Tomasz Baranowski wrote: > >>Hi, >> >>Is it possible to create ISO image with SGI installer as >>a replacement of the origuinal RH 7.3 disk 1 ? >> >>It's very inconvenient to switch 3 disks. >>With just two (SGI modified "boot" and original RH7.3) >>its even possible to install system without swaping CD's. >> >>Regards, >>Blizbor > > > If You want an easy install without disk swapping, go for Mandrake 8.2. You > can install a basic system with only the first CD of the download edition. It > offers You a choice of journaling file systems and even allows the creation of > an auto install floppy, so You can easily install the same setup on a lot of > machines. > > Regards, > Harald > From owner-linux-xfs@oss.sgi.com Wed May 15 05:16:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FCGanC030189 for ; Wed, 15 May 2002 05:16:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FCGapd030188 for linux-xfs-outgoing; Wed, 15 May 2002 05:16:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.tvol.net ([66.150.46.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FCGTnC030161 for ; Wed, 15 May 2002 05:16:30 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCR0Z5; Wed, 15 May 2002 08:14:11 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4FCGtH20043 for ; Wed, 15 May 2002 08:16:56 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE251B7.9020706@wgate.com> Date: Wed, 15 May 2002 08:16:55 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? References: <3CE246C1.7060104@wgate.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Sinz wrote: > I have only been able to see this behavior on my system running the > kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. > > The problem is that I started up a number of "rxvt" sessions and they > took well over a minute to start up. During that time, the cpu > utilization was almost nil. (Less than 1%) > > There was a background find operation happening, and this seems to be > the key item. > > I could not run top while waiting for the sessions to start. I could > not run "ps" either. Both blocked until the sessions finally came up > and thus they produced no useful information. > > Is there some BKL that is being held longer than it should be in the > XFS code? The 2.4.18 non-XFS system does not show this behavior. > (Well, at least not to this degree. The find in the background does > slow things up a bit but only by a second or two, not over 60 seconds) Well, I must be unlucky or something - I have been trying to reproduce this for some time and just happened to get it to happen again. There seems to be something strange going on in the VFS layer as I was also able to get this to happen in a non-XFS system. So, it looks like it really is not an XFS problem afterall. I really wish it were easier to reproduce... -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed May 15 05:35:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FCZ6nC030793 for ; Wed, 15 May 2002 05:35:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FCZ69M030792 for linux-xfs-outgoing; Wed, 15 May 2002 05:35:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FCYxnC030762 for ; Wed, 15 May 2002 05:35:00 -0700 Received: (qmail 28607 invoked from network); 15 May 2002 12:35:24 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 15 May 2002 12:35:24 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 72C1A3000BA; Wed, 15 May 2002 22:35:22 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 15CF598; Wed, 15 May 2002 22:35:21 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Michael Sinz Cc: linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? In-reply-to: Your message of "Wed, 15 May 2002 07:30:09 -0400." <3CE246C1.7060104@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 22:35:16 +1000 Message-ID: <22203.1021466116@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 15 May 2002 07:30:09 -0400, Michael Sinz wrote: >I have only been able to see this behavior on my system running the >kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. > >The problem is that I started up a number of "rxvt" sessions and they >took well over a minute to start up. During that time, the cpu >utilization was almost nil. (Less than 1%) > >There was a background find operation happening, and this seems to be >the key item. When the problem occurs, does typing sync get everything running again? I have been seeing an intermittent lock problem with XFS where everything stops until some other disk activity kicks in and the lock is released. From owner-linux-xfs@oss.sgi.com Wed May 15 06:37:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FDbGnC032728 for ; Wed, 15 May 2002 06:37:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FDbGQA032727 for linux-xfs-outgoing; Wed, 15 May 2002 06:37:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gw-nl3.philips.com (gw-nl3.philips.com [212.153.190.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FDb8nC032689 for ; Wed, 15 May 2002 06:37:09 -0700 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id 939A83B245 for ; Wed, 15 May 2002 15:37:34 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA12075 for ; Wed, 15 May 2002 15:37:33 +0200 (MET DST) From: darren.miller@philips.com Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA03080 for ; Wed, 15 May 2002 15:37:32 +0200 (MET DST) To: linux-xfs@oss.sgi.com Subject: XFS v1.1 and Linux X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 15 May 2002 14:37:09 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 15/05/2002 15:38:26, Serialize complete at 15/05/2002 15:38:26 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, We have a strange requirement and are attempting to use XFS with our Linux system. Now, the requirement comes in, due to a rank amateur creating a computer generated system which creates files in excess of 400 characters in filename length. What we need to know is how if any is it possible to support these ridiculous files on our Linux machine, it presently works fine on HPUX (vxfs) and so we are trying to get these onto Linux. Firstly, is it possible? Secondly, How or Why? Darren ============================================================================== Darren Miller Senior Systems Support Engineer Microsoft Certified Professional SCO Advanced Certified Engineer Infomation Systems Department (Core Server Support) Philips Semiconductors,Milbrook Industrial Estate,Southampton,SO15 0DJ,England [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed May 15 06:39:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FDd7nC000489 for ; Wed, 15 May 2002 06:39:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FDd7ll000488 for linux-xfs-outgoing; Wed, 15 May 2002 06:39:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FDd1nC000454 for ; Wed, 15 May 2002 06:39:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA61690; Wed, 15 May 2002 08:39:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA68874; Wed, 15 May 2002 08:39:18 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4FDd0O08442; Wed, 15 May 2002 08:39:00 -0500 Subject: Re: Strange behavior on the 2.4.18 XFS tree? From: Steve Lord To: Keith Owens Cc: Michael Sinz , linux-xfs@oss.sgi.com In-Reply-To: <22203.1021466116@ocs3.intra.ocs.com.au> References: <22203.1021466116@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 May 2002 08:39:00 -0500 Message-Id: <1021469940.19994.388.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-15 at 07:35, Keith Owens wrote: > On Wed, 15 May 2002 07:30:09 -0400, > Michael Sinz wrote: > >I have only been able to see this behavior on my system running the > >kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. > > > >The problem is that I started up a number of "rxvt" sessions and they > >took well over a minute to start up. During that time, the cpu > >utilization was almost nil. (Less than 1%) > > > >There was a background find operation happening, and this seems to be > >the key item. > > When the problem occurs, does typing sync get everything running again? > I have been seeing an intermittent lock problem with XFS where > everything stops until some other disk activity kicks in and the lock > is released. I wish people would tell us things like this when they happen. For the record, there is no use of the BKL in xfs at all. Michael's problem sounds more like memory getting chewed up by the dcache and icache. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 15 07:54:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FEs7nC002810 for ; Wed, 15 May 2002 07:54:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FEs7cd002809 for linux-xfs-outgoing; Wed, 15 May 2002 07:54:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FErxnC002778 for ; Wed, 15 May 2002 07:54:00 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA64034; Wed, 15 May 2002 09:54:21 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA74508; Wed, 15 May 2002 09:54:20 -0500 (CDT) Subject: Re: XFS v1.1 and Linux From: Eric Sandeen To: darren.miller@philips.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 May 2002 09:54:20 -0500 Message-Id: <1021474461.30041.114.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-15 at 08:37, darren.miller@philips.com wrote: > Now, the requirement comes in, due to a rank amateur creating a computer > generated system > which creates files in excess of 400 characters in filename length. > > What we need to know is how if any is it possible to support these > ridiculous files on our Linux machine, > it presently works fine on HPUX (vxfs) and so we are trying to get these > onto Linux. In XFS, we have: /* * MAXNAMELEN is the length (including the terminating null) of * the longest permissible file (component) name. */ #define MAXNAMELEN 256 Ext2 has #define EXT2_NAME_LEN 255 and reiserfs: #define REISERFS_MAX_NAME_LEN(block_size) 255 so I'm afraid that's your answer. -Eric > [[HTML alternate version deleted]] -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 15 08:02:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FF2NnC003325 for ; Wed, 15 May 2002 08:02:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FF2NUt003324 for linux-xfs-outgoing; Wed, 15 May 2002 08:02:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FF2HnC003290 for ; Wed, 15 May 2002 08:02:18 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g4FF2bI32035; Wed, 15 May 2002 17:02:37 +0200 Date: Wed, 15 May 2002 17:02:37 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: darren.miller@philips.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS v1.1 and Linux Message-ID: <20020515170237.B19518@vestdata.no> References: <1021474461.30041.114.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1021474461.30041.114.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, May 15, 2002 at 09:54:20AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 09:54:20AM -0500, Eric Sandeen wrote: > /* > * MAXNAMELEN is the length (including the terminating null) of > * the longest permissible file (component) name. > */ > #define MAXNAMELEN 256 > > Ext2 has > #define EXT2_NAME_LEN 255 > > and reiserfs: > #define REISERFS_MAX_NAME_LEN(block_size) 255 > > so I'm afraid that's your answer. I believe reiserfs is able to handle names up to 4095 charecters internally, but a lower limit is imposed because of VFS limitations. I think there was a discussion on the reiserfs list on how this should be handled; so if you need this feature you should post on reiserfs-dev and linux-fs lists. -- Ragnar Kjorstad Big Storage From owner-linux-xfs@oss.sgi.com Wed May 15 08:24:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FFOwnC005357 for ; Wed, 15 May 2002 08:24:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FFOwJc005356 for linux-xfs-outgoing; Wed, 15 May 2002 08:24:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from revere3.musc.edu (revere3.musc.edu [128.23.203.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FFOqnC005320 for ; Wed, 15 May 2002 08:24:52 -0700 Received: from flopsy.musc.edu (flopsy.musc.edu [128.23.203.162]) by revere3.musc.edu (8.8.8/8.8.8) with ESMTP id LAA21150 for ; Wed, 15 May 2002 11:25:13 -0400 (EDT) Received: from fade2.harborview.musc.edu (fade2.harborview.musc.edu [128.23.43.11]) by flopsy.musc.edu (8.11.6/8.11.6) with ESMTP id g4FFPDA08955 for ; Wed, 15 May 2002 11:25:13 -0400 Date: Wed, 15 May 2002 11:23:56 -0000 From: John Imholz To: linux-xfs@oss.sgi.com Subject: Argument list too long Message-ID: <3050000.1021461836@fade2.harborview.musc.edu> Originator-Info: login-id=imholzj; server=imaps.musc.edu X-Mailer: Mulberry/2.2.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please excuse the newbie question (I searched the archives and didn't find an answer). When I setfacl on the directory "testacl" with this: user::rwx user:user1:rwx user:user2:rwx user:user3:rwx user:user4:rwx user:user5:rwx user:user7:rwx user:user8:rwx user:user9:rwx user:user10:rwx user:user11:rwx user:user12:rwx user:user13:rwx group::rwx group:user0:r-x mask::rwx other::r-x Then getfacl returns: getfacl: testacl: Argument list too long One less user works fine. I thought the limit was 25. Any suggestions? jji From owner-linux-xfs@oss.sgi.com Wed May 15 08:30:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FFUrnC007244 for ; Wed, 15 May 2002 08:30:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FFUrun007243 for linux-xfs-outgoing; Wed, 15 May 2002 08:30:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta04.algx.net (chimta04.algx.net [216.99.233.79]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FFUknC007212 for ; Wed, 15 May 2002 08:30:46 -0700 Received: from jtsdell.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx04.algx.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0GW500387SE9FN@chimmx04.algx.net> for linux-xfs@oss.sgi.com; Wed, 15 May 2002 10:30:09 -0500 (CDT) Date: Wed, 15 May 2002 11:29:35 -0400 From: John M Trostel Subject: Re: Argument list too long In-reply-to: <3050000.1021461836@fade2.harborview.musc.edu> To: John Imholz Cc: linux-xfs@oss.sgi.com Message-id: <1021476576.1566.1.camel@jtsdell> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.5 Content-type: text/plain Content-transfer-encoding: 7BIT References: <3050000.1021461836@fade2.harborview.musc.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This has been fixed in the CVS tree. On Wed, 2002-05-15 at 07:23, John Imholz wrote: > Please excuse the newbie question (I searched the archives and didn't find > an answer). > > When I setfacl on the directory "testacl" with this: > user::rwx > user:user1:rwx > user:user2:rwx > user:user3:rwx > user:user4:rwx > user:user5:rwx > user:user7:rwx > user:user8:rwx > user:user9:rwx > user:user10:rwx > user:user11:rwx > user:user12:rwx > user:user13:rwx > group::rwx > group:user0:r-x > mask::rwx > other::r-x > > Then getfacl returns: > > getfacl: testacl: Argument list too long > > One less user works fine. I thought the limit was 25. Any suggestions? > > jji > -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Wed May 15 08:36:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FFaCnC007588 for ; Wed, 15 May 2002 08:36:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FFaCx3007587 for linux-xfs-outgoing; Wed, 15 May 2002 08:36:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FFa5nC007557 for ; Wed, 15 May 2002 08:36:06 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 1780nL-00074G-00; Wed, 15 May 2002 09:34:27 -0600 Message-ID: <3CE2807B.5000508@emergence.com> Date: Wed, 15 May 2002 09:36:27 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomasz Baranowski CC: linux-xfs@oss.sgi.com Subject: Re: RH7.3 installer - question References: <3CE249E9.8090803@globalintech.pl> <3CE24AD3.7FCA020@hamburg.fcb.com> <3CE24D12.6000606@globalintech.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The absolute easiest way without modifying installers that I can think of is to use two systems/partitions/drives etc. (You can come up with another method if you like) System 1) *) Install Redhat 7.3 as you wish with ext2/ext3 *) Install the 2.4.18-XFS or CVS Kernel and utilities System/ 2) *) Install Mandrake 8.2 on a 200 meg partition at the end of the drive *) Make your XFS filesystem(s) on the rest of the drive as you want them *) Copy the Contents of your Redhat 7.3 install to the XFS partitions (rsync, etc) *) Install/modify the appropriate boot managers You can either leave the minimal Mandrake system or repartition and grow your XFS filesystem. -Mike On one system partition about 200 megs near the end of the drive to do a Mandrake 8.2 minimal install. Tomasz Baranowski wrote: > Of course you are right in your opinion on Mandrake. > But for some reasons I cant switch my distribution. > I'm using RH since 1997, I was evaluating misc others, > Mandrake is cool but I must use RH. > > Regards, > Blizbor From owner-linux-xfs@oss.sgi.com Wed May 15 08:45:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FFjmnC008005 for ; Wed, 15 May 2002 08:45:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FFjmQZ008004 for linux-xfs-outgoing; Wed, 15 May 2002 08:45:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FFjZnC007973 for ; Wed, 15 May 2002 08:45:37 -0700 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA20811 for ; Wed, 15 May 2002 11:45:56 -0400 Subject: A couple of long-standing XFS (non-fatal) wierdnesses From: Derek Glidden To: "linux-xfs@oss.sgi.com" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 May 2002 11:45:56 -0400 Message-Id: <1021477557.30434.23.camel@two.nks.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I haven't bothered posting about these because they really aren't that big a deal and I've been otherwise too occupied to work on any followup. I've had a couple of strange behaviours with XFS on a few of my machines since about the 2.4.14 days or so, up through the current 2.4.18 1.1 RELEASE version. Weird #1: On my workstation at home - and this is the only machine I've seen this behaviour on - which is an Athlon 1.33Ghz with 512MB of RAM and IDE drives running Debian Woody current as of a couple of weeks ago (I've recently moved and only have dialup for now, grr...) when I sit down in the evening after work and log in, the HD goes nuts for anywhere from 30-60 seconds while the system drags under I/O load. If I log in and immediately type "sync" it takes some time for it to return, so it appears that the system is flushing a bunch of buffers. Also, if I do a "free" it shows that all the memory is used, mostly for filesystem buffers. All filesystems on this machine (except / which is ext3) are XFS. I suspect this has something to do with some nightly process that grinds through the drive for some reason or another - the "find" that updates the "locate" database or something. It's not a big deal, and after that inital "sync" the machine behaves normally, but it's curious. This may not even actually be an XFS issue, my suspicion is based on the fact that it started doing this shortly after I converted the filesystems to XFS. Weird #2: This I can reproduce on few XFS machines. (Again with IDE.) If a LOT of data changing file activity takes place on an XFS filesystem (i.e. untar and rebuild a kernel, rsync a lot of data from another box, etc) it takes a while for that filesystem to umount and the drive light comes on steady while it's umount'ing. The more file create/delete actions that have taken place, the longer it seems to take to umount the filesystem. These are primarily Debian Potato boxes (what we use at work and I use at home) that I see this behaviour on, although I've also seen Woody do it a few times. (I saw something come across the list once about certain RedHat versions taking a long time to umount, but I don't know if that was related because I can't find the details.) Doing "sync" before umount'ing the partition doesn't seem to make a difference. I can't say for absolutely sure, but I *think* that I've only seen this behaviour on systems with more than one IDE hard drive in them, which is just plain weird. (I know the machines that I can reproduce it fairly easily are my work workstation with two drives, my home workstation with two, and my home server with four.) Neither one of these things is really causing me problems, although once or twice I've had to reboot my file server at home and had to wait a couple minutes for the drives to spin while it umount'ed them before it would come back up, but that's just an inconvenience rather than a real problem. If there's any kind of instrumentation I can build into a kernel to see what's happening at the XFS or VFS levels in these two cases, I'd like to take a look. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed May 15 09:30:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FGU8nC009729 for ; Wed, 15 May 2002 09:30:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FGU831009728 for linux-xfs-outgoing; Wed, 15 May 2002 09:30:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FGTwnC009685 for ; Wed, 15 May 2002 09:30:00 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g4FGUOI32183 for ; Wed, 15 May 2002 18:30:24 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdeuGAQK; Wed May 15 18:30:17 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g4FGUGf15467 for ; Wed, 15 May 2002 18:30:16 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g4FGUGX23200 for linux-xfs@oss.sgi.com; Wed, 15 May 2002 18:30:16 +0200 Date: Wed, 15 May 2002 18:30:16 +0200 From: Utz Lehmann To: linux-xfs@oss.sgi.com Subject: xfs_ncheck shows only one filename per inode Message-ID: <20020515183016.C9309@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi xfs_ncheck shows only one filename per inode, even if there exsist more: # ln FILE1 FILE2 # ls -i FILE* 185 FILE1 185 FILE2 # xfs_ncheck -i 185 /dev/vg00/tmp 185 FILE1 # xfs_ncheck /dev/vg00/tmp | grep " 185 " 185 FILE1 # rm FILE1 # xfs_ncheck -i 185 /dev/vg00/tmp 185 FILE2 # ln FILE2 FILE3 # ls -i FILE* 185 FILE2 185 FILE3 # xfs_ncheck -i 185 /dev/vg00/tmp 185 FILE3 Is this a bug? btw: Is it safe to run xfs_ncheck on a mounted fs? utz From owner-linux-xfs@oss.sgi.com Wed May 15 09:45:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FGjGnC011078 for ; Wed, 15 May 2002 09:45:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FGjGtD011077 for linux-xfs-outgoing; Wed, 15 May 2002 09:45:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FGj9nC011048 for ; Wed, 15 May 2002 09:45:10 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g4FGjZL32230 for ; Wed, 15 May 2002 18:45:35 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdRn1bvr; Wed May 15 18:45:29 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g4FGjRf15879 for ; Wed, 15 May 2002 18:45:27 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g4FGjR523641 for linux-xfs@oss.sgi.com; Wed, 15 May 2002 18:45:27 +0200 Date: Wed, 15 May 2002 18:45:27 +0200 From: Utz Lehmann To: linux-xfs@oss.sgi.com Subject: may 2002 mailinglist archive on oss is broken Message-ID: <20020515184527.D9309@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi FYI: http://oss.sgi.com/projects/xfs/mail_archive/200205/threads.html Mason error error in file: /oss/www/projects/xfs/mail_archive/200205/threads.html line 723: '<%' with no matching '%>' context: ... 719: 720: 721:
  • Check This Out!!, 722: Jeniffer
    • 723:
  • B!*9-9p!*Nx$N!!%a!<%k%^%,%8(B 724: )B%s(B 725: , 726: milk
    • 727:
  • Re: [Acl-Devel] Naming User Attributes, ... code stack: /oss/www/projects/xfs/mail_archive/200205/threads.html:723 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm:374 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm:116 utz From owner-linux-xfs@oss.sgi.com Wed May 15 10:49:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FHnFnC013839 for ; Wed, 15 May 2002 10:49:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FHnFv7013838 for linux-xfs-outgoing; Wed, 15 May 2002 10:49:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FHn9nC013812 for ; Wed, 15 May 2002 10:49:10 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA65697; Wed, 15 May 2002 12:49:31 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA78745; Wed, 15 May 2002 12:49:31 -0500 (CDT) Subject: Re: May 2002 XFS Mailing List Archive From: Eric Sandeen To: Sarwer Zafiruddin Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 May 2002 12:49:31 -0500 Message-Id: <1021484971.30579.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fixed now, sorry about that. oss got rebuilt, all the tweaks we had to make things work got broken, it seems. Slowly rediscovering them all. :) -Eric On Wed, 2002-05-15 at 12:35, Sarwer Zafiruddin wrote: > Hello, > > I frequently browse the XFS Mailing list and I found I was unable to > browse the list due to a "Mason Error" I get when I try to view the May > 2002 archives. Is it possible if you can fix this? > > http://oss.sgi.com/projects/xfs/mail_archive/200205/threads.html > > Thank You, > Sarwer Zafiruddin > > -- > -------------------------- > System Administrator > Rune Information Services > http://www.rune.org > e-mail: sarwer@rune.org > -------------------------- -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed May 15 11:10:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FIAwnC014659 for ; Wed, 15 May 2002 11:10:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FIAwLf014658 for linux-xfs-outgoing; Wed, 15 May 2002 11:10:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.tvol.net ([66.150.46.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FIAlnC014632 for ; Wed, 15 May 2002 11:10:51 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCSGHT; Wed, 15 May 2002 14:08:27 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4FIBBH21056; Wed, 15 May 2002 14:11:11 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE2A4BE.7060508@wgate.com> Date: Wed, 15 May 2002 14:11:10 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? References: <22203.1021466116@ocs3.intra.ocs.com.au> <1021469940.19994.388.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > On Wed, 2002-05-15 at 07:35, Keith Owens wrote: > >>On Wed, 15 May 2002 07:30:09 -0400, >>Michael Sinz wrote: >> >>>I have only been able to see this behavior on my system running the >>>kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. >>> >>>The problem is that I started up a number of "rxvt" sessions and they >>>took well over a minute to start up. During that time, the cpu >>>utilization was almost nil. (Less than 1%) >>> >>>There was a background find operation happening, and this seems to be >>>the key item. >> >>When the problem occurs, does typing sync get everything running again? >>I have been seeing an intermittent lock problem with XFS where >>everything stops until some other disk activity kicks in and the lock >>is released. > > I wish people would tell us things like this when they happen. If I can make a better (more reliable) mechanism to repeat this, I will send it to you. It has happened a number of times in the last two days. > For the record, there is no use of the BKL in xfs at all. Michael's > problem sounds more like memory getting chewed up by the dcache and > icache. Ahh, I have seen this happen in the past - I have not understood why so much memory was used at times in the system. The machine is running headless (no local X display) and thus it should have lots of resources. Is there something specific you would like me to try? -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed May 15 11:15:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FIFInC014918 for ; Wed, 15 May 2002 11:15:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FIFILQ014917 for linux-xfs-outgoing; Wed, 15 May 2002 11:15:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FIFDnC014886 for ; Wed, 15 May 2002 11:15:13 -0700 Received: from mail.tvol.net ([66.150.46.254]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02987 for ; Wed, 15 May 2002 11:15:33 -0700 (PDT) mail_from (msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCSG29; Wed, 15 May 2002 14:11:21 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4FIE6H21060; Wed, 15 May 2002 14:14:06 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE2A56D.3000308@wgate.com> Date: Wed, 15 May 2002 14:14:05 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? References: <22203.1021466116@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Wed, 15 May 2002 07:30:09 -0400, > Michael Sinz wrote: > >>I have only been able to see this behavior on my system running the >>kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. >> >>The problem is that I started up a number of "rxvt" sessions and they >>took well over a minute to start up. During that time, the cpu >>utilization was almost nil. (Less than 1%) >> >>There was a background find operation happening, and this seems to be >>the key item. > > > When the problem occurs, does typing sync get everything running again? > I have been seeing an intermittent lock problem with XFS where > everything stops until some other disk activity kicks in and the lock > is released. I will try that next time it happens. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed May 15 11:29:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FITbnC015504 for ; Wed, 15 May 2002 11:29:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FITbgw015503 for linux-xfs-outgoing; Wed, 15 May 2002 11:29:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FITTnC015469 for ; Wed, 15 May 2002 11:29:30 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 11:29:52 -0700 Received: from qarce-lnx.afara.com ([10.2.4.98]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 11:29:51 -0700 Subject: Re: Are these errors bad? xfs_repair finding errors. From: Quentin Arce To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020514094608.P120284@wobbly.melbourne.sgi.com> References: <1021134063.3827.978.camel@qarce-lnx> <20020514094608.P120284@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 May 2002 11:29:51 -0700 Message-Id: <1021487391.1596.107.camel@qarce-lnx> Mime-Version: 1.0 X-OriginalArrivalTime: 15 May 2002 18:29:51.0800 (UTC) FILETIME=[808D4B80:01C1FC3E] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thank YOU!!! Q On Mon, 2002-05-13 at 16:46, Nathan Scott wrote: > On Sat, May 11, 2002 at 09:21:03AM -0700, Quentin Arce wrote: > > > > > > Hello, > > > > I have been using XFS since if first came out... well a little before > > that :) > > > > Anyhow, I have just finished running xfs_repair on a x86 build system > > and found this error twice: > > > > LEAFN node level is 1 inode 104051713 bno = 8388608 > > From a quick look at the code, this seems to be something > unexpected which xfs_repair does nothing about. You could > try recreating that directory (for inode 104051713 -- use > xfs_ncheck -i to find the full path to the inode). > > > Please if you know what this means please let me know... Seem it was not > > repaired on the first pass with xfs_repair. > > > > Also one other question regarding xfs_repair... This system as well as > > my laptop seem to always rebuild inode 128. Is their a reason why this > > is rebuilt on some systems but not others? > > 128 is usually the root inode in a 4K bsize filesystem -- if you > are re-running repair and the lost+found directory is re-created > each time, then this directory will need to be reconstructed. > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Wed May 15 12:00:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FJ0QnC019547 for ; Wed, 15 May 2002 12:00:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FJ0QjN019546 for linux-xfs-outgoing; Wed, 15 May 2002 12:00:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FJ0LnC019509 for ; Wed, 15 May 2002 12:00:21 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 634DAC001C5; Thu, 16 May 2002 05:00:41 +1000 (EST) Date: Thu, 16 May 2002 05:00:41 +1000 From: Ian Cumming To: darren.miller@philips.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS v1.1 and Linux Message-ID: <20020515190041.GA32452@ids.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Couldn't you use XFS file attributes to store these longs strings for each file name? Just a thought. Ian. On Wed, May 15, 2002 at 02:37:09PM +0100, darren.miller@philips.com wrote: > Now, the requirement comes in, due to a rank amateur creating a computer > generated system > which creates files in excess of 400 characters in filename length. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Wed May 15 12:17:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FJH7nC020332 for ; Wed, 15 May 2002 12:17:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FJH7kp020331 for linux-xfs-outgoing; Wed, 15 May 2002 12:17:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FJH0nC020268 for ; Wed, 15 May 2002 12:17:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA67013; Wed, 15 May 2002 14:17:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA35391; Wed, 15 May 2002 14:17:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4FJH1C19829; Wed, 15 May 2002 14:17:01 -0500 Subject: Re: xfs_ncheck shows only one filename per inode From: Steve Lord To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020515183016.C9309@de.tecosim.com> References: <20020515183016.C9309@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 May 2002 14:17:01 -0500 Message-Id: <1021490221.19994.526.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-05-15 at 11:30, Utz Lehmann wrote: > Hi > > xfs_ncheck shows only one filename per inode, even if there exsist more: > > # ln FILE1 FILE2 > # ls -i FILE* > 185 FILE1 185 FILE2 > # xfs_ncheck -i 185 /dev/vg00/tmp > 185 FILE1 > # xfs_ncheck /dev/vg00/tmp | grep " 185 " > 185 FILE1 > # rm FILE1 > # xfs_ncheck -i 185 /dev/vg00/tmp > 185 FILE2 > # ln FILE2 FILE3 > # ls -i FILE* > 185 FILE2 185 FILE3 > # xfs_ncheck -i 185 /dev/vg00/tmp > 185 FILE3 > > Is this a bug? > > btw: Is it safe to run xfs_ncheck on a mounted fs? See the man page, it says you can, but might get error messages. As for the multiple names for an inode, I suspect it is just written to stop after one name is found. If you use it without the -i it should report all names, you could pipe that into grep for your inode number. OK I know that is horribly inefficient. Steve > > > utz -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed May 15 12:40:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FJeAnC030570 for ; Wed, 15 May 2002 12:40:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FJeAZM030569 for linux-xfs-outgoing; Wed, 15 May 2002 12:40:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FJe3nC030534 for ; Wed, 15 May 2002 12:40:03 -0700 Received: from [209.96.185.84] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 1784dR-0003c8-00; Wed, 15 May 2002 15:40:29 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4FJcRN21897; Wed, 15 May 2002 15:38:27 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4FJcR410083; Wed, 15 May 2002 15:38:27 -0400 Date: Wed, 15 May 2002 15:38:27 -0400 From: Charles Shannon Hendrix To: Michael Sinz Cc: Steve Lord , Keith Owens , linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? Message-ID: <20020515193826.GA10067@widomaker.com> References: <22203.1021466116@ocs3.intra.ocs.com.au> <1021469940.19994.388.camel@jen.americas.sgi.com> <3CE2A4BE.7060508@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE2A4BE.7060508@wgate.com> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 02:11:10PM -0400, Michael Sinz wrote: > >For the record, there is no use of the BKL in xfs at all. Michael's > >problem sounds more like memory getting chewed up by the dcache and > >icache. > > Ahh, I have seen this happen in the past - I have not understood why > so much memory was used at times in the system. The machine is running > headless (no local X display) and thus it should have lots of resources. Can you elaborate on this? Are you saying that a report from the free program does not account for all memory? I'm asking because a constant problem for me with Linux 2.4.x kernels is that I seem to gradually lose memory. Booting up my system takes under 20MB of RAM. After running a few days with X on my XFS 1.1 system, going back to console shows 50-100MB unaccounted for in the memory stats. I mean, after subtracting buffers and everything, memory is missing. A lot of wierd filesystem behavior also started happening on my Linux systems after I started noticing memory seems to be going away. It might be nothing but /proc lying about memory use, as someone suggested some time back in a kernel discussion I read. However, it bothers me a bit that bad behavior, espeically with XFS, seems to have accompanied this missing memory problem. Of course, if that isn't what you meant, maybe I'm the only one... :) -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Wed May 15 14:25:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FLPfnC001878 for ; Wed, 15 May 2002 14:25:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FLPfjh001877 for linux-xfs-outgoing; Wed, 15 May 2002 14:25:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FLPanC001851 for ; Wed, 15 May 2002 14:25:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA79841 for ; Wed, 15 May 2002 16:25:58 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA54290 for ; Wed, 15 May 2002 16:25:41 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g4FLPfE28816; Wed, 15 May 2002 16:25:41 -0500 Message-Id: <200205152125.g4FLPfE28816@stout.americas.sgi.com> Date: Wed, 15 May 2002 16:25:41 -0500 Subject: TAKE - More log recovery error fixes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks to the folks at bigstorage and to Willi Langenberger for pointing this one out. In some circumstances the code that finds the log head could end up getting an uninitialized block number for the log head, leading to all sorts of interesting behavior... Date: Wed May 15 14:23:31 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:119239a cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.6 - Return EIO from xlog_find_zeroed if xlog_find_verify_log_record can't find the header. Otherwise the block number from xlog_find_zeroed will be used uninitialized. Modid: 2.4.x-xfs:slinx:119239b linux/fs/xfs/xfs_log_recover.c - 1.227 - Return EIO from xlog_find_zeroed if xlog_find_verify_log_record can't find the header. Otherwise the block number from xlog_find_zeroed will be used uninitialized. From owner-linux-xfs@oss.sgi.com Wed May 15 15:41:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMf1nC003300 for ; Wed, 15 May 2002 15:41:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMf1v5003299 for linux-xfs-outgoing; Wed, 15 May 2002 15:41:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMeonC003272 for ; Wed, 15 May 2002 15:40:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA97543; Wed, 15 May 2002 17:41:13 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA21641; Wed, 15 May 2002 17:41:13 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id RAA19067; Wed, 15 May 2002 17:41:13 -0500 (CDT) Message-ID: <3CE2E408.1578669D@sgi.com> Date: Wed, 15 May 2002 17:41:12 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> <3CE1835A.89040F77@sgi.com> <20020515034808.GA349@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles, I am unable to reproduce this issue in our lab here since we dont have Slackware 8.0 on any of the test machines. I used xfsdump/xfsrestore on Red Hat 7.2 with 2.4.18-xfs kernel and glibc version 2.2.4 and it works. Would you upgrade glibc to version 2.2.4 and see if that would work? Thanks, Kihonge JN Charles Shannon Hendrix wrote: > On Tue, May 14, 2002 at 04:36:26PM -0500, John Kihonge wrote: > > > > Charles, > > > > It is difficult at the moment to determine why xfsrestore is not working > > properly without getting more details from you. Here are afew quesions; > > > > What is the xfsretore command line that you are using? > > All of them... :) > > Seriously, no combination of xfsrestore commands is special with regard > to restoring or not restoring files. I have tried incremental, sub-path > specification, and full restores. Incremental shows files but won't > restore them. xfsrestore -t shows files in the listing. > > > What version of glibc are you using? > > 2.2.3 right now. Slackware came with an older version. I do not know > when I upgraded. However, I did a successful restore under 2.2.3 about a > month ago. > > > Are there changes you have made to the kernel or libraries between the > > time the xfsrestore was working properly and the time you realized it > > wasnt? Are there any changes between the time you backed the files and > > now? > > Yes. Starting last fall, I tracked XFS as it was updated, and made > kernel upgrades as the 2.4 series had problems and fixes were issued. I > have run kernel 2.4.9, 2.4.12, 2.4.16, and 2.4.18 with XFS current at > the time. I used whichever XFS was current for the kernel version at the > time I upgraded. > > Unfortunately, I had to save space and remove my old kernels, so I > cannot give you an exact roadmap. > > The other thing I track actively is the nVidia kernel drivers, patching > the kernel with each upgrade. > > When I first started using XFS, I did a lot of testing to make sure it > worked, and have done several restores since then and they all worked. > I did a successful xfsrestore under kernel 2.4.16 and whatever XFS was > current with that release. > > My best guess is that this problem is recent, but I could not prove that > for sure. The problem might simply not have affected my restores under > kernel 2.4.16, but I'm sure you know that. > > I log all my backups. Unfortunately, I do not log my restores, though > I plan to start. > > > What Linux are you running - SuSe, Red Hat, other? > > Slackware 8.0 with utility upgrades as specified by the 2.4 series of > kernels. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Wed May 15 15:43:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMhRnC003405 for ; Wed, 15 May 2002 15:43:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMhRhj003404 for linux-xfs-outgoing; Wed, 15 May 2002 15:43:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMhLnC003378 for ; Wed, 15 May 2002 15:43:22 -0700 Received: from pc9391 (guc28561@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id AAA15045 for ; Thu, 16 May 2002 00:43:49 +0200 (MET DST) Date: Thu, 16 May 2002 00:43:49 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: scsi2ide Hardware Raid5 questions Message-ID: <20020516004349.C22460@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.3 Lines: 23 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we just bought a Infortrend IFT-6300 scsi2ide hardware Raid. It consists of 12 Maxtor 160GB drives and is connected to DualPII via an adaptec 29160 scsi controller.(32bit pci only). I configured it as Raid5 with all 12 drives and so has a capacity of about 1650 GB. Here my Problems start: I tried latest 2.4-xfs cvs kernel and 2.4.19-pre8aa2. 1. aic7xxx reports a negative size of that big scsi array. Can this message be ignored? I tried fdisk and finally got a working partition table on this device. 2. The IFT-6300 comes with no documentation about block, stride and stripe sizes. Is it safe for me to use mkfs.xfs without any sunit and swith options? thanks in advance Christian Guggenberger From owner-linux-xfs@oss.sgi.com Wed May 15 19:18:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G2IenC011860 for ; Wed, 15 May 2002 19:18:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G2IeBc011859 for linux-xfs-outgoing; Wed, 15 May 2002 19:18:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G2IanC011833 for ; Wed, 15 May 2002 19:18:36 -0700 Received: from wilma.widomaker.com (wilma.widomaker.com [204.17.220.5]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA00575 for ; Wed, 15 May 2002 19:18:57 -0700 (PDT) mail_from (shannon@escape.shannon.net) Received: from [209.96.179.226] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 178Ait-000PLc-00; Wed, 15 May 2002 22:10:31 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4G29dN09673; Wed, 15 May 2002 22:09:39 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4G29d010414; Wed, 15 May 2002 22:09:39 -0400 Date: Wed, 15 May 2002 22:09:39 -0400 From: Charles Shannon Hendrix To: John Kihonge Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems Message-ID: <20020516020938.GB10343@widomaker.com> References: <20020511205125.GD4462@widomaker.com> <3CE1835A.89040F77@sgi.com> <20020515034808.GA349@widomaker.com> <3CE2E408.1578669D@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE2E408.1578669D@sgi.com> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 05:41:12PM -0500, John Kihonge wrote: > > Charles, > > I am unable to reproduce this issue in our lab here since we dont have > Slackware 8.0 on any of the test machines. I used xfsdump/xfsrestore on Red > Hat 7.2 with 2.4.18-xfs kernel and glibc version 2.2.4 and it works. You can install it in about 30 minutes... and in any case, it's not likely related to Slackware since another user had the same trouble in February. I think he was using Red Hat, but I don't remember. > Would you upgrade glibc to version 2.2.4 and see if that would work? That's non-trivial. Do you have any reason for me to do this? I mean, is there something about 2.2.3 that you suspect? I'll have to see what is involved in the upgrade. Slackware is close to another release which might use that version or later. From owner-linux-xfs@oss.sgi.com Wed May 15 21:00:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G408nC012577 for ; Wed, 15 May 2002 21:00:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G408BJ012570 for linux-xfs-outgoing; Wed, 15 May 2002 21:00:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G401nC012542 for ; Wed, 15 May 2002 21:00:01 -0700 Received: from [209.96.179.226] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 178CRI-00097N-00; Thu, 16 May 2002 00:00:28 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4G3tpN22376; Wed, 15 May 2002 23:55:51 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4G3tox12250; Wed, 15 May 2002 23:55:50 -0400 Date: Wed, 15 May 2002 23:55:50 -0400 From: Charles Shannon Hendrix To: John Kihonge Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems Message-ID: <20020516035549.GA12197@widomaker.com> References: <20020511205125.GD4462@widomaker.com> <3CE1835A.89040F77@sgi.com> <20020515034808.GA349@widomaker.com> <3CE2E408.1578669D@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE2E408.1578669D@sgi.com> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 05:41:12PM -0500, John Kihonge wrote: > Charles, > > I am unable to reproduce this issue in our lab here since we dont have > Slackware 8.0 on any of the test machines. I used xfsdump/xfsrestore on Red > Hat 7.2 with 2.4.18-xfs kernel and glibc version 2.2.4 and it works. > > Would you upgrade glibc to version 2.2.4 and see if that would work? OK... glibc 2.2.4 is in place. I forget sometimes how easy Slackware is to upgrade. I'm running an interactive restore of my /usr/local/src directory, which is what I recently lost that needs restoration the most. OK... I got a bit further this time, but the restore ended with this error: xfsrestore: restoring non-directory files xfsrestore: examining media file 8 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( contextp->dc_recsz )' failed. Aborted It managed to restore 15790 files. Unfortunately, it is still stopping short of the files I actually need. This error sounds like the original dump failed, but it didn't, and I'm fairly certain I verified this tape. Is this backup lost? Would it be worthwhile to bring back my /var/lib/xfsdump directory and try again? From owner-linux-xfs@oss.sgi.com Thu May 16 00:21:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G7L7nC014626 for ; Thu, 16 May 2002 00:21:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G7L7br014625 for linux-xfs-outgoing; Thu, 16 May 2002 00:21:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G7L1nC014599 for ; Thu, 16 May 2002 00:21:02 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id QAA13250; Thu, 16 May 2002 16:57:58 +0930 Message-ID: <3CE36031.4AE1DDD2@rebel.net.au> Date: Thu, 16 May 2002 17:00:57 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cumming CC: darren.miller@philips.com, linux-xfs@oss.sgi.com Subject: Re: XFS v1.1 and Linux References: <20020515190041.GA32452@ids.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmmm... > Couldn't you use XFS file attributes to store these longs strings for each > file name? If the program were able to know the name without actually "see" the name (eg, I could construct the name from other information) you could md5sum the "real" name...or something like that. DSL -- And Ptah begat the thought and the word And by these thoughts and words Atum, mighty God, created the world from the void! [An interpretation of the Memphite Creation myphs] From owner-linux-xfs@oss.sgi.com Thu May 16 06:50:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GDoUnC023528 for ; Thu, 16 May 2002 06:50:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GDoUk8023527 for linux-xfs-outgoing; Thu, 16 May 2002 06:50:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GDo6nC023498 for ; Thu, 16 May 2002 06:50:10 -0700 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g4GDoVcm009269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 May 2002 09:50:32 -0400 Message-ID: <3CE3B927.30806@Lehigh.EDU> Date: Thu, 16 May 2002 09:50:31 -0400 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, andrea@suse.de Subject: 2.4.19-pre6aa1 oops Content-Type: multipart/mixed; boundary="------------090309050402040007010101" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------090309050402040007010101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit After two weeks of uneventful uptime with -pre6aa1 the system hung with no symptoms, no messages, no way in. XFS filesystems recovered themselves on reboot with no apparent problems. About twelve hours later got the appended oops, in the early AM. I suspect it may have been triggered by the system backup, which is now stuck in D state. Otherwise the system is running normally except loadavg is high (6-7) even though there is little CPU and IO usage. Jim --------------090309050402040007010101 Content-Type: text/plain; name="rain.oops.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rain.oops.txt" ksymoops 2.4.0 on i686 2.4.19-pre6aa1. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.19-pre6aa1 (default) May 16 03:37:33 xxxx kernel: kernel BUG at ll_rw_blk.c:926! May 16 03:37:33 xxxx kernel: invalid operand: 0000 May 16 03:37:33 xxxx kernel: CPU: 0 May 16 03:37:33 xxxx kernel: EIP: 0010:[__make_request+127/1668] Not tainted May 16 03:37:33 xxxx kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 May 16 03:37:33 xxxx kernel: EFLAGS: 00010246 May 16 03:37:33 xxxx kernel: eax: 00000008 ebx: 00000841 ecx: 00000200 edx: 00000004 May 16 03:37:33 xxxx kernel: esi: 00000001 edi: e35e6f80 ebp: 00000008 esp: d9b33c60 May 16 03:37:33 xxxx kernel: ds: 0018 es: 0018 ss: 0018 May 16 03:37:33 xxxx kernel: Process procmail (pid: 23564, stackpage=d9b33000) May 16 03:37:33 xxxx kernel: Stack: 00000841 e35e6f80 c040d4a0 00000000 d9b33cb4 c8771170 00000200 c7708a40 May 16 03:37:33 xxxx kernel: 00000003 d9b33cd0 08410000 00000000 00000000 002007d0 00000001 c0232f00 May 16 03:37:33 xxxx kernel: c7708a18 00000001 e35e6f80 00000008 00000001 00000002 00000200 c0232fd0 May 16 03:37:33 xxxx kernel: Call Trace: [generic_make_request+164/292] [submit_bh+80/108] [ll_rw_block+339/464] [write_buffer+68/80] [fsync_inode_buffers+158/348] May 16 03:37:33 xxxx kernel: Call Trace: [] [] [] [] [] May 16 03:37:33 xxxx kernel: [] [] [] [] [] [] May 16 03:37:33 xxxx kernel: [] [] [] [] [] [] May 16 03:37:33 xxxx kernel: [] [] [] [] [] [] May 16 03:37:33 xxxx kernel: [] [] [] May 16 03:37:33 xxxx kernel: Code: 0f 0b 9e 03 82 81 31 c0 a1 d0 b3 3f c0 8b 4f 38 29 c1 89 c8 >>EIP; c0232857 <__make_request+7f/684> <===== Trace; c0232f00 Trace; c0232fd0 Trace; c02331cb Trace; c013d684 Trace; c013e3b2 Trace; c01f25a7 Trace; c01f6720 Trace; c01e94be Trace; c013e918 <__refile_buffer+54/5c> Trace; c0206ea3 Trace; c020722e <__pb_block_commit_write_async+2e/4c> Trace; c02060b2 Trace; c02060e9 Trace; c0207966 Trace; c0207998 Trace; c01f7172 Trace; c01f7172 Trace; c01e230b Trace; c0200c14 Trace; c020d004 Trace; c020611b Trace; c0208e51 Trace; c01fc1fd Trace; c02089f9 Trace; c013dcee Trace; c0108bab Code; c0232857 <__make_request+7f/684> 00000000 <_EIP>: Code; c0232857 <__make_request+7f/684> <===== 0: 0f 0b ud2a <===== Code; c0232859 <__make_request+81/684> 2: 9e sahf Code; c023285a <__make_request+82/684> 3: 03 82 81 31 c0 a1 add 0xa1c03181(%edx),%eax Code; c0232860 <__make_request+88/684> 9: d0 (bad) Code; c0232861 <__make_request+89/684> a: b3 3f mov $0x3f,%bl Code; c0232863 <__make_request+8b/684> c: c0 8b 4f 38 29 c1 89 rorb $0x89,0xc129384f(%ebx) Code; c023286a <__make_request+92/684> 13: c8 00 00 00 enter $0x0,$0x0 May 16 03:38:02 xxxx kernel: kernel BUG at ll_rw_blk.c:926! May 16 03:38:02 xxxx kernel: invalid operand: 0000 May 16 03:38:02 xxxx kernel: CPU: 4 May 16 03:38:02 xxxx kernel: EIP: 0010:[__make_request+127/1668] Not tainted May 16 03:38:02 xxxx kernel: EIP: 0010:[] Not tainted May 16 03:38:02 xxxx kernel: EFLAGS: 00010246 May 16 03:38:02 xxxx kernel: eax: 00000008 ebx: 00000841 ecx: 00000200 edx: 00000004 May 16 03:38:02 xxxx kernel: esi: 00000001 edi: dbc78120 ebp: 00000008 esp: c77e5ea8 May 16 03:38:02 xxxx kernel: ds: 0018 es: 0018 ss: 0018 May 16 03:38:02 xxxx kernel: Process kupdated (pid: 13, stackpage=c77e5000) May 16 03:38:02 xxxx kernel: Stack: 00000841 dbc78120 c040d4a0 00000000 084118f8 c8771170 00000200 c7708a40 May 16 03:38:02 xxxx kernel: c83df480 c7708a38 08410400 00000000 00000000 002007d0 00000001 c0232f00 May 16 03:38:02 xxxx kernel: c7708a18 00000001 dbc78120 00000008 00000001 c77e5f50 ef6c84e0 c0232fd0 May 16 03:38:02 xxxx kernel: Call Trace: [generic_make_request+164/292] [submit_bh+80/108] [write_locked_buffers+32/44] [write_some_buffers+128/328] [sync_old_buffers+92/148] May 16 03:38:02 xxxx kernel: Call Trace: [] [] [] [] [] May 16 03:38:02 xxxx kernel: [] [] [] [] May 16 03:38:02 xxxx kernel: Code: 0f 0b 9e 03 82 81 31 c0 a1 d0 b3 3f c0 8b 4f 38 29 c1 89 c8 >>EIP; c0232857 <__make_request+7f/684> <===== Trace; c0232f00 Trace; c0232fd0 Trace; c013d7b4 Trace; c013d840 Trace; c0140eac Trace; c01411a5 Trace; c0105000 <_stext+0/0> Trace; c01072b6 Trace; c01072bf Code; c0232857 <__make_request+7f/684> 00000000 <_EIP>: Code; c0232857 <__make_request+7f/684> <===== 0: 0f 0b ud2a <===== Code; c0232859 <__make_request+81/684> 2: 9e sahf Code; c023285a <__make_request+82/684> 3: 03 82 81 31 c0 a1 add 0xa1c03181(%edx),%eax Code; c0232860 <__make_request+88/684> 9: d0 (bad) Code; c0232861 <__make_request+89/684> a: b3 3f mov $0x3f,%bl Code; c0232863 <__make_request+8b/684> c: c0 8b 4f 38 29 c1 89 rorb $0x89,0xc129384f(%ebx) Code; c023286a <__make_request+92/684> 13: c8 00 00 00 enter $0x0,$0x0 --------------090309050402040007010101-- From owner-linux-xfs@oss.sgi.com Thu May 16 07:29:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GETrnC024237 for ; Thu, 16 May 2002 07:29:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GETrT8024236 for linux-xfs-outgoing; Thu, 16 May 2002 07:29:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GETnnC024210 for ; Thu, 16 May 2002 07:29:49 -0700 Received: from test2 (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with SMTP id 16736B66B for ; Thu, 16 May 2002 07:30:13 -0700 (PDT) From: "Tang Lingbo (Allan)" To: "Linux-Xfs" Subject: XFS-1.1+DEBUG+dbench = panic Date: Thu, 16 May 2002 22:30:40 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g4GETnnC024211 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, If I run dbench 50 after enabling the 'CONFIG_XFS_DEBUG' and 'CONFIG_XFS_VNODE_TRACING' in XFS-1.1, the system will report Kernel panic. ( patched kdb) The partition is a new one and no other operations and this panic can be reproduced. But if disable these flags, panic seems disappeared. Is there any issues in debug routines? Allan From owner-linux-xfs@oss.sgi.com Thu May 16 07:42:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GEgsnC025938 for ; Thu, 16 May 2002 07:42:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GEgseN025937 for linux-xfs-outgoing; Thu, 16 May 2002 07:42:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GEgnnC025909 for ; Thu, 16 May 2002 07:42:50 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA30699; Thu, 16 May 2002 09:43:15 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA37935; Thu, 16 May 2002 09:41:59 -0500 (CDT) Subject: Re: XFS-1.1+DEBUG+dbench = panic From: Eric Sandeen To: "Tang Lingbo (Allan)" Cc: Linux-Xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 May 2002 09:41:59 -0500 Message-Id: <1021560119.30538.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Allan - What compiler did you use? I had DEBUG panics with Red Hat's 2.96-98 and 2.96-101, but 2.96-107 worked. kgcc, as always, also worked. Oh, and out of curiosity.... did it say DA READ ERROR? That's what I hit. -Eric On Thu, 2002-05-16 at 09:30, Tang Lingbo (Allan) wrote: > Hi, > > If I run dbench 50 after enabling the 'CONFIG_XFS_DEBUG' and > 'CONFIG_XFS_VNODE_TRACING' in XFS-1.1, the system will report > Kernel panic. ( patched kdb) The partition is a new one and no other > operations and this panic can be reproduced. > > But if disable these flags, panic seems disappeared. > Is there any issues in debug routines? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu May 16 08:17:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFHunC026520 for ; Thu, 16 May 2002 08:17:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFHuOX026519 for linux-xfs-outgoing; Thu, 16 May 2002 08:17:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFHmnC026493 for ; Thu, 16 May 2002 08:17:50 -0700 Received: from black.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id RAA04925; Thu, 16 May 2002 17:40:11 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by black.random (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g4GFLiZ27755; Thu, 16 May 2002 17:21:44 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g4GFI094010454; Thu, 16 May 2002 17:18:00 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g4GFHsQ4010451; Thu, 16 May 2002 17:17:54 +0200 X-Authentication-Warning: dualathlon.random: andrea set sender to andrea@suse.de using -f Date: Thu, 16 May 2002 17:17:54 +0200 From: Andrea Arcangeli To: Jim Eshleman Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre6aa1 oops Message-ID: <20020516151754.GJ1025@dualathlon.random> References: <3CE3B927.30806@Lehigh.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE3B927.30806@Lehigh.EDU> User-Agent: Mutt/1.3.27i X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 09:50:31AM -0400, Jim Eshleman wrote: > After two weeks of uneventful uptime with -pre6aa1 the system hung > with no symptoms, no messages, no way in. XFS filesystems recovered > themselves on reboot with no apparent problems. About twelve hours > later got the appended oops, in the early AM. I suspect it may have > been triggered by the system backup, which is now stuck in D state. > Otherwise the system is running normally except loadavg is high (6-7) > even though there is little CPU and IO usage. I would suggest a full forced fsck and an upgrade to 2.4.19pre8aa3 that includes the xfs 1.1 release (it fixes various xfs issues compared to 2.4.19pre6aa1). Personally I mostly care about the glue between xfs and mainline kernel, so for specific xfs bugs you were right to CC the xfs mailing list. Andrea From owner-linux-xfs@oss.sgi.com Thu May 16 08:29:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFTLnC026838 for ; Thu, 16 May 2002 08:29:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFTLso026837 for linux-xfs-outgoing; Thu, 16 May 2002 08:29:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFTFnC026809 for ; Thu, 16 May 2002 08:29:15 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA39430; Thu, 16 May 2002 10:29:41 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-38.corp.sgi.com [134.15.64.38]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA78837; Thu, 16 May 2002 10:28:24 -0500 (CDT) Subject: Re: 2.4.19-pre6aa1 oops From: Stephen Lord To: Andrea Arcangeli Cc: Jim Eshleman , linux-xfs@oss.sgi.com In-Reply-To: <20020516151754.GJ1025@dualathlon.random> References: <3CE3B927.30806@Lehigh.EDU> <20020516151754.GJ1025@dualathlon.random> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 May 2002 10:26:46 -0500 Message-Id: <1021562808.1175.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-16 at 10:17, Andrea Arcangeli wrote: > On Thu, May 16, 2002 at 09:50:31AM -0400, Jim Eshleman wrote: > > After two weeks of uneventful uptime with -pre6aa1 the system hung > > with no symptoms, no messages, no way in. XFS filesystems recovered > > themselves on reboot with no apparent problems. About twelve hours > > later got the appended oops, in the early AM. I suspect it may have > > been triggered by the system backup, which is now stuck in D state. > > Otherwise the system is running normally except loadavg is high (6-7) > > even though there is little CPU and IO usage. > > I would suggest a full forced fsck and an upgrade to 2.4.19pre8aa3 that > includes the xfs 1.1 release (it fixes various xfs issues compared to > 2.4.19pre6aa1). Personally I mostly care about the glue between xfs and > mainline kernel, so for specific xfs bugs you were right to CC the xfs > mailing list. > > Andrea Well with xfs there is no fsck, but there is xfs_repair which is the equivalent. You can also run xfs_check which will not fix a filesystem but runs an extensive set of checks on its consistency. Andrea the interfaces between xfs and the kernel are about to change, we will no longer require code in vmscan.c and the code in buffer.c gets simpler. I was not aware that the xfs code in the aa kernels still predated 1.1, in that case upgrading is definitely a good idea. Steve From owner-linux-xfs@oss.sgi.com Thu May 16 08:30:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFUenC026959 for ; Thu, 16 May 2002 08:30:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFUekh026958 for linux-xfs-outgoing; Thu, 16 May 2002 08:30:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFUZnC026918 for ; Thu, 16 May 2002 08:30:35 -0700 Received: (qmail 11953 invoked by uid 1000); 16 May 2002 15:29:51 -0000 To: Eric Sandeen Cc: "Jonathan F. Dill" , Stefan Smietanowski , Mike Burger , Linux XFS Mailing List Subject: Re: "badblocks" for XFS? References: <3CDFB2A0.9020700@stesmi.com> <1021296035.1577.9.camel@localhost.localdomain> <1021311815.3935.206.camel@stout.americas.sgi.com> From: Florian Weimer Date: Thu, 16 May 2002 17:29:51 +0200 In-Reply-To: <1021311815.3935.206.camel@stout.americas.sgi.com> (Eric Sandeen's message of "13 May 2002 12:43:34 -0500") Message-ID: <878z6kkt5c.fsf@CERT.Uni-Stuttgart.DE> Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen writes: > As I understand it, all modern drives do defect management internally, > remapping data blocks as they go bad. If you're actually seeing a bad > block from the outside, that probably means that the drive has run out > of blocks to remap to, and it's all downhill from there. There is one case in which you'll see actual bad blocks with (some) modern drivers: if a sector has not been fully written during power down. The sector carries bad check sums, and you get hard errors when trying to read it. However, writing to the block should correct the checksum and remove the bad block. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Thu May 16 08:33:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFXrnC027186 for ; Thu, 16 May 2002 08:33:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFXruq027185 for linux-xfs-outgoing; Thu, 16 May 2002 08:33:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFXhnC027157 for ; Thu, 16 May 2002 08:33:45 -0700 Received: from black.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id RAA05359; Thu, 16 May 2002 17:56:10 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by black.random (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g4GFbsZ27771; Thu, 16 May 2002 17:37:54 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g4GFYA94011248; Thu, 16 May 2002 17:34:10 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g4GFYAJB011247; Thu, 16 May 2002 17:34:10 +0200 X-Authentication-Warning: dualathlon.random: andrea set sender to andrea@suse.de using -f Date: Thu, 16 May 2002 17:34:10 +0200 From: Andrea Arcangeli To: Stephen Lord Cc: Jim Eshleman , linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre6aa1 oops Message-ID: <20020516153410.GL1025@dualathlon.random> References: <3CE3B927.30806@Lehigh.EDU> <20020516151754.GJ1025@dualathlon.random> <1021562808.1175.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021562808.1175.6.camel@localhost.localdomain> User-Agent: Mutt/1.3.27i X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 10:26:46AM -0500, Stephen Lord wrote: > On Thu, 2002-05-16 at 10:17, Andrea Arcangeli wrote: > > On Thu, May 16, 2002 at 09:50:31AM -0400, Jim Eshleman wrote: > > > After two weeks of uneventful uptime with -pre6aa1 the system hung > > > with no symptoms, no messages, no way in. XFS filesystems recovered > > > themselves on reboot with no apparent problems. About twelve hours > > > later got the appended oops, in the early AM. I suspect it may have > > > been triggered by the system backup, which is now stuck in D state. > > > Otherwise the system is running normally except loadavg is high (6-7) > > > even though there is little CPU and IO usage. > > > > I would suggest a full forced fsck and an upgrade to 2.4.19pre8aa3 that > > includes the xfs 1.1 release (it fixes various xfs issues compared to > > 2.4.19pre6aa1). Personally I mostly care about the glue between xfs and > > mainline kernel, so for specific xfs bugs you were right to CC the xfs > > mailing list. > > > > Andrea > > Well with xfs there is no fsck, but there is xfs_repair which is > the equivalent. You can also run xfs_check which will not fix a > filesystem but runs an extensive set of checks on its consistency. Yep. > > Andrea the interfaces between xfs and the kernel are about to change, > we will no longer require code in vmscan.c and the code in buffer.c > gets simpler. > > I was not aware that the xfs code in the aa kernels still > predated 1.1, in that case upgrading is definitely a good idea. the reason is that at the time 2.4.19pre6aa1 was released xfs 1.1 wasn't yet released. Andrea From owner-linux-xfs@oss.sgi.com Thu May 16 08:45:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFjFnC027518 for ; Thu, 16 May 2002 08:45:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFjFh5027517 for linux-xfs-outgoing; Thu, 16 May 2002 08:45:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFj8nC027491 for ; Thu, 16 May 2002 08:45:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA39981; Thu, 16 May 2002 10:45:34 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA05443; Thu, 16 May 2002 10:44:17 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA20254; Thu, 16 May 2002 10:44:17 -0500 (CDT) Message-ID: <3CE3D3CF.7DBAF8A9@sgi.com> Date: Thu, 16 May 2002 10:44:16 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> <3CE1835A.89040F77@sgi.com> <20020515034808.GA349@widomaker.com> <3CE2E408.1578669D@sgi.com> <20020516020938.GB10343@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles Shannon Hendrix wrote: > On Wed, May 15, 2002 at 05:41:12PM -0500, John Kihonge wrote: > > > > Charles, > > > > I am unable to reproduce this issue in our lab here since we dont have > > Slackware 8.0 on any of the test machines. I used xfsdump/xfsrestore on Red > > Hat 7.2 with 2.4.18-xfs kernel and glibc version 2.2.4 and it works. > > You can install it in about 30 minutes... and in any case, it's not > likely related to Slackware since another user had the same trouble in > February. I think he was using Red Hat, but I don't remember. I saw the emails from February and it was a problem with SuSe. I need to do more investigation to see if I can determine why this is happening. > > > Would you upgrade glibc to version 2.2.4 and see if that would work? > > That's non-trivial. Do you have any reason for me to do this? I mean, is > there something about 2.2.3 that you suspect? > I know Red Hat 7.2 with glibc 2.2.4 is working since that is what I used to do test ,but I havent done any tests with glibc 2.2.3. By upgrading, we would determine if the library is causing the error. > > > I'll have to see what is involved in the upgrade. Slackware is close to > another release which might use that version or later. ---- Kihonge JN From owner-linux-xfs@oss.sgi.com Thu May 16 08:59:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFx5nC000942 for ; Thu, 16 May 2002 08:59:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFx5RD000941 for linux-xfs-outgoing; Thu, 16 May 2002 08:59:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFwwnC000914 for ; Thu, 16 May 2002 08:58:58 -0700 Received: from test2 (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with SMTP id 15838B66B; Thu, 16 May 2002 08:59:25 -0700 (PDT) From: "Tang Lingbo (Allan)" To: "Eric Sandeen" Cc: "Linux-Xfs" Subject: RE: XFS-1.1+DEBUG+dbench = panic Date: Thu, 16 May 2002 23:59:51 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <1021560119.30538.10.camel@stout.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g4GFwxnC000915 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, the system seems good after compiled by kgcc. And the previous error is what you have hit. Allan > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On > Behalf Of Eric Sandeen > Sent: Thursday, May 16, 2002 10:42 PM > To: Tang Lingbo (Allan) > Cc: Linux-Xfs > Subject: Re: XFS-1.1+DEBUG+dbench = panic > > > hi Allan - > > What compiler did you use? I had DEBUG panics with Red Hat's 2.96-98 > and 2.96-101, but 2.96-107 worked. kgcc, as always, also worked. > > Oh, and out of curiosity.... did it say DA READ ERROR? That's what I > hit. > > -Eric > > On Thu, 2002-05-16 at 09:30, Tang Lingbo (Allan) wrote: > > > Hi, > > > > If I run dbench 50 after enabling the 'CONFIG_XFS_DEBUG' and > > 'CONFIG_XFS_VNODE_TRACING' in XFS-1.1, the system will report > > Kernel panic. ( patched kdb) The partition is a new one and no other > > operations and this panic can be reproduced. > > > > But if disable these flags, panic seems disappeared. > > Is there any issues in debug routines? > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Thu May 16 09:08:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GG8pnC003206 for ; Thu, 16 May 2002 09:08:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GG8paW003205 for linux-xfs-outgoing; Thu, 16 May 2002 09:08:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GG8cnC003179 for ; Thu, 16 May 2002 09:08:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA39124 for ; Thu, 16 May 2002 11:09:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA50780 for ; Thu, 16 May 2002 11:07:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4GG6ow24690; Thu, 16 May 2002 11:06:50 -0500 Message-Id: <200205161606.g4GG6ow24690@jen.americas.sgi.com> Date: Thu, 16 May 2002 11:06:50 -0500 Subject: TAKE - XFS multiple blocksize support To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This allows Linux XFS to support filesystem blocksizes of less than a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also switches more of the xfs I/O path to use the generic code used by other filesystems, the write path is still specific to XFS, but this too should change over time. It has had pretty extensive testing, and we have no known problems on 4K filesystems, I do have one failure in fsx on a 1K block filesystem which shows after a few hundred thousand interations. We will continue to work on that one. There is also a repair problem on small blocksizes. You should upgrade commands, but apart from some changes in repair there have been no changes there which are necessary for the small block support. Success, or otherwise, stories would be appreciated. I would keep this code off critical servers for a while, but I will be running it on my machines. Steve Date: Thu May 16 09:00:48 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119308a linux/mm/vmscan.c - 1.95 - Remove xfs changes to this file linux/mm/filemap.c - 1.108 - Remove a BUG check for delalloc which is no longer needed, clear PG_delalloc when unlocking a page. linux/kernel/ksyms.c - 1.126 - remove some exports no longer needed by xfs linux/include/linux/mm.h - 1.80 - define PageDelalloc differently linux/fs/buffer.c - 1.104 - Simplify delayed buffer handling, when flushing a delayed buffer, set the delalloc flag on the page. linux/fs/xfs/xfs_vnodeops.c - 1.525 - remove some vops linux/fs/xfs/xfs_iocore.c - 1.29 - Some inode size manipulation changes linux/fs/xfs/xfs_mount.c - 1.281 - Allow in filesystems with a blocksize of less than a page linux/fs/xfs/linux/xfs_lrw.h - 1.20 - remove prototypes for page VOPs, they are gone linux/fs/xfs/linux/xfs_lrw.c - 1.134 - Some fixups for multiple block size support, and always use the generic read path. linux/fs/xfs/linux/xfs_super.c - 1.168 - Set s_blocksize based on filesystem blocksize, not always 512 linux/fs/xfs/linux/xfs_iops.c - 1.138 - Move towards using the generic I/O path code more, add a getblock function to pass to the generic prepare write and direct I/O code. linux/fs/xfs/linux/xfs_ioctl.c - 1.59 - For direct I/O alignment, report the fs blocksize, not 512 bytes as the required alignment. linux/kdb/modules/kdbm_pg.c - 1.52 - fixup a few bugs linux/fs/xfs/linux/xfs_vnode.h - 1.30 - Remove some VOPs and fix VN_DIRTY test linux/fs/xfs/pagebuf/page_buf_io.c - 1.33 - major brain surgery, rework delalloc conversion for multiple blocksize case again. Remove remainder of read path, and basically make the write path use the generic code for buffered - a copy of it for now. linux/fs/xfs/pagebuf/page_buf.c - 1.21 - Fixes for metadata ops on blocksize less than a pagesize. linux/fs/xfs/pagebuf/page_buf.h - 1.11 - prototype removal for dead code linux/fs/xfs/pagebuf/page_buf_internal.h - 1.4 - remove unused defines From owner-linux-xfs@oss.sgi.com Thu May 16 10:25:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GHPpnC004435 for ; Thu, 16 May 2002 10:25:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GHPpWZ004434 for linux-xfs-outgoing; Thu, 16 May 2002 10:25:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GHPlnC004408 for ; Thu, 16 May 2002 10:25:47 -0700 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 10:31:12 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F15C@cdserv.meridian-data.com> From: "Stephenson, Dale" To: "'linux-xfs@oss.sgi.com'" Subject: Why does xfs_fs_thaw() call xfs_unmountfs_writesb()? Date: Thu, 16 May 2002 10:31:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The xfs_freeze command uses xfs_fs_freeze() to flush out and freeze new writes to a file system, and xfs_fs_thaw() to let writes through again. In between an xfs_freeze -f and xfs_freeze -u, the file system should be effectively frozen. The last thing xfs_fs_freeze() does before returning is call xfs_unmountfs_writesb(). The first thing xfs_fs_thaw() does call it again. Since all new writes between the two calls should be waiting for the filesystem to be thawed, why does xfs_unmountfs_writesb() need to be called again? What does xfs_unmountfs_writesb() accomplish in these two functions? Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Thu May 16 10:33:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GHXTnC004728 for ; Thu, 16 May 2002 10:33:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GHXTZd004727 for linux-xfs-outgoing; Thu, 16 May 2002 10:33:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GHXPnC004701 for ; Thu, 16 May 2002 10:33:25 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA43749; Thu, 16 May 2002 12:33:51 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-38.corp.sgi.com [134.15.64.38]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA90030; Thu, 16 May 2002 12:32:34 -0500 (CDT) Subject: Re: Why does xfs_fs_thaw() call xfs_unmountfs_writesb()? From: Stephen Lord To: "Stephenson, Dale" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F15C@cdserv.meridian-data.com> References: <2D0AFEFEE711D611923E009027D39F2B02F15C@cdserv.meridian-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 May 2002 12:30:51 -0500 Message-Id: <1021570253.1174.9.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-16 at 12:31, Stephenson, Dale wrote: > The xfs_freeze command uses xfs_fs_freeze() to flush out and freeze new > writes to a file system, and xfs_fs_thaw() to let writes through again. In > between an xfs_freeze -f and xfs_freeze -u, the file system should be > effectively frozen. > > The last thing xfs_fs_freeze() does before returning is call > xfs_unmountfs_writesb(). The first thing xfs_fs_thaw() does call it again. > Since all new writes between the two calls should be waiting for the > filesystem to be thawed, why does xfs_unmountfs_writesb() need to be called > again? What does xfs_unmountfs_writesb() accomplish in these two functions? > > Dale Stephenson > steph@snapserver.com The function ensures the on disk superblock is uptodate, since we just made the log clean. As for why both functions do it, good question, probably just overzealous coding - rather like typing sync sync sync before reboot. Steve From owner-linux-xfs@oss.sgi.com Thu May 16 10:41:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GHfTnC005099 for ; Thu, 16 May 2002 10:41:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GHfTmc005097 for linux-xfs-outgoing; Thu, 16 May 2002 10:41:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GHfMnC005070 for ; Thu, 16 May 2002 10:41:22 -0700 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g4GHfmcm031095 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 May 2002 13:41:48 -0400 Message-ID: <3CE3EF5C.9030101@Lehigh.EDU> Date: Thu, 16 May 2002 13:41:48 -0400 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: 2.4.19-pre6aa1 oops References: <3CE3B927.30806@Lehigh.EDU> <20020516151754.GJ1025@dualathlon.random> <1021562808.1175.6.camel@localhost.localdomain> <20020516153410.GL1025@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andrea Arcangeli wrote: > On Thu, May 16, 2002 at 10:26:46AM -0500, Stephen Lord wrote: > >>On Thu, 2002-05-16 at 10:17, Andrea Arcangeli wrote: >> >>>On Thu, May 16, 2002 at 09:50:31AM -0400, Jim Eshleman wrote: >>> >>>> After two weeks of uneventful uptime with -pre6aa1 the system hung >>>>with no symptoms, no messages, no way in. XFS filesystems recovered >>>>themselves on reboot with no apparent problems. About twelve hours >>>>later got the appended oops, in the early AM. I suspect it may have >>>>been triggered by the system backup, which is now stuck in D state. >>>>Otherwise the system is running normally except loadavg is high (6-7) >>>>even though there is little CPU and IO usage. >>> >>>I would suggest a full forced fsck and an upgrade to 2.4.19pre8aa3 that >>>includes the xfs 1.1 release (it fixes various xfs issues compared to >>>2.4.19pre6aa1). Personally I mostly care about the glue between xfs and >>>mainline kernel, so for specific xfs bugs you were right to CC the xfs >>>mailing list. >>> >>>Andrea >> >>Well with xfs there is no fsck, but there is xfs_repair which is >>the equivalent. You can also run xfs_check which will not fix a >>filesystem but runs an extensive set of checks on its consistency. > > > Yep. > > >>Andrea the interfaces between xfs and the kernel are about to change, >>we will no longer require code in vmscan.c and the code in buffer.c >>gets simpler. >> >>I was not aware that the xfs code in the aa kernels still >>predated 1.1, in that case upgrading is definitely a good idea. > > > the reason is that at the time 2.4.19pre6aa1 was released xfs 1.1 wasn't > yet released. > > Andrea Will do. Thank you Andrea and Steve. Jim From owner-linux-xfs@oss.sgi.com Thu May 16 10:57:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GHvLnC005334 for ; Thu, 16 May 2002 10:57:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GHvLGZ005333 for linux-xfs-outgoing; Thu, 16 May 2002 10:57:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.tvol.net ([66.150.46.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GHvDnC005306 for ; Thu, 16 May 2002 10:57:13 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2NJCS596; Thu, 16 May 2002 13:55:01 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4GHviH24525; Thu, 16 May 2002 13:57:44 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE3F318.1080500@wgate.com> Date: Thu, 16 May 2002 13:57:44 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens , Linux XFS List Subject: Re: Strange behavior on the 2.4.18 XFS tree? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Sinz wrote: > Keith Owens wrote: > >> On Wed, 15 May 2002 07:30:09 -0400, Michael Sinz wrote: >> >>> I have only been able to see this behavior on my system running the >>> kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. >>> >>> The problem is that I started up a number of "rxvt" sessions and they >>> took well over a minute to start up. During that time, the cpu >>> utilization was almost nil. (Less than 1%) >>> >>> There was a background find operation happening, and this seems to be >>> the key item. >> >> When the problem occurs, does typing sync get everything running again? >> I have been seeing an intermittent lock problem with XFS where >> everything stops until some other disk activity kicks in and the lock >> is released. > > I will try that next time it happens. Well, given the "transient" nature of the problem, I can not be sure it really "fixed" it but doing the sync did look like it helped - alot. I could not even do an "ls -l" of a directory during the "stall" period. My already running system monitors (one of which is xosview) showed no CPU usage (well, almost none) and almost no disk I/O (mostly 0) All of memory was used - something on the order of: (but not exactly as this was run after the system unblocked) total used free shared buffers cached Mem: 577396 567464 9932 0 0 233460 -/+ buffers/cache: 334004 243392 Swap: 2048276 1964 2046312 (Yes, mozilla was running and so was the find in the background) The find (or other major filesystem traversal) is what helps trigger this condition. Where is the system hung if there is no disk I/O and no CPU used (unless the CPU usage is not being accounted for?) BTW - once I did sync things worked as expected (ls ran quickly, etc) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Thu May 16 11:33:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GIXbnC005954 for ; Thu, 16 May 2002 11:33:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GIXbFI005953 for linux-xfs-outgoing; Thu, 16 May 2002 11:33:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GIXUnC005925 for ; Thu, 16 May 2002 11:33:31 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 178Q4d-0002id-00; Thu, 16 May 2002 19:33:59 +0100 Date: Thu, 16 May 2002 19:33:59 +0100 From: Christoph Hellwig To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - XFS multiple blocksize support Message-ID: <20020516193359.A10137@infradead.org> References: <200205161606.g4GG6ow24690@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205161606.g4GG6ow24690@jen.americas.sgi.com>; from lord@sgi.com on Thu, May 16, 2002 at 11:06:50AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 11:06:50AM -0500, Steve Lord wrote: > This allows Linux XFS to support filesystem blocksizes of less than > a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also > switches more of the xfs I/O path to use the generic code used by > other filesystems, the write path is still specific to XFS, but this > too should change over time. > > It has had pretty extensive testing, and we have no known problems > on 4K filesystems, I do have one failure in fsx on a 1K block filesystem > which shows after a few hundred thousand interations. We will continue > to work on that one. > > There is also a repair problem on small blocksizes. You should upgrade > commands, but apart from some changes in repair there have been no changes > there which are necessary for the small block support. So far I just had a short look over the diffs and the changes look really nice. It's good to see the VM intrusions (mostly) gone and the VOPs now removed also looked very strange for someone having done on vnode based filesystems (just SVR4, not IRIX) :) Two nitpicks I found: - traversing inode->i_dirty_buffers and inode->i_dirty_data_buffers needs the lru_list_lock, thus both the old and the new version are (at least in theory) racy, maybe just use inode_has_buffers() instead? - a ClearPageDelalloc macro is missing and PG_delalloc is directly cleared in filemap.c. Yes, I see the excuse that Andrea did the same mistake with PG_launder but he already fixed that in his tree. As a I plan to merge that over before 2.4.19 maybe you could fix PG_delalloc also in that merge. Will take a closer look at the changes now. Christoph From owner-linux-xfs@oss.sgi.com Thu May 16 11:48:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GImunC006297 for ; Thu, 16 May 2002 11:48:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GImukD006296 for linux-xfs-outgoing; Thu, 16 May 2002 11:48:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GImlnC006269 for ; Thu, 16 May 2002 11:48:47 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA48864; Thu, 16 May 2002 13:49:13 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-38.corp.sgi.com [134.15.64.38]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA95773; Thu, 16 May 2002 13:47:56 -0500 (CDT) Subject: Re: TAKE - XFS multiple blocksize support From: Stephen Lord To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020516193359.A10137@infradead.org> References: <200205161606.g4GG6ow24690@jen.americas.sgi.com> <20020516193359.A10137@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 May 2002 13:46:13 -0500 Message-Id: <1021574774.1300.25.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-16 at 13:33, Christoph Hellwig wrote: > On Thu, May 16, 2002 at 11:06:50AM -0500, Steve Lord wrote: > > This allows Linux XFS to support filesystem blocksizes of less than > > a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also > > switches more of the xfs I/O path to use the generic code used by > > other filesystems, the write path is still specific to XFS, but this > > too should change over time. > > > > It has had pretty extensive testing, and we have no known problems > > on 4K filesystems, I do have one failure in fsx on a 1K block filesystem > > which shows after a few hundred thousand interations. We will continue > > to work on that one. > > > > There is also a repair problem on small blocksizes. You should upgrade > > commands, but apart from some changes in repair there have been no changes > > there which are necessary for the small block support. > > So far I just had a short look over the diffs and the changes look really > nice. It's good to see the VM intrusions (mostly) gone and the VOPs now > removed also looked very strange for someone having done on vnode based > filesystems (just SVR4, not IRIX) :) > > Two nitpicks I found: > > - traversing inode->i_dirty_buffers and inode->i_dirty_data_buffers needs > the lru_list_lock, thus both the old and the new version are (at least > in theory) racy, maybe just use inode_has_buffers() instead? It is not exported right now, so I would have to add that, this is VN_DIRTY you are talking about right? Both the places we use that may be dead meat anyway, we should have true inode dirty management now as a side effect of this change. I have not really investigated that part of things yet. > - a ClearPageDelalloc macro is missing and PG_delalloc is directly cleared > in filemap.c. Yes, I see the excuse that Andrea did the same mistake > with PG_launder but he already fixed that in his tree. As a I plan to > merge that over before 2.4.19 maybe you could fix PG_delalloc also in > that merge. Done. > > Will take a closer look at the changes now. If you can find the place where we do not zero part of a page when writing into a hole in the file in the block size < pagesize case that would be great! fsx_linux runs a few hundred thousand ops before it finds that. I have been staring at the code too hard for too long to see it right now. > > Christoph Steve From owner-linux-xfs@oss.sgi.com Thu May 16 11:52:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GIqdnC006513 for ; Thu, 16 May 2002 11:52:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GIqdeS006512 for linux-xfs-outgoing; Thu, 16 May 2002 11:52:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GIqZnC006484 for ; Thu, 16 May 2002 11:52:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA47020 for ; Thu, 16 May 2002 13:53:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA64474 for ; Thu, 16 May 2002 13:51:45 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4GIolh01743; Thu, 16 May 2002 13:50:47 -0500 Message-Id: <200205161850.g4GIolh01743@jen.americas.sgi.com> Date: Thu, 16 May 2002 13:50:47 -0500 Subject: TAKE - cleanup PG_delalloc handling To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Small tweak to the multiple blocksize stuff. Date: Thu May 16 11:50:49 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-noirq The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119337a linux/mm/filemap.c - 1.109 - Use macro to clear PG_delalloc rather than doing it directly linux/include/linux/mm.h - 1.81 - Add macro to clear PG_delalloc From owner-linux-xfs@oss.sgi.com Thu May 16 12:18:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GJIWnC007040 for ; Thu, 16 May 2002 12:18:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GJIWHL007039 for linux-xfs-outgoing; Thu, 16 May 2002 12:18:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GJIPnC007012 for ; Thu, 16 May 2002 12:18:26 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 178Qlv-0003RR-00; Thu, 16 May 2002 20:18:43 +0100 Date: Thu, 16 May 2002 20:18:43 +0100 From: Christoph Hellwig To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - XFS multiple blocksize support Message-ID: <20020516201843.A13086@infradead.org> References: <200205161606.g4GG6ow24690@jen.americas.sgi.com> <20020516193359.A10137@infradead.org> <1021574774.1300.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1021574774.1300.25.camel@localhost.localdomain>; from lord@sgi.com on Thu, May 16, 2002 at 01:46:13PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 01:46:13PM -0500, Stephen Lord wrote: > > - traversing inode->i_dirty_buffers and inode->i_dirty_data_buffers needs > > the lru_list_lock, thus both the old and the new version are (at least > > in theory) racy, maybe just use inode_has_buffers() instead? > > It is not exported right now, so I would have to add that, this is > VN_DIRTY you are talking about right? Umm, yes. (should have mentioned that..) > Both the places we use that > may be dead meat anyway, we should have true inode dirty management > now as a side effect of this change. I have not really investigated > that part of things yet. Okay. > If you can find the place where we do not zero part of a page when > writing into a hole in the file in the block size < pagesize case > that would be great! fsx_linux runs a few hundred thousand ops > before it finds that. I have been staring at the code too hard > for too long to see it right now. I can take a look, but of course I can't promise anything :) From owner-linux-xfs@oss.sgi.com Thu May 16 12:19:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GJJSnC007156 for ; Thu, 16 May 2002 12:19:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GJJRDI007152 for linux-xfs-outgoing; Thu, 16 May 2002 12:19:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GJJKnC007123 for ; Thu, 16 May 2002 12:19:20 -0700 Received: from nodin.corp.sgi.com ([198.29.75.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05198 for ; Thu, 16 May 2002 12:19:41 -0700 (PDT) mail_from (florin@sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4GJIkPF6622709 for ; Thu, 16 May 2002 12:18:46 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA6006079 for ; Thu, 16 May 2002 12:18:45 -0700 (PDT) mail_from (florin@sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4GJHjPF6551493 for ; Thu, 16 May 2002 12:17:45 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA5693345 for ; Thu, 16 May 2002 12:17:44 -0700 (PDT) mail_from (florin@sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4GJGiPF6622886 for ; Thu, 16 May 2002 12:16:44 -0700 (PDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA5712081 for ; Thu, 16 May 2002 12:16:44 -0700 (PDT) mail_from (florin@sgi.com) Received: from deliverator.sgi.com (deliverator.sgi.com [192.26.71.45]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4GJFhPF6619066 for ; Thu, 16 May 2002 12:15:43 -0700 (PDT) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA5940812 for ; Thu, 16 May 2002 12:15:43 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA42200 for ; Thu, 16 May 2002 12:15:12 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id A44D213641F for ; Thu, 16 May 2002 12:15:12 -0700 (PDT) Subject: Re: Status on RH7.3 installer ? From: Florin Andrei To: linux-xfs In-Reply-To: <3CE18B3F.1060605@emergence.com> References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 16 May 2002 12:15:12 -0700 Message-Id: <1021576512.21567.25.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael, Can you put the results of your work online? I think i'll try to play a little bit with the booting disc image. I did some customised Red Hat installers in the past, so i think there should be no problem now. On Tue, 2002-05-14 at 15:10, Michael Best wrote: > Perhaps someone knows how to do the step that I stopped on, which was to > generate a disk/disc image for booting from the cdrom. The default > Redhat installer uses a 2.8M installer image in the dosutils/autoboot > directory of the cd: > > 2.8M cdboot.img > 1.9M initrd.img > > Which appears to be a 2.8M boot image which contains: > > 784k of vmlinuz (kernel) and > 1.9M of initrd.img plus > various bootup files. > > I need to make one of these and then I can probably make a cd that boots > with a different kernel. By simply using mkinitrd it makes a minimalist > initrd image. > > I already did these other steps too: > > *) Added the xfs utilities to RedHat/base/stage2.img > *) Added the xfs utility rpms to Redhat/RPMS on disc1 and disc2 > *) modified RedHat/base/comps to include xfs util rpms > *) updated hdlist/hdlist2 in Redhat/base/ using genhdlist from the > anaconda 7.3 source > *) learned about embedding the MD5 into the implantisomd5 and > checkisomd5 from the anaconda 7.3 source > *) examined the anaconda source code for claimed xfs support > (it appears to append XFS to the list of available filesystems > if that filesystem choice is available, more work here is needed) > > -Mike > -- Florin Andrei As many as three times a week, on average, XP users see a little window pop-up at the bottom of their computer screens announcing the availability of another new update for their system. This plethora of patches has left many users wondering whether their hard drives are big enough to handle "Trustworthy Computing." From owner-linux-xfs@oss.sgi.com Thu May 16 12:43:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GJhanC007776 for ; Thu, 16 May 2002 12:43:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GJhaok007774 for linux-xfs-outgoing; Thu, 16 May 2002 12:43:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-154-216.client.attbi.com [12.234.154.216]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GJhRnC007748 for ; Thu, 16 May 2002 12:43:27 -0700 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by weiqi.home.local (Postfix) with SMTP id AF735309B3 for ; Thu, 16 May 2002 12:43:59 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 6BB6D3094D for ; Thu, 16 May 2002 12:43:59 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 00A4013641F for ; Thu, 16 May 2002 12:43:48 -0700 (PDT) Subject: Re: Status on RH7.3 installer ? From: Florin Andrei To: linux-xfs In-Reply-To: <3CE18B3F.1060605@emergence.com> References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 16 May 2002 12:43:48 -0700 Message-Id: <1021578229.23062.41.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael, Can you put the results of your work online? I think i'll try to play a little bit with the booting disc image. I did some customised Red Hat installers in the past, so i think there should be no problem now. I really want to get the damn installer working... :-) On Tue, 2002-05-14 at 15:10, Michael Best wrote: > Perhaps someone knows how to do the step that I stopped on, which was to > generate a disk/disc image for booting from the cdrom. The default > Redhat installer uses a 2.8M installer image in the dosutils/autoboot > directory of the cd: > > 2.8M cdboot.img > 1.9M initrd.img > > Which appears to be a 2.8M boot image which contains: > > 784k of vmlinuz (kernel) and > 1.9M of initrd.img plus > various bootup files. > > I need to make one of these and then I can probably make a cd that boots > with a different kernel. By simply using mkinitrd it makes a minimalist > initrd image. > > I already did these other steps too: > > *) Added the xfs utilities to RedHat/base/stage2.img > *) Added the xfs utility rpms to Redhat/RPMS on disc1 and disc2 > *) modified RedHat/base/comps to include xfs util rpms > *) updated hdlist/hdlist2 in Redhat/base/ using genhdlist from the > anaconda 7.3 source > *) learned about embedding the MD5 into the implantisomd5 and > checkisomd5 from the anaconda 7.3 source > *) examined the anaconda source code for claimed xfs support > (it appears to append XFS to the list of available filesystems > if that filesystem choice is available, more work here is needed) > > -Mike > -- Florin Andrei As many as three times a week, on average, XP users see a little window pop-up at the bottom of their computer screens announcing the availability of another new update for their system. This plethora of patches has left many users wondering whether their hard drives are big enough to handle "Trustworthy Computing." From owner-linux-xfs@oss.sgi.com Thu May 16 12:50:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GJo1nC007963 for ; Thu, 16 May 2002 12:50:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GJo1vm007962 for linux-xfs-outgoing; Thu, 16 May 2002 12:50:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GJnrnC007931 for ; Thu, 16 May 2002 12:49:54 -0700 Received: from fwd06.sul.t-online.de by mailout07.sul.t-online.com with smtp id 178RGX-0003VX-06; Thu, 16 May 2002 21:50:21 +0200 Received: from tower (340024412816-0001@[80.145.79.122]) by fwd06.sul.t-online.com with esmtp id 178RGP-1nAhuaC; Thu, 16 May 2002 21:50:13 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) Reply-To: hasch@t-online.de To: John Kihonge , Charles Shannon Hendrix Subject: Re: xfsrestore problems Date: Thu, 16 May 2002 21:51:07 +0200 X-Mailer: KMail [version 1.4] Cc: linux-xfs@oss.sgi.com References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> In-Reply-To: <3CE3D3CF.7DBAF8A9@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205162151.07376.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Donnerstag, 16. Mai 2002 17:44 schrieb John Kihonge: > Charles Shannon Hendrix wrote: > > On Wed, May 15, 2002 at 05:41:12PM -0500, John Kihonge wrote: > > > Charles, > > > > > > I am unable to reproduce this issue in our lab here since we dont have > > > Slackware 8.0 on any of the test machines. I used xfsdump/xfsrestore on > > > Red Hat 7.2 with 2.4.18-xfs kernel and glibc version 2.2.4 and it > > > works. > > > > You can install it in about 30 minutes... and in any case, it's not > > likely related to Slackware since another user had the same trouble in > > February. I think he was using Red Hat, but I don't remember. > > I saw the emails from February and it was a problem with SuSe. I need to > do more investigation to see if I can determine why this is happening. This was me :-) I still have the tapes from February which exhibit the problem. I can retest, if you have an idea where to look. > > > Would you upgrade glibc to version 2.2.4 and see if that would work? > > > > That's non-trivial. Do you have any reason for me to do this? I mean, is > > there something about 2.2.3 that you suspect? > > I know Red Hat 7.2 with glibc 2.2.4 is working since that is what I used to > do test ,but I havent done any tests with glibc 2.2.3. By upgrading, we > would determine if the library is causing the error. > > > I'll have to see what is involved in the upgrade. Slackware is close to > > another release which might use that version or later. I really don't understand how a minor glibc library update can cause such problems. All other binaries were identical (kernel, modules, xfs libraries). ...Juergen From owner-linux-xfs@oss.sgi.com Thu May 16 13:28:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GKSUnC008745 for ; Thu, 16 May 2002 13:28:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GKSUoC008744 for linux-xfs-outgoing; Thu, 16 May 2002 13:28:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf03bis.bellsouth.net (mail203.mail.bellsouth.net [205.152.58.143]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GKSNnC008718 for ; Thu, 16 May 2002 13:28:23 -0700 Received: from taz ([66.156.2.161]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> for ; Thu, 16 May 2002 16:30:17 -0400 Date: Thu, 16 May 2002 16:24:01 -0400 From: Greg Freemyer Subject: xfsdump sample scripts To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4GKSNnC008719 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just been looking at xfsdump and all of its options. It looks like a really good, feature laden backup program. I want to start calling it every night from cron. Are there any sample scripts which are designed to be called from cron and do something like the following: Session = Todays date switch(day-of-week) { SUN: Make a full backup (-L $Session) MON-SAT: Make an incremental from the Sunday backup session } use xfsinvutil to verify the inventory and send an e-mail if there are any problems use xfsinvutil to delete any inventory over a year old Perform any other xfs daily maintenance. i.e. xfs_check, defrag or whatever if appropriate. == Also there any GUI type interfaces for xfsdump/restore. I'm thinking of the ones that HP's Omniback uses. It would be really nice if restores in particular could be controlled via a HTTP interface. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu May 16 13:45:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GKj2nC009055 for ; Thu, 16 May 2002 13:45:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GKj23N009054 for linux-xfs-outgoing; Thu, 16 May 2002 13:45:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stumpy.chowhouse.com (root@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GKivnC009026 for ; Thu, 16 May 2002 13:44:58 -0700 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.11.6/8.11.3) with ESMTP id g4GKjT413079 for ; Thu, 16 May 2002 14:45:29 -0600 Date: Thu, 16 May 2002 14:45:29 -0600 (MDT) From: James Rich To: linux-xfs@oss.sgi.com Subject: Re: TAKE - XFS multiple blocksize support In-Reply-To: <200205161606.g4GG6ow24690@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 16 May 2002, Steve Lord wrote: > This allows Linux XFS to support filesystem blocksizes of less than > a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also > switches more of the xfs I/O path to use the generic code used by > other filesystems, the write path is still specific to XFS, but this > too should change over time. Does the change of IO path affect the performance or features in any way? James Rich james@chowhouse.com From owner-linux-xfs@oss.sgi.com Thu May 16 13:53:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GKrAnC009433 for ; Thu, 16 May 2002 13:53:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GKrA0K009432 for linux-xfs-outgoing; Thu, 16 May 2002 13:53:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GKr4nC009406 for ; Thu, 16 May 2002 13:53:05 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA55798; Thu, 16 May 2002 15:53:31 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-38.corp.sgi.com [134.15.64.38]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA00316; Thu, 16 May 2002 15:52:15 -0500 (CDT) Subject: Re: TAKE - XFS multiple blocksize support From: Stephen Lord To: James Rich Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 May 2002 15:50:31 -0500 Message-Id: <1021582233.1175.28.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-16 at 15:45, James Rich wrote: > On Thu, 16 May 2002, Steve Lord wrote: > > > This allows Linux XFS to support filesystem blocksizes of less than > > a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also > > switches more of the xfs I/O path to use the generic code used by > > other filesystems, the write path is still specific to XFS, but this > > too should change over time. > > Does the change of IO path affect the performance or features in any way? > > James Rich > james@chowhouse.com I am interested in hearing reports, the loads I tried were within a few percent, some improved, some not. There is more tweaking to do in this area. Steve From owner-linux-xfs@oss.sgi.com Thu May 16 14:49:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GLntnC010192 for ; Thu, 16 May 2002 14:49:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GLnt4W010191 for linux-xfs-outgoing; Thu, 16 May 2002 14:49:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GLnpnC010164 for ; Thu, 16 May 2002 14:49:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA06386 for ; Thu, 16 May 2002 14:50:21 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA32766 for linux-xfs@oss.sgi.com; Fri, 17 May 2002 07:49:02 +1000 (EST) Date: Fri, 17 May 2002 07:49:02 +1000 (EST) From: Nathan Scott Message-Id: <200205162149.HAA32766@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - couple more bsize cleanups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu May 16 14:44:39 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119372a linux/fs/xfs/linux/xfs_lrw.c - 1.135 - remove [ab;-)]use of several xs_attr stats variables here - these crept in during the blocksize code merge, unintentionally. linux/fs/xfs/pagebuf/page_buf_io.c - 1.34 - add in several missing uses of STATIC; fix up a few comment typos or now out-of-date comments; make 1st 4/5 function's declarations consistent with the rest of the file. From owner-linux-xfs@oss.sgi.com Thu May 16 16:17:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GNHcnC018368 for ; Thu, 16 May 2002 16:17:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GNHcjl018367 for linux-xfs-outgoing; Thu, 16 May 2002 16:17:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GNHQnC018341 for ; Thu, 16 May 2002 16:17:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA00012 for ; Thu, 16 May 2002 16:17:57 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27365; Fri, 17 May 2002 09:16:41 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA63560; Fri, 17 May 2002 09:16:39 +1000 (AEST) Date: Fri, 17 May 2002 09:16:38 +1000 From: Nathan Scott To: Simons Cc: linux-xfs@oss.sgi.com Subject: Re: Invalid argument Message-ID: <20020517091638.G151579@wobbly.melbourne.sgi.com> References: <000b01c1fa39$f4f2b070$2ed1c6cb@simonchs> <20020513181503.I120284@wobbly.melbourne.sgi.com> <000b01c1fb2e$1d8d2020$2ed1c6cb@simonchs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000b01c1fb2e$1d8d2020$2ed1c6cb@simonchs>; from xfs@127878.net on Tue, May 14, 2002 at 06:00:01PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, May 14, 2002 at 06:00:01PM +0800, Simons wrote: > > I just tried this and don't seem to be able to reproduce the > > problem - it works as advertised for me. Are you able to build > > your own kernel? If so, I'd suggest putting some printk's into > > xfs_qm_syscalls.c::xfs_qm_scall_quotaon(); esp. where EINVAL is > > returned and we will get a better picture of where this is going > > wrong. > > > > I'll try it out on a few more machines tomorrow and see if I can > > uncover the problem. It smells like an uninitialised or perhaps > > only partially inited flags variable, or something like that -- > > nothing leaps out at me after reading through the code though. > > > > seems i have just found out the reason, the problem only occured on the > machine with scsi hdd. > i have setup 3 scsi machines: > machine A - adaptec 29160, ibm 18g scsi > machine B - adaptec 29160, seagate 9g scsi > machine C - adaptec 2940UW, seagate 9g scsi > > both machines got the "Invalid argument" problem, but i have setup 2 ide hdd > machines last night, and don't have such problem. > Hmm... it's working for me on SCSI too: 9:01 fsgqa@bruce ~ 20> sudo quotaon -v / Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. Enabling group quota on root filesystem (reboot to take effect) /dev/scsi/host1/bus0/target1/lun0/part3: group quotas turned on Enabling user quota on root filesystem (reboot to take effect) /dev/scsi/host1/bus0/target1/lun0/part3: user quotas turned on 9:02 fsgqa@bruce ~ 21> 9:02 fsgqa@bruce ~ 21> sudo repquota -vug / Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. *** Report for user quotas on device /dev/scsi/host1/bus0/target1/lun0/part3 Block grace time: 00:00; Inode grace time: 00:00 Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- *** Status for user quotas on device /dev/scsi/host1/bus0/target1/lun0/part3 Accounting: OFF; Enforcement: OFF Accounting [ondisk]: ON; Enforcement [ondisk]: ON Inode: none *** Report for group quotas on device /dev/scsi/host1/bus0/target1/lun0/part3 Block grace time: 00:00; Inode grace time: 00:00 Block limits File limits Group used soft hard grace used soft hard grace ---------------------------------------------------------------------- *** Status for group quotas on device /dev/scsi/host1/bus0/target1/lun0/part3 Accounting: OFF; Enforcement: OFF Accounting [ondisk]: ON; Enforcement [ondisk]: ON Inode: none 9:03 fsgqa@bruce ~ 28> mount | fgrep ' / ' /dev/scsi/host1/bus0/target1/lun0/part3 on / type xfs (rw,logbufs=8) 9:03 fsgqa@bruce ~ 29> Must be some other factor here - have you had any joy with the printk's? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 16 17:10:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H0A3nC018907 for ; Thu, 16 May 2002 17:10:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H0A3f0018906 for linux-xfs-outgoing; Thu, 16 May 2002 17:10:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H09vnC018874 for ; Thu, 16 May 2002 17:09:58 -0700 Received: from [209.96.185.129] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 178VKH-0007v5-00; Thu, 16 May 2002 20:10:29 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4H06QN24615; Thu, 16 May 2002 20:06:26 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4H06OA13707; Thu, 16 May 2002 20:06:24 -0400 Date: Thu, 16 May 2002 20:06:24 -0400 From: Charles Shannon Hendrix To: Juergen Hasch Cc: John Kihonge , linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems Message-ID: <20020517000623.GA13675@widomaker.com> References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> <200205162151.07376.hasch@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205162151.07376.hasch@t-online.de> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 09:51:07PM +0200, Juergen Hasch wrote: > > > I'll have to see what is involved in the upgrade. Slackware is close to > > > another release which might use that version or later. > > I really don't understand how a minor glibc library update can cause such > problems. All other binaries were identical (kernel, modules, xfs libraries). I don't know for sure it even changed anything. In fact, I really don't believe the upgrade to 2.2.4 actually did anything. Today I looked through the files again, and I really think the results were about the same. The main difference this time was the error message I got more than the number of files restored. I think it's very bad that a restore program can be so heavily affected by the dump program's online database. The restore should do a restore, period, no funny business. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Thu May 16 17:17:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H0HgnC019115 for ; Thu, 16 May 2002 17:17:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H0Hglw019114 for linux-xfs-outgoing; Thu, 16 May 2002 17:17:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H0HVnC019088 for ; Thu, 16 May 2002 17:17:31 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA04951 for ; Thu, 16 May 2002 17:17:44 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4H0GaPF6662737; Thu, 16 May 2002 17:16:37 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B8B633000B8; Fri, 17 May 2002 10:16:35 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A259098; Fri, 17 May 2002 10:16:35 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Michael Sinz Cc: Linux XFS List Subject: Re: Strange behavior on the 2.4.18 XFS tree? In-reply-to: Your message of "Thu, 16 May 2002 13:57:44 -0400." <3CE3F318.1080500@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 May 2002 10:16:30 +1000 Message-ID: <5939.1021594590@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 16 May 2002 13:57:44 -0400, Michael Sinz wrote: >Well, given the "transient" nature of the problem, I can not be sure it >really "fixed" it but doing the sync did look like it helped - alot. > >I could not even do an "ls -l" of a directory during the "stall" period. >My already running system monitors (one of which is xosview) showed no >CPU usage (well, almost none) and almost no disk I/O (mostly 0) > >All of memory was used - something on the order of: (but not exactly as >this was run after the system unblocked) > > total used free shared buffers cached >Mem: 577396 567464 9932 0 0 233460 >-/+ buffers/cache: 334004 243392 >Swap: 2048276 1964 2046312 > >(Yes, mozilla was running and so was the find in the background) > >The find (or other major filesystem traversal) is what helps trigger this >condition. Where is the system hung if there is no disk I/O and no CPU >used (unless the CPU usage is not being accounted for?) > >BTW - once I did sync things worked as expected (ls ran quickly, etc) That is the same symptom I have seen. Something has a lock and is not moving, probably waiting on an event. Forcing some disk flush activity causes enough events to get everything going again. From owner-linux-xfs@oss.sgi.com Thu May 16 17:21:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H0LTnC019302 for ; Thu, 16 May 2002 17:21:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H0LTAi019301 for linux-xfs-outgoing; Thu, 16 May 2002 17:21:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H0LOnC019275 for ; Thu, 16 May 2002 17:21:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA02899 for ; Thu, 16 May 2002 17:21:27 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA46206 for linux-xfs@oss.sgi.com; Fri, 17 May 2002 10:20:08 +1000 (EST) Date: Fri, 17 May 2002 10:20:08 +1000 (EST) From: Nathan Scott Message-Id: <200205170020.KAA46206@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - warnings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu May 16 16:54:04 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:119397a cmd/xfstests/common.config - 1.16 - update config for couple of hosts. Date: Thu May 16 17:18:15 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119399a linux/fs/xfs/xfs_macros.c - 1.40 linux/fs/xfs/xfs_inode.c - 1.337 linux/fs/xfs/xfs_bmap.c - 1.282 - fix some warnings generated during ia64/debug builds. From owner-linux-xfs@oss.sgi.com Thu May 16 19:03:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H23EnC020613 for ; Thu, 16 May 2002 19:03:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H23Enc020612 for linux-xfs-outgoing; Thu, 16 May 2002 19:03:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H238nC020586 for ; Thu, 16 May 2002 19:03:08 -0700 Received: from Eric.cn.mvd (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id EE5E2B662; Thu, 16 May 2002 19:03:39 -0700 (PDT) Date: Fri, 17 May 2002 10:03:27 +0800 (CST) From: ericm@mountainviewdata.com X-X-Sender: ericm@Eric.cn.mvd To: Eric Sandeen Cc: Linux-Xfs Subject: Re: XFS-1.1+DEBUG+dbench = panic In-Reply-To: <1021560119.30538.10.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes the mysterious "DA READ ERROR" :-) FIY: We test with 2.96-110 (in redhat 7.3), it works well. Eric On 16 May 2002, Eric Sandeen wrote: > hi Allan - > > What compiler did you use? I had DEBUG panics with Red Hat's 2.96-98 > and 2.96-101, but 2.96-107 worked. kgcc, as always, also worked. > > Oh, and out of curiosity.... did it say DA READ ERROR? That's what I > hit. > > -Eric > > On Thu, 2002-05-16 at 09:30, Tang Lingbo (Allan) wrote: > > > Hi, > > > > If I run dbench 50 after enabling the 'CONFIG_XFS_DEBUG' and > > 'CONFIG_XFS_VNODE_TRACING' in XFS-1.1, the system will report > > Kernel panic. ( patched kdb) The partition is a new one and no other > > operations and this panic can be reproduced. > > > > But if disable these flags, panic seems disappeared. > > Is there any issues in debug routines? > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Thu May 16 22:42:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H5gWnC023971 for ; Thu, 16 May 2002 22:42:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H5gWCl023970 for linux-xfs-outgoing; Thu, 16 May 2002 22:42:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H5g7nC023942 for ; Thu, 16 May 2002 22:42:08 -0700 Received: by ids.org.au (Postfix, from userid 1001) id DC07BC001C2; Fri, 17 May 2002 15:42:34 +1000 (EST) Date: Fri, 17 May 2002 15:42:34 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: Re: xfsdump sample scripts Message-ID: <20020517054234.GA25311@ids.org.au> References: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Greg, Thu, May 16, 2002 at 04:24:01PM -0400, Greg Freemyer wrote: > Are there any sample scripts which are designed to be called from cron and do something like the following: I posted this script to the list last month (I've since tidied it up a little bit), which might be what you are looking for. Basically, I do full (level 0) dumps every Sunday, with incremental backups every other day of the week. I've been running this script for a few weeks. It does the job for me :) See the attached files, and the brief documentation within. Ian. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 --ZGiS0Q5IWpPtfppv Content-Type: application/x-sh Content-Disposition: attachment; filename="backup.sh" Content-Transfer-Encoding: quoted-printable #!/bin/sh =09 # Simple backup script to backup filesystems with xfsdump to a local disk. # Written by Ian Cumming, 25/04/02 - ian@ids.org.au # Operation: # Incremental backups are performed daily, with full backup performed on th= e first day of the week. # Dump files are archived with gzip to improve space efficiency. # Compressed dumps may be restored with "gunzip -c xfsdump.gz | xfsrestore = -i - /restore/path" # Usage: # ./backup.sh [dump_level] # With no arguments, the script will backup filesystems using incremental d= ump options (-l) # The dump level is the offset from the first day of the week, ie: Sunday = =3D 0, Monday =3D 1, etc.. # If dump_level is specified, then this will override the default behaviour. # Example: # An example cron job entry, to run at 4am every day. # 0 4 * * * /root/scripts/backup.sh # commands WALL=3D"/usr/bin/wall" XFSDUMP=3D"/sbin/xfsdump" MOUNT=3D"/bin/mount" UMOUNT=3D"/bin/umount" DAY=3D"date +%a" # print the day of the week CHECK_FS=3D"/sbin/e2fsck -p /dev/hdd5" # variables BACKUP_PATH=3D"/mnt/backup" # could be subdir of mount path MOUNT_PATH=3D"/mnt/backup" MEDIA_LABEL=3D"Backup Drive (hdd5)" PATH=3D"/usr/bin:/usr/sbin:/bin:/sbin" # it all starts here main() { # Perform pre backup operations pre_backup # Get the level of the backup (can be overriden with argv[1]) if [ "$1" !=3D "" ] ; then echo "Overriding dump level with $1" LEVEL=3D$1 else=20 LEVEL=3D`get_dump_level` fi # Perform the backups # These commands could be rolled into a separate function, but I decided a= gainst this to improve readability. =09 echo "dumping /" $XFSDUMP -l $LEVEL -F -L "/" -M "$MEDIA_LABEL" - / | gzip - > "$BACKUP_PAT= H/root/root_xfsdump$LEVEL.gz" =09 echo "dumping /usr" $XFSDUMP -l $LEVEL -F -L "/usr" -M "$MEDIA_LABEL" - /usr | gzip - > "$BACK= UP_PATH/usr/usr_xfsdump$LEVEL.gz" =09 echo "dumping /var" $XFSDUMP -l $LEVEL -F -L "/var" -M "$MEDIA_LABEL" - /var | gzip - > "$BACK= UP_PATH/var/var_xfsdump$LEVEL.gz" echo "dumping /pub" $XFSDUMP -l $LEVEL -F -L "/pub" -M "$MEDIA_LABEL" - /pub | gzip - > "$BACK= UP_PATH/pub/pub_xfsdump$LEVEL.gz" echo "dumping /home" $XFSDUMP -l $LEVEL -F -L "/home" -M "$MEDIA_LABEL" - /home | gzip - > "$BA= CKUP_PATH/home/home_xfsdump$LEVEL.gz" # Perform post backup operations post_backup } # Return the dump level, indexed from Sunday (level 0) get_dump_level() { case `$DAY` in Sun) echo 0;; Mon) echo 1;; Tue) echo 2;; Wed) echo 3;; Thu) echo 4;; Fri) echo 5;; Sat) echo 6;; esac }=09 # commands to perform before the backup occurs pre_backup() { # warn users of backup #`echo Daily backups are being performed. You may stay logged in while thi= s occurs. | $WALL` # set the umask umask 027 # fsck the filesystem every Sunday (LEVEL 0) # use tune2fs to set the frequency that this will occur $CHECK_FS # mount the backup volume echo "Mounting $MOUNT_PATH" if ! `$MOUNT $MOUNT_PATH`; then echo "Unable to mount $MOUNT_PATH (perhaps its already mounted?)" exit 0 fi } # commands to perform after the backup occurs post_backup() { # notify users that backup is complete #`echo Daily backups completed. | $WALL` # unmount the backup volume echo "Unmounting $MOUNT_PATH" if ! `$UMOUNT $MOUNT_PATH`; then echo "Unable to umount $MOUNT_PATH" fi } # do main main $@ --ZGiS0Q5IWpPtfppv Content-Type: application/x-sh Content-Disposition: attachment; filename="backup_cron.sh" Content-Transfer-Encoding: quoted-printable #!/bin/sh # simple script to run the daily backups, log then output the results # perform the backup operation and log to the file /root/scripts/backup/backup.sh > /var/log/ids/backup/`date +%a`.log 2>&1 # cat the log file (cron will email the result) cat /var/log/ids/backup/`date +%a`.log --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs@oss.sgi.com Thu May 16 23:38:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H6crnC024525 for ; Thu, 16 May 2002 23:38:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H6cri3024524 for linux-xfs-outgoing; Thu, 16 May 2002 23:38:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H6cknC024496 for ; Thu, 16 May 2002 23:38:47 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 035A9C00B5E for ; Fri, 17 May 2002 14:39:10 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 08FA9C00B5D for ; Fri, 17 May 2002 14:39:04 +0800 (PHT) Date: Fri, 17 May 2002 14:39:03 +0800 (PHT) From: Federico Sevilla III X-X-Sender: jijo@gusi.leathercollection.ph To: Linux XFS Mailing List Subject: Re: xfsdump sample scripts In-Reply-To: <20020517054234.GA25311@ids.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 17 May 2002 at 15:42, Ian Cumming wrote: > Basically, I do full (level 0) dumps every Sunday, with incremental > backups every other day of the week. Cool. Reading your script already answered a number of my questions (including can the dumps be compressed). I'm not very familiar yet with how xfsdump and xfsrestore work, but it looks like creating an incremental backup does not need access to an uncompressed full backup reference. When it comes to restoring, I wonder, if I want to do something like "restore foo.bar as of Wednesday", will it be possible to get this from the incremental backup of Wednesday, without uncompressing all the backup files? My apologies for the neophyte questions. Thanks in advance. And thanks again for sending us all the scripts. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key Fingerprint : 0x93B746BE From owner-linux-xfs@oss.sgi.com Thu May 16 23:56:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H6u4nC024972 for ; Thu, 16 May 2002 23:56:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H6u4F1024971 for linux-xfs-outgoing; Thu, 16 May 2002 23:56:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H6tsnC024939 for ; Thu, 16 May 2002 23:55:55 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 8CB5BC001C2; Fri, 17 May 2002 16:56:22 +1000 (EST) Date: Fri, 17 May 2002 16:56:22 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: Re: xfsdump sample scripts Message-ID: <20020517065622.GA26553@ids.org.au> References: <20020517054234.GA25311@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico, Here's a cut and paste out of my personal documentation. Hope this helps, Restore procedure: - Compressed dumps may be restored with the command: gunzip -c xfsdump.gz | xfsrestore -i - /restore/path This is useful to restore files that a user may have deleted, for example. - For example, a user's home directory can be restored interactively by using the command: gunzip -c /mnt/backup/home/home_xfsdump0.gz | xfsrestore -i - /home Then by selecting the user's home directory with "add", followed by the "extract" command. - Full restoration may be performed by using the -r (Cumulative) option in xfsrestore. Read xfsrestore man page thouroughly before attempting to do this! Note: Be sure to only restore the backup dumps up to the date you wish to restore to! For example, if you want to restore to Tuesday, only restore 0, 1 and 2 - not anything else! hope this helps, Ian. On Fri, May 17, 2002 at 02:39:03PM +0800, Federico Sevilla III wrote: > On Fri, 17 May 2002 at 15:42, Ian Cumming wrote: > > Basically, I do full (level 0) dumps every Sunday, with incremental > > backups every other day of the week. > > Cool. Reading your script already answered a number of my questions > (including can the dumps be compressed). I'm not very familiar yet with > how xfsdump and xfsrestore work, but it looks like creating an incremental > backup does not need access to an uncompressed full backup reference. > > When it comes to restoring, I wonder, if I want to do something like > "restore foo.bar as of Wednesday", will it be possible to get this from > the incremental backup of Wednesday, without uncompressing all the backup > files? > > My apologies for the neophyte questions. Thanks in advance. And thanks > again for sending us all the scripts. > > --> Jijo > > -- > Federico Sevilla III : > Network Administrator : The Leather Collection, Inc. > GnuPG Key Fingerprint : 0x93B746BE > -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Fri May 17 02:21:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H9LsnC026961 for ; Fri, 17 May 2002 02:21:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H9LsQq026960 for linux-xfs-outgoing; Fri, 17 May 2002 02:21:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail011.syd.optusnet.com.au (mail011.syd.optusnet.com.au [210.49.20.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H9LmnC026930 for ; Fri, 17 May 2002 02:21:49 -0700 Received: from localhost.localdomain (c17835.eburwd2.vic.optusnet.com.au [210.49.188.189]) by mail011.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g4H9MHA31518 for ; Fri, 17 May 2002 19:22:18 +1000 Subject: From: Menaka Lashitha Bandara To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 May 2002 19:22:16 +1000 Message-Id: <1021627338.469.2.camel@revolution> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys, My Debian PowerPC ibook2 had to go down twice after some errors while apt-get dist-upgrading. I'm running xfs filesystems. When gdm now loads, and tries looking in /etc/gconf/, it spits this out on the console: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=641920, sector=641856 end_request: I/O error, dev 03:02 (hda), sector 641856 I/O error in filesystem ("ide0(3,2)") meta-data dev 0x302 block 0x9cb40 ("xfs_trans_read_buf") error 5 buf count 8192 Now, is this a hardware defect with my hdd, or XFS error? I know it says I/O error in filesystem, but I just want to make sure that XFS is not seeing it as it's own error, when it's really the drive that's bad. Thanx. \LaShI From owner-linux-xfs@oss.sgi.com Fri May 17 02:37:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H9bpnC027330 for ; Fri, 17 May 2002 02:37:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H9bp4g027329 for linux-xfs-outgoing; Fri, 17 May 2002 02:37:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H9bknC027297 for ; Fri, 17 May 2002 02:37:46 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 178eBo-0000rR-00; Fri, 17 May 2002 02:38:20 -0700 To: Linux XFS Subject: Re: none References: <1021627338.469.2.camel@revolution> From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Message-Flag: Message text advisory: PROMOTION OF SELF, ADULT LANGUAGE/SITUATIONS X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 17 May 2002 10:38:20 +0100 In-Reply-To: <1021627338.469.2.camel@revolution> (Menaka Lashitha Bandara's message of "17 May 2002 19:22:16 +1000") Message-ID: <6u3cwr6rn7.fsf@zork.zork.net> Lines: 27 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence Menaka Lashitha Bandara quotation: > My Debian PowerPC ibook2 had to go down twice after some errors > while apt-get dist-upgrading. I'm running xfs filesystems. When gdm > now loads, and tries looking in /etc/gconf/, it spits this out on > the console: > > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=641920, > sector=641856 > end_request: I/O error, dev 03:02 (hda), sector 641856 > I/O error in filesystem ("ide0(3,2)") meta-data dev 0x302 block 0x9cb40 > ("xfs_trans_read_buf") error 5 buf count 8192 > > Now, is this a hardware defect with my hdd, or XFS error? I know it > says I/O error in filesystem, but I just want to make sure that XFS > is not seeing it as it's own error, when it's really the drive > that's bad. Those two "hda:" errors are coming from the IDE layer itself, and are definitely hardware errors. Back up your data immediately and have the disk replaced. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri May 17 02:53:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H9rrnC027741 for ; Fri, 17 May 2002 02:53:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H9rrXr027740 for linux-xfs-outgoing; Fri, 17 May 2002 02:53:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail021.syd.optusnet.com.au (mail021.syd.optusnet.com.au [210.49.20.161]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H9rnnC027714 for ; Fri, 17 May 2002 02:53:50 -0700 Received: from localhost.localdomain (c17835.eburwd2.vic.optusnet.com.au [210.49.188.189]) by mail021.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g4H9sFi25960; Fri, 17 May 2002 19:54:16 +1000 Subject: Re: none From: Menaka Lashitha Bandara To: Sean Neakums Cc: Linux XFS In-Reply-To: <6u3cwr6rn7.fsf@zork.zork.net> References: <1021627338.469.2.camel@revolution> <6u3cwr6rn7.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 May 2002 19:54:15 +1000 Message-Id: <1021629256.464.5.camel@revolution> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm... I did a badblocks -v /dev/hda2. But it didn't print out any bad blocks, just kept giving me this { DriveSeek ... } error. I guess bad blocks works at a much lower level (ie, it's filesystem independant yeah?)... So if it can't see through, I guess it's hardware... Thankx... \LaShI From owner-linux-xfs@oss.sgi.com Fri May 17 02:55:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H9tDnC027923 for ; Fri, 17 May 2002 02:55:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H9tDGm027922 for linux-xfs-outgoing; Fri, 17 May 2002 02:55:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H9t8nC027896 for ; Fri, 17 May 2002 02:55:09 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 74799C00B5B for ; Fri, 17 May 2002 17:55:42 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 3642FC00B5A for ; Fri, 17 May 2002 17:55:36 +0800 (PHT) Date: Fri, 17 May 2002 17:55:36 +0800 (PHT) From: Federico Sevilla III X-X-Sender: jijo@gusi.leathercollection.ph To: Linux XFS Mailing List Subject: Re: xfsdump sample scripts In-Reply-To: <20020517065622.GA26553@ids.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 17 May 2002 at 16:56, Ian Cumming wrote: > Note: Be sure to only restore the backup dumps up to the date you wish > to restore to! For example, if you want to restore to Tuesday, only > restore 0, 1 and 2 - not anything else! So I restore from 0, then from 1, then from 2? Simply restoring from 2 wouldn't work? --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key Fingerprint : 0x93B746BE From owner-linux-xfs@oss.sgi.com Fri May 17 03:05:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HA5wnC028348 for ; Fri, 17 May 2002 03:05:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HA5wG8028347 for linux-xfs-outgoing; Fri, 17 May 2002 03:05:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HA5pnC028318 for ; Fri, 17 May 2002 03:05:52 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g4HA6lX31178; Fri, 17 May 2002 12:06:47 +0200 Date: Fri, 17 May 2002 12:06:47 +0200 (CEST) From: Matteo Centonza To: Federico Sevilla III cc: Linux XFS Mailing List Subject: [OT] Re: xfsdump sample scripts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, On Fri, 17 May 2002, Federico Sevilla III wrote: > On Fri, 17 May 2002 at 16:56, Ian Cumming wrote: > > Note: Be sure to only restore the backup dumps up to the date you wish > > to restore to! For example, if you want to restore to Tuesday, only > > restore 0, 1 and 2 - not anything else! > > So I restore from 0, then from 1, then from 2? Simply restoring from 2 > wouldn't work? > > --> Jijo > have you ever thought of using amanda for your backups? Doing so, you'll get rid of all sorts of implementation details plus a whole bunch of interesting extras (for short). Just a thought. Ciao, -m From owner-linux-xfs@oss.sgi.com Fri May 17 05:05:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HC5inC031860 for ; Fri, 17 May 2002 05:05:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HC5iOm031859 for linux-xfs-outgoing; Fri, 17 May 2002 05:05:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HC5cnC031828 for ; Fri, 17 May 2002 05:05:39 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 18A82C001C2; Fri, 17 May 2002 22:06:07 +1000 (EST) Date: Fri, 17 May 2002 22:05:41 +1000 From: Ian Cumming To: Federico Sevilla III Subject: Re: xfsdump sample scripts Message-ID: <20020517120541.GA29674@ids.org.au> References: <20020517065622.GA26553@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you modified the file on Tueday, then you could simply restore the Wednesday backup (which backs up Tuesday's files) If you lost your system entirely, then you would want to iteratively restore from 0 -> day, as this will "similate" files being added/removed from your fs. - On Fri, May 17, 2002 at 05:55:36PM +0800, Federico Sevilla III wrote: > On Fri, 17 May 2002 at 16:56, Ian Cumming wrote: > > Note: Be sure to only restore the backup dumps up to the date you wish > > to restore to! For example, if you want to restore to Tuesday, only > > restore 0, 1 and 2 - not anything else! > > So I restore from 0, then from 1, then from 2? Simply restoring from 2 > wouldn't work? > > --> Jijo > > -- > Federico Sevilla III : > Network Administrator : The Leather Collection, Inc. > GnuPG Key Fingerprint : 0x93B746BE -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Fri May 17 07:34:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HEYVnC005366 for ; Fri, 17 May 2002 07:34:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HEYVcM005365 for linux-xfs-outgoing; Fri, 17 May 2002 07:34:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fruit.eu.org (qmailr@h149.wib.euronet.nl [194.134.114.149]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HEYBnC005330 for ; Fri, 17 May 2002 07:34:26 -0700 Received: (qmail 15990 invoked by uid 500); 17 May 2002 14:34:45 -0000 Date: Fri, 17 May 2002 16:34:45 +0200 From: Wessel Dankers To: Linux XFS List Subject: Re: Strange behavior on the 2.4.18 XFS tree? Message-ID: <20020517143445.GD633@fruit.eu.org> Mail-Followup-To: Linux XFS List References: <3CE3F318.1080500@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE3F318.1080500@wgate.com> User-Agent: Mutt/1.3.28i X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002-05-16 13:57:44-0400, Michael Sinz wrote: > total used free shared buffers cached > Mem: 577396 567464 9932 0 0 233460 > -/+ buffers/cache: 334004 243392 > Swap: 2048276 1964 2046312 Don't use the free utility, its parsing of /proc/meminfo is broken. Better to look at /proc/meminfo directly. Regards, -- Wessel Dankers sticktion From owner-linux-xfs@oss.sgi.com Fri May 17 07:59:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HExinC006588 for ; Fri, 17 May 2002 07:59:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HExiDA006587 for linux-xfs-outgoing; Fri, 17 May 2002 07:59:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HExRnC006541 for ; Fri, 17 May 2002 07:59:27 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Fri, 17 May 2002 10:59:57 -0400 Message-ID: From: Murthy Kambhampaty To: "'Ian Cumming'" , linux-xfs@oss.sgi.com Subject: RE: xfsdump sample scripts Date: Fri, 17 May 2002 10:59:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ian, thanks for the scripts (I was also in the process of setting up a backup routine, and these will save me a lot of time, and they're more polished than what I would have hacked up). A variation for those who have sufficient backup storage/small amounts of data to backup, would be to set the backup "level" on all days except Sunday to 1 to reduce the number of tapes required to recover a given day's filesystem state (some vendors call this strategy "differential backups"). Under this strategy, to recover the filesystem state as of the Wednesday backup, for example, one would only have to restore the Sunday xfsdump and then the Wednesday xfsdump. This can be accomplished, for example, with the following changes (in diff-like notation; essentially archive files are named by day rather than level, and the get_dump_level() function is defaults to 1, setting Sunday's level to 0): ### Begin code snippet: ### # it all starts here main() { # Perform pre backup operations pre_backup # Get the level of the backup (can be overriden with argv[1]) if [ "$1" != "" ] ; then echo "Overriding dump level with $1" LEVEL=$1 else LEVEL=`get_dump_level` fi # Perform the backups # These commands could be rolled into a separate function, but I decided against this to improve readability. echo "dumping /" - $XFSDUMP -l $LEVEL -F -L "/" -M "$MEDIA_LABEL" - / | gzip - > "$BACKUP_PATH/root/root_xfsdump$LEVEL.gz" + $XFSDUMP -l $LEVEL -F -L "/" -M "$MEDIA_LABEL" - / | gzip - > "$BACKUP_PATH/root/root_xfsdump$(date +%A).gz" echo "dumping /usr" - $XFSDUMP -l $LEVEL -F -L "/usr" -M "$MEDIA_LABEL" - /usr | gzip - > "$BACKUP_PATH/usr/usr_xfsdump$LEVEL.gz" + $XFSDUMP -l $LEVEL -F -L "/usr" -M "$MEDIA_LABEL" - /usr | gzip - > "$BACKUP_PATH/root/root_xfsdump$(date +%A).gz" echo "dumping /var" - $XFSDUMP -l $LEVEL -F -L "/var" -M "$MEDIA_LABEL" - /var | gzip - > "$BACKUP_PATH/var/var_xfsdump$LEVEL.gz" + $XFSDUMP -l $LEVEL -F -L "/var" -M "$MEDIA_LABEL" - /var | gzip - > "$BACKUP_PATH/root/root_xfsdump$(date +%A).gz" echo "dumping /pub" - $XFSDUMP -l $LEVEL -F -L "/pub" -M "$MEDIA_LABEL" - /pub | gzip - > "$BACKUP_PATH/pub/pub_xfsdump$LEVEL.gz" + $XFSDUMP -l $LEVEL -F -L "/pub" -M "$MEDIA_LABEL" - /pub | gzip - > "$BACKUP_PATH/root/root_xfsdump$(date +%A).gz" echo "dumping /home" - $XFSDUMP -l $LEVEL -F -L "/home" -M "$MEDIA_LABEL" - /home | gzip - > "$BACKUP_PATH/home/home_xfsdump$LEVEL.gz" + $XFSDUMP -l $LEVEL -F -L "/home" -M "$MEDIA_LABEL" - /home | gzip - > "$BACKUP_PATH/root/root_xfsdump$(date +%A).gz" # Perform post backup operations post_backup } # Return the dump level, indexed from Sunday (level 0) get_dump_level() { case `$DAY` in Sun) echo 0;; + *) echo 1;; - Mon) echo 1;; - Tue) echo 2;; - Wed) echo 3;; - Thu) echo 4;; - Fri) echo 5;; - Sat) echo 6;; esac } ### End code snippet ### Thanks again for sharing your shell scripts, Murthy > -----Original Message----- > From: Ian Cumming [mailto:ian@ids.org.au] > Sent: Friday, May 17, 2002 01:43 > To: linux-xfs@oss.sgi.com > Subject: Re: xfsdump sample scripts > > > Hi Greg, > > Thu, May 16, 2002 at 04:24:01PM -0400, Greg Freemyer wrote: > > Are there any sample scripts which are designed to be > called from cron and do something like the following: > > I posted this script to the list last month (I've since tidied it up a > little bit), which might be what you are looking for. > > Basically, I do full (level 0) dumps every Sunday, with incremental > backups every other day of the week. > > I've been running this script for a few weeks. It does the > job for me :) > > See the attached files, and the brief documentation within. > > Ian. > > -- > Ian Cumming, ian@semisphere.org > > "The number of Unix installations has grown to 10, with more > expected." > -- The Unix Programmer's Manual, 2nd Edition, June, 1972 > > From owner-linux-xfs@oss.sgi.com Fri May 17 08:15:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HFFinC007127 for ; Fri, 17 May 2002 08:15:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HFFioZ007126 for linux-xfs-outgoing; Fri, 17 May 2002 08:15:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HFFbnC007091 for ; Fri, 17 May 2002 08:15:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA81735; Fri, 17 May 2002 10:16:07 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA95589; Fri, 17 May 2002 10:14:50 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA21676; Fri, 17 May 2002 10:14:49 -0500 (CDT) Message-ID: <3CE51E68.A877E9CE@sgi.com> Date: Fri, 17 May 2002 10:14:49 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Federico Sevilla III CC: Linux XFS Mailing List Subject: Re: xfsdump sample scripts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III wrote: > On Fri, 17 May 2002 at 16:56, Ian Cumming wrote: > > Note: Be sure to only restore the backup dumps up to the date you wish > > to restore to! For example, if you want to restore to Tuesday, only > > restore 0, 1 and 2 - not anything else! > > So I restore from 0, then from 1, then from 2? Simply restoring from 2 > wouldn't work? > > --> Jijo > Federico, Restoring from level 2 will not work. xfsdump doea a full dump on base dump (level 0) and then succeeding incremental dumps only dumps changes since the previous dump level. To restore to Tuesday you will need to restore the Sunday's base dump (level 0) and succeeding higher level dumps in succession. In this case you will restore level 0 (Sunday's base dump), then level 1 (Monday's incremental dump) and finally level 2 (Tuesday's incremental dump) in that order. Use the -r option to inform xfsrestore you are performing a cumulative recovery. For example, issue the following command to restore level 0 dump; # /usr/sbin/xfsrestore -f /dev/tape -r /restore_dir Enter the same command again and to restore the next level (level 1) # /usr/sbin/xfsrestore -f /dev/tape -r /restore_dir and finally issue the same command the third time to restore level 2 dump (Tuesday's dump). # /usr/sbin/xfsrestore -f /dev/tape -r /restore_dir I hope this answers your question. See the xfsrestore manpages. Thanks, Kihonge JN From owner-linux-xfs@oss.sgi.com Fri May 17 09:13:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGDgnC008704 for ; Fri, 17 May 2002 09:13:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGDgIT008702 for linux-xfs-outgoing; Fri, 17 May 2002 09:13:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGDYnC008671 for ; Fri, 17 May 2002 09:13:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA82966; Fri, 17 May 2002 11:14:04 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA11255; Fri, 17 May 2002 11:12:47 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA22285; Fri, 17 May 2002 11:12:47 -0500 (CDT) Message-ID: <3CE52BFE.2D3E20FE@sgi.com> Date: Fri, 17 May 2002 11:12:46 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Greg Freemyer CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump sample scripts References: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg Freemyer wrote: > I've just been looking at xfsdump and all of its options. > > It looks like a really good, feature laden backup program. > > I want to start calling it every night from cron. > > Are there any sample scripts which are designed to be called from cron and do something like the following: > > Session = Todays date > > switch(day-of-week) { > SUN: Make a full backup (-L $Session) > MON-SAT: Make an incremental from the Sunday backup session > } > > use xfsinvutil to verify the inventory and send an e-mail if there are any problems > > use xfsinvutil to delete any inventory over a year old > > Perform any other xfs daily maintenance. i.e. xfs_check, defrag or whatever if appropriate. > > == > Also there any GUI type interfaces for xfsdump/restore. I'm thinking of the ones that HP's Omniback uses. > > It would be really nice if restores in particular could be controlled via a HTTP interface. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com I hope the tips and scripts from the users have been helpful to you. At the moment, there are no GUI type interfaces for xfsdump/restore. Kihonge JN From owner-linux-xfs@oss.sgi.com Fri May 17 09:14:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGECnC008795 for ; Fri, 17 May 2002 09:14:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGEB6k008794 for linux-xfs-outgoing; Fri, 17 May 2002 09:14:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf17bis.bellsouth.net (mail217.mail.bellsouth.net [205.152.58.157]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGE1nC008732 for ; Fri, 17 May 2002 09:14:02 -0700 Received: from taz ([66.156.2.161]) by imf17bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020517161559.CSFJ7584.imf17bis.bellsouth.net@taz>; Fri, 17 May 2002 12:15:59 -0400 Date: Fri, 17 May 2002 12:09:45 -0400 From: Greg Freemyer Subject: re[2]: xfsdump sample scripts To: Ian Cumming , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020517161559.CSFJ7584.imf17bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4HGE2nC008737 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ian, That will be very helpfull. Thanks. One problem is that you are calling e2fsck if I read your script correctly. I don't think that works with xfs. xfs_check would be a better choice I think. I don't know if there are any other maintenance programs one should invoke on a scheduled basis. And a real nit-picky thing is that you are not triming the xfs backup inventory. It probably won't be a problem for a while. xfsinvutil does this. I't looks easy to delete anything over a year old if you want to do something like that. It's probably going overboard, but I think I will actually write an expect script that invokes xfsinvutil and actually maintains a preset retention schedule. i.e. Quarterly Full - Maintain for 5 years Monthly Full - Maintain for 12 months Weekly Full - Maintain for 6 months Daily Differential - Maintain for 3 months. I tend to do something like the above for my production backup tapes, and it only makes sense for the inventory to match the real tapes. Thanks again, Greg >> Hi Greg, >> Thu, May 16, 2002 at 04:24:01PM -0400, Greg Freemyer wrote: >> > Are there any sample scripts which are designed to be called from cron >> and do something like the following: >> I posted this script to the list last month (I've since tidied it up a >> little bit), which might be what you are looking for. >> Basically, I do full (level 0) dumps every Sunday, with incremental >> backups every other day of the week. >> I've been running this script for a few weeks. It does the job for me :) >> See the attached files, and the brief documentation within. >> Ian. >> -- >> Ian Cumming, ian@semisphere.org >> "The number of Unix installations has grown to 10, with more expected." >> -- The Unix Programmer's Manual, 2nd Edition, June, 1972 >> -- NextPart -- >> Attached File: c:\program files\goldmine\MailBox\Attach\gaf\backup.sh >> -- NextPart -- >> Attached File: c:\program files\goldmine\MailBox\Attach\gaf\backup_cron.sh Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri May 17 09:15:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGFBnC009058 for ; Fri, 17 May 2002 09:15:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGFBlX009057 for linux-xfs-outgoing; Fri, 17 May 2002 09:15:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGF5nC009024 for ; Fri, 17 May 2002 09:15:05 -0700 Received: from [209.96.179.131] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 178kO9-000Od9-00; Fri, 17 May 2002 12:15:30 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4HGD5N27564; Fri, 17 May 2002 12:13:05 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4HGD2T14343; Fri, 17 May 2002 12:13:02 -0400 Date: Fri, 17 May 2002 12:13:02 -0400 From: Charles Shannon Hendrix To: Wessel Dankers Cc: Linux XFS List Subject: Re: Strange behavior on the 2.4.18 XFS tree? Message-ID: <20020517161301.GB13880@widomaker.com> References: <3CE3F318.1080500@wgate.com> <20020517143445.GD633@fruit.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020517143445.GD633@fruit.eu.org> User-Agent: Mutt/1.3.23.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, May 17, 2002 at 04:34:45PM +0200, Wessel Dankers wrote: > On 2002-05-16 13:57:44-0400, Michael Sinz wrote: > > total used free shared buffers cached > > Mem: 577396 567464 9932 0 0 233460 > > -/+ buffers/cache: 334004 243392 > > Swap: 2048276 1964 2046312 > > Don't use the free utility, its parsing of /proc/meminfo is broken. > Better to look at /proc/meminfo directly. My free is just about exactly what /proc/meminfo says. /proc/meminfo isn't correct all the time. Many times it has shown what basically appears to be a memory leak, when in reality the memory was allocated and /proc/meminfo just doesn't show it. I think either /proc/meminfo needs to be changed to include full information, or the free and other utilities need to use /proc/slabinfo. When I exit a full X session, I often have 100MB or more memory missing. /proc/meminfo does not show this, so free's parsing doesn't really matter: even done correctly, it would be wrong. But looking in /proc/slabinfo, you can sometimes see where the memory is. I can run a memory-eater to ask for slightly more memory than what I have as real RAM, and that missing memory mostly comes back. Accounting in the current Linux kernels needs improvement, IMHO. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Fri May 17 09:25:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGPJnC009418 for ; Fri, 17 May 2002 09:25:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGPJgc009417 for linux-xfs-outgoing; Fri, 17 May 2002 09:25:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf26bis.bellsouth.net (mail026.mail.bellsouth.net [205.152.58.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGPAnC009380 for ; Fri, 17 May 2002 09:25:10 -0700 Received: from taz ([66.156.2.161]) by imf26bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020517162540.JMPC25163.imf26bis.bellsouth.net@taz>; Fri, 17 May 2002 12:25:40 -0400 Date: Fri, 17 May 2002 12:20:53 -0400 From: Greg Freemyer Subject: re: [OT] Re: xfsdump sample scripts To: Matteo Centonza cc: Linux XFS Mailing List Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020517162540.JMPC25163.imf26bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4HGPBnC009385 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Matteo, I actually went and briefly looked at the Amanda website a couple of months ago. It sounded as if it was targeting a collection of Linux servers being backed up to a single tape drive. I'm just backing up one server to local large disk drive. (This is just what the sample script does as well. :) ) Does using Amanda in this type of an environment simplify life, or make it worse. In particular, I want to come up with a end-user friendly restore mechanism. My plan is to keep the last 30 days of backups online and I would like to give end-users the ability to restore their own files. Hopefully via a http interface. I'm not sure if that is feasible yet or not, but that is my goal. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> Hi all, >> On Fri, 17 May 2002, Federico Sevilla III wrote: >> > On Fri, 17 May 2002 at 16:56, Ian Cumming wrote: >> > > Note: Be sure to only restore the backup dumps up to the date you wish >> > > to restore to! For example, if you want to restore to Tuesday, only >> > > restore 0, 1 and 2 - not anything else! >> > >> > So I restore from 0, then from 1, then from 2? Simply restoring from 2 >> > wouldn't work? >> > >> > --> Jijo >> > >> have you ever thought of using amanda for your backups? >> Doing so, you'll get rid of all sorts of implementation details >> plus a whole bunch of interesting extras (for short). >> Just a thought. >> Ciao, >> -m From owner-linux-xfs@oss.sgi.com Fri May 17 09:32:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGWpnC009772 for ; Fri, 17 May 2002 09:32:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGWp7r009771 for linux-xfs-outgoing; Fri, 17 May 2002 09:32:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGWinC009741 for ; Fri, 17 May 2002 09:32:44 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g4HGXAv26543; Fri, 17 May 2002 12:33:10 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 17 May 2002 12:33:10 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Greg Freemyer cc: Matteo Centonza , Linux XFS Mailing List Subject: re: [OT] Re: xfsdump sample scripts In-Reply-To: <20020517162540.JMPC25163.imf26bis.bellsouth.net@taz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 17 May 2002 at 12:20pm, Greg Freemyer wrote > It sounded as if it was targeting a collection of Linux servers being > backed up to a single tape drive. Actually the design is for one or more *nix boxes (and Win boxes via samba) backing up to a single tape drive. Many people do use it for a single server, however. > I'm just backing up one server to local large disk drive. (This is > just what the sample script does as well. :) ) Version 2.4.3 of amanda (currently in beta3) does this by design, using files on disk as if they were tapes. Previous versions could do it by just specifying a non-existent device as the tape drive, and letting backups stay on the holding disk. > Does using Amanda in this type of an environment simplify life, or make > it worse. Amanda is *very* nice. It does almost all the management, so you don't have to. But... > In particular, I want to come up with a end-user friendly restore mechanism. amrecover (the command line file recovery utility) is very friendly. Tell it the date, and it will list the files that existed on that day. So you can even recover multiple versions of the same file, depending upon date. > My plan is to keep the last 30 days of backups online and I would like > to give end-users the ability to restore their own files. Hopefully via > a http interface. Well, amrecover does want to be run as root. sudo could take care of that, but then you have issues with users having access to the files of others. And I don't know of any http front end, so this may be an issue. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri May 17 09:35:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGZ4nC009989 for ; Fri, 17 May 2002 09:35:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGZ4Ju009988 for linux-xfs-outgoing; Fri, 17 May 2002 09:35:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGYwnC009957 for ; Fri, 17 May 2002 09:34:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA84309; Fri, 17 May 2002 11:35:28 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA79465; Fri, 17 May 2002 11:34:11 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA22222; Fri, 17 May 2002 11:34:11 -0500 (CDT) Message-ID: <3CE53102.2B550CF8@sgi.com> Date: Fri, 17 May 2002 11:34:10 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: Juergen Hasch , linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> <200205162151.07376.hasch@t-online.de> <20020517000623.GA13675@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles Shannon Hendrix wrote: > On Thu, May 16, 2002 at 09:51:07PM +0200, Juergen Hasch wrote: > > > > > I'll have to see what is involved in the upgrade. Slackware is close to > > > > another release which might use that version or later. > > > > I really don't understand how a minor glibc library update can cause such > > problems. All other binaries were identical (kernel, modules, xfs libraries). > > I don't know for sure it even changed anything. In fact, I really don't > believe the upgrade to 2.2.4 actually did anything. Today I looked > through the files again, and I really think the results were about the > same. > > The main difference this time was the error message I got more than the > number of files restored. > > I think it's very bad that a restore program can be so heavily affected > by the dump program's online database. The restore should do a restore, > period, no funny business. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com We are working to try and determine what might be happening and to help you restore the data. The backup may not be lost and you may be able to recover the files you want. The problem you are having may have nothing to do with the online database. We are working hard at it and we will get back to you early next week. Thanks, Kihonge JN From owner-linux-xfs@oss.sgi.com Fri May 17 09:39:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HGdGnC010226 for ; Fri, 17 May 2002 09:39:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HGdGST010224 for linux-xfs-outgoing; Fri, 17 May 2002 09:39:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf05bis.bellsouth.net (mail305.mail.bellsouth.net [205.152.58.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HGd6nC010192 for ; Fri, 17 May 2002 09:39:06 -0700 Received: from taz ([66.156.2.161]) by imf05bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020517164104.XPWI22872.imf05bis.bellsouth.net@taz>; Fri, 17 May 2002 12:41:04 -0400 Date: Fri, 17 May 2002 12:34:50 -0400 From: Greg Freemyer Subject: re[2]: [OT] Re: xfsdump sample scripts To: Joshua Baker-LePain cc: Linux XFS Mailing List Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020517164104.XPWI22872.imf05bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4HGd6nC010193 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the info. Looks like time to go get Amanda 2.4.3 >> On Fri, 17 May 2002 at 12:20pm, Greg Freemyer wrote >> > It sounded as if it was targeting a collection of Linux servers being >> > backed up to a single tape drive. >> Actually the design is for one or more *nix boxes (and Win boxes via >> samba) backing up to a single tape drive. Many people do use it for a >> single server, however. >> > I'm just backing up one server to local large disk drive. (This is >> > just what the sample script does as well. :) ) >> Version 2.4.3 of amanda (currently in beta3) does this by design, using >> files on disk as if they were tapes. Previous versions could do it by >> just specifying a non-existent device as the tape drive, and letting >> backups stay on the holding disk. >> > Does using Amanda in this type of an environment simplify life, or make >> > it worse. >> Amanda is *very* nice. It does almost all the management, so you don't >> have to. But... >> > In particular, I want to come up with a end-user friendly restore >> mechanism. >> amrecover (the command line file recovery utility) is very friendly. Tell >> >> it the date, and it will list the files that existed on that day. So you >> can even recover multiple versions of the same file, depending upon date. >> > My plan is to keep the last 30 days of backups online and I would like >> > to give end-users the ability to restore their own files. Hopefully via >> >> > a http interface. >> Well, amrecover does want to be run as root. sudo could take care of >> that, but then you have issues with users having access to the files of >> others. And I don't know of any http front end, so this may be an issue. >> -- >> Joshua Baker-LePain >> Department of Biomedical Engineering >> Duke University Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri May 17 10:23:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HHNcnC011270 for ; Fri, 17 May 2002 10:23:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HHNcf1011269 for linux-xfs-outgoing; Fri, 17 May 2002 10:23:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HHNXnC011237 for ; Fri, 17 May 2002 10:23:33 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA89459 for ; Fri, 17 May 2002 12:24:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA14100 for ; Fri, 17 May 2002 12:22:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4HHLdE03672; Fri, 17 May 2002 12:21:39 -0500 Message-Id: <200205171721.g4HHLdE03672@jen.americas.sgi.com> Date: Fri, 17 May 2002 12:21:39 -0500 Subject: TAKE - Small I/O path cleanups To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is worth a few percent on write performance, and about 15% on O_SYNC writes. Basically get more information about the type of I/O we are doing down to the block layer code. Date: Fri May 17 10:20:52 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119446a linux/fs/xfs/linux/xfs_lrw.c - 1.136 - Pass info on the expected new file size down to the allocator linux/fs/xfs/linux/xfs_iops.c - 1.140 - Add getblock case for passing O_SYNC information down to the allocator, don't just use 64K as the default preallocation size. linux/fs/xfs/pagebuf/page_buf_io.c - 1.35 - pass file pointer into prepare and commit write so they can get O_SYNC information. From owner-linux-xfs@oss.sgi.com Fri May 17 11:13:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HIDanC012470 for ; Fri, 17 May 2002 11:13:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HIDaXH012469 for linux-xfs-outgoing; Fri, 17 May 2002 11:13:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HIDVnC012438 for ; Fri, 17 May 2002 11:13:32 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 68D021E25E; Fri, 17 May 2002 20:14:00 +0200 (MEST) Date: Fri, 17 May 2002 20:13:59 +0200 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Small I/O path cleanups Message-ID: <20020517201359.A32604@wotan.suse.de> References: <200205171721.g4HHLdE03672@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205171721.g4HHLdE03672@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, May 17, 2002 at 12:21:39PM -0500, Steve Lord wrote: > This is worth a few percent on write performance, and about 15% on > O_SYNC writes. Basically get more information about the type of I/O > we are doing down to the block layer code. Are the numbers relative to the old write path or the new write path ? -Andi From owner-linux-xfs@oss.sgi.com Fri May 17 12:12:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HJCWnC013942 for ; Fri, 17 May 2002 12:12:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HJCV7i013941 for linux-xfs-outgoing; Fri, 17 May 2002 12:12:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HJCRnC013911 for ; Fri, 17 May 2002 12:12:28 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 178n7z-0008T1-00; Fri, 17 May 2002 13:10:59 -0600 Message-ID: <3CE5563A.6090501@emergence.com> Date: Fri, 17 May 2002 13:12:58 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs@oss.sgi.com Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> <1021576512.21567.25.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have prepared a short page here at: http://www.pendragon.org/projects/valhalla-xfs/index_html -Mike Florin Andrei wrote: > Michael, > > Can you put the results of your work online? > I think i'll try to play a little bit with the booting disc image. I did > some customised Red Hat installers in the past, so i think there should > be no problem now. From owner-linux-xfs@oss.sgi.com Fri May 17 12:28:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HJS1nC014220 for ; Fri, 17 May 2002 12:28:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HJS1Cb014219 for linux-xfs-outgoing; Fri, 17 May 2002 12:28:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HJRtnC014193 for ; Fri, 17 May 2002 12:27:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA95189; Fri, 17 May 2002 14:28:26 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA95303; Fri, 17 May 2002 14:27:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4HJQ1E06376; Fri, 17 May 2002 14:26:01 -0500 Subject: Re: TAKE - Small I/O path cleanups From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020517201359.A32604@wotan.suse.de> References: <200205171721.g4HHLdE03672@jen.americas.sgi.com> <20020517201359.A32604@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 May 2002 14:26:01 -0500 Message-Id: <1021663561.1423.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-05-17 at 13:13, Andi Kleen wrote: > On Fri, May 17, 2002 at 12:21:39PM -0500, Steve Lord wrote: > > This is worth a few percent on write performance, and about 15% on > > O_SYNC writes. Basically get more information about the type of I/O > > we are doing down to the block layer code. > > Are the numbers relative to the old write path or the new write path ? > > -Andi The new one, mostly performance was very close to the old, but O_SYNC took a bit of a dive. I should have a number of other tweaks like this coming along - I think I may be on the verge of removing the io lock from xfs, that will be a big win - and MIGHT let us use the generic write path. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri May 17 12:31:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HJV6nC014401 for ; Fri, 17 May 2002 12:31:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HJV6p0014400 for linux-xfs-outgoing; Fri, 17 May 2002 12:31:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HJUwnC014371 for ; Fri, 17 May 2002 12:30:58 -0700 Received: (qmail 18934 invoked by uid 500); 17 May 2002 19:31:23 -0000 Subject: Re: TAKE - Small I/O path cleanups From: Austin Gonyou To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <1021663561.1423.24.camel@jen.americas.sgi.com> References: <1021663561.1423.24.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cfmxCtywXvnLnCOMAv8z" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 17 May 2002 14:31:23 -0500 Message-Id: <1021663883.26418.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-cfmxCtywXvnLnCOMAv8z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Woooohooo!!! Go Steve! On Fri, 2002-05-17 at 14:26, Steve Lord wrote: > ...I should have a number of other > tweaks like this coming along - I think I may be on the verge > of removing the io lock from xfs, that will be a big win - and > MIGHT let us use the generic write path. >=20 > Steve >=20 > --=20 >=20 > Steve Lord voice: > +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-cfmxCtywXvnLnCOMAv8z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA85VqL94g6ZVmFMoIRAkl+AJ4pYxsYTpGX1uBqPasFi0Yrh/K4NgCgnwaI TNttPulVdh9PIg7YRKtTiAk= =IvYB -----END PGP SIGNATURE----- --=-cfmxCtywXvnLnCOMAv8z-- From owner-linux-xfs@oss.sgi.com Fri May 17 12:33:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HJXmnC014927 for ; Fri, 17 May 2002 12:33:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HJXmJ8014926 for linux-xfs-outgoing; Fri, 17 May 2002 12:33:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HJXinC014898 for ; Fri, 17 May 2002 12:33:44 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 976ED1EA41; Fri, 17 May 2002 21:34:15 +0200 (MEST) Date: Fri, 17 May 2002 21:34:15 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - Small I/O path cleanups Message-ID: <20020517213414.A24363@wotan.suse.de> References: <200205171721.g4HHLdE03672@jen.americas.sgi.com> <20020517201359.A32604@wotan.suse.de> <1021663561.1423.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021663561.1423.24.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The new one, mostly performance was very close to the old, but > O_SYNC took a bit of a dive. I should have a number of other > tweaks like this coming along - I think I may be on the verge > of removing the io lock from xfs, that will be a big win - and > MIGHT let us use the generic write path. What io lock do you mean? The vnode lock? -Andi From owner-linux-xfs@oss.sgi.com Fri May 17 13:10:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HKAanC015437 for ; Fri, 17 May 2002 13:10:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HKAao4015436 for linux-xfs-outgoing; Fri, 17 May 2002 13:10:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fruit.eu.org (qmailr@h149.wib.euronet.nl [194.134.114.149]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HKAUnC015410 for ; Fri, 17 May 2002 13:10:31 -0700 Received: (qmail 17425 invoked by uid 500); 17 May 2002 20:11:05 -0000 Date: Fri, 17 May 2002 22:11:05 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: xfsdump sample scripts Message-ID: <20020517201105.GE633@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020516203017.QLEB28927.imf03bis.bellsouth.net@taz> User-Agent: Mutt/1.3.28i X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk oi! While we're discussing backup schemas, is there a way to make decremental backups with xfsdump? I'm referring to a system where the latest backup is always a full dump and older files are kept in archives that describe the differences relative to their successor. In a really fancy setup, (daily/weekly) differential archives could be merged to form (weekly/monthly) archives, at will. I suppose this is not really suitable for a tape based backup scenario but I'm using it for my PostgreSQL backups[0] and so far it has been very useful. Just daydreaming, -- Wessel Dankers [0] PostgreSQL uses plain text dumps, a record per line, so I could simply use a diff-based approach. From owner-linux-xfs@oss.sgi.com Fri May 17 14:14:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HLEwnC016375 for ; Fri, 17 May 2002 14:14:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HLEw8u016374 for linux-xfs-outgoing; Fri, 17 May 2002 14:14:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HLErnC016339 for ; Fri, 17 May 2002 14:14:54 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 178p2T-00006K-00 for linux-xfs@oss.sgi.com; Fri, 17 May 2002 15:13:25 -0600 Message-ID: <3CE572ED.2080005@emergence.com> Date: Fri, 17 May 2002 15:15:25 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> <1021576512.21567.25.camel@stantz.corp.sgi.com> <3CE5563A.6090501@emergence.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Noticed a small discrepency and removed glibc-kernheaders from the comps file and removed the glibc-kernheaders file. I didn't update the hdlist files at this time. -Mike Michael Best wrote: > I have prepared a short page here at: > http://www.pendragon.org/projects/valhalla-xfs/index_html > > -Mike > > Florin Andrei wrote: > >> Michael, >> >> Can you put the results of your work online? >> I think i'll try to play a little bit with the booting disc image. I did >> some customised Red Hat installers in the past, so i think there should >> be no problem now. From owner-linux-xfs@oss.sgi.com Fri May 17 14:20:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HLKCnC016559 for ; Fri, 17 May 2002 14:20:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HLKC6Z016558 for linux-xfs-outgoing; Fri, 17 May 2002 14:20:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-154-216.client.attbi.com [12.234.154.216]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HLK7nC016532 for ; Fri, 17 May 2002 14:20:07 -0700 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by weiqi.home.local (Postfix) with SMTP id 07EF4309B5 for ; Fri, 17 May 2002 14:20:44 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 74F09309B4 for ; Fri, 17 May 2002 14:20:43 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 0C55413641F for ; Fri, 17 May 2002 14:20:33 -0700 (PDT) Subject: Re: Status on RH7.3 installer ? From: Florin Andrei To: linux-xfs In-Reply-To: <3CE572ED.2080005@emergence.com> References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> <1021576512.21567.25.camel@stantz.corp.sgi.com> <3CE5563A.6090501@emergence.com> <3CE572ED.2080005@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 17 May 2002 14:20:33 -0700 Message-Id: <1021670433.1307.7.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-05-17 at 14:15, Michael Best wrote: > Noticed a small discrepency and removed glibc-kernheaders from the comps > file and removed the glibc-kernheaders file. > > I didn't update the hdlist files at this time. > > -Mike > > Michael Best wrote: > > I have prepared a short page here at: > > http://www.pendragon.org/projects/valhalla-xfs/index_html So the only thing left to do is to generate the cdboot.img and the initrd.img, right? -- Florin Andrei Spiderman according to Jon Katz: "the web-slinging arachnoid-nerd from Queens who gets the bad guy but really wants the girl." From owner-linux-xfs@oss.sgi.com Fri May 17 14:26:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HLQHnC016743 for ; Fri, 17 May 2002 14:26:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HLQHoL016742 for linux-xfs-outgoing; Fri, 17 May 2002 14:26:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HLQAnC016716 for ; Fri, 17 May 2002 14:26:10 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 178pDO-00006q-00 for linux-xfs@oss.sgi.com; Fri, 17 May 2002 15:24:42 -0600 Message-ID: <3CE57592.5030309@emergence.com> Date: Fri, 17 May 2002 15:26:42 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Status on RH7.3 installer ? References: <1021411822.19054.6.camel@dumbo.zwecker.de> <3CE1837E.4010606@emergence.com> <1021412646.19054.13.camel@dumbo.zwecker.de> <3CE18B3F.1060605@emergence.com> <1021576512.21567.25.camel@stantz.corp.sgi.com> <3CE5563A.6090501@emergence.com> <3CE572ED.2080005@emergence.com> <1021670433.1307.7.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Before the first test, I expect it to go badly mind you. Eric also wrote this about the installer needing a bit flipped for the anaconda installer. -Mike Eric Sandeen wrote: > > At a minimum, you'd need to change "self.supported = 0" to "1" in class > xfsFileSystem in the fsset.py file... > > You're going about it a different way, I think, more directly modifying > the RH ISOs with a binary diff; we made a stand-alone ISO, so we had to > let Anaconda know about a 3rd CD (now would be 4th) to get kernels & > utilities for XFS. > > There may be other things, but that's a start. Florin Andrei wrote: > On Fri, 2002-05-17 at 14:15, Michael Best wrote: > >>Noticed a small discrepency and removed glibc-kernheaders from the comps >>file and removed the glibc-kernheaders file. >> >>I didn't update the hdlist files at this time. >> >>-Mike >> >>Michael Best wrote: >> >>>I have prepared a short page here at: >>>http://www.pendragon.org/projects/valhalla-xfs/index_html >> > > So the only thing left to do is to generate the cdboot.img and the > initrd.img, right? From owner-linux-xfs@oss.sgi.com Fri May 17 19:19:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I2JenC021199 for ; Fri, 17 May 2002 19:19:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I2JegT021198 for linux-xfs-outgoing; Fri, 17 May 2002 19:19:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dc-mx03.cluster1.charter.net (dc-mx03.cluster1.charter.net [209.225.8.13]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I2JbnC021170 for ; Fri, 17 May 2002 19:19:38 -0700 Received: from [216.207.95.43] (HELO there) by dc-mx03.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 13237097 for linux-xfs@oss.sgi.com; Fri, 17 May 2002 22:17:40 -0400 Content-Type: text/plain; charset="iso-8859-15" From: Raymond To: linux-xfs@oss.sgi.com Subject: XFS-Enabled Redhat 7.3 ISO Date: Fri, 17 May 2002 19:21:46 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone know when the XFS-enabled Redhat 7.3 iso will be available??? From owner-linux-xfs@oss.sgi.com Sat May 18 01:55:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I8t1nC000562 for ; Sat, 18 May 2002 01:55:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I8t1bK000561 for linux-xfs-outgoing; Sat, 18 May 2002 01:55:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I8stnC000531 for ; Sat, 18 May 2002 01:54:56 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.33 #1) id 178zzx-0000RV-00 for linux-xfs@oss.sgi.com; Sat, 18 May 2002 10:55:33 +0200 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.15 #1) id 178zxn-00061h-00 for linux-xfs@oss.sgi.com; Sat, 18 May 2002 10:53:19 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 10:53:25 +0200 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181053.25654.jojo@automatix.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, did anyone successfully tried to build a mosix cluster with XFS ? Reffer to http://www.mosix.org http://www.openmosix.org mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmFoUACgkQW7UKI9EqarHgGQCgoOrvqCVetsUkLsxHlAFNRP1Y klsAn0IgIozy/ae2yuhwEGWkgXjYXszX =kRis -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat May 18 03:27:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IARCnC005386 for ; Sat, 18 May 2002 03:27:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IARCja005385 for linux-xfs-outgoing; Sat, 18 May 2002 03:27:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail018.syd.optusnet.com.au (mail018.syd.optusnet.com.au [210.49.20.176]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IAR7nC005353 for ; Sat, 18 May 2002 03:27:08 -0700 Received: from localhost.localdomain (c17835.eburwd2.vic.optusnet.com.au [210.49.188.189]) by mail018.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g4IARND11628; Sat, 18 May 2002 20:27:23 +1000 Subject: Re: Bad Blocks From: Menaka Lashitha Bandara To: Menaka Lashitha Bandara Cc: Sean Neakums , Linux XFS In-Reply-To: <1021629256.464.5.camel@revolution> References: <1021627338.469.2.camel@revolution> <6u3cwr6rn7.fsf@zork.zork.net> <1021629256.464.5.camel@revolution> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 18 May 2002 20:27:13 +1000 Message-Id: <1021717634.381.3.camel@revolution> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I rebooted my powerpc machine with gentoo recovery disk, and ran xfs_repair. This cloncked out on the apparent bad sector. badblocks couldn't read from it either. But when I finally decided to mkfs.xfs /dev/hda2 -f, everything was back to normal. To be on the safe side, I left my desktop running all night with a destructive badblocks scan, and it still didn't find a bad sector. Maybe driver fault? Or could xfs confuse the driver at all (I can't think of any resonable way of this happening)? \LaShI From owner-linux-xfs@oss.sgi.com Sat May 18 04:28:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IBSRnC009486 for ; Sat, 18 May 2002 04:28:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IBSRpJ009485 for linux-xfs-outgoing; Sat, 18 May 2002 04:28:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IBSInC009444 for ; Sat, 18 May 2002 04:28:19 -0700 Received: from erbenson.alaska.net (42-pm21.nwc.alaska.net [209.112.143.42]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g4IBSuX55304 for ; Sat, 18 May 2002 03:28:56 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id EF7AD393A for ; Sat, 18 May 2002 03:28:54 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id B78781028E; Sat, 18 May 2002 03:28:54 -0800 (AKDT) Date: Sat, 18 May 2002 03:28:54 -0800 From: Ethan Benson To: Linux XFS Subject: Re: Bad Blocks Message-ID: <20020518032854.A3467@plato.local.lan> Mail-Followup-To: Linux XFS References: <1021627338.469.2.camel@revolution> <6u3cwr6rn7.fsf@zork.zork.net> <1021629256.464.5.camel@revolution> <1021717634.381.3.camel@revolution> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1021717634.381.3.camel@revolution>; from lashi@lashitha.org on Sat, May 18, 2002 at 08:27:13PM +1000 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 18, 2002 at 08:27:13PM +1000, Menaka Lashitha Bandara wrote: > Hi all, >=20 > I rebooted my powerpc machine with gentoo recovery disk, and ran > xfs_repair. This cloncked out on the apparent bad sector. badblocks > couldn't read from it either. But when I finally decided to mkfs.xfs > /dev/hda2 -f, everything was back to normal. To be on the safe side, I > left my desktop running all night with a destructive badblocks scan, and > it still didn't find a bad sector. >=20 > Maybe driver fault? Or could xfs confuse the driver at all (I can't > think of any resonable way of this happening)? what kernel are you running? older 2.4 and 2.2 kernels will possibly have problems with the IDE in the ibook2, also i have seen reports of screwy behavior with the 2.4.19-pre-benh branch. 2.4.18 from kernel.org should be fine. also im sure your not, but if you were booting with BootX instead of yaboot that would likly explain it, only yaboot can be used on NewWorld PowerMacs. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmOvYACgkQJKx7GixEevwJxgCeJBMh+qZQbOzQNJ7YSx2MuaN2 /eAAnRKvnTh3hwp9u4Q8fx84WgNC3t1s =1J/q -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-linux-xfs@oss.sgi.com Sat May 18 05:19:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ICJNnC013532 for ; Sat, 18 May 2002 05:19:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ICJN3J013531 for linux-xfs-outgoing; Sat, 18 May 2002 05:19:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from christooley.cjb.net (user-0ccsns3.cable.mindspring.com [24.206.95.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ICJHnC013499 for ; Sat, 18 May 2002 05:19:17 -0700 Received: (from ctooley@localhost) by christooley.cjb.net (8.11.6/8.11.6) id g4ICEw302542; Sat, 18 May 2002 07:14:58 -0500 X-Authentication-Warning: christooley.cjb.net: ctooley set sender to ctooley@amoa.org using -f Subject: Re: MosiX Cluster with XFS - Tried anyone ? From: Chris Tooley To: Juergen Sauer Cc: linux-xfs@oss.sgi.com In-Reply-To: <200205181053.25654.jojo@automatix.de> References: <200205181053.25654.jojo@automatix.de> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-3) Date: 18 May 2002 07:14:57 -0500 Message-Id: <1021724097.2378.1.camel@christooley.cjb.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4ICJHnC013500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Moshe Bar, who develops openMosix explicitly supports XFS as he thinks it is a higher performance filesystem than most of the other offerings for linux. There is a lot of information about it on the openMosix website. Or at least their used to be. Chris Tooley On Sat, 2002-05-18 at 03:53, Juergen Sauer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Moin, > did anyone successfully tried to build a mosix cluster > with XFS ? > Reffer to > http://www.mosix.org > http://www.openmosix.org > > mfG > Jojo > - -- > Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** > ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** > http://www.automatix.de to Mail me: remove: -not-for-spawm- ** > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iEYEARECAAYFAjzmFoUACgkQW7UKI9EqarHgGQCgoOrvqCVetsUkLsxHlAFNRP1Y > klsAn0IgIozy/ae2yuhwEGWkgXjYXszX > =kRis > -----END PGP SIGNATURE----- > From owner-linux-xfs@oss.sgi.com Sat May 18 07:34:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IEYenC024153 for ; Sat, 18 May 2002 07:34:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IEYeWh024152 for linux-xfs-outgoing; Sat, 18 May 2002 07:34:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IEYVnC024115 for ; Sat, 18 May 2002 07:34:32 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.33 #1) id 1795Ic-0000xp-00 for linux-xfs@oss.sgi.com; Sat, 18 May 2002 16:35:10 +0200 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.15 #1) id 1795G9-0000wc-00; Sat, 18 May 2002 16:32:37 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: Chris Tooley Subject: Re: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 16:32:41 +0200 User-Agent: KMail/1.4.5 Cc: linux-xfs@oss.sgi.com References: <200205181053.25654.jojo@automatix.de> <1021724097.2378.1.camel@christooley.cjb.net> In-Reply-To: <1021724097.2378.1.camel@christooley.cjb.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181632.46109.jojo@automatix.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 18. Mai 2002 14:14 schrieb Chris Tooley: > Moshe Bar, who develops openMosix explicitly supports XFS as he thinks > it is a higher performance filesystem than most of the other offerings > for linux. There is a lot of information about it on the openMosix > website. Or at least their used to be. Yes, I did know this before. But it is not usable. 1. Getting CVS Version of openmosix [does not contain XFS] 2. getting the XFS-Patch for 2.4.17 3. Installing the patch works with some linefuzzes, configuring, works, builing the xfs-mosix-kernel definitley not: pc2:/usr/src/linux-openmosix # make gcc -D__KERNEL__ -I/usr/src/linux-openmosix/include -Wall - -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer - -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 - -march=i686 -c -o init/main.o init/main.c In file included from /usr/src/linux-openmosix/include/linux/capability.h:17, from /usr/src/linux-openmosix/include/linux/binfmts.h:5, from /usr/src/linux-openmosix/include/linux/sched.h:9, from /usr/src/linux-openmosix/include/linux/mm.h:4, from /usr/src/linux-openmosix/include/linux/slab.h:14, from /usr/src/linux-openmosix/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux-openmosix/include/linux/fs.h:530: field `xfs_i' has incomplete type make: *** [init/main.o] Fehler 1 pc2:/usr/src/linux-openmosix # That's why I asked, if somewhere a XFS-Mosix ist already installed and working. Any ideas here ? mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmZgwACgkQW7UKI9EqarFVxwCcCY6P613hm3G9lSPUWFg8/efk r3YAn3feDtyKK0HalKEji3eLrJ3P5CxP =ST5H -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat May 18 08:35:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IFZanC029736 for ; Sat, 18 May 2002 08:35:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IFZauR029735 for linux-xfs-outgoing; Sat, 18 May 2002 08:35:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IFZVnC029694 for ; Sat, 18 May 2002 08:35:32 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g4IFa9x21752 for linux-xfs@oss.sgi.com.KAV; Sat, 18 May 2002 17:36:09 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g4IFa8921744 for ; Sat, 18 May 2002 17:36:09 +0200 (CEST) Received: from venus.local.navi.pl (localhost.localdomain [127.0.0.1]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g4IF3Yr04464 for ; Sat, 18 May 2002 17:03:34 +0200 Date: Sat, 18 May 2002 17:03:33 +0200 From: Olaf Fr±czyk To: linux-xfs@oss.sgi.com Subject: How to audit file access ? Message-ID: <20020518150333.GA4358@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Disposition: inline X-Mailer: Balsa 1.3.3 Lines: 8 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I would like to audit file access (open/close/create/remove etc.). Does somebody knows any tools for it which work with XFS? Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Sat May 18 09:59:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IGxmnC004473 for ; Sat, 18 May 2002 09:59:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IGxm4Y004472 for linux-xfs-outgoing; Sat, 18 May 2002 09:59:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dc-mx04.cluster1.charter.net (dc-mx04.cluster1.charter.net [209.225.8.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IGxjnC004428 for ; Sat, 18 May 2002 09:59:45 -0700 Received: from [216.207.95.43] (HELO there) by dc-mx04.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 14499184 for linux-xfs@oss.sgi.com; Sat, 18 May 2002 12:59:57 -0400 Content-Type: text/plain; charset="iso-8859-15" From: Raymond To: linux-xfs@oss.sgi.com Subject: Suse 8.0 XFS Update Date: Sat, 18 May 2002 10:01:53 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Suse v8.0 has XFS v1.02 support. Will the 2.4.31 kernel and utility XFS RPM's update SUSE to XFS 1.1? How do the XFS kernel RPMs differ from Suse's builds? Raymond From owner-linux-xfs@oss.sgi.com Sat May 18 11:04:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4II4anC012087 for ; Sat, 18 May 2002 11:04:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4II4agV012086 for linux-xfs-outgoing; Sat, 18 May 2002 11:04:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4II4WnC012057 for ; Sat, 18 May 2002 11:04:32 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA09897; Sat, 18 May 2002 13:05:06 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA22018; Sat, 18 May 2002 13:03:49 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA34242; Sat, 18 May 2002 13:03:49 -0500 (CDT) Message-Id: <200205181803.NAA34242@slobber.americas.sgi.com> To: Olaf Fr1czyk cc: linux-xfs@oss.sgi.com Subject: Re: How to audit file access ? Date: Sat, 18 May 2002 13:03:48 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Olaf Fr1czyk >Hi, > >I would like to audit file access (open/close/create/remove etc.). >Does somebody knows any tools for it which work with XFS? You can check on the status of fam/imon: http://oss.sgi.com/projects/fam/news.html The Linux imon project looks like it's independent of XFS, so if it works :) it should work with any filesystem on Linux. Dean From owner-linux-xfs@oss.sgi.com Sat May 18 11:10:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IIAEnC012299 for ; Sat, 18 May 2002 11:10:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IIAErW012298 for linux-xfs-outgoing; Sat, 18 May 2002 11:10:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IIA8nC012272 for ; Sat, 18 May 2002 11:10:08 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA07144; Sat, 18 May 2002 13:10:43 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA93641; Sat, 18 May 2002 13:09:27 -0500 (CDT) Date: Sat, 18 May 2002 13:09:32 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Raymond cc: Subject: Re: Suse 8.0 XFS Update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Raymond - I'd need to look at SuSE's SRPM to know for sure what's in it, but it probably has several specific patches in it, that will be different from the patches in the 2.4.9-31 RPMs we have that are based on Red Hat's kernel sources. You could probably update your SuSE box with the 2.4.9-31 RPMs, but some things may break, not sure. The kernels have different patches and probably different configurations. The userspace RPMs are a different story; the userspace RPMs from XFS 1.1 will likely work just fine, as long as the SuSE kernel RPM has the new EA interface (I'm 99.9% certain that it does) and a non-broken BLKGETSIZE64 ioctl. Of course Andi can probably chime in and let you know for sure. -Eric On Sat, 18 May 2002, Raymond wrote: > Suse v8.0 has XFS v1.02 support. > > Will the 2.4.31 kernel and utility XFS RPM's update SUSE to XFS 1.1? > > How do the XFS kernel RPMs differ from Suse's builds? > > Raymond > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat May 18 11:19:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IIJNnC012493 for ; Sat, 18 May 2002 11:19:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IIJNLJ012492 for linux-xfs-outgoing; Sat, 18 May 2002 11:19:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IIJKnC012465 for ; Sat, 18 May 2002 11:19:20 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 4602C1EB52; Sat, 18 May 2002 20:19:54 +0200 (MEST) Date: Sat, 18 May 2002 20:19:53 +0200 From: Andi Kleen To: Raymond Cc: linux-xfs@oss.sgi.com Subject: Re: Suse 8.0 XFS Update Message-ID: <20020518201953.A31722@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, May 18, 2002 at 10:01:53AM -0700, Raymond wrote: > Suse v8.0 has XFS v1.02 support. The XFS in the SuSE 8.0 kernel is very near XFS 1.1 including most/all of the important bug fixes. Probably not worth updating just for the 1.1 tag. -Andi From owner-linux-xfs@oss.sgi.com Sun May 19 09:00:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JG0fnC025405 for ; Sun, 19 May 2002 09:00:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JG0fp0025404 for linux-xfs-outgoing; Sun, 19 May 2002 09:00:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.blazebox.homeip.net (pool-141-155-136-201.ny5030.east.verizon.net [141.155.136.201]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JG0PnC025307 for ; Sun, 19 May 2002 09:00:26 -0700 Received: from blaze.homeip.net (blaze [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id B7289E5 for ; Sun, 19 May 2002 12:00:09 -0400 (EDT) Subject: DMAPI as module (kernel compilation failure). From: Paul Blazejowski To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KMbpbpIPthnexis3F8T1" X-Mailer: Ximian Evolution 1.0.5 Date: 19 May 2002 12:01:33 -0400 Message-Id: <1021824094.1955.15.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-KMbpbpIPthnexis3F8T1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello folks, I'm not sure if this has been answered on the list.Sorry if it was. .config snip: CONFIG_XFS_FS=3Dy CONFIG_XFS_RT=3Dy CONFIG_XFS_QUOTA=3Dy CONFIG_XFS_DMAPI=3Dm CONFIG_HAVE_XFS_DMAPI=3Dy Building kernel 2.4.18 with CVS patch and DMAPI enabled as module (M) gives this compilation error: make[1]: Entering directory `/usr/src/linux-2.4.18' ld -m elf_i386 -T /usr/src/linux-2.4.18/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/acpi/acpi.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o net/network.o /usr/src/linux-2.4.18/arch/i386/lib/lib.a /usr/src/linux-2.4.18/lib/lib.a /usr/src/linux-2.4.18/arch/i386/lib/lib.a --end-group -o vmlinux fs/fs.o: In function `xfs_dm_send_data_event': fs/fs.o(.text+0x2d1d9): undefined reference to `dm_send_data_event' fs/fs.o: In function `xfs_dm_send_create_event': fs/fs.o(.text+0x2d291): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_dm_bulkstat_one': fs/fs.o(.text+0x2d69a): undefined reference to `dm_vp_to_handle' fs/fs.o: In function `xfs_dm_mount': fs/fs.o(.text+0x305ed): undefined reference to `dm_send_mount_event' fs/fs.o(.text+0x30601): undefined reference to `dm_hookup_vfsmount' fs/fs.o: In function `xfs_rename': fs/fs.o(.text+0x7be9a): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x7c784): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_unmount': fs/fs.o(.text+0x81f1d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x81ff6): undefined reference to `dm_send_unmount_event' fs/fs.o: In function `xfs_setattr': fs/fs.o(.text+0x84061): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_inactive': fs/fs.o(.text+0x84ed5): undefined reference to `dm_send_destroy_event' fs/fs.o: In function `xfs_create': fs/fs.o(.text+0x85d80): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_remove': fs/fs.o(.text+0x8636a): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x8679c): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_link': fs/fs.o(.text+0x86910): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x86cd9): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x872ec): more undefined references to `dm_send_namesp_event' follow make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.18' make: *** [vmlinux] Error 2 But when DMAPI is enabled (Y) in kernel, there's no problem with compilation.Any ideas or suggestions would be appreciated.Thanks. Paul B. --=-KMbpbpIPthnexis3F8T1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA858xdOkMJCMfleaIRAsZAAKCHW+yKEx9//w2eLaYzY33JgowZEgCeLcmO jPXJNMpYHYJrOz33Ht1/Ya4= =ZKBw -----END PGP SIGNATURE----- --=-KMbpbpIPthnexis3F8T1-- From owner-linux-xfs@oss.sgi.com Sun May 19 17:43:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K0hSnC014249 for ; Sun, 19 May 2002 17:43:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K0hSDq014248 for linux-xfs-outgoing; Sun, 19 May 2002 17:43:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K0hLnC014183 for ; Sun, 19 May 2002 17:43:21 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA01654 for ; Sun, 19 May 2002 17:44:03 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA89008 for linux-xfs@oss.sgi.com; Mon, 20 May 2002 10:42:43 +1000 (EST) Date: Mon, 20 May 2002 10:42:43 +1000 (EST) From: Nathan Scott Message-Id: <200205200042.KAA89008@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - misc, minor Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu May 16 18:05:22 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119403a linux/fs/xfs/linux/xfs_iops.c - 1.139 - make linvfs_get_block_core STATIC; + play code consistency fairy. Date: Thu May 16 20:17:50 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:119415a cmd/xfsprogs/repair/phase4.c - 1.5 - make us more tolerant in the face of failure - continue gracefully, don't dump core. theres still a problem lurking here somewhere for 1K blocksizes though.. Date: Sun May 19 17:40:44 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119513a linux/fs/xfs/xfs_qm_syscalls.c - 1.59 - additional diagnostics to help track down this EINVAL/quotaon issue. From owner-linux-xfs@oss.sgi.com Sun May 19 19:01:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K21VnC003210 for ; Sun, 19 May 2002 19:01:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K21VSm003209 for linux-xfs-outgoing; Sun, 19 May 2002 19:01:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K21KnC003146 for ; Sun, 19 May 2002 19:01:20 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA03799 for ; Sun, 19 May 2002 19:02:02 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4K20xPF6879837; Sun, 19 May 2002 19:01:01 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id F0D463000B8; Mon, 20 May 2002 12:00:58 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B05D194; Mon, 20 May 2002 12:00:58 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Paul Blazejowski Cc: linux-xfs@oss.sgi.com, roehrich@sgi.com Subject: Re: DMAPI as module (kernel compilation failure). In-reply-to: Your message of "19 May 2002 12:01:33 -0400." <1021824094.1955.15.camel@blaze> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 May 2002 12:00:53 +1000 Message-ID: <2244.1021860053@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19 May 2002 12:01:33 -0400, Paul Blazejowski wrote: >I'm not sure if this has been answered on the list.Sorry if it was. >CONFIG_XFS_FS=y >CONFIG_XFS_RT=y >CONFIG_XFS_QUOTA=y >CONFIG_XFS_DMAPI=m >CONFIG_HAVE_XFS_DMAPI=y Originally sent April 19, 2002. I don't recall getting a definitive answer on whether we want to support XFS built in with DMAPI as a module or not. Dean? From: Keith Owens To: matthew@arts.usyd.edu.au Cc: linux-xfs@oss.sgi.com, roehrich@sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS In-reply-to: Your message of "Fri, 19 Apr 2002 10:36:52 +1000." <1019176612.3cbf66a453076@admin.arts.usyd.edu.au> Date: Fri, 19 Apr 2002 12:02:42 +1000 On Fri, 19 Apr 2002 10:36:52 +1000, matthew@arts.usyd.edu.au wrote: > Not sure why you would want to - but I accidently selected DMAPI m instead of n >and the resulting kernel would not link due to what appeared to be missing DMAPI >function calls. > > I guess some one should get into kbuild and remove the option to build it as a >module ? Dean, as currently coded XFS has unconditional calls to DMAPI. This means that when XFS is built in then DMAPI cannot be a module. The patch below enforces this rule but I am not going to check it in until you decide if the code is correct or not. If XFS built in with DMAPI in a module is desirable then forget this patch, the DMAPI code has to be changed to use a register function and XFS to make conditional calls to DMAPI via the registered data. =========================================================================== Index: linux/fs/Config.in =========================================================================== --- /usr/tmp/TmpDir.27777-0/linux/fs/Config.in_1.77 Fri Apr 19 11:58:11 2002 +++ linux/fs/Config.in Fri Apr 19 11:50:22 2002 @@ -100,8 +100,16 @@ dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS if [ "$CONFIG_XFS_FS" != "n" ]; then + # Current DMAPI code has calls from XFS to DMAPI. This requires that + # DMAPI be built in if selected and XFS is built in. Valid combinations + # XFS=n, DMAPI=n + # XFS=y, DMAPI=[yn] + # XFS=m, DMAPI=[mn] dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS if [ "$CONFIG_XFS_DMAPI" != "n" ]; then + if [ "$CONFIG_XFS_FS" = "y" ]; then + define_tristate CONFIG_XFS_DMAPI y + fi define_bool CONFIG_HAVE_XFS_DMAPI y fi fi From owner-linux-xfs@oss.sgi.com Sun May 19 20:16:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K3GnnC019612 for ; Sun, 19 May 2002 20:16:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K3GnSf019611 for linux-xfs-outgoing; Sun, 19 May 2002 20:16:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K3GfnC019550 for ; Sun, 19 May 2002 20:16:41 -0700 Received: from musume.snl.home ([67.36.181.87]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20020520025942.SFB4339.mail1-0.chcgil.ameritech.net@musume.snl.home> for ; Sun, 19 May 2002 21:59:42 -0500 Subject: XFS in the 2.5 kernel From: Stuart Luppescu To: Linux-xfs list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BAHvtmA0vWpi0yjqJM2Q" X-Mailer: Ximian Evolution 1.0.5 Date: 19 May 2002 22:07:39 -0500 Message-Id: <1021864059.2008.56.camel@musume.snl.home> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-BAHvtmA0vWpi0yjqJM2Q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable There was a little thread recently on Linux Today about official inclusion of XFS in the 2.5 kernel. One interchange went like this: > when is XFS going in? anyone know ? Not anytime soon. The parts of XFS that overlap with generic kernel code have to be cut out and put into pieces that can be used by other filesystems. This response was written someone named whateva (rakarnik@yahoo.com). The question is, does he know what he's talking about? --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.18-xfs=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The aim of science is to seek the simplest explanations of complex facts. Seek simplicity and distrust it. -- Whitehead.=20 =20 --=-BAHvtmA0vWpi0yjqJM2Q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjzoaHsACgkQDBHcBS0tWxNF/ACgw+aEZFU/SjCtBIdxhUYMm8Hb TGIAn1DPspgbjgW7u00Bg0zGDUrbZ/Fh =sfbd -----END PGP SIGNATURE----- --=-BAHvtmA0vWpi0yjqJM2Q-- From owner-linux-xfs@oss.sgi.com Mon May 20 00:23:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K7NfnC030404 for ; Mon, 20 May 2002 00:23:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K7Nf3P030403 for linux-xfs-outgoing; Mon, 20 May 2002 00:23:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K7NWnC030376 for ; Mon, 20 May 2002 00:23:33 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g4K7ONR23161; Mon, 20 May 2002 09:24:24 +0200 Date: Mon, 20 May 2002 09:24:23 +0200 (CEST) From: Matteo Centonza To: Greg Freemyer cc: Linux XFS Mailing List Subject: re: [OT] Re: xfsdump sample scripts In-Reply-To: <20020517162540.JMPC25163.imf26bis.bellsouth.net@taz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Greg, > I actually went and briefly looked at the Amanda website a couple of months > ago. > It sounded as if it was targeting a collection of Linux servers being backed > up to a single tape drive. > > I'm just backing up one server to local large disk drive. (This is just what > the sample script does as well. :) ) > > Does using Amanda in this type of an environment simplify life, or make it > worse. > > In particular, I want to come up with a end-user friendly restore mechanism. > > My plan is to keep the last 30 days of backups online and I would like to > give end-users the ability to restore their own files. Hopefully via a > http interface. > > I'm not sure if that is feasible yet or not, but that is my goal. Well, in few words, it does. More precisely: -- While has been developed for a networking enviroment, should do the trick locally too. -- Amanda can take "degraded backup" to an holding disk if you have no tape drive available (your case probably). -- Has a nice ftp like interactive recover interface. -- If you want, can plan your backup schedule for you. It's worth a shot ;) HTH, -m From owner-linux-xfs@oss.sgi.com Mon May 20 03:36:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KAaNnC020605 for ; Mon, 20 May 2002 03:36:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KAaNHn020604 for linux-xfs-outgoing; Mon, 20 May 2002 03:36:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KAaHnC020578 for ; Mon, 20 May 2002 03:36:18 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id F17D71E5DA; Mon, 20 May 2002 12:36:59 +0200 (MEST) Date: Mon, 20 May 2002 12:36:57 +0200 From: Andi Kleen To: Stuart Luppescu Cc: Linux-xfs list Subject: Re: XFS in the 2.5 kernel Message-ID: <20020520123657.A19992@wotan.suse.de> References: <1021864059.2008.56.camel@musume.snl.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021864059.2008.56.camel@musume.snl.home> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, May 19, 2002 at 10:07:39PM -0500, Stuart Luppescu wrote: > There was a little thread recently on Linux Today about official > inclusion of XFS in the 2.5 kernel. One interchange went like this: > > > when is XFS going in? anyone know ? > Not anytime soon. The parts of XFS that overlap with generic kernel code > have to be cut out and put into pieces that can be used by other > filesystems. > > This response was written someone named whateva (rakarnik@yahoo.com). > The question is, does he know what he's talking about? I don't think so. While it would be nice if XFS used more common infrastructure or its infrastructure (pagebuf) would be more open to other fs it is not an absolute requirement for merging. That's IMHO based on merging of other file system and code, the last word has Linus of course. More important is probably some more cleanup of the XFS code to "linuxify" it a bit more, but that can also occur once it is merged. -Andi From owner-linux-xfs@oss.sgi.com Mon May 20 05:14:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KCECnC022082 for ; Mon, 20 May 2002 05:14:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KCEC4I022081 for linux-xfs-outgoing; Mon, 20 May 2002 05:14:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KCE6nC022054 for ; Mon, 20 May 2002 05:14:08 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 179m3s-0003On-00; Mon, 20 May 2002 13:14:48 +0100 Date: Mon, 20 May 2002 13:14:48 +0100 From: Christoph Hellwig To: Andi Kleen Cc: Stuart Luppescu , Linux-xfs list Subject: Re: XFS in the 2.5 kernel Message-ID: <20020520131448.A12985@infradead.org> References: <1021864059.2008.56.camel@musume.snl.home> <20020520123657.A19992@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020520123657.A19992@wotan.suse.de>; from ak@suse.de on Mon, May 20, 2002 at 12:36:57PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 12:36:57PM +0200, Andi Kleen wrote: > I don't think so. While it would be nice if XFS used more common > infrastructure or its infrastructure (pagebuf) would be more open to > other fs it is not an absolute requirement for merging. That's IMHO > based on merging of other file system and code, the last word has Linus > of course. Pagebuf is basically useable by other filesystems. For example I think I could port JFS to use it as backing for it's metapges - it just far too complex for JFS's needs so I don't see any point in doing so. From owner-linux-xfs@oss.sgi.com Mon May 20 05:35:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KCZZnC022360 for ; Mon, 20 May 2002 05:35:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KCZZvH022359 for linux-xfs-outgoing; Mon, 20 May 2002 05:35:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KCZTnC022333 for ; Mon, 20 May 2002 05:35:29 -0700 Received: from mail.tvol.net ([66.150.46.254]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA00342 for ; Mon, 20 May 2002 05:36:11 -0700 (PDT) mail_from (msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LDMBHWXM; Mon, 20 May 2002 08:31:03 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g4KCY4H38692; Mon, 20 May 2002 08:34:04 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3CE8ED3B.2090401@wgate.com> Date: Mon, 20 May 2002 08:34:03 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc1) Gecko/20020509 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: Strange behavior on the 2.4.18 XFS tree? References: <22203.1021466116@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Wed, 15 May 2002 07:30:09 -0400, > Michael Sinz wrote: > >>I have only been able to see this behavior on my system running the >>kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. >> >>The problem is that I started up a number of "rxvt" sessions and they >>took well over a minute to start up. During that time, the cpu >>utilization was almost nil. (Less than 1%) >> >>There was a background find operation happening, and this seems to be >>the key item. > > When the problem occurs, does typing sync get everything running again? > I have been seeing an intermittent lock problem with XFS where > everything stops until some other disk activity kicks in and the lock > is released. A build of 2.4.18-XFS from CVS on Friday night seems to not show the problem. At least not over the last 2+ days. It could also be that I did not run into it either. Just providing some more information as it develops :-) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon May 20 06:17:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KDHLnC022815 for ; Mon, 20 May 2002 06:17:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KDHKTj022814 for linux-xfs-outgoing; Mon, 20 May 2002 06:17:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chacho.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KDHAnC022788 for ; Mon, 20 May 2002 06:17:14 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by chacho.sgo.es (8.11.6/8.11.6) id g4KDJtg10354 for linux-xfs@oss.sgi.com; Mon, 20 May 2002 15:19:55 +0200 Message-Id: <200205201319.g4KDJtg10354@chacho.sgo.es> Content-Type: text/plain; charset="iso-8859-15" From: Miguel ANgel To: linux-xfs@oss.sgi.com Subject: XFS in redhat 7.2 max filesize limit?? Date: Mon, 20 May 2002 15:18:54 +0200 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by chacho.sgo.es id g4KDJtg10354 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KDHHnC022789 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a problem with XFS, when I tried to write a file of more of 2 Gygabyte the system returns me this error "Superado el límite de tamaño de fichero" that is "max filesize limit was reached" (more or less xD). My system is a Dual Pentium 2, with redhat 7.2 and kernel 2.4.9-13 with XFS 1.0.2. Have this a filesize limitation?? has this limitation the latest release of XFS? or this is a problem of linux?? thanks Michi From owner-linux-xfs@oss.sgi.com Mon May 20 06:43:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KDhXnC023197 for ; Mon, 20 May 2002 06:43:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KDhXZu023196 for linux-xfs-outgoing; Mon, 20 May 2002 06:43:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KDhSnC023170 for ; Mon, 20 May 2002 06:43:28 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA42817; Mon, 20 May 2002 08:44:11 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA05076; Mon, 20 May 2002 08:42:55 -0500 (CDT) Date: Mon, 20 May 2002 08:43:00 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Miguel ANgel cc: Subject: Re: XFS in redhat 7.2 max filesize limit?? In-Reply-To: <200205201319.g4KDJtg10354@chacho.sgo.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ledzep.americas.sgi.com id IAA42817 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KDhTnC023171 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What shell are you using? tcsh had some problems with large files, if I remember right. -Eric On Mon, 20 May 2002, Miguel ANgel wrote: > Hi, > > I have a problem with XFS, when I tried to write a file of more of 2 Gygabyte > the system returns me this error "Superado el límite de tamaño de fichero" > that is "max filesize limit was reached" (more or less xD). > > My system is a Dual Pentium 2, with redhat 7.2 and kernel 2.4.9-13 with XFS > 1.0.2. Have this a filesize limitation?? has this limitation the latest > release of XFS? or this is a problem of linux?? > > thanks > Michi > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 20 07:22:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KEMcnC023615 for ; Mon, 20 May 2002 07:22:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KEMciQ023614 for linux-xfs-outgoing; Mon, 20 May 2002 07:22:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KEMXnC023588 for ; Mon, 20 May 2002 07:22:33 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44790; Mon, 20 May 2002 09:23:13 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA49194; Mon, 20 May 2002 09:21:56 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA25183; Mon, 20 May 2002 09:21:56 -0500 (CDT) Message-Id: <200205201421.JAA25183@slobber.americas.sgi.com> To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI as module (kernel compilation failure). Date: Mon, 20 May 2002 09:21:56 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >=========================================================================== >Index: linux/fs/Config.in >=========================================================================== > >--- /usr/tmp/TmpDir.27777-0/linux/fs/Config.in_1.77 Fri Apr 19 11:58:11 200 >2 >+++ linux/fs/Config.in Fri Apr 19 11:50:22 2002 >@@ -100,8 +100,16 @@ > dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS > dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS > if [ "$CONFIG_XFS_FS" != "n" ]; then >+ # Current DMAPI code has calls from XFS to DMAPI. This requires that >+ # DMAPI be built in if selected and XFS is built in. Valid combinations >+ # XFS=n, DMAPI=n >+ # XFS=y, DMAPI=[yn] >+ # XFS=m, DMAPI=[mn] > dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS > if [ "$CONFIG_XFS_DMAPI" != "n" ]; then >+ if [ "$CONFIG_XFS_FS" = "y" ]; then >+ define_tristate CONFIG_XFS_DMAPI y >+ fi > define_bool CONFIG_HAVE_XFS_DMAPI y > fi > fi Check it in when you get a chance, please. Dean From owner-linux-xfs@oss.sgi.com Mon May 20 07:39:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KEdOnC025673 for ; Mon, 20 May 2002 07:39:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KEdOCk025671 for linux-xfs-outgoing; Mon, 20 May 2002 07:39:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chacho.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KEdAnC025609 for ; Mon, 20 May 2002 07:39:15 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by chacho.sgo.es (8.11.6/8.11.6) id g4KEfa310498; Mon, 20 May 2002 16:41:36 +0200 Message-Id: <200205201441.g4KEfa310498@chacho.sgo.es> Content-Type: text/plain; charset="iso-8859-1" From: Miguel ANgel To: Eric Sandeen Subject: Re: XFS in redhat 7.2 max filesize limit?? Date: Mon, 20 May 2002 16:40:36 +0200 X-Mailer: KMail [version 1.3.1] Cc: References: In-Reply-To: MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by chacho.sgo.es id g4KEfa310498 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KEdKnC025635 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using /bin/bash El Lun 20 May 2002 15:43, Eric Sandeen escribió: > What shell are you using? tcsh had some problems with large files, > if I remember right. > > -Eric > > On Mon, 20 May 2002, Miguel ANgel wrote: > > Hi, > > > > I have a problem with XFS, when I tried to write a file of more of 2 > > Gygabyte the system returns me this error "Superado el límite de tamaño > > de fichero" that is "max filesize limit was reached" (more or less xD). > > > > My system is a Dual Pentium 2, with redhat 7.2 and kernel 2.4.9-13 with > > XFS 1.0.2. Have this a filesize limitation?? has this limitation the > > latest release of XFS? or this is a problem of linux?? > > > > thanks > > Michi From owner-linux-xfs@oss.sgi.com Mon May 20 07:45:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KEj6nC026611 for ; Mon, 20 May 2002 07:45:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KEj664026610 for linux-xfs-outgoing; Mon, 20 May 2002 07:45:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KEj0nC026559 for ; Mon, 20 May 2002 07:45:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44313; Mon, 20 May 2002 09:45:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA31216; Mon, 20 May 2002 09:44:26 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KEgoN00574; Mon, 20 May 2002 09:42:50 -0500 Subject: Re: XFS in redhat 7.2 max filesize limit?? From: Steve Lord To: Miguel ANgel Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <200205201441.g4KEfa310498@chacho.sgo.es> References: <200205201441.g4KEfa310498@chacho.sgo.es> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.5 Date: 20 May 2002 09:42:50 -0500 Message-Id: <1021905770.26712.57.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KEj0nC026574 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-20 at 09:40, Miguel ANgel wrote: > > I'm using /bin/bash > > El Lun 20 May 2002 15:43, Eric Sandeen escribió: > > What shell are you using? tcsh had some problems with large files, > > if I remember right. > > > > -Eric > > > > On Mon, 20 May 2002, Miguel ANgel wrote: > > > Hi, > > > > > > I have a problem with XFS, when I tried to write a file of more of 2 > > > Gygabyte the system returns me this error "Superado el límite de tamaño > > > de fichero" that is "max filesize limit was reached" (more or less xD). > > > > > > My system is a Dual Pentium 2, with redhat 7.2 and kernel 2.4.9-13 with > > > XFS 1.0.2. Have this a filesize limitation?? has this limitation the > > > latest release of XFS? or this is a problem of linux?? > > > Check the output of ulimit -a Something other than xfs is restricting you here. some ways of logging into a system seem to configure reduced resource limits. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon May 20 07:52:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KEqLnC027742 for ; Mon, 20 May 2002 07:52:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KEqLom027741 for linux-xfs-outgoing; Mon, 20 May 2002 07:52:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailman.mnd.com (adsfw.mnd.com [208.226.69.17] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KEqGnC027708 for ; Mon, 20 May 2002 07:52:17 -0700 Received: from alpha2.production.mnd.com (alpha2.production.mnd.com [192.168.3.105]) by mailman.mnd.com (8.9.3/8.9.3) with ESMTP id JAA01424; Mon, 20 May 2002 09:49:49 -0500 Date: Mon, 20 May 2002 09:49:48 -0500 (CDT) From: Chris Bednar X-Sender: cjb@alpha2.production.mnd.com To: Miguel ANgel cc: linux-xfs@oss.sgi.com Subject: Re: XFS in redhat 7.2 max filesize limit?? In-Reply-To: <200205201441.g4KEfa310498@chacho.sgo.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 20 May 2002, Miguel ANgel wrote: > > I'm using /bin/bash Perhaps more to the point is, ``how are you trying to write the file''? If it's your code, make sure you have the necessary macros defined (for example, -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 will do it on the compile line), and make sure you're using off_t instead of int or long for file offsets. Also, be aware that there are a handful of packages shipped with rh72 that are not correctly compiled for this (I don't have a list, but I do remember having trouble with things like mkisofs and wu-ftpd before). ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/ From owner-linux-xfs@oss.sgi.com Mon May 20 07:54:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KEsUnC028220 for ; Mon, 20 May 2002 07:54:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KEsUiu028219 for linux-xfs-outgoing; Mon, 20 May 2002 07:54:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chacho.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KEsInC028141 for ; Mon, 20 May 2002 07:54:23 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by chacho.sgo.es (8.11.6/8.11.6) id g4KEutX10590; Mon, 20 May 2002 16:56:55 +0200 Message-Id: <200205201456.g4KEutX10590@chacho.sgo.es> Content-Type: text/plain; charset="iso-8859-1" From: Miguel ANgel To: Steve Lord Subject: Re: XFS in redhat 7.2 max filesize limit?? Date: Mon, 20 May 2002 16:55:54 +0200 X-Mailer: KMail [version 1.3.1] Cc: Eric Sandeen , linux-xfs@oss.sgi.com References: <200205201441.g4KEfa310498@chacho.sgo.es> <1021905770.26712.57.camel@jen.americas.sgi.com> In-Reply-To: <1021905770.26712.57.camel@jen.americas.sgi.com> MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by chacho.sgo.es id g4KEutX10590 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KEsQnC028182 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk El Lun 20 May 2002 16:42, Steve Lord escribió: > ulimit -a core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes) unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 4095 virtual memory (kbytes) unlimited I'm downloading redhat 7.3, and I will install lastest XFS kernel, I don't if it is a good idea but... I haven't more yet. Thanks From owner-linux-xfs@oss.sgi.com Mon May 20 08:11:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KFBnnC030813 for ; Mon, 20 May 2002 08:11:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KFBnXN030812 for linux-xfs-outgoing; Mon, 20 May 2002 08:11:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf18bis.bellsouth.net (mail018.mail.bellsouth.net [205.152.58.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KFBinC030780 for ; Mon, 20 May 2002 08:11:44 -0700 Received: from taz ([66.156.2.161]) by imf18bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020520151227.SWVX209.imf18bis.bellsouth.net@taz>; Mon, 20 May 2002 11:12:27 -0400 Date: Mon, 20 May 2002 11:06:02 -0400 From: Greg Freemyer Subject: re[2]: Suse 8.0 XFS Update To: Andi Kleen , Raymond cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020520151227.SWVX209.imf18bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KFBinC030785 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> On Sat, May 18, 2002 at 10:01:53AM -0700, Raymond wrote: >> > Suse v8.0 has XFS v1.02 support. >> The XFS in the SuSE 8.0 kernel is very near XFS 1.1 including most/all >> of the important bug fixes. Probably not worth updating just for the 1.1 >> tag. >> -Andi The stock SuSE 8.0 kernel has the bug where xfsrestore does not bring back ACLs. If you care about ACLs, then it is a big bug. I have downloaded and installed the SuSE experimental kernel from ftp://ftp.suse.com/pub/people/mantel/next/RPM/ and I have not had any problems yet. It does have the xfsrestore bug fixed. I gather that this is equivalent to a rawhide kernel from Redhat, so it is not recommended for production use. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Mon May 20 08:26:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KFQ5nC032371 for ; Mon, 20 May 2002 08:26:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KFQ51H032370 for linux-xfs-outgoing; Mon, 20 May 2002 08:26:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KFPtnC032301 for ; Mon, 20 May 2002 08:25:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA05042; Mon, 20 May 2002 10:26:37 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA85715; Mon, 20 May 2002 10:25:20 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA28139; Mon, 20 May 2002 10:25:14 -0500 (CDT) Message-ID: <3CE91559.D5D36B75@sgi.com> Date: Mon, 20 May 2002 10:25:14 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix , linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> <200205162151.07376.hasch@t-online.de> <20020517000623.GA13675@widomaker.com> <3CE53102.2B550CF8@sgi.com> <20020517181451.GC13880@widomaker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles Shannon Hendrix wrote: > On Fri, May 17, 2002 at 11:34:10AM -0500, John Kihonge wrote: > > > We are working to try and determine what might be happening and to help you > > restore the data. The backup may not be lost and you may be able to recover > > the files you want. The problem you are having may have nothing to do with > > the online database. We are working hard at it and we will get back to you > > early next week. > > Sounds great. > > I gathered a bit more information. > > I log all my backups in a written journal, and this backup is number 23, > dated 16 April 2002. > > My current kernel is dated 1 May 2002, so it's looking like the backup > was done under XFS 1.0, kernel 2.4.16, and glibc 2.2.3. My first move to > an XFS kernel was 24 August 2001, with whatever was current at the time, > and all filesystems date from that time. However, I really don't believe > the kernel the dump was performed under matters. > > I have my old kernels saved if you need any symbol information from > them. > > I have attempted to restore a November backup, and I believe the same problem > exists. xfsrestore will report something like this: > > xfsrestore: 1085 directories and 14713 entries processed > > ...and will restore the 1085 directories, but only a fraction of the > entries. I assume that entries == files. > > In this testing, I'm just doing level 0 dumps with a command like: > > % xfsrestore -f /dev/nst0 /u/restore > > On a dump dated 9 November I restored / which gave me all the > directories and 1663 files out of ~4000 entries. The next > restore was for /home, 1085 directories and 14713 entries, > and it failed with the following error: > > xfsrestore: examining media file 3 > xfsrestore: seeking past media file directory dump > xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > contextp->dc_recsz )' failed. > Aborted > If the problem is just the assertion one, it maybe that you are restoring an old dump (dumped prior to a fix for xfsdump-1.1.10 of 10th December 2001). The mail archive: http://marc.theaimsgroup.com/?l=linux-xfs&m=101435725816823&w=2 has an explanation of the problem and the suggested fix to allow one to restore such a dump. I hope that will fix the problem. > > I thought it might be useful to re-create this problem with an older > dump. > > Let me know if any other information would be useful. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com ---- Kihonge JN From owner-linux-xfs@oss.sgi.com Mon May 20 08:57:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KFvAnC017490 for ; Mon, 20 May 2002 08:57:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KFvAoI017489 for linux-xfs-outgoing; Mon, 20 May 2002 08:57:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bsc-ws-03 (sbs-ims-external.chw.edu [206.132.94.9]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KFv7nC017440 for ; Mon, 20 May 2002 08:57:08 -0700 Received: from 162.135.65.9 by bsc-ws-03 with ESMTP (CHW MMS SMTP Relay (MMS v5.0)); Mon, 20 May 2002 08:54:18 -0700 X-Server-Uuid: DFBE654E-438C-42DD-B377-2B4A1C2DB971 Received: by SFMH-IMS-01 with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 08:57:45 -0700 Message-ID: <3A05DACD2733D511BA0500902798AEDFAB3883@dsc-msg-04.dsc.chw.edu> From: "Baker, Dick - Perot" To: "'linux-xfs@oss.sgi.com'" Subject: Linux xfs Date: Mon, 20 May 2002 08:56:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10F7C3A0913013-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, just wondering for us not so savvy users, will there be an updated xfs iso image anytime soon? Thanks, Dick Baker From owner-linux-xfs@oss.sgi.com Mon May 20 10:17:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KHHqnC031691 for ; Mon, 20 May 2002 10:17:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KHHqPC031690 for linux-xfs-outgoing; Mon, 20 May 2002 10:17:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from im1.sec.tds.net ([216.170.230.91]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KHHanC031636 for ; Mon, 20 May 2002 10:17:37 -0700 Received: from vfermi (watn0pool0-a125.tn.tds.net [216.170.209.126]) by im1.sec.tds.net (8.12.3/8.12.3) with SMTP id g4KHINmv007895 for ; Mon, 20 May 2002 12:18:24 -0500 (CDT) From: "Ernest Ashford" To: Subject: xfsdump failure with ONSTREAM ADR50 drive Date: Mon, 20 May 2002 10:18:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1FFE7.BAA24710" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1FFE7.BAA24710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I am running Mandrake 8.2 with the 1.1 xfs from SGI in a vanilla 2.4.18 kernel. If I try to do a xfsdump it fails with xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: drive_scsitape.c:1985: do_get_write_buf: Assertion `contextp->dc_nextp < contextp->dc_recendp' failed. Aborted I am attaching a error file I created from the output. Can you help? Thanks Ernest Ashford ------=_NextPart_000_0000_01C1FFE7.BAA24710 Content-Type: application/octet-stream; name="xfsdump.err" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xfsdump.err" [root@klein root]# xfsdump -J -b 512 -l0 -p5 -v1 -M ONSTREAM -L test -f /de= v/nst0 /dev/sda7 xfsdump: using scsi tape (drive_scsitape) strategy xfsdump: version 3.0 - Running single-threaded xfsdump: level 0 dump of klein:/ xfsdump: dump date: Mon May 20 09:43:11 2002 xfsdump: session id: f5e206f3-2423-4e89-81b7-a0bbd830bc64 xfsdump: session label: "test" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 434902336 bytes xfsdump: preparing drive xfsdump: attempt to get status of tape drive /dev/nst0 failed: 6 (No such d= evice or address) xfsdump: attempt to access/open device /dev/nst0 failed: 6 (No such device = or address) xfsdump: dump size (non-dir files) : 0 bytes xfsdump: NOTE: dump interrupted: 943 seconds elapsed xfsdump: Dump Status: INTERRUPT [root@klein eea]# mt -f /dev/nst0 stoptions scsi2log [root@klein eea]# mt erase [root@klein eea]# xfsdump -J -b 512 -l0 -p5 -v1 -f /dev/nst0 /dev/sda7 xfsdump: using scsi tape (drive_scsitape) strategy xfsdump: version 3.0 - Running single-threaded =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 dump label dialog =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 please enter label for this dump session (timeout in 300 sec) -> ONSTREAM session label entered: "ONSTREAM" --------------------------------- end dialog ---------------------------= ------ xfsdump: level 0 dump of klein:/ xfsdump: dump date: Mon May 20 11:14:55 2002 xfsdump: session id: ab15fbd0-e82d-4f09-acca-24a19aaa8651 xfsdump: session label: "ONSTREAM" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 436430208 bytes xfsdump: preparing drive =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 media label dialog =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 please enter label for media in drive 0 (timeout in 300 sec) -> test media label entered: "test" --------------------------------- end dialog ----------------------------= ----- xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: drive_scsitape.c:1985: do_get_write_buf: Assertion=20 `contextp->dc_nextp < contextp->dc_recendp' failed. Aborted =20=20=20 ------=_NextPart_000_0000_01C1FFE7.BAA24710-- From owner-linux-xfs@oss.sgi.com Mon May 20 10:41:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KHf6nC001377 for ; Mon, 20 May 2002 10:41:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KHf6NM001376 for linux-xfs-outgoing; Mon, 20 May 2002 10:41:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KHexnC001349 for ; Mon, 20 May 2002 10:40:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA57504; Mon, 20 May 2002 12:41:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA80354; Mon, 20 May 2002 12:40:25 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KHcmm04828; Mon, 20 May 2002 12:38:48 -0500 Subject: Re: Strange behavior on the 2.4.18 XFS tree? From: Steve Lord To: Michael Sinz Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <3CE8ED3B.2090401@wgate.com> References: <22203.1021466116@ocs3.intra.ocs.com.au> <3CE8ED3B.2090401@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 May 2002 12:38:48 -0500 Message-Id: <1021916328.26650.251.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-20 at 07:34, Michael Sinz wrote: > Keith Owens wrote: > > On Wed, 15 May 2002 07:30:09 -0400, > > Michael Sinz wrote: > > > >>I have only been able to see this behavior on my system running the > >>kernel from the 2.4 XFS CVS tree. It is somewhat reproduceable. > >> > >>The problem is that I started up a number of "rxvt" sessions and they > >>took well over a minute to start up. During that time, the cpu > >>utilization was almost nil. (Less than 1%) > >> > >>There was a background find operation happening, and this seems to be > >>the key item. > > > > When the problem occurs, does typing sync get everything running again? > > I have been seeing an intermittent lock problem with XFS where > > everything stops until some other disk activity kicks in and the lock > > is released. > > A build of 2.4.18-XFS from CVS on Friday night seems to not show the > problem. At least not over the last 2+ days. > > It could also be that I did not run into it either. Just providing > some more information as it develops :-) Keep an eye on this problem, the code changes which went in for the multiple blocksize support will affect when we sync data to disk. I think could well have a positive effect on what ever is happening to you. Steve > > -- > Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com > A master's secrets are only as good as > the master's ability to explain them to others. > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon May 20 11:15:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KIFCnC004825 for ; Mon, 20 May 2002 11:15:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KIFCFI004824 for linux-xfs-outgoing; Mon, 20 May 2002 11:15:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from andrei.myip.org (12-234-154-216.client.attbi.com [12.234.154.216]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KIF9nC004790 for ; Mon, 20 May 2002 11:15:09 -0700 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by weiqi.home.local (Postfix) with SMTP id 529BF309B5 for ; Mon, 20 May 2002 11:15:58 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id BF3AD309B4 for ; Mon, 20 May 2002 11:15:57 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 5801113641F for ; Mon, 20 May 2002 11:15:47 -0700 (PDT) Subject: Re: XFS-Enabled Redhat 7.3 ISO From: Florin Andrei To: linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 20 May 2002 11:15:47 -0700 Message-Id: <1021918547.7124.10.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-05-17 at 19:21, Raymond wrote: > Anyone know when the XFS-enabled Redhat 7.3 iso will be available??? Michael Best did some work on this thing. If he doesn't finish it, i'll pick it up soon. I might also go insane meanwhile, because i have like one thousand other things to solve, but what the heck... :-) -- Florin Andrei Spiderman according to Jon Katz: "the web-slinging arachnoid-nerd from Queens who gets the bad guy but really wants the girl." From owner-linux-xfs@oss.sgi.com Mon May 20 11:39:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KIddnC008746 for ; Mon, 20 May 2002 11:39:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KIddKh008744 for linux-xfs-outgoing; Mon, 20 May 2002 11:39:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KIdZnC008693 for ; Mon, 20 May 2002 11:39:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA51636 for ; Mon, 20 May 2002 13:40:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA53159 for ; Mon, 20 May 2002 13:39:02 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KIbOv05165; Mon, 20 May 2002 13:37:24 -0500 Message-Id: <200205201837.g4KIbOv05165@jen.americas.sgi.com> Date: Mon, 20 May 2002 13:37:24 -0500 Subject: TAKE - small pagebuf cleanup To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig spotted this one. Date: Mon May 20 11:37:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119541a linux/fs/xfs/pagebuf/page_buf.c - 1.22 - Use lock_page instead of a homebrew alternative From owner-linux-xfs@oss.sgi.com Mon May 20 12:06:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJ6LnC013368 for ; Mon, 20 May 2002 12:06:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJ6LYZ013366 for linux-xfs-outgoing; Mon, 20 May 2002 12:06:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJ4SnC012936 for ; Mon, 20 May 2002 12:04:29 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id JAA18973 for linux-xfs@oss.sgi.com; Mon, 20 May 2002 09:05:16 -1000 Date: Mon, 20 May 2002 09:05:15 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: "Corruption of in-memory data" Message-ID: <20020520090515.B18897@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello - Thanks again for your help several months ago with xfs_growfs! Now we have a new problem . . . I was trying to resolve the slow performance issue of some of our RAID5+XFS (2.4.16 kernel) by upgrading to 2.4.18 and XFS-1.1, and reformatting with an external log, as suggested in the FAQ. During resyncing, one of the disks failed and the raid 5 went into degraded mode (no other disks had errors). After a clean reboot, still running in degraded mode, (shouldn't matter to XFS, but I thought I'd mention it) everything seemed OK until I tried to remove a directory: May 19 19:03:51 ike kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01ed751 May 19 19:03:51 ike kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) May 19 19:03:51 ike kernel: Please umount the filesystem, and rectify the problem(s) [System froze!] After hitting the reset button and booting, I mounted the filesystem to replay the log, and ran xfs_repair -n. The output is included below. I'm thinking of trying again later today, maybe with an internal log again (which should be usable now, with 2.4.18, right?) But the crash above worries me. Please let me know if there are any other tests I should run on the crashed filesystem before starting over. Be seeing you, - Sidik ----------------------------------------------------------------------------- kernel: 2.4.18 ("vanilla") patches: ide.2.4.18-rc1.02152002 <--- Is this safe with XFS? xfs: 1.1 release mkfs: 2.0.5 from CVS today. kgcc: egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) lvm: NO raid: raid5 on 6 active disks + a 30MB raid1 on the side for logdev= By the way, the current version of mkfs should have sensed the right sunit= and swidth= for my raid5, correct? [root@ike:~/] # cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md1 : active raid1 ide/host0/bus1/target0/lun0/part2[1] ide/host0/bus0/target1/lun0/part2[0] 32064 blocks [2/2] [UU] md0 : active raid5 ide/host2/bus1/target1/lun0/part1[5] ide/host2/bus0/target0/lun0/part1[3] ide/host0/bus1/target1/lun0/part1[2] ide/host0/bus1/target0/lun0/part1[1] ide/host0/bus0/target1/lun0/part1[0] 84179840 blocks level 5, 32k chunk, algorithm 0 [6/5] [UUUU_U] unused devices: [root@ike:~/] # mount -o logdev=/dev/md1 /dev/md0 /local/data May 19 21:45:48 ike kernel: XFS mounting filesystem md(9,0) May 19 21:45:48 ike kernel: Starting XFS recovery on filesystem: md(9,0) (dev: 9/1) May 19 21:45:51 ike kernel: Ending XFS recovery on filesystem: md(9,0) (dev: 9/1) [root@ike:~/] # umount /local/data [root@ike:~/] # xfs_repair -n -l /dev/md1 /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using external log on /dev/md1 - scan filesystem freespace and inode maps... bad on-disk superblock 14 - bad magic number primary and secondary superblock 14 conflict - AG superblock geometry info conflicts with filesystem geometry bad flags field in superblock 14 bad shared version number in superblock 14 bad inode alignment field in superblock 14 bad stripe unit/width fields in superblock 14 bad magic # 0x7af17ddc for agf 14 bad version # 469718790 for agf 14 bad sequence # 1516474927 for agf 14 bad length -1893459923 for agf 14, should be 1048576 flfirst -1709257637 in agf 14 too large (max = 128) fllast -1476572807 in agf 14 too large (max = 128) bad magic # 0x5d6b4918 for agi 14 bad version # -557171968 for agi 14 bad sequence # 1264850556 for agi 14 bad length # 494154035 for agi 14, should be 1048576 would reset bad sb for ag 14 would reset bad agf for ag 14 would reset bad agi for ag 14 bad uncorrected agheader 14, skipping ag... bad on-disk superblock 17 - bad magic number primary and secondary superblock 17 conflict - AG superblock geometry info conflicts with filesystem geometry bad flags field in superblock 17 bad stripe unit/width fields in superblock 17 bad magic # 0x4f081d07 for agf 17 bad version # -1391714832 for agf 17 bad sequence # -1640162692 for agf 17 bad length -749449933 for agf 17, should be 1048576 flfirst -518252623 in agf 17 too large (max = 128) fllast -324494456 in agf 17 too large (max = 128) bad magic # 0x7448b3be for agi 17 bad version # -1613057248 for agi 17 bad sequence # 1129318682 for agi 17 bad length # -1191853674 for agi 17, should be 1048576 would reset bad sb for ag 17 would reset bad agf for ag 17 would reset bad agi for ag 17 bad uncorrected agheader 17, skipping ag... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... error following ag 14 unlinked list error following ag 17 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 bad directory block magic # 0x4315cf46 in block 0 for directory inode 218110467 corrupt block 0 in directory inode 218110467 would junk block no . entry for directory 218110467 no .. entry for directory 218110467 problem with directory contents in inode 218110467 would have cleared inode 218110467 - agno = 14 - agno = 15 - agno = 16 bad magic number 0x281a on inode 268435712 bad version number 0xffffffdd on inode 268435712 bad inode format in inode 268435712 bad magic number 0x1e09 on inode 268435713 bad version number 0x1f on inode 268435713 bad inode format in inode 268435713 bad magic number 0xab23 on inode 268435714 bad version number 0x67 on inode 268435714 bad inode format in inode 268435714 bad magic number 0xafec on inode 268435715 bad version number 0xffffffeb on inode 268435715 bad (negative) size -3741760305385614623 on inode 268435715 bad magic number 0x260b on inode 268435716 bad version number 0x7a on inode 268435716 bad (negative) size -3658651245050632655 on inode 268435716 bad magic number 0x68ad on inode 268435717 bad version number 0xffffffa7 on inode 268435717 bad (negative) size -8061786041470882404 on inode 268435717 bad magic number 0xa7c8 on inode 268435718 bad version number 0xffffff9b on inode 268435718 bad inode format in inode 268435718 bad magic number 0x5afe on inode 268435719 bad version number 0x7b on inode 268435719 bad inode format in inode 268435719 bad magic number 0x5fff on inode 268435720 bad version number 0x14 on inode 268435720 bad (negative) size -6559184817219992953 on inode 268435720 bad magic number 0x57ba on inode 268435721 bad version number 0x49 on inode 268435721 bad inode format in inode 268435721 bad magic number 0xa962 on inode 268435722 bad version number 0x8 on inode 268435722 bad inode format in inode 268435722 bad magic number 0x49c4 on inode 268435723 bad version number 0x42 on inode 268435723 bad inode format in inode 268435723 bad magic number 0x1b1e on inode 268435724 bad version number 0x20 on inode 268435724 bad inode format in inode 268435724 bad magic number 0x5864 on inode 268435725 bad version number 0xffffffa2 on inode 268435725 bad inode format in inode 268435725 bad magic number 0xe070 on inode 268435726 bad version number 0x2f on inode 268435726 bad inode format in inode 268435726 bad magic number 0x37b1 on inode 268435727 bad version number 0x54 on inode 268435727 bad inode format in inode 268435727 bad magic number 0xda5b on inode 268435728 bad version number 0xffffff92 on inode 268435728 bad inode format in inode 268435728 bad magic number 0x9286 on inode 268435729 bad version number 0xfffffffa on inode 268435729 bad (negative) size -6844212487954574407 on inode 268435729 bad magic number 0xedc6 on inode 268435730 bad version number 0x63 on inode 268435730 bad inode format in inode 268435730 bad magic number 0xdbc on inode 268435731 bad version number 0xffffffa8 on inode 268435731 bad (negative) size -7504915599599269110 on inode 268435731 bad magic number 0xe941 on inode 268435732 bad version number 0x58 on inode 268435732 bad inode format in inode 268435732 bad magic number 0x851b on inode 268435733 bad version number 0xfffffff7 on inode 268435733 bad inode format in inode 268435733 bad magic number 0xa411 on inode 268435734 bad version number 0xffffffab on inode 268435734 bad inode format in inode 268435734 bad magic number 0x4446 on inode 268435735 bad version number 0x60 on inode 268435735 bad inode format in inode 268435735 bad magic number 0x2a1c on inode 268435736 bad version number 0x2a on inode 268435736 bad inode format in inode 268435736 bad magic number 0x8a49 on inode 268435737 bad version number 0x35 on inode 268435737 bad (negative) size -2977792079054983672 on inode 268435737 bad magic number 0xcf4e on inode 268435738 bad version number 0x67 on inode 268435738 bad inode format in inode 268435738 bad magic number 0xb79c on inode 268435739 bad version number 0xffffff8a on inode 268435739 bad (negative) size -5988854802164675092 on inode 268435739 bad magic number 0xc9f2 on inode 268435740 bad version number 0x65 on inode 268435740 bad inode format in inode 268435740 bad magic number 0xec3b on inode 268435741 bad version number 0x2a on inode 268435741 bad (negative) size -7224737337336917654 on inode 268435741 bad magic number 0xda94 on inode 268435742 bad version number 0xffffffd6 on inode 268435742 bad inode format in inode 268435742 bad magic number 0x2fc5 on inode 268435743 bad version number 0x12 on inode 268435743 bad inode format in inode 268435743 bad magic number 0x281a on inode 268435712, would reset magic number bad version number 0xffffffdd on inode 268435712, would reset version number bad inode format in inode 268435712 would have cleared inode 268435712 bad magic number 0x1e09 on inode 268435713, would reset magic number bad version number 0x1f on inode 268435713, would reset version number bad inode format in inode 268435713 would have cleared inode 268435713 bad magic number 0xab23 on inode 268435714, would reset magic number bad version number 0x67 on inode 268435714, would reset version number bad inode format in inode 268435714 would have cleared inode 268435714 bad magic number 0xafec on inode 268435715, would reset magic number bad version number 0xffffffeb on inode 268435715, would reset version number bad (negative) size -3741760305385614623 on inode 268435715 would have cleared inode 268435715 bad magic number 0x260b on inode 268435716, would reset magic number bad version number 0x7a on inode 268435716, would reset version number bad (negative) size -3658651245050632655 on inode 268435716 would have cleared inode 268435716 bad magic number 0x68ad on inode 268435717, would reset magic number bad version number 0xffffffa7 on inode 268435717, would reset version number bad (negative) size -8061786041470882404 on inode 268435717 would have cleared inode 268435717 bad magic number 0xa7c8 on inode 268435718, would reset magic number bad version number 0xffffff9b on inode 268435718, would reset version number bad inode format in inode 268435718 would have cleared inode 268435718 bad magic number 0x5afe on inode 268435719, would reset magic number bad version number 0x7b on inode 268435719, would reset version number bad inode format in inode 268435719 would have cleared inode 268435719 bad magic number 0x5fff on inode 268435720, would reset magic number bad version number 0x14 on inode 268435720, would reset version number bad (negative) size -6559184817219992953 on inode 268435720 would have cleared inode 268435720 bad magic number 0x57ba on inode 268435721, would reset magic number bad version number 0x49 on inode 268435721, would reset version number bad inode format in inode 268435721 would have cleared inode 268435721 bad magic number 0xa962 on inode 268435722, would reset magic number bad version number 0x8 on inode 268435722, would reset version number bad inode format in inode 268435722 would have cleared inode 268435722 bad magic number 0x49c4 on inode 268435723, would reset magic number bad version number 0x42 on inode 268435723, would reset version number bad inode format in inode 268435723 would have cleared inode 268435723 bad magic number 0x1b1e on inode 268435724, would reset magic number bad version number 0x20 on inode 268435724, would reset version number bad inode format in inode 268435724 would have cleared inode 268435724 bad magic number 0x5864 on inode 268435725, would reset magic number bad version number 0xffffffa2 on inode 268435725, would reset version number bad inode format in inode 268435725 would have cleared inode 268435725 bad magic number 0xe070 on inode 268435726, would reset magic number bad version number 0x2f on inode 268435726, would reset version number bad inode format in inode 268435726 would have cleared inode 268435726 bad magic number 0x37b1 on inode 268435727, would reset magic number bad version number 0x54 on inode 268435727, would reset version number bad inode format in inode 268435727 would have cleared inode 268435727 bad magic number 0xda5b on inode 268435728, would reset magic number bad version number 0xffffff92 on inode 268435728, would reset version number bad inode format in inode 268435728 would have cleared inode 268435728 bad magic number 0x9286 on inode 268435729, would reset magic number bad version number 0xfffffffa on inode 268435729, would reset version number bad (negative) size -6844212487954574407 on inode 268435729 would have cleared inode 268435729 bad magic number 0xedc6 on inode 268435730, would reset magic number bad version number 0x63 on inode 268435730, would reset version number bad inode format in inode 268435730 would have cleared inode 268435730 bad magic number 0xdbc on inode 268435731, would reset magic number bad version number 0xffffffa8 on inode 268435731, would reset version number bad (negative) size -7504915599599269110 on inode 268435731 would have cleared inode 268435731 bad magic number 0xe941 on inode 268435732, would reset magic number bad version number 0x58 on inode 268435732, would reset version number bad inode format in inode 268435732 would have cleared inode 268435732 bad magic number 0x851b on inode 268435733, would reset magic number bad version number 0xfffffff7 on inode 268435733, would reset version number bad inode format in inode 268435733 would have cleared inode 268435733 bad magic number 0xa411 on inode 268435734, would reset magic number bad version number 0xffffffab on inode 268435734, would reset version number bad inode format in inode 268435734 would have cleared inode 268435734 bad magic number 0x4446 on inode 268435735, would reset magic number bad version number 0x60 on inode 268435735, would reset version number bad inode format in inode 268435735 would have cleared inode 268435735 bad magic number 0x2a1c on inode 268435736, would reset magic number bad version number 0x2a on inode 268435736, would reset version number bad inode format in inode 268435736 would have cleared inode 268435736 bad magic number 0x8a49 on inode 268435737, would reset magic number bad version number 0x35 on inode 268435737, would reset version number bad (negative) size -2977792079054983672 on inode 268435737 would have cleared inode 268435737 bad magic number 0xcf4e on inode 268435738, would reset magic number bad version number 0x67 on inode 268435738, would reset version number bad inode format in inode 268435738 would have cleared inode 268435738 bad magic number 0xb79c on inode 268435739, would reset magic number bad version number 0xffffff8a on inode 268435739, would reset version number bad (negative) size -5988854802164675092 on inode 268435739 would have cleared inode 268435739 bad magic number 0xc9f2 on inode 268435740, would reset magic number bad version number 0x65 on inode 268435740, would reset version number bad inode format in inode 268435740 would have cleared inode 268435740 bad magic number 0xec3b on inode 268435741, would reset magic number bad version number 0x2a on inode 268435741, would reset version number bad (negative) size -7224737337336917654 on inode 268435741 would have cleared inode 268435741 bad magic number 0xda94 on inode 268435742, would reset magic number bad version number 0xffffffd6 on inode 268435742, would reset version number bad inode format in inode 268435742 would have cleared inode 268435742 bad magic number 0x2fc5 on inode 268435743, would reset magic number bad version number 0x12 on inode 268435743, would reset version number bad inode format in inode 268435743 would have cleared inode 268435743 bad directory block magic # 0x781bca72 in block 0 for directory inode 268435861 corrupt block 0 in directory inode 268435861 would junk block no . entry for directory 268435861 no .. entry for directory 268435861 problem with directory contents in inode 268435861 would have cleared inode 268435861 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 entry ".." at block 0 offset 32 in directory inode 1101209 references non-existent inode 234881408 would clear inode number in entry at offset 32... - agno = 1 entry "ncpfs" at block 0 offset 872 in directory inode 16777344 references non-existent inode 234881152 would clear inode number in entry at offset 872... entry "romfs" at block 0 offset 1000 in directory inode 16777344 references non-existent inode 285212800 would clear inode number in entry at offset 1000... entry "jffs" at block 0 offset 1448 in directory inode 16777344 references non-existent inode 234881166 would clear inode number in entry at offset 1448... entry "reiserfs" at block 0 offset 1528 in directory inode 16777344 references non-existent inode 285212803 would clear inode number in entry at offset 1528... entry ".." at block 0 offset 32 in directory inode 16802338 references non-existent inode 234921646 would clear inode number in entry at offset 32... - agno = 2 entry ".." at block 0 offset 32 in directory inode 33554618 references non-existent inode 234881408 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 33560325 references non-existent inode 234921646 would clear inode number in entry at offset 32... - agno = 3 entry ".." at block 0 offset 32 in directory inode 50331950 references non-existent inode 234881408 would clear inode number in entry at offset 32... entry "cris" at block 0 offset 280 in directory inode 50335119 references non-existent inode 234921646 would clear inode number in entry at offset 280... entry "lib" at block 0 offset 176 in directory inode 50335137 references non-existent inode 285227557 would clear inode number in entry at offset 176... entry "mac" at block 0 offset 360 in directory inode 50335142 references non-existent inode 285227564 would clear inode number in entry at offset 360... - agno = 4 - agno = 5 entry ".." at block 0 offset 32 in directory inode 83886464 references non-existent inode 234881408 would clear inode number in entry at offset 32... entry "tools" at block 0 offset 264 in directory inode 83888799 references non-existent inode 234885305 would clear inode number in entry at offset 264... entry "baget" at block 0 offset 336 in directory inode 83888799 references non-existent inode 285227533 would clear inode number in entry at offset 336... - agno = 6 entry "chrp" in shortform directory 100664757 references non-existent inode 234921600 would have junked entry "chrp" in directory inode 100664757 - agno = 7 entry "net" at block 0 offset 208 in directory inode 117440662 references non-existent inode 234881187 would clear inode number in entry at offset 208... entry "asm-ppc" at block 0 offset 224 in directory inode 117440662 references non-existent inode 285212830 would clear inode number in entry at offset 224... entry "video" at block 0 offset 312 in directory inode 117440662 references non-existent inode 285213100 would clear inode number in entry at offset 312... entry "asm-parisc" at block 0 offset 472 in directory inode 117440662 references non-existent inode 285213187 would clear inode number in entry at offset 472... entry "gcc" at block 0 offset 2672 in directory inode 117440680 references non-existent inode 234881328 would clear inode number in entry at offset 2672... entry ".." at block 0 offset 32 in directory inode 117440934 references non-existent inode 234881408 would clear inode number in entry at offset 32... - agno = 8 entry "raid" at block 2 offset 2336 in directory inode 134217895 references non-existent inode 234881175 would clear inode number in entry at offset 2336... entry "isdn" at block 2 offset 3288 in directory inode 134217895 references non-existent inode 285212828 would clear inode number in entry at offset 3288... entry "namespace" at block 0 offset 184 in directory inode 134219173 references non-existent inode 234885261 would clear inode number in entry at offset 184... entry "resources" at block 0 offset 248 in directory inode 134219173 references non-existent inode 285219763 would clear inode number in entry at offset 248... entry "stboards" in shortform directory 134242967 references non-existent inode 234921624 would have junked entry "stboards" in directory inode 134242967 entry "sgi-ip22" at block 0 offset 304 in directory inode 134242972 references non-existent inode 234921632 would clear inode number in entry at offset 304... entry "math-emu" at block 0 offset 400 in directory inode 134242972 references non-existent inode 285231283 would clear inode number in entry at offset 400... - agno = 9 entry ".." at block 0 offset 32 in directory inode 150995351 references non-existent inode 234881408 would clear inode number in entry at offset 32... - agno = 10 - agno = 11 entry "devices" at block 0 offset 344 in directory inode 184555267 references free inode 218110467 would clear inode number in entry at offset 344... entry "maps" at block 0 offset 368 in directory inode 184555267 references non-existent inode 234885276 would clear inode number in entry at offset 368... - agno = 12 entry "joystick" at block 0 offset 2232 in directory inode 201327150 references non-existent inode 285213370 would clear inode number in entry at offset 2232... entry "emu10k1" at block 0 offset 3248 in directory inode 201327491 references non-existent inode 234881825 would clear inode number in entry at offset 3248... entry "kernel" in shortform directory 201332535 references non-existent inode 285227406 would have junked entry "kernel" in directory inode 201332535 entry "pb1000" in shortform directory 201350536 references non-existent inode 234885308 would have junked entry "pb1000" in directory inode 201350536 entry "lib" at block 0 offset 160 in directory inode 201350546 references non-existent inode 285227579 would clear inode number in entry at offset 160... - agno = 13 entry "netfilter" at block 0 offset 648 in directory inode 218104243 references non-existent inode 234881330 would clear inode number in entry at offset 648... entry "net" at block 0 offset 48 in directory inode 218104333 references non-existent inode 234881408 would clear inode number in entry at offset 48... entry "cdrom" at block 0 offset 168 in directory inode 218104333 references non-existent inode 285213464 would clear inode number in entry at offset 168... entry "video" at block 0 offset 248 in directory inode 218104333 references non-existent inode 234882309 would clear inode number in entry at offset 248... entry "tc" at block 0 offset 416 in directory inode 218104333 references non-existent inode 234885252 would clear inode number in entry at offset 416... entry "pcmcia" at block 0 offset 472 in directory inode 218104333 references non-existent inode 285219718 would clear inode number in entry at offset 472... entry "md" at block 0 offset 640 in directory inode 218104333 references non-existent inode 285227392 would clear inode number in entry at offset 640... entry "compressor" in shortform directory 218104334 references non-existent inode 234881819 would have junked entry "compressor" in directory inode 218104334 bad directory block magic # 0x4315cf46 in block 0 for directory inode 218110467 corrupt block 0 in directory inode 218110467 would junk block no . entry for directory 218110467 no .. entry for directory 218110467 problem with directory contents in inode 218110467 would have cleared inode 218110467 entry "tools" in shortform directory 218110480 references non-existent inode 234885302 would have junked entry "tools" in directory inode 218110480 entry "amiga" in shortform directory 218110518 references non-existent inode 234921605 would have junked entry "amiga" in directory inode 218110518 entry "compressed" in shortform directory 218110519 references non-existent inode 234921608 would have junked entry "compressed" in directory inode 218110519 entry "filesystems" at block 0 offset 48 in directory inode 218111767 references non-existent inode 234921652 would clear inode number in entry at offset 48... entry "cdrom" at block 0 offset 264 in directory inode 218111767 references non-existent inode 285233959 would clear inode number in entry at offset 264... entry "DocBook" at block 0 offset 2112 in directory inode 218111767 references non-existent inode 234933772 would clear inode number in entry at offset 2112... entry "usb" at block 0 offset 2176 in directory inode 218111767 references non-existent inode 285233975 would clear inode number in entry at offset 2176... - agno = 14 - agno = 15 entry ".." at block 0 offset 32 in directory inode 251658496 references non-existent inode 234881187 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 251658649 references non-existent inode 234881408 would clear inode number in entry at offset 32... entry "lmc" at block 0 offset 968 in directory inode 251658649 references free inode 268435861 would clear inode number in entry at offset 968... entry "ddb5477" in shortform directory 251670196 references non-existent inode 285227547 would have junked entry "ddb5477" in directory inode 251670196 entry "dig" at block 0 offset 136 in directory inode 251671431 references non-existent inode 285231279 would clear inode number in entry at offset 136... entry "rescue" in shortform directory 251671454 references non-existent inode 285233953 would have junked entry "rescue" in directory inode 251671454 - agno = 16 entry "current.h" at block 0 offset 240 in directory inode 268435639 references free inode 268435712 would clear inode number in entry at offset 240... entry "delay.h" at block 0 offset 264 in directory inode 268435639 references free inode 268435713 would clear inode number in entry at offset 264... entry "div64.h" at block 0 offset 288 in directory inode 268435639 references free inode 268435714 would clear inode number in entry at offset 288... entry "dma.h" at block 0 offset 312 in directory inode 268435639 references free inode 268435715 would clear inode number in entry at offset 312... entry "ebcdic.h" at block 0 offset 328 in directory inode 268435639 references free inode 268435716 would clear inode number in entry at offset 328... entry "elf.h" at block 0 offset 352 in directory inode 268435639 references free inode 268435717 would clear inode number in entry at offset 352... entry "errno.h" at block 0 offset 368 in directory inode 268435639 references free inode 268435718 would clear inode number in entry at offset 368... entry "fcntl.h" at block 0 offset 392 in directory inode 268435639 references free inode 268435719 would clear inode number in entry at offset 392... entry "gdb-stub.h" at block 0 offset 416 in directory inode 268435639 references free inode 268435720 would clear inode number in entry at offset 416... entry "hardirq.h" at block 0 offset 440 in directory inode 268435639 references free inode 268435721 would clear inode number in entry at offset 440... entry "hdreg.h" at block 0 offset 464 in directory inode 268435639 references free inode 268435722 would clear inode number in entry at offset 464... entry "ide.h" at block 0 offset 488 in directory inode 268435639 references free inode 268435723 would clear inode number in entry at offset 488... entry "init.h" at block 0 offset 504 in directory inode 268435639 references free inode 268435724 would clear inode number in entry at offset 504... entry "io.h" at block 0 offset 528 in directory inode 268435639 references free inode 268435725 would clear inode number in entry at offset 528... entry "ioctl.h" at block 0 offset 544 in directory inode 268435639 references free inode 268435726 would clear inode number in entry at offset 544... entry "ioctls.h" at block 0 offset 568 in directory inode 268435639 references free inode 268435727 would clear inode number in entry at offset 568... entry "ipc.h" at block 0 offset 592 in directory inode 268435639 references free inode 268435728 would clear inode number in entry at offset 592... entry "ipcbuf.h" at block 0 offset 608 in directory inode 268435639 references free inode 268435729 would clear inode number in entry at offset 608... entry "irq.h" at block 0 offset 632 in directory inode 268435639 references free inode 268435730 would clear inode number in entry at offset 632... entry "mathemu.h" at block 0 offset 648 in directory inode 268435639 references free inode 268435731 would clear inode number in entry at offset 648... entry "lowcore.h" at block 0 offset 672 in directory inode 268435639 references free inode 268435732 would clear inode number in entry at offset 672... entry "page.h" at block 0 offset 696 in directory inode 268435639 references free inode 268435733 would clear inode number in entry at offset 696... entry "pgalloc.h" at block 0 offset 720 in directory inode 268435639 references free inode 268435734 would clear inode number in entry at offset 720... entry "ptrace.h" at block 0 offset 744 in directory inode 268435639 references free inode 268435735 would clear inode number in entry at offset 744... entry "mman.h" at block 0 offset 768 in directory inode 268435639 references free inode 268435736 would clear inode number in entry at offset 768... entry "mmu_context.h" at block 0 offset 792 in directory inode 268435639 references free inode 268435737 would clear inode number in entry at offset 792... entry "msgbuf.h" at block 0 offset 816 in directory inode 268435639 references free inode 268435738 would clear inode number in entry at offset 816... entry "namei.h" at block 0 offset 840 in directory inode 268435639 references free inode 268435739 would clear inode number in entry at offset 840... entry "queue.h" at block 0 offset 864 in directory inode 268435639 references free inode 268435740 would clear inode number in entry at offset 864... entry "param.h" at block 0 offset 888 in directory inode 268435639 references free inode 268435741 would clear inode number in entry at offset 888... entry "s390dyn.h" at block 0 offset 912 in directory inode 268435639 references free inode 268435742 would clear inode number in entry at offset 912... entry "pgtable.h" at block 0 offset 936 in directory inode 268435639 references free inode 268435743 would clear inode number in entry at offset 936... bad magic number 0x281a on inode 268435712, would reset magic number bad version number 0xffffffdd on inode 268435712, would reset version number bad inode format in inode 268435712 would have cleared inode 268435712 bad magic number 0x1e09 on inode 268435713, would reset magic number bad version number 0x1f on inode 268435713, would reset version number bad inode format in inode 268435713 would have cleared inode 268435713 bad magic number 0xab23 on inode 268435714, would reset magic number bad version number 0x67 on inode 268435714, would reset version number bad inode format in inode 268435714 would have cleared inode 268435714 bad magic number 0xafec on inode 268435715, would reset magic number bad version number 0xffffffeb on inode 268435715, would reset version number bad (negative) size -3741760305385614623 on inode 268435715 would have cleared inode 268435715 bad magic number 0x260b on inode 268435716, would reset magic number bad version number 0x7a on inode 268435716, would reset version number bad (negative) size -3658651245050632655 on inode 268435716 would have cleared inode 268435716 bad magic number 0x68ad on inode 268435717, would reset magic number bad version number 0xffffffa7 on inode 268435717, would reset version number bad (negative) size -8061786041470882404 on inode 268435717 would have cleared inode 268435717 bad magic number 0xa7c8 on inode 268435718, would reset magic number bad version number 0xffffff9b on inode 268435718, would reset version number bad inode format in inode 268435718 would have cleared inode 268435718 bad magic number 0x5afe on inode 268435719, would reset magic number bad version number 0x7b on inode 268435719, would reset version number bad inode format in inode 268435719 would have cleared inode 268435719 bad magic number 0x5fff on inode 268435720, would reset magic number bad version number 0x14 on inode 268435720, would reset version number bad (negative) size -6559184817219992953 on inode 268435720 would have cleared inode 268435720 bad magic number 0x57ba on inode 268435721, would reset magic number bad version number 0x49 on inode 268435721, would reset version number bad inode format in inode 268435721 would have cleared inode 268435721 bad magic number 0xa962 on inode 268435722, would reset magic number bad version number 0x8 on inode 268435722, would reset version number bad inode format in inode 268435722 would have cleared inode 268435722 bad magic number 0x49c4 on inode 268435723, would reset magic number bad version number 0x42 on inode 268435723, would reset version number bad inode format in inode 268435723 would have cleared inode 268435723 bad magic number 0x1b1e on inode 268435724, would reset magic number bad version number 0x20 on inode 268435724, would reset version number bad inode format in inode 268435724 would have cleared inode 268435724 bad magic number 0x5864 on inode 268435725, would reset magic number bad version number 0xffffffa2 on inode 268435725, would reset version number bad inode format in inode 268435725 would have cleared inode 268435725 bad magic number 0xe070 on inode 268435726, would reset magic number bad version number 0x2f on inode 268435726, would reset version number bad inode format in inode 268435726 would have cleared inode 268435726 bad magic number 0x37b1 on inode 268435727, would reset magic number bad version number 0x54 on inode 268435727, would reset version number bad inode format in inode 268435727 would have cleared inode 268435727 bad magic number 0xda5b on inode 268435728, would reset magic number bad version number 0xffffff92 on inode 268435728, would reset version number bad inode format in inode 268435728 would have cleared inode 268435728 bad magic number 0x9286 on inode 268435729, would reset magic number bad version number 0xfffffffa on inode 268435729, would reset version number bad (negative) size -6844212487954574407 on inode 268435729 would have cleared inode 268435729 bad magic number 0xedc6 on inode 268435730, would reset magic number bad version number 0x63 on inode 268435730, would reset version number bad inode format in inode 268435730 would have cleared inode 268435730 bad magic number 0xdbc on inode 268435731, would reset magic number bad version number 0xffffffa8 on inode 268435731, would reset version number bad (negative) size -7504915599599269110 on inode 268435731 would have cleared inode 268435731 bad magic number 0xe941 on inode 268435732, would reset magic number bad version number 0x58 on inode 268435732, would reset version number bad inode format in inode 268435732 would have cleared inode 268435732 bad magic number 0x851b on inode 268435733, would reset magic number bad version number 0xfffffff7 on inode 268435733, would reset version number bad inode format in inode 268435733 would have cleared inode 268435733 bad magic number 0xa411 on inode 268435734, would reset magic number bad version number 0xffffffab on inode 268435734, would reset version number bad inode format in inode 268435734 would have cleared inode 268435734 bad magic number 0x4446 on inode 268435735, would reset magic number bad version number 0x60 on inode 268435735, would reset version number bad inode format in inode 268435735 would have cleared inode 268435735 bad magic number 0x2a1c on inode 268435736, would reset magic number bad version number 0x2a on inode 268435736, would reset version number bad inode format in inode 268435736 would have cleared inode 268435736 bad magic number 0x8a49 on inode 268435737, would reset magic number bad version number 0x35 on inode 268435737, would reset version number bad (negative) size -2977792079054983672 on inode 268435737 would have cleared inode 268435737 bad magic number 0xcf4e on inode 268435738, would reset magic number bad version number 0x67 on inode 268435738, would reset version number bad inode format in inode 268435738 would have cleared inode 268435738 bad magic number 0xb79c on inode 268435739, would reset magic number bad version number 0xffffff8a on inode 268435739, would reset version number bad (negative) size -5988854802164675092 on inode 268435739 would have cleared inode 268435739 bad magic number 0xc9f2 on inode 268435740, would reset magic number bad version number 0x65 on inode 268435740, would reset version number bad inode format in inode 268435740 would have cleared inode 268435740 bad magic number 0xec3b on inode 268435741, would reset magic number bad version number 0x2a on inode 268435741, would reset version number bad (negative) size -7224737337336917654 on inode 268435741 would have cleared inode 268435741 bad magic number 0xda94 on inode 268435742, would reset magic number bad version number 0xffffffd6 on inode 268435742, would reset version number bad inode format in inode 268435742 would have cleared inode 268435742 bad magic number 0x2fc5 on inode 268435743, would reset magic number bad version number 0x12 on inode 268435743, would reset version number bad inode format in inode 268435743 would have cleared inode 268435743 bad directory block magic # 0x781bca72 in block 0 for directory inode 268435861 corrupt block 0 in directory inode 268435861 would junk block no . entry for directory 268435861 no .. entry for directory 268435861 problem with directory contents in inode 268435861 would have cleared inode 268435861 entry ".." at block 0 offset 32 in directory inode 268435974 references non-existent inode 234882309 would clear inode number in entry at offset 32... - agno = 17 - agno = 18 entry ".." at block 0 offset 32 in directory inode 301990447 references non-existent inode 234881408 would clear inode number in entry at offset 32... - agno = 19 entry ".." at block 0 offset 32 in directory inode 318784537 references non-existent inode 234921646 would clear inode number in entry at offset 32... - agno = 20 entry "arch-integrator" at block 0 offset 2512 in directory inode 335544744 references non-existent inode 234881311 would clear inode number in entry at offset 2512... entry "lapb" at block 0 offset 472 in directory inode 335544979 references non-existent inode 285213343 would clear inode number in entry at offset 472... entry ".." at block 0 offset 32 in directory inode 335544993 references non-existent inode 234881408 would clear inode number in entry at offset 32... No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "filesystems" in directory inode 218111767 points to non-existent inode, would junk entry entry "cdrom" in directory inode 218111767 points to non-existent inode, would junk entry entry "DocBook" in directory inode 218111767 points to non-existent inode, would junk entry entry "usb" in directory inode 218111767 points to non-existent inode, would junk entry entry "cris" in directory inode 50335119 points to non-existent inode, would junk entry entry "sgi-ip22" in directory inode 134242972 points to non-existent inode, would junk entry entry "math-emu" in directory inode 134242972 points to non-existent inode, would junk entry entry "dig" in directory inode 251671431 points to non-existent inode, would junk entry entry "stboards" in shortform directory 134242967 references non-existent inode 234921624 would junk entry entry "lib" in directory inode 201350546 points to non-existent inode, would junk entry entry "compressed" in shortform directory 218110519 references non-existent inode 234921608 would junk entry entry "compressed" in shortform directory 218110519 references non-existent inode 234921608 would junk entry entry "compressed" in shortform directory 218110519 references non-existent inode 234921608 would junk entry entry "mac" in directory inode 50335142 points to non-existent inode, would junk entry entry "amiga" in shortform directory 218110518 references non-existent inode 234921605 would junk entry entry "lib" in directory inode 50335137 points to non-existent inode, would junk entry entry "chrp" in shortform directory 100664757 references non-existent inode 234921600 would junk entry entry "chrp" in shortform directory 100664757 references non-existent inode 234921600 would junk entry entry "chrp" in shortform directory 100664757 references non-existent inode 234921600 would junk entry entry "tools" in directory inode 83888799 points to non-existent inode, would junk entry entry "baget" in directory inode 83888799 points to non-existent inode, would junk entry entry "ddb5477" in shortform directory 251670196 references non-existent inode 285227547 would junk entry entry "pb1000" in shortform directory 201350536 references non-existent inode 234885308 would junk entry entry "kernel" in shortform directory 201332535 references non-existent inode 285227406 would junk entry entry "kernel" in shortform directory 201332535 references non-existent inode 285227406 would junk entry entry "kernel" in shortform directory 201332535 references non-existent inode 285227406 would junk entry entry "tools" in shortform directory 218110480 references non-existent inode 234885302 would junk entry entry "tools" in shortform directory 218110480 references non-existent inode 234885302 would junk entry entry "tools" in shortform directory 218110480 references non-existent inode 234885302 would junk entry entry "net" in directory inode 218104333 points to non-existent inode, would junk entry entry "cdrom" in directory inode 218104333 points to non-existent inode, would junk entry entry "video" in directory inode 218104333 points to non-existent inode, would junk entry entry "tc" in directory inode 218104333 points to non-existent inode, would junk entry entry "pcmcia" in directory inode 218104333 points to non-existent inode, would junk entry entry "md" in directory inode 218104333 points to non-existent inode, would junk entry entry "devices" in directory inode 184555267 points to free inode 218110467, would junk entry entry "maps" in directory inode 184555267 points to non-existent inode, would junk entry entry "namespace" in directory inode 134219173 points to non-existent inode, would junk entry entry "resources" in directory inode 134219173 points to non-existent inode, would junk entry entry "emu10k1" in directory inode 201327491 points to non-existent inode, would junk entry entry "joystick" in directory inode 201327150 points to non-existent inode, would junk entry entry "compressor" in shortform directory 218104334 references non-existent inode 234881819 would junk entry entry "compressor" in shortform directory 218104334 references non-existent inode 234881819 would junk entry entry "compressor" in shortform directory 218104334 references non-existent inode 234881819 would junk entry entry "lapb" in directory inode 335544979 points to non-existent inode, would junk entry entry "netfilter" in directory inode 218104243 points to non-existent inode, would junk entry entry "net" in directory inode 117440662 points to non-existent inode, would junk entry entry "asm-ppc" in directory inode 117440662 points to non-existent inode, would junk entry entry "video" in directory inode 117440662 points to non-existent inode, would junk entry entry "asm-parisc" in directory inode 117440662 points to non-existent inode, would junk entry entry "current.h" in directory inode 268435639 points to free inode 268435712, would junk entry entry "delay.h" in directory inode 268435639 points to free inode 268435713, would junk entry entry "div64.h" in directory inode 268435639 points to free inode 268435714, would junk entry entry "dma.h" in directory inode 268435639 points to free inode 268435715, would junk entry entry "ebcdic.h" in directory inode 268435639 points to free inode 268435716, would junk entry entry "elf.h" in directory inode 268435639 points to free inode 268435717, would junk entry entry "errno.h" in directory inode 268435639 points to free inode 268435718, would junk entry entry "fcntl.h" in directory inode 268435639 points to free inode 268435719, would junk entry entry "gdb-stub.h" in directory inode 268435639 points to free inode 268435720, would junk entry entry "hardirq.h" in directory inode 268435639 points to free inode 268435721, would junk entry entry "hdreg.h" in directory inode 268435639 points to free inode 268435722, would junk entry entry "ide.h" in directory inode 268435639 points to free inode 268435723, would junk entry entry "init.h" in directory inode 268435639 points to free inode 268435724, would junk entry entry "io.h" in directory inode 268435639 points to free inode 268435725, would junk entry entry "ioctl.h" in directory inode 268435639 points to free inode 268435726, would junk entry entry "ioctls.h" in directory inode 268435639 points to free inode 268435727, would junk entry entry "ipc.h" in directory inode 268435639 points to free inode 268435728, would junk entry entry "ipcbuf.h" in directory inode 268435639 points to free inode 268435729, would junk entry entry "irq.h" in directory inode 268435639 points to free inode 268435730, would junk entry entry "mathemu.h" in directory inode 268435639 points to free inode 268435731, would junk entry entry "lowcore.h" in directory inode 268435639 points to free inode 268435732, would junk entry entry "page.h" in directory inode 268435639 points to free inode 268435733, would junk entry entry "pgalloc.h" in directory inode 268435639 points to free inode 268435734, would junk entry entry "ptrace.h" in directory inode 268435639 points to free inode 268435735, would junk entry entry "mman.h" in directory inode 268435639 points to free inode 268435736, would junk entry entry "mmu_context.h" in directory inode 268435639 points to free inode 268435737, would junk entry entry "msgbuf.h" in directory inode 268435639 points to free inode 268435738, would junk entry entry "namei.h" in directory inode 268435639 points to free inode 268435739, would junk entry entry "queue.h" in directory inode 268435639 points to free inode 268435740, would junk entry entry "param.h" in directory inode 268435639 points to free inode 268435741, would junk entry entry "s390dyn.h" in directory inode 268435639 points to free inode 268435742, would junk entry entry "pgtable.h" in directory inode 268435639 points to free inode 268435743, would junk entry entry "gcc" in directory inode 117440680 points to non-existent inode, would junk entry entry "arch-integrator" in directory inode 335544744 points to non-existent inode, would junk entry entry "raid" in directory inode 134217895 points to non-existent inode, would junk entry entry "isdn" in directory inode 134217895 points to non-existent inode, would junk entry entry "ncpfs" in directory inode 16777344 points to non-existent inode, would junk entry entry "romfs" in directory inode 16777344 points to non-existent inode, would junk entry entry "jffs" in directory inode 16777344 points to non-existent inode, would junk entry entry "reiserfs" in directory inode 16777344 points to non-existent inode, would junk entry - traversal finished ... - traversing all unattached subtrees ... entry "lmc" in directory inode 251658649 points to free inode 268435861, would junk entry entry "rescue" in shortform directory 251671454 references non-existent inode 285233953 would junk entry entry "rescue" in shortform directory 251671454 references non-existent inode 285233953 would junk entry - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 1101209, would move to lost+found disconnected dir inode 16802338, would move to lost+found disconnected dir inode 33554618, would move to lost+found disconnected dir inode 33560325, would move to lost+found disconnected dir inode 50331950, would move to lost+found disconnected dir inode 50344847, would move to lost+found disconnected dir inode 83886464, would move to lost+found disconnected dir inode 100663587, would move to lost+found disconnected dir inode 117440934, would move to lost+found disconnected dir inode 134219062, would move to lost+found disconnected dir inode 150995351, would move to lost+found disconnected inode 201332539, would move to lost+found disconnected inode 218110468, would move to lost+found disconnected inode 218110469, would move to lost+found disconnected inode 218110470, would move to lost+found disconnected inode 218110471, would move to lost+found disconnected inode 218110472, would move to lost+found disconnected inode 218110473, would move to lost+found disconnected inode 218110474, would move to lost+found disconnected inode 218110475, would move to lost+found disconnected inode 218110476, would move to lost+found disconnected inode 218110477, would move to lost+found disconnected inode 218110478, would move to lost+found disconnected inode 218110479, would move to lost+found disconnected inode 218110484, would move to lost+found disconnected inode 218110485, would move to lost+found disconnected inode 218110521, would move to lost+found disconnected dir inode 251658496, would move to lost+found disconnected dir inode 251658649, would move to lost+found disconnected dir inode 251658760, would move to lost+found disconnected dir inode 251658811, would move to lost+found disconnected dir inode 251670197, would move to lost+found disconnected dir inode 251671427, would move to lost+found disconnected dir inode 251671454, would move to lost+found disconnected dir inode 251671456, would move to lost+found disconnected dir inode 268435608, would move to lost+found disconnected inode 268435862, would move to lost+found disconnected inode 268435863, would move to lost+found disconnected inode 268435864, would move to lost+found disconnected inode 268435865, would move to lost+found disconnected inode 268435866, would move to lost+found disconnected inode 268435867, would move to lost+found disconnected inode 268435868, would move to lost+found disconnected inode 268435869, would move to lost+found disconnected inode 268435870, would move to lost+found disconnected inode 268435871, would move to lost+found disconnected inode 268435872, would move to lost+found disconnected inode 268435873, would move to lost+found disconnected inode 268435874, would move to lost+found disconnected inode 268435875, would move to lost+found disconnected dir inode 268435876, would move to lost+found disconnected dir inode 268435974, would move to lost+found disconnected dir inode 268441119, would move to lost+found disconnected dir inode 301990447, would move to lost+found disconnected dir inode 301990570, would move to lost+found disconnected dir inode 301996819, would move to lost+found disconnected dir inode 301996824, would move to lost+found disconnected dir inode 302002444, would move to lost+found disconnected dir inode 318784537, would move to lost+found disconnected dir inode 335544993, would move to lost+found Phase 7 - verify link counts... would have reset inode 16777344 nlinks from 33 to 29 would have reset inode 50335119 nlinks from 17 to 16 would have reset inode 50335137 nlinks from 12 to 11 would have reset inode 50335142 nlinks from 20 to 19 would have reset inode 83888799 nlinks from 23 to 21 would have reset inode 100664757 nlinks from 12 to 9 would have reset inode 117440662 nlinks from 24 to 20 would have reset inode 117440680 nlinks from 9 to 8 would have reset inode 134217895 nlinks from 11 to 9 would have reset inode 134219173 nlinks from 15 to 13 would have reset inode 134242967 nlinks from 7 to 6 would have reset inode 134242972 nlinks from 13 to 11 would have reset inode 184555267 nlinks from 6 to 4 would have reset inode 201327150 nlinks from 11 to 10 would have reset inode 201327491 nlinks from 5 to 4 would have reset inode 201332535 nlinks from 7 to 5 would have reset inode 201350536 nlinks from 4 to 3 would have reset inode 201350546 nlinks from 16 to 15 would have reset inode 218104243 nlinks from 3 to 2 would have reset inode 218104333 nlinks from 39 to 33 would have reset inode 218104334 nlinks from 5 to 2 would have reset inode 218110480 nlinks from 3 to 2 would have reset inode 218110518 nlinks from 3 to 2 would have reset inode 218110519 nlinks from 4 to 2 would have reset inode 218111767 nlinks from 28 to 24 would have reset inode 251658649 nlinks from 3 to 2 would have reset inode 251670196 nlinks from 4 to 3 would have reset inode 251671431 nlinks from 11 to 10 would have reset inode 251671454 nlinks from 5 to 3 would have reset inode 335544744 nlinks from 19 to 18 would have reset inode 335544979 nlinks from 28 to 27 No modify flag set, skipping filesystem flush and exiting. From owner-linux-xfs@oss.sgi.com Mon May 20 12:23:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJNEnC016431 for ; Mon, 20 May 2002 12:23:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJNEhJ016430 for linux-xfs-outgoing; Mon, 20 May 2002 12:23:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJN5nC016375 for ; Mon, 20 May 2002 12:23:05 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g4KJNnvv079934; Mon, 20 May 2002 21:23:49 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id VAA24676; Mon, 20 May 2002 21:23:49 +0200 (CEST) Date: Mon, 20 May 2002 21:23:49 +0200 (CEST) From: Seth Mos To: Sidik Isani cc: Subject: Re: "Corruption of in-memory data" In-Reply-To: <20020520090515.B18897@cfht.hawaii.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 20 May 2002, Sidik Isani wrote: > Hello - > > Thanks again for your help several months ago with xfs_growfs! > Now we have a new problem . . . > I was trying to resolve the slow performance issue of some of our > RAID5+XFS (2.4.16 kernel) by upgrading to 2.4.18 and XFS-1.1, and > reformatting with an external log, as suggested in the FAQ. 2.4.18 has a lot better RAID5 performance with an internal log as well. I also believe that the fixes that went into the CVS tree for the multiple block sizes support makes the raid5 support better. I don't think anyone benchmarked this yet but the performance difference is probably not as large anymore. > During resyncing, one of the disks failed and the raid 5 went into > degraded mode (no other disks had errors). After a clean reboot, still > running in degraded mode, (shouldn't matter to XFS, but I thought I'd > mention it) everything seemed OK until I tried to remove a directory: > > May 19 19:03:51 ike kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01ed751 > May 19 19:03:51 ike kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) > May 19 19:03:51 ike kernel: Please umount the filesystem, and rectify the problem(s) > [System froze!] I think something went bad the moment that the raid5 went into degraded mode. This shouldn't happen but you are wise in not automatically repairing the fs. > to replay the log, and ran xfs_repair -n. The output is included below. > I'm thinking of trying again later today, maybe with an internal > log again (which should be usable now, with 2.4.18, right?) But the > crash above worries me. Please let me know if there are any other > tests I should run on the crashed filesystem before starting over. As stated aboce the internal log raid5 should be OK. I still have a system raid5 with an internal log that did get a bit faster with the change to 2.4.18. Since it looks like filesystem corruption I think it is best to be careful from here on. I think making a backup now would be a good idea. Cheers Seth From owner-linux-xfs@oss.sgi.com Mon May 20 12:39:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJdwnC019078 for ; Mon, 20 May 2002 12:39:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJdwDN019077 for linux-xfs-outgoing; Mon, 20 May 2002 12:39:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJdrnC019024 for ; Mon, 20 May 2002 12:39:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA55953; Mon, 20 May 2002 14:40:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA26307; Mon, 20 May 2002 14:39:19 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KJbfh05886; Mon, 20 May 2002 14:37:41 -0500 Subject: Re: "Corruption of in-memory data" From: Steve Lord To: Sidik Isani Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020520090515.B18897@cfht.hawaii.edu> References: <20020520090515.B18897@cfht.hawaii.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 May 2002 14:37:41 -0500 Message-Id: <1021923461.4832.335.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-20 at 14:05, Sidik Isani wrote: > Hello - > > Thanks again for your help several months ago with xfs_growfs! > Now we have a new problem . . . > I was trying to resolve the slow performance issue of some of our > RAID5+XFS (2.4.16 kernel) by upgrading to 2.4.18 and XFS-1.1, and > reformatting with an external log, as suggested in the FAQ. > > During resyncing, one of the disks failed and the raid 5 went into > degraded mode (no other disks had errors). After a clean reboot, still > running in degraded mode, (shouldn't matter to XFS, but I thought I'd > mention it) everything seemed OK until I tried to remove a directory: > Just from a quick scan, all your corruption is localized to two parts of the volume, these are around the headers for allocation groups 14 and 17. I do not know if these areas will map onto the failed disk, but it looks something like that. Destruction in these areas also appears pretty drastic. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon May 20 12:56:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJtxnC021376 for ; Mon, 20 May 2002 12:55:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJtx6v021375 for linux-xfs-outgoing; Mon, 20 May 2002 12:55:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJtonC021282 for ; Mon, 20 May 2002 12:55:51 -0700 Received: (qmail 27053 invoked by uid 500); 20 May 2002 19:56:12 -0000 Subject: Re: XFS in the 2.5 kernel From: Austin Gonyou To: Christoph Hellwig Cc: Andi Kleen , Stuart Luppescu , Linux-xfs list In-Reply-To: <20020520131448.A12985@infradead.org> References: <20020520131448.A12985@infradead.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L1rywqpHujHF5pPYG8to" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 20 May 2002 14:56:12 -0500 Message-Id: <1021924572.26055.19.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-L1rywqpHujHF5pPYG8to Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a thought, but isn't the XFS pagebuf code part of what makes it so damn fast too? On Mon, 2002-05-20 at 07:14, Christoph Hellwig wrote: > On Mon, May 20, 2002 at 12:36:57PM +0200, Andi Kleen wrote: > > I don't think so. While it would be nice if XFS used more common > > infrastructure or its infrastructure (pagebuf) would be more open > to=20 > > other fs it is not an absolute requirement for merging. That's > IMHO > > based on merging of other file system and code, the last word has > Linus=20 > > of course. >=20 > Pagebuf is basically useable by other filesystems. For example I > think > I could port JFS to use it as backing for it's metapges - it just > far > too complex for JFS's needs so I don't see any point in doing so. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-L1rywqpHujHF5pPYG8to Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA86VTc94g6ZVmFMoIRAjJuAKCpgQKnWzw/W6k7lNOwBsMdrJEP5QCfeTO6 dfuqfCPlJNefBoOoNgDNuZU= =kcV5 -----END PGP SIGNATURE----- --=-L1rywqpHujHF5pPYG8to-- From owner-linux-xfs@oss.sgi.com Mon May 20 13:10:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKA1nC022937 for ; Mon, 20 May 2002 13:10:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKA1r3022936 for linux-xfs-outgoing; Mon, 20 May 2002 13:10:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KK9unC022887 for ; Mon, 20 May 2002 13:09:57 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 4F76B1D805 for ; Mon, 20 May 2002 22:10:37 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052022103680:6927 ; Mon, 20 May 2002 22:10:36 +0200 Message-ID: <3CE95846.5020000@propack-data.com> Date: Mon, 20 May 2002 22:10:46 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: problems with xfs as root fs X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 22:10:37, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 22:10:37, Serialize complete at 20.05.2002 22:10:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, on my 'new' linux-box i've set up an linuxfromscatch system with xfs as root fs on an promise ide raid controller (using /dev/ataraid/dXpY). I use the kernel 2.4.18 with the xfs 1.1 patch. Often after a (obviously clean) shutdown I have problems with booting into my system. I get a kernel panic saying thast there is something wrong with the log of the xfs filesystem. Than I must reboot with my old SCSI disk and run xfs_repair (often with the -L option ;-( ) to get the system running again. Some hints what's wrong there? And how to get a working xfs-system without emergency partition ? regards micha From owner-linux-xfs@oss.sgi.com Mon May 20 13:27:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKRrnC024974 for ; Mon, 20 May 2002 13:27:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKRrZ7024973 for linux-xfs-outgoing; Mon, 20 May 2002 13:27:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKRnnC024939 for ; Mon, 20 May 2002 13:27:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA40079 for ; Mon, 20 May 2002 15:28:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA57752 for ; Mon, 20 May 2002 15:28:34 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KKQtK07733; Mon, 20 May 2002 15:26:55 -0500 Message-Id: <200205202026.g4KKQtK07733@jen.americas.sgi.com> Date: Mon, 20 May 2002 15:26:55 -0500 Subject: TAKE - make sure dmapi cannot be configured differently from xfs To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Reduce the possible combinations of xfs and dmapi to ones which actually compile. Date: Mon May 20 13:26:12 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119561a linux/fs/Config.in - 1.78 - Fix up dmapi config flags From owner-linux-xfs@oss.sgi.com Mon May 20 13:27:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKR9nC024897 for ; Mon, 20 May 2002 13:27:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKR9Kt024896 for linux-xfs-outgoing; Mon, 20 May 2002 13:27:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKR4nC024870 for ; Mon, 20 May 2002 13:27:04 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA40057; Mon, 20 May 2002 15:27:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA28178; Mon, 20 May 2002 15:27:47 -0500 (CDT) Subject: Re: problems with xfs as root fs From: Eric Sandeen To: Michael Wahlbrink Cc: linux-xfs In-Reply-To: <3CE95846.5020000@propack-data.com> References: <3CE95846.5020000@propack-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 20 May 2002 15:27:58 -0500 Message-Id: <1021926479.2249.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What was the exact error message that you got on the panic? Also, does the promise controller do write caching? -Eric On Mon, 2002-05-20 at 15:10, Michael Wahlbrink wrote: > hi, > on my 'new' linux-box i've set up an linuxfromscatch system with xfs as > root fs on an promise ide raid controller (using /dev/ataraid/dXpY). I > use the kernel 2.4.18 with the xfs 1.1 patch. > Often after a (obviously clean) shutdown I have problems with booting > into my system. I get a kernel panic saying thast there is something > wrong with the log of the xfs filesystem. Than I must reboot with my old > SCSI disk and run xfs_repair (often with the -L option ;-( ) to get the > system running again. > Some hints what's wrong there? And how to get a working xfs-system > without emergency partition ? > > regards > micha > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 20 13:28:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKSSnC025175 for ; Mon, 20 May 2002 13:28:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKSSHM025174 for linux-xfs-outgoing; Mon, 20 May 2002 13:28:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKSInC025108 for ; Mon, 20 May 2002 13:28:19 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id KAA19251; Mon, 20 May 2002 10:28:54 -1000 Date: Mon, 20 May 2002 10:28:54 -1000 From: Sidik Isani To: Steve Lord Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: "Corruption of in-memory data" Message-ID: <20020520102853.C18897@cfht.hawaii.edu> References: <20020520090515.B18897@cfht.hawaii.edu> <1021923461.4832.335.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1021923461.4832.335.camel@jen.americas.sgi.com>; from lord@sgi.com on Mon, May 20, 2002 at 02:37:41PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 02:37:41PM -0500, Steve Lord wrote: > On Mon, 2002-05-20 at 14:05, Sidik Isani wrote: > > Hello - > > > > Thanks again for your help several months ago with xfs_growfs! > > Now we have a new problem . . . > > I was trying to resolve the slow performance issue of some of our > > RAID5+XFS (2.4.16 kernel) by upgrading to 2.4.18 and XFS-1.1, and > > reformatting with an external log, as suggested in the FAQ. > > > > During resyncing, one of the disks failed and the raid 5 went into > > degraded mode (no other disks had errors). After a clean reboot, still > > running in degraded mode, (shouldn't matter to XFS, but I thought I'd > > mention it) everything seemed OK until I tried to remove a directory: > > > > Just from a quick scan, all your corruption is localized to two parts of > the volume, these are around the headers for allocation groups 14 and > 17. I do not know if these areas will map onto the failed disk, but it It's a software raid5, and only one of 6 disks failed. To XFS, the device should have been completely functional. > looks something like that. Destruction in these areas also appears > pretty drastic. Oh, there's no worry about the contents of this filesystem. I was actually trying to do the benchmarks on performance that Seth mentioned had not been done. If I get them done, I'll post the results here. I'd just really like to understand what happened. If raid5 is to blame here, there isn't much point in using it! Any suggestions on the best way to narrow it down? Maybe it is worth starting over, with the bad disk still in there, to see if it happens again. The sequence was: 1. Partitioned 6 13GB IDE disks as ~12.9x6 raid5 plus a small raid1 on the first two disks for the log. 2. Rebooted to be sure partition tables were seen correctly. 3. mkraid /dev/md0 (the raid5 ... resyncing began) 4. mkraid /dev/md1 (the raid1 ... resyncing delayed because on same disk) 5. mkfs.xfs -o logdev=/dev/md1 /dev/md0 6. mounted it and untarred a kernel tree (notably faster than 2.4.16!) 7. resyncing continues until about half way through it finds a bad sector on *one* of the disks and switches to degraded mode. No IDE errors after that one. 8. Rebooted (wanted to see if it came back still in degraded mode. It did.) 9. mounted again and tried to rm -rf the linux kernel tree... crash. Only a second disk failing should have caused any data loss, but this was not the case here. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Mon May 20 13:34:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKYRnC025530 for ; Mon, 20 May 2002 13:34:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKYRHA025529 for linux-xfs-outgoing; Mon, 20 May 2002 13:34:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKYLnC025496 for ; Mon, 20 May 2002 13:34:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA40504 for ; Mon, 20 May 2002 15:35:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA64312 for ; Mon, 20 May 2002 15:35:05 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g4KKXRd08179; Mon, 20 May 2002 15:33:27 -0500 Message-Id: <200205202033.g4KKXRd08179@jen.americas.sgi.com> Date: Mon, 20 May 2002 15:33:27 -0500 Subject: TAKE - fix fsx test case failure on 1K block fs To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This I think completes the core of the multiple blocksize support. Still some open issues in O_DIRECT, but this was a corruption case during random I/O. Filesystems with blocksize == pagesize were not affected by this. Steve Date: Mon May 20 13:33:09 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:119562a linux/fs/xfs/xfs_vnodeops.c - 1.526 - remove sethole vop linux/fs/xfs/linux/xfs_lrw.c - 1.137 - remove a large chunk of dead code linux/fs/xfs/linux/xfs_fs_subr.c - 1.29 - remove fs_pages_sethole - we no longer have a way to call it anyway linux/fs/xfs/linux/xfs_iops.c - 1.141 - Pay more attention to buffer_uptodate state. linux/fs/xfs/linux/xfs_vnode.h - 1.31 - remove VOP_PAGES_SETHOLE - it is not used linux/fs/xfs/linux/xfs_fs_subr.h - 1.5 - remove fs_pages_sethole linux/fs/xfs/pagebuf/page_buf_io.c - 1.36 - If a buffer is not uptodate, then we are definitely not supposed to put an extent underneath it. From owner-linux-xfs@oss.sgi.com Mon May 20 13:34:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKYqnC025686 for ; Mon, 20 May 2002 13:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKYqP8025685 for linux-xfs-outgoing; Mon, 20 May 2002 13:34:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKYjnC025634 for ; Mon, 20 May 2002 13:34:45 -0700 Received: from [206.246.249.108] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 179tsT-000DKC-00; Mon, 20 May 2002 16:35:33 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g4KKVbN07349; Mon, 20 May 2002 16:31:37 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g4KKVac08667; Mon, 20 May 2002 16:31:36 -0400 Date: Mon, 20 May 2002 16:31:36 -0400 From: Charles Shannon Hendrix To: John Kihonge Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems Message-ID: <20020520203135.GA4906@widomaker.com> References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> <200205162151.07376.hasch@t-online.de> <20020517000623.GA13675@widomaker.com> <3CE53102.2B550CF8@sgi.com> <20020517181451.GC13880@widomaker.com> <3CE91559.D5D36B75@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE91559.D5D36B75@sgi.com> User-Agent: Mutt/1.3.99i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 10:25:14AM -0500, John Kihonge wrote: > > xfsrestore: examining media file 3 > > xfsrestore: seeking past media file directory dump > > xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > > contextp->dc_recsz )' failed. > > Aborted > > > > If the problem is just the assertion one, it maybe that you are restoring an > old dump (dumped prior to a fix for xfsdump-1.1.10 of 10th December 2001). > > The mail archive: > http://marc.theaimsgroup.com/?l=linux-xfs&m=101435725816823&w=2 has an > explanation of the problem and the suggested fix to allow one to restore > such a dump. > > I hope that will fix the problem. I made the recommended change to common/xlate.c, removing the first_mark_offset endian conversion. No joy: xfsrestore: restoring non-directory files xfsrestore: examining media file 8 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1481: do_next_mark: Assertion `rechdrp->first_mark_offset != 0' failed. I then made the recommended changes to 2.01 of xfsdump drive_scsitape.c. The change was for 1.5, but the file looks about the same. The modification goes just before the failing assertion listed in the error above. The results from running this version is: ...the same exact error. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Mon May 20 13:37:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKbDnC025879 for ; Mon, 20 May 2002 13:37:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKbDJP025877 for linux-xfs-outgoing; Mon, 20 May 2002 13:37:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKb7nC025847 for ; Mon, 20 May 2002 13:37:07 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id D11E61D805 for ; Mon, 20 May 2002 22:37:47 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052022374825:6935 ; Mon, 20 May 2002 22:37:48 +0200 Message-ID: <3CE95EA5.5070604@propack-data.com> Date: Mon, 20 May 2002 22:37:57 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Re: problems with xfs as root fs References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 22:37:48, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 22:37:48, Serialize complete at 20.05.2002 22:37:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > What was the exact error message that you got on the panic? I've to go home and write it down and then come back to company to send the error messages ;-| (my internet access at home is broken) > > Also, does the promise controller do write caching? I dom't think so, it's such a 'cheap' promise 'FastTrak100 TX2'. I also didn'n find something about caching on theyr website....... regards micha > > -Eric > > On Mon, 2002-05-20 at 15:10, Michael Wahlbrink wrote: > >>hi, >>on my 'new' linux-box i've set up an linuxfromscatch system with xfs as >>root fs on an promise ide raid controller (using /dev/ataraid/dXpY). I >>use the kernel 2.4.18 with the xfs 1.1 patch. >>Often after a (obviously clean) shutdown I have problems with booting >>into my system. I get a kernel panic saying thast there is something >>wrong with the log of the xfs filesystem. Than I must reboot with my old >>SCSI disk and run xfs_repair (often with the -L option ;-( ) to get the >>system running again. >>Some hints what's wrong there? And how to get a working xfs-system >>without emergency partition ? >> >>regards >>micha >> > From owner-linux-xfs@oss.sgi.com Mon May 20 13:41:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKfOnC026211 for ; Mon, 20 May 2002 13:41:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKfOFE026210 for linux-xfs-outgoing; Mon, 20 May 2002 13:41:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKfGnC026179 for ; Mon, 20 May 2002 13:41:17 -0700 Received: (qmail 28028 invoked by uid 500); 20 May 2002 20:41:54 -0000 Subject: xfsdump/xfsrestore questions. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7gqDjOyw2FfGVeLY8sdL" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 20 May 2002 15:41:54 -0500 Message-Id: <1021927314.27937.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-7gqDjOyw2FfGVeLY8sdL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I dumped about 9gb of data to a DDS3 DAT. It took about 4 hours with xfsdump. On a windows box, with the same TBU, I can dump the same amount in about 1.5 hrs. Can anyone suggest what I can do to speed things up a bit? HP DDS3 SCSI DAT model: C1537A=20 TIA. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-7gqDjOyw2FfGVeLY8sdL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA86V+S94g6ZVmFMoIRArXfAKDT9+yCzliDCEgcuAOL//W9TKaNOQCgif4P IzTqVR/aFHMS35UybmqrAqw= =4KuI -----END PGP SIGNATURE----- --=-7gqDjOyw2FfGVeLY8sdL-- From owner-linux-xfs@oss.sgi.com Mon May 20 14:09:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KL98nC027018 for ; Mon, 20 May 2002 14:09:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KL98wv027017 for linux-xfs-outgoing; Mon, 20 May 2002 14:09:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf24bis.bellsouth.net (mail124.mail.bellsouth.net [205.152.58.84]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KL8xnC026978 for ; Mon, 20 May 2002 14:08:59 -0700 Received: from taz ([66.156.2.161]) by imf24bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020520210943.YYXJ24137.imf24bis.bellsouth.net@taz>; Mon, 20 May 2002 17:09:43 -0400 Date: Mon, 20 May 2002 17:04:21 -0400 From: Greg Freemyer Subject: re: xfsdump/xfsrestore questions. To: Austin Gonyou , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020520210943.YYXJ24137.imf24bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KL8xnC026979 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I can't talk to xfs tuning but ... Making a generic comparison between windows and xfsdump is unfair, unless you have exactly the same hardware involved. In general you need to have a feed speed about 3x the tapes max. write speed to keep the tape streaming. IIRC a small dat drive can do about 3.6 GB/hr of compressed data. If your data is 2:1 compressible, that is 7.2 GB/hr uncompressed. That sounds like what you are getting on the windows box. To get this, you probably have a disk-drive speed of about 21.6 GB/hr or more on the windows box. What sort of disk-drive speed do you have on the xfs box? I'm sure you know that RAID can drastically improve your disk-speed. BTW: With really high-end drives like SDLT (39 GB/hr compressed), you basically have to design your whole storage system around their required feed rate if you want them to be able to stream. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> I dumped about 9gb of data to a DDS3 DAT. It took about 4 hours with >> xfsdump. >> On a windows box, with the same TBU, I can dump the same amount in about >> 1.5 hrs. Can anyone suggest what I can do to speed things up a bit? >> HP DDS3 SCSI DAT model: C1537A >> TIA. >> -- >> Austin Gonyou >> Systems Architect, CCNA >> Coremetrics, Inc. >> Phone: 512-698-7250 >> email: austin@coremetrics.com >> "One ought never to turn one's back on a threatened danger and >> try to run away from it. If you do that, you will double the danger. >> But if you meet it promptly and without flinching, you will >> reduce the danger by half." >> Sir Winston Churchill >> -- NextPart -- >> Attached File: c:\program >> files\goldmine\MailBox\Attach\gaf\signature(12).asc From owner-linux-xfs@oss.sgi.com Mon May 20 14:11:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLBxnC027188 for ; Mon, 20 May 2002 14:11:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLBxBX027187 for linux-xfs-outgoing; Mon, 20 May 2002 14:11:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLBpnC027161 for ; Mon, 20 May 2002 14:11:52 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA42192; Mon, 20 May 2002 16:12:36 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA05205; Mon, 20 May 2002 16:12:35 -0500 (CDT) Subject: Re: problems with xfs as root fs From: Eric Sandeen To: Michael Wahlbrink Cc: linux-xfs In-Reply-To: <3CE9648E.70403@propack-data.com> References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> <3CE9648E.70403@propack-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 20 May 2002 16:12:46 -0500 Message-Id: <1021929167.2249.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok, two things here then. Apparently your filesystem thinks it was not shut down cleanly; it's doing recovery. Then recovery fails, and it can't mount the root FS so you get the panic. To quote Steve, "Bad clientid means there was something in the log which was not recognized." I don't know for sure what might have caused this, it seems like write caching could be the culprit. What version is the kernel? I wonder where the XFS bits came from. I would make sure write caching is off on the IDE drives and see if that solves the problem (will change your performance quite a bit too, I'm afraid.) -Eric On Mon, 2002-05-20 at 16:03, Michael Wahlbrink wrote: > Eric Sandeen wrote: > > What was the exact error message that you got on the panic? > > Ok here come the error messages (hope without typos): > > [...] > FAT: bogus logical sector size 0 > FAT: bogus logical sector size 0 > XFS mounting filesystem ataraid(114,1) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem ataraid(114,1) (dev: 114/1) > XFS: xlog_recover_process_data:bad clientid > XFS: log mount/recovery failed > XFS: log mount failed > Kernel panic: VFS: Unable to mount root fs on 72:01 > > thats it ;-) > > > > Also, does the promise controller do write caching? > > I don't think so, but perhaps the two IDE disks .... > should I disable this cache if it's enabled? > > hth > > regards > micha > > > -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 20 14:19:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLJBnC027385 for ; Mon, 20 May 2002 14:19:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLJBU6027384 for linux-xfs-outgoing; Mon, 20 May 2002 14:19:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLJ4nC027357 for ; Mon, 20 May 2002 14:19:05 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 2BFFF1D807; Mon, 20 May 2002 23:19:46 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052023194575:6942 ; Mon, 20 May 2002 23:19:45 +0200 Message-ID: <3CE9687B.4070102@propack-data.com> Date: Mon, 20 May 2002 23:19:55 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Cc: Eric Sandeen Subject: Re: problems with xfs as root fs References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> <3CE9648E.70403@propack-data.com> <1021929167.2249.8.camel@stout.americas.sgi.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 23:19:45, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 23:19:46, Serialize complete at 20.05.2002 23:19:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Ok, two things here then. Apparently your filesystem thinks it was not > shut down cleanly; it's doing recovery. Then recovery fails, and it > can't mount the root FS so you get the panic. To quote Steve, "Bad > clientid means there was something in the log which was not > recognized." I don't know for sure what might have caused this, it > seems like write caching could be the culprit. > > What version is the kernel? I wonder where the XFS bits came from. The Kernel is a 2.4.18 from kernel.org with the xfs-1.1-2.4.18-all.patch patch from oss.sgi.com :-| nothing special or have I missed something? ;-) > > I would make sure write caching is off on the IDE drives and see if that > solves the problem (will change your performance quite a bit too, I'm > afraid.) It's slow enough with cache - how will it be without? ;-) > I'll go home and try this ..... > -Eric > thanks for the fast answers! I will report the results soon ;-) regards micha From owner-linux-xfs@oss.sgi.com Mon May 20 14:20:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLKBnC027658 for ; Mon, 20 May 2002 14:20:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLKB3N027657 for linux-xfs-outgoing; Mon, 20 May 2002 14:20:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLK0nC027614 for ; Mon, 20 May 2002 14:20:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA42278; Mon, 20 May 2002 16:20:44 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA29551; Mon, 20 May 2002 16:20:44 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id QAA34809; Mon, 20 May 2002 16:20:43 -0500 (CDT) Message-ID: <3CE968AA.9EFC53D0@sgi.com> Date: Mon, 20 May 2002 16:20:42 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Charles Shannon Hendrix CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore problems References: <20020511205125.GD4462@widomaker.com> <20020516020938.GB10343@widomaker.com> <3CE3D3CF.7DBAF8A9@sgi.com> <200205162151.07376.hasch@t-online.de> <20020517000623.GA13675@widomaker.com> <3CE53102.2B550CF8@sgi.com> <20020517181451.GC13880@widomaker.com> <3CE91559.D5D36B75@sgi.com> <20020520203135.GA4906@widomaker.com> Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Charles Shannon Hendrix wrote: > On Mon, May 20, 2002 at 10:25:14AM -0500, John Kihonge wrote: > > > > xfsrestore: examining media file 3 > > > xfsrestore: seeking past media file directory dump > > > xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion > > > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > > > contextp->dc_recsz )' failed. > > > Aborted > > > > > > > If the problem is just the assertion one, it maybe that you are restoring an > > old dump (dumped prior to a fix for xfsdump-1.1.10 of 10th December 2001). > > > > The mail archive: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=101435725816823&w=2 has an > > explanation of the problem and the suggested fix to allow one to restore > > such a dump. > > > > I hope that will fix the problem. > > I made the recommended change to common/xlate.c, removing the > first_mark_offset endian conversion. > > No joy: > > xfsrestore: restoring non-directory files > xfsrestore: examining media file 8 > xfsrestore: seeking past media file directory dump > xfsrestore: drive_scsitape.c:1481: do_next_mark: Assertion > `rechdrp->first_mark_offset != 0' failed. > > I then made the recommended changes to 2.01 of xfsdump drive_scsitape.c. > The change was for 1.5, but the file looks about the same. The > modification goes just before the failing assertion listed in the > error above. Try making the recommended changes to restore/arch_xlate.c and see if it makes any difference. If it dosnt work, use -v5 option and put the output in a location that we could look at it to see if we can find any indication of what is hapenning. > > > The results from running this version is: > > ...the same exact error. > > -- > UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com ---- Kihonge JN [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon May 20 14:26:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLQinC027955 for ; Mon, 20 May 2002 14:26:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLQhHO027954 for linux-xfs-outgoing; Mon, 20 May 2002 14:26:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLQdnC027927 for ; Mon, 20 May 2002 14:26:40 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA42999; Mon, 20 May 2002 16:27:24 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA24040; Mon, 20 May 2002 16:27:24 -0500 (CDT) Subject: Re: problems with xfs as root fs From: Eric Sandeen To: Michael Wahlbrink Cc: linux-xfs In-Reply-To: <3CE9687B.4070102@propack-data.com> References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas. sgi.com> <3CE9648E.70403@propack-data.com> <1021929167.2249.8.camel@stout.americas.sgi.com> <3CE9687B.4070102@propack-data.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 20 May 2002 16:27:34 -0500 Message-Id: <1021930055.2191.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-20 at 16:19, Michael Wahlbrink wrote: > The Kernel is a 2.4.18 from kernel.org with the xfs-1.1-2.4.18-all.patch > patch from oss.sgi.com :-| > nothing special or have I missed something? ;-) Oh, sorry, you said that already. Too little sleep, too many brain-threads. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon May 20 14:27:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLRLnC028116 for ; Mon, 20 May 2002 14:27:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLRLHQ028115 for linux-xfs-outgoing; Mon, 20 May 2002 14:27:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLR6nC027997 for ; Mon, 20 May 2002 14:27:06 -0700 Received: (qmail 28544 invoked by uid 500); 20 May 2002 21:27:39 -0000 Subject: re: xfsdump/xfsrestore questions. From: Austin Gonyou To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020520210943.YYXJ24137.imf24bis.bellsouth.net@taz> References: <20020520210943.YYXJ24137.imf24bis.bellsouth.net@taz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MAHaRL4GRB13TFzHzkpB" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 20 May 2002 16:27:39 -0500 Message-Id: <1021930059.28495.16.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-MAHaRL4GRB13TFzHzkpB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-05-20 at 16:04, Greg Freemyer wrote: > I can't talk to xfs tuning but ... >=20 > Making a generic comparison between windows and xfsdump is unfair, > unless you have exactly the same hardware involved. >=20 Yes, exactly the same hardware. Only difference in this case is software. > In general you need to have a feed speed about 3x the tapes max. > write speed to keep the tape streaming. >=20 > IIRC a small dat drive can do about 3.6 GB/hr of compressed data. >=20 Yes, that can be correct. > If your data is 2:1 compressible, that is 7.2 GB/hr uncompressed.=20 > That sounds like what you are getting on the windows box. >=20 The issue here is that both jobs are using compression, but Arcserve 2000 on NT is performing faster than say, tar or xfsdump. The problem I've got with this though, is that it's so much longer there's got to be something I could tweak, either with xfsdump or the drive, so that's what prompted my query. > What sort of disk-drive speed do you have on the xfs box? I'm sure > you know that RAID can drastically improve your disk-speed. 10K RPM 18GB Seagate at LVD(80mb/s) (yes..I know about theoretical max, etc.) The HP is at 10MB/s, I'd prefer to make it 20MB/s though..at least.(can set it in the SCSI bios I think? > BTW: With really high-end drives like SDLT (39 GB/hr compressed), > you basically have to design your whole storage system around their > required feed rate if you want them to be able to stream. >=20 I'm quite aware of that..but thanks for the reminder. :) > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com >=20 >=20 > >> I dumped about 9gb of data to a DDS3 DAT. It took about 4 hours > with > >> xfsdump. >=20 > >> On a windows box, with the same TBU, I can dump the same amount > in about > >> 1.5 hrs. Can anyone suggest what I can do to speed things up a > bit? >=20 > >> HP DDS3 SCSI DAT model: C1537A=20 >=20 > >> TIA. >=20 > >> --=20 > >> Austin Gonyou > >> Systems Architect, CCNA > >> Coremetrics, Inc. > >> Phone: 512-698-7250 > >> email: austin@coremetrics.com >=20 > >> "One ought never to turn one's back on a threatened danger and=20 > >> try to run away from it. If you do that, you will double the > danger.=20 > >> But if you meet it promptly and without flinching, you will=20 > >> reduce the danger by half." > >> Sir Winston Churchill >=20 >=20 >=20 > >> -- NextPart -- > >> Attached File: c:\program > >> files\goldmine\MailBox\Attach\gaf\signature(12).asc --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-MAHaRL4GRB13TFzHzkpB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA86WpL94g6ZVmFMoIRAuekAKC5fMq14oMfhSQgxLymSG+Hv72yyQCfWD9t VSWluzdUHWwZP2a2Wtq0pFA= =PhkI -----END PGP SIGNATURE----- --=-MAHaRL4GRB13TFzHzkpB-- From owner-linux-xfs@oss.sgi.com Mon May 20 14:30:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLU5nC028293 for ; Mon, 20 May 2002 14:30:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLU5Ze028292 for linux-xfs-outgoing; Mon, 20 May 2002 14:30:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLTxnC028257 for ; Mon, 20 May 2002 14:29:59 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id C566D1D805; Mon, 20 May 2002 23:03:01 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052023030071:6939 ; Mon, 20 May 2002 23:03:00 +0200 Message-ID: <3CE9648E.70403@propack-data.com> Date: Mon, 20 May 2002 23:03:10 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen , linux-xfs Subject: Re: problems with xfs as root fs References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 23:03:00, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.05.2002 23:03:01, Serialize complete at 20.05.2002 23:03:01 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > What was the exact error message that you got on the panic? Ok here come the error messages (hope without typos): [...] FAT: bogus logical sector size 0 FAT: bogus logical sector size 0 XFS mounting filesystem ataraid(114,1) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem ataraid(114,1) (dev: 114/1) XFS: xlog_recover_process_data:bad clientid XFS: log mount/recovery failed XFS: log mount failed Kernel panic: VFS: Unable to mount root fs on 72:01 thats it ;-) > Also, does the promise controller do write caching? I don't think so, but perhaps the two IDE disks .... should I disable this cache if it's enabled? hth regards micha > -Eric From owner-linux-xfs@oss.sgi.com Mon May 20 15:31:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KMVunC029079 for ; Mon, 20 May 2002 15:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KMVugW029078 for linux-xfs-outgoing; Mon, 20 May 2002 15:31:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KMVknC029052 for ; Mon, 20 May 2002 15:31:47 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 65B3D1D805; Tue, 21 May 2002 00:32:28 +0200 (CEST) Received: from propack-data.com ([10.2.100.1]) by pegasus.propack-data.de (Lotus Domino Release 5.0.8) with ESMTP id 2002052100322802:6954 ; Tue, 21 May 2002 00:32:28 +0200 Message-ID: <3CE97985.8060405@propack-data.com> Date: Tue, 21 May 2002 00:32:37 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs , Eric Sandeen Subject: Re: problems with xfs as root fs References: <3CE95846.5020000@propack-data.com> <1021926479.2249.4.camel@stout.americas.sgi.com> <3CE9648E.70403@propack-data.com> <1021929167.2249.8.camel@stout.americas.sgi.com> <3CE9687B.4070102@propack-data.com> X-MIMETrack: Itemize by SMTP Server on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 21.05.2002 00:32:28, Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 21.05.2002 00:32:28, Serialize complete at 21.05.2002 00:32:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Michael Wahlbrink wrote: > Eric Sandeen wrote: > >> Ok, two things here then. Apparently your filesystem thinks it was not >> shut down cleanly; it's doing recovery. Then recovery fails, and it >> can't mount the root FS so you get the panic. To quote Steve, "Bad >> clientid means there was something in the log which was not >> recognized." I don't know for sure what might have caused this, it >> seems like write caching could be the culprit. >> >> What version is the kernel? I wonder where the XFS bits came from. > > > The Kernel is a 2.4.18 from kernel.org with the xfs-1.1-2.4.18-all.patch > patch from oss.sgi.com :-| > nothing special or have I missed something? ;-) > >> >> I would make sure write caching is off on the IDE drives and see if that >> solves the problem (will change your performance quite a bit too, I'm >> afraid.) > > It's slow enough with cache - how will it be without? ;-) > > I'll go home and try this ..... > >> -Eric Ok, was at home to get the stuff working, but ...... I booted my 'repairsystem' and tried the usual xfs_repair (-L) commands out of the bash-history, but this time they fail. # xfs_repair -L /dev/ataraid/d0p1 xfs_repair: warning - cannot set blocksize on block device /dev/ataraid/d0p1: Invalid argument Phase 1 - find and verify superblock ... Phase 2 - using internal log - zero log ... xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion 'start_blk !=0 || *last_blk != start_blk' failed. Aborted. Hmmm, looks bad for my system :o Any chance left to get my system / data back or have I to do the mkfs again? ;-/ regards micha From owner-linux-xfs@oss.sgi.com Mon May 20 15:58:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KMwBnC029411 for ; Mon, 20 May 2002 15:58:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KMwAjZ029410 for linux-xfs-outgoing; Mon, 20 May 2002 15:58:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf10bis.bellsouth.net (mail010.mail.bellsouth.net [205.152.58.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KMw0nC029380 for ; Mon, 20 May 2002 15:58:01 -0700 Received: from taz ([66.156.2.161]) by imf10bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020520230012.PFMJ11666.imf10bis.bellsouth.net@taz>; Mon, 20 May 2002 19:00:12 -0400 Date: Mon, 20 May 2002 18:53:27 -0400 From: Greg Freemyer Subject: re[2]: xfsdump/xfsrestore questions. To: Austin Gonyou cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020520230012.PFMJ11666.imf10bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4KMw1nC029381 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> > If your data is 2:1 compressible, that is 7.2 GB/hr uncompressed. >> > That sounds like what you are getting on the windows box. >> > >> The issue here is that both jobs are using compression, but Arcserve >> 2000 on NT is performing faster than say, tar or xfsdump. The problem >> I've got with this though, is that it's so much longer there's got to be >> something I could tweak, either with xfsdump or the drive, so that's >> what prompted my query. Tape drives slow down excessively when they go from a streaming to a non-streaming situation. If your feedrate is borderline, then a small speed reduction in data throughput caused by the software, could have a huge impact on backup times. >> > What sort of disk-drive speed do you have on the xfs box? I'm sure >> > you know that RAID can drastically improve your disk-speed. >> 10K RPM 18GB Seagate at LVD(80mb/s) (yes..I know about theoretical max, >> etc.) >> The HP is at 10MB/s, I'd prefer to make it 20MB/s though..at least.(can >> set it in the SCSI bios I think? That drive should be plenty fast, IIRC about 100 GB/hr if no seeks are involved. For the HP, 7.2 GB/hr is only 2 MB/sec so the 10 MB/sec scsi bus should be fast enough unless your scsi bus is very busy doing other stuff. Are your tape drive and disks sharing the same controller? If so, the contention might be slowing things down just enough to kick you out of streaming. If so, you would think it would happen under windows too. Out of curiosity, if you do a xfsdump and send the output to /dev/null, what sort of time do you get? As I said before, the general goal is to overdrive the tape by 3x, so if the tape can do a full backup in 90 minutes when it is streaming, the above needs to finish within 30 minutes to be optimum. If the xfsdump time looks good, I would look into scsi-bus contention between disk and tape. BTW: I'm leaving for the day, and I won't be back on e-mail til wed., so maybe they above gives you something to chew on. Greg >> > BTW: With really high-end drives like SDLT (39 GB/hr compressed), >> > you basically have to design your whole storage system around their >> > required feed rate if you want them to be able to stream. >> > >> I'm quite aware of that..but thanks for the reminder. :) It's been a pain for me recently, so maybe I was a little pedantic. >> > Greg Freemyer >> > Internet Engineer >> > Deployment and Integration Specialist >> > Compaq ASE - Tru64 >> > Compaq Master ASE - SAN Architect >> > The Norcross Group >> > www.NorcrossGroup.com >> > >> > Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Mon May 20 16:51:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KNponC030261 for ; Mon, 20 May 2002 16:51:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KNpo9D030260 for linux-xfs-outgoing; Mon, 20 May 2002 16:51:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KNpinC030234 for ; Mon, 20 May 2002 16:51:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA50963; Mon, 20 May 2002 18:52:29 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA05899; Mon, 20 May 2002 18:52:29 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id SAA34939; Mon, 20 May 2002 18:52:28 -0500 (CDT) Message-ID: <3CE98C3B.6FD3E53E@sgi.com> Date: Mon, 20 May 2002 18:52:28 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Ernest Ashford CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump failure with ONSTREAM ADR50 drive References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Would you test the tape drive/tape to make sure it is writeble? Does the xfsump command still fails if you load a different tape. Also "mt stat" the drive to see what the output would be. A more detail output from the dump session would help; try -v5 and post the log. Thanks, Kihonge JN Ernest Ashford wrote: > Hello, > > I am running Mandrake 8.2 with the 1.1 xfs from SGI in a vanilla 2.4.18 > kernel. > If I try to do a xfsdump it fails with > > xfsdump: creating dump session media file 0 (media 0, file 0) > xfsdump: dumping ino map > xfsdump: drive_scsitape.c:1985: do_get_write_buf: Assertion > `contextp->dc_nextp < contextp->dc_recendp' failed. > Aborted > > I am attaching a error file I created from the output. Can you help? > > Thanks Ernest Ashford > > ------------------------------------------------------------------------ > Name: xfsdump.err > xfsdump.err Type: unspecified type (application/octet-stream) > Encoding: quoted-printable From owner-linux-xfs@oss.sgi.com Mon May 20 18:16:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L1GvnC032270 for ; Mon, 20 May 2002 18:16:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L1Gvoc032269 for linux-xfs-outgoing; Mon, 20 May 2002 18:16:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta02-srv.alltel.net (mta02.alltel.net [166.102.165.144]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L1GknC032241 for ; Mon, 20 May 2002 18:16:46 -0700 Received: from localhost3.localdomain ([166.102.225.151]) by mta02-srv.alltel.net with ESMTP id <20020521011734.DPPY352.mta02-srv.alltel.net@localhost3.localdomain> for ; Mon, 20 May 2002 20:17:34 -0500 Subject: XFS & Swusp (Software Suspend Project) From: Roger To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oqotcwvLFJqKVSbXcMBb" X-Mailer: Ximian Evolution 1.0.5-1mdk Date: 20 May 2002 21:16:57 -0400 Message-Id: <1021943822.3622.33.camel@localhost3.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-oqotcwvLFJqKVSbXcMBb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've done a quick search on the mailling list archive & FAQ and was amazed to find no mention of this. Has anybody tried making a patch for the "Software Suspend" project? http://falcon.sch.bme.hu/~seasons/linux/swsusp.html (you can also find this project on sourceforge.net Apperantly there is a patch for the rieserfs and you can find it here. http://fchabaud.free.fr/English/default.php3?COUNT=3D4&FILE0=3DTricks&FILE1= =3DLaptop&FILE2=3DSwsusp&FILE3=3DOptions http://fchabaud.free.fr/English/Tricks/Laptop/Swsusp/Options/patch-reiserfs= .gz It appears quite simple and I'm wondering if there's something i can do to help since i'm using XFS on this laptop. A Brief explanation of the "Software Suspend Project" (similar to Windows Hibernation): Name: swsusp Version: v8 Kernelver: 2.5.1 Status: 8 (usable)=20 Author: Gabor Kuti Description: Software Suspend using pretty near only high level routines Date: 20-DEC-2001 Descfile-URL: http://falcon.sch.bme.hu/~seasons/linux/swsusp.desc Download-URL: http://falcon.sch.bme.hu/~seasons/linux/swsusp-current.gz Homepage-URL: http://falcon.sch.bme.hu/~seasons/linux/swsusp.html Remark: _MUST_ be compiled by gcc-2.91.66, with 2.95.3 won't work Enable the possibilty of suspendig machine. It doesn't need APM. You may suspend your machine by either pressing Sysrq-d or with 'swsusp' or 'shutdown -z